We noticed that some of our DDS created times ago under DX8 failed to load under DX9. After dumped the DDS content, we think to notice that some contents are written differently. For instance, dwPitchOrLinearSize was always correcly stored under DX8 whereas under DX9 it seems it's allowed to pass 0 (for the same texture in the same conditions). dwFlags also seems to be different. In the opposite, when I create a DDS under DX9 and try to load it under texture tool of DX8, it returns with the error "Unexpected file format". This is going to be extremely problematic for applications distribution. I cannot even imagine a user complaining of an error at startup such as "DDS file format error". Currently, we use RGB888 or ARGB8888. The texture stays in this format if the user setuped 24 bits format and the card allows it. Otherwhise a conversion is made on-the-fly to match the required format (D3DX toolkit seems to do the job very well for us). However, for other formats like ARGB4444, it can work under DX8 but not DX9 (or the opposite). All of this is not very encouraging and clearly get me nervous since our deadline is coming. Finally, the question : is there any known problems regarding DDS file format between DirectX version ? Izidor.
[DDS] compatibility break between DX8 and DX9 ?
1 posts
• Page 1 of 1
- Windows XP
- Windows XP
- matlab
- MS OFFICE OUTLOOK
- javascript
- scanner
- forth
- palm
- FLASH
- Win32 Programming
Jump to:
- 1. Terrain shows up all white when splatting
I am writing a renderer using the "splatting" technique of texturing. I have hit a problem when blending the second texture onto the terrain. This causes the terrain to be rendered all in pure white, which as you can imagine, looks something horrific. What am I doing wrong? I am using the multitexturing implementation of splatting discussed at cbloom.com. My hardware is an Athlon 2000+ and GeForce4 MX integrated graphics, which should be adequate for the multitexturing :) Is it my framebuffer, or a render state, or what? Thanks for any advice on this Chris Forbes XXXX@XXXXX.COM - 2. Display static 2D DXFs in Direct3D
What would be the best way to display a 2D DXF in a rendered 3D environment? Should I use GDI to make a texture, then put that on a box? Or perhaps use DirectX7 2D functions to write to a surface? device.DrawPrimitives(PrimitiveType.LineList, 0, ....... is too slow... Any help would be greatly appreciated. Thanks - 3. texture blending in one stage possible ?
hi! I am making terrain engine. I use 2 stage texture for texture blending . ( for exam, grass texture -> sand texture for different material area boundary ) smoothly changing from grass texture -> sand texture. ( sorry for short english ) but I want to know any method to blend textures in one texture stage exists. is it possible to blend textures in one stage ? if exists , let me know how to .. thanks. - 4. ID3DXAnimationController
Does ID3DXAnimationController contain pointers to the bone matrices. Because the SDK says SetTime updates the bone matrices. However, ID3DXAnimationController does not provide any method to get these updated bones. So I'm guessing it has pointers to the D3DXFRAME::TransformationMatrix member. Also, is it correct to say that SetTime simply interpolates the bones based on the time, but it doesn't do the propogation multiplications? From the SDK sample it appears I'm correct since UpdateFrameMatrices does the propogation: if (m_pAnimController != NULL) m_pAnimController->SetTime(m_pAnimController->GetTime() + m_fElapsedTime); UpdateFrameMatrices(m_pFrameRoot, &matWorld); - 5. D3DXMESHCONTAINER
I'm wondering why there is a next pointer pNextMeshContainer in the D3DXMESHCONTAINER structure. Basically, I'm not understanding why it is necessary to have a linked list of mesh containers per frame node. Or am i wrong and the next pointer points to a mesh container in a different frame node?
Next
[DDS] compatibility break between DX8 and DX9 ?
by Izidor » Mon, 01 Sep 2003 01:44:35 GMT
Similar Threads:
1.FX 5600 DX8.1 compatibility question
Hi, I'm about to buy a FX 5600 or 5700 (or maybe the ATI 9600 equivalent) to have a VS/PS 2 card. The seller tolds me I have to install dx9 to have it working properly. But I'm working with dx8.1 and I'm not ready to change all my work to dx9. Is he true? I think it must work with any dx version, isn't it? maybe depending on a driver to install? thanks pb
2.Performance factors between DX8 and DX9?
I seem to recall someone publishes some caveats regarding performance when
moving from DX8 to DX9.
I'm interested because my VB/IB rendering of a skinned/animated 47000 poly
mesh has gone from 160fps+ to 50...
Anybody recall something like that?
WTH
3.EnumAdapterModes changes (DX8.1 to DX9)
I'm looking into the changes made to enumadaptermodes in DX9, and I'm wondering wether I'm misunderstanding the SDK help, or if it's just wrong. In the Converting to DX9 article, under "EnumAdapterModes Changes", it says the following: quote: -------------------------------------------------------------------------------- The application specifies a pixel format and the enumeration is restricted to those display modes that exactly match the format. The following is a list of the allowed formats: D3DFMT_X8R8G8B8 D3DFMT_A8R8G8B8 D3DFMT_A2B10G10R10 D3DFMT_X1R5G5B5 D3DFMT_A1R5G5B5 D3DFMT_R5G6B5 -------------------------------------------------------------------------------- Hang on.. Display modes that match Alpha formats? Surely that can't be right? Shouldn't the list consist solely of D3DFMT_X8R8G8B8, X1R5G5B5 and R5G6B5? After all, those are the only allowable display formats, right? But hang on, the sdk continues: quote: -------------------------------------------------------------------------------- Enumeration is equivalent for alpha and nonalpha versions of the same format. The returned FORMAT member of D3DDISPLAYMODE will always be filled with the same format supplied by the application. -------------------------------------------------------------------------------- Ah. So... If I supply the function with A8R8G8B8, it'll return modes supporting X8R8G8B8? Let's run a quick test.. No, it doesn't. EnumAdapterModes fails when supplying it with A8R8G8B8, but it succeeds when supplying it X8R8G8B8. Oh yeah, another weird thing in that same article: quote: -------------------------------------------------------------------------------- This method treats 565 and 555 as equivalent, and returns the correct version in the Format. -------------------------------------------------------------------------------- Nope. Also not true. Enumerating with 565 works, but enumerating with x1R5G5B5 fails. So it does -not- treat them as equivalent. So... What is up with that? The Enumeration is apparently -not- equivalent for alpha and nonalpha versions of the same format, nor is 565 equivalent to 555. So why does the SDK claim it is? And why does it list alpha formats as possible display formats? Anyone?
I've managed to pretty much convert my app to DX9 as far as the geometry renders correctly, but the texture coordinates seem to be wrong. The correct textures are complety skewed and tiled across the polys and the vertices seem to have been coloured. At the moment it looks as if my scene has a patch work effect. I'm using custom vertex shaders with fixed function pixel shaders. I'm assuming it is a texture/sampler state problem. It all work fine under DX8, so the core data should be correct, I did have to setup an FVF as the DX8 version didn't. Sorry this is a bit vague, but it seems like the sort of thing other people may have encountered. Oh yeah, non textured objects render fine.
5.Converted test app is slower in DX9 than in DX8
Hi there, I've been working in DX8 up to now but am currently moving to DX9. I have therefore tried to convert a test application to DX9 but discovered that it's now much slower than before. I moved from about 150 fps to about 70, which is obviously not what I expected... The application calls D3DXCreateMeshFVF and sets the vertices and indices. It them simply rotates the mesh, so it's not especially advanced code. The scene has one light and specular highlights are enabled. It seems to be the call to ID3DXBaseMesh::DrawSubset that is slower. I'm really puzzled over this and have no idea what I have done wrong. I did the conversion by replacing "8" by "9" in all interface and function names (and some other smaller modifications) abd everything seems to work. It's just that it's slow. I would be really grateful for any advice on this issue. I'm happy to post some code if that helps, just tell me. BTW, my old DX8 program still executes with the same speed as before, eventhough I have now installed the new DirectX version. Thus it's not a driver problem. My system is a 733 MHz PIII, GeForce 2 GTS, Windows XP Pro. Thanks in advance, Emil
6. 2D game - which way - DX8 or DX9
8. Is it possible to specify that my code is to use Version DX8 on a DX9 installation?
1 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 3 guest