Jump to content

  • Log In with Google      Sign In   
  • Create Account


Updating engine from dx9 to dx11


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Slig Commando   Members   -  Reputation: 334

Like
0Likes
Like

Posted 29 September 2012 - 09:42 PM

I have been building a home grown engine for a few years now just as a hobby using dx9, so not working on it full time. So my question is, eventually I will need to update to directx11, and was just curious if someone with experience could enlighten me how difficult this could be. Really just changing how you use the d3ddevice right? I am already using a programmable pipeline, so that wont be an issue, but are there any other big challenges involved? Thanks.

Sponsor:

#2 Narf the Mouse   Members   -  Reputation: 318

Like
0Likes
Like

Posted 29 September 2012 - 10:26 PM

Make sure all your effect files designate row_major - Matrices (float4x4) are row major by default in DX9, and column major (matrix) in DX10 and DX11.

More generally speaking, my own game engine seems to be working fine just wrapping DX9, D10 and DX11 in genericized classes. Ideally, only the smallest possible part of the foundation of your engine should even know it's using DirectX, or which version.

If you've built it along good "separation of concerns" lines, you should be able to swap out that small subset. You could even put it in a DLL - DX9API.dll, DX10API.dll, DX11API.dll. Then, when/if you get your hands on DX12, or OpenGL, or whatever, you can swap in a DX12API.dll, OpenGLAPI.dll (not familiar with OpenGL version numbers) or, I dunno, AsYetUninventedConsoleAPI.dll.

In short, there's no reason even so much as your Mesh class/struct should have a clue what you're using - Leave that to your VertexBuffer and IndexBuffer classes.

#3 Hodgman   Moderators   -  Reputation: 27590

Like
0Likes
Like

Posted 30 September 2012 - 03:06 AM

Two of the biggest differences to me are -
* DX9 vertex declarations are forgiving in that they can be slightly incorrect and still work. DX11 input layouts on the other hand need to exactly match your vertex shader input structure. This means that if the same mesh is drawn using 2 shaders, you may need 2 input layouts.
* DX11 render states are immutable objects. E.g. You can't just set "depth test = less" at any time, instead you've got to create a complete depth-stencil-state object ahead of time. If porting a DX9 engine, you might need to create a bunch of large tables/maps of state objects in advance.

Make sure all your effect files designate row_major - Matrices (float4x4) are row major by default in DX9, and column major (matrix) in DX10 and DX11.

I don't know about D3DX math, but the HLSL compiler hasn't changed in that column_major is the default float4x4 layout in DX9 too.

#4 kubera   Members   -  Reputation: 860

Like
1Likes
Like

Posted 30 September 2012 - 06:24 AM

Please consider not using D3DX tools, they are obsolete.
Now are available more modern elements, XNAMath and D3DCompileXX,DLL.

#5 mhagain   Crossbones+   -  Reputation: 7422

Like
1Likes
Like

Posted 30 September 2012 - 06:57 AM

A third major difference I'd highlight is use of constant buffers instead of free-standing constants in HLSL code. Depending how you've currently got things set up that may result in a good deal of re-thinking, re-organizing and re-writing.

There are also many smaller, more subtle differences throughout the two versions, such as the differences between Lock and Map, and these can sometimes trip you up.

Around the release of D3D10 the major GPU vendors published sets of slides outlining advice and trouble-spots to look out for, and these are still quite relevant to D3D11 and worth reading. Here's a good overview: http://developer.download.nvidia.com/presentations/2008/GDC/GDC08-D3DDay-Performance.pdf

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#6 MJP   Moderators   -  Reputation: 10226

Like
1Likes
Like

Posted 30 September 2012 - 10:09 AM

The initial port probably won't be too hard for you. It's not too hard to spend a week or two and get a DX9 renderer working on DX11. What's harder is actually making it run fast (or faster), and integrating the new functionality that DX11 offers you. Constant buffers are usually the biggest performance problem for a quick and dirty port, since using them to emulate DX9 constant registers can actually be slower than doing the same thing in DX9. Past that you may need a lot of re-writing for things like handling structured buffers instead of just textures everywhere, having texturs/buffers bound to all shader stages, changing shaders to use integer ops or more robust branching/indexing, and so on.

Edited by MJP, 30 September 2012 - 10:09 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS