Quote:Original post by Dakiar
Well, the motivation for my question was, that I think direct3D 10 as it's of course called right now, makes such a significant difference that the design will be fundamentaly different.

Yea, this is correct. Unlike some previous API updates (ie D3D8 to D3D9), you really have to do some re-architecting to your interfaces. This is due to the numerous new features and design changes of D3D10. For example, just consider stream out. You wouldn't have that exposed right now, but you will need to in 10. All in all, it's just a lot of work.

This goes beyond the "if you have a hard time, you code isn't modular blah blah blah" stuff.

Do both, but start with D3D9 because you can at least implement and test that for now.

I read through the Feb. SDK stuff on it. They are changing the way you create and manage your front and back display buffers. They seem to be using some kind of swap chain interface for all if it now.

However, I then browsed through the various DX10 .h files, because the SDK does not mention many of the other interfaces. I found that a lot of stuff is not changing much, like the ID3DX10Mesh, ID3DX10Animationxxxx, and the many D3DX functions. So, the major changes seem to be with how you manage the display buffers, and the loss of many fixed function pipeline stuff (that I don't care about because I find shaders easier to use anyway).

So, I would continue to use DX9 for now, since you cannot test any of the DX10 stuff against your graphics hardware. Then when DX10 is offically released, you can see what the differences are. For now, it is way too sketchy.

Regarding abstracting D3D9/D3D10 - the word from the DX team seemed to be to treat them as seperate platforms. Despite the version number, D3D 10 is more than D3D 9+1. As Dustin pointed out - it gets difficult to abstract 9 and 10 and actually make good use of 10's potential.

Quote:Original post by DXnut
They are changing the way you create and manage your front and back display buffers. They seem to be using some kind of swap chain interface for all if it now.

It's called the "DirectX Graphics Infrastructure" - DXGI. It's a refactored and seperate entity now. The basic idea is that the low level stuff handled by DXGI rarely changes - look back at previous Direct3D releases and the same fundamentals are still there w.r.t. swap chains. Thus they moved them to a seperate foundation that they can then build multiple Direct3D's from (the PDC slides mention Direct3D "10+1" and "10+2" being based on DXGI).

Oh, and there are swap chain interfaces in D3D9 - but you aren't required to use them.

My personal opinion on using 9 vs 10...

Stick with Direct3D9 for now, but design any new code with D3D10 in mind - making it easier for you to upgrade that code when you do choose to move over to D3D10.

I'm doing a lot of D3D10 programming, and I love it - just as an API to program via it's cleaner and better than D3D9. My production code is still based on D3D9 though, and that won't change for the foreseeable future.

Jack

Quote:Original post by jollyjeffers
Regarding abstracting D3D9/D3D10 - the word from the DX team seemed to be to treat them as seperate platforms. Despite the version number, D3D 10 is more than D3D 9+1. As Dustin pointed out - it gets difficult to abstract 9 and 10 and actually make good use of 10's potential.

Hmm, by separate platforms, did they mean treat it like a completely separate codepath? Kinda like how you would separate Xbox and PS2, since they are so different?

I think you can make some abstractions, but have some type of NOT_SUPPORTED error code or something. So lets say we have Graphics::SetStreamOut() or whatever - the earlier versions (ie D3D9) could just bail out early on that. This would keep the bulk of the engine code in-tact, and just rely on different client code (which you would have anyways).

I suppose you could also use #ifdef things out. Creating a totally separate engine though could prove to be tons of extra coding, as well as a lot of maintainance.