Jump to content
  • Advertisement
Sign in to follow this  
Dakiar

DirectX 10 to use or not to use?

This topic is 4487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I can't decide!, it's a very big difference and it only have vista support. What do you people here think, is it time to take the step and start our new game projects in 10, or is it too early?

Share this post


Link to post
Share on other sites
Advertisement
If you write your project well enough with a nice modular architecture you should be able to write it with DirectX 9 and then easily port it to DirectX 10. When it comes to starting a new project, switching graphics APIs shouldn't be a problem if you write it well enough.

Dave

Share this post


Link to post
Share on other sites
Just to clarify, as it stands now it's Direct3D10 not DirectX10.
When designing game engines or any type of software you should have some kind of abstraction layer. This is so that you don't have to spend countless hours recoding your renderer, at least this way you can always have a basic engine ready to transform to new technologies.

Direct3D10 is just going to work on Vista yes but it's a powerful API and introduces a whole new era of rendering and games.

I hope this helps.
Take care.

Share this post


Link to post
Share on other sites
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. As many of my friends works on large game companies, I know that they're having the same problem. The step to Direct3D 10 is just such a big one, that it's too much work to have both a 9 and 10 version of the game or engine you're developing. However as I respect many people on gameDev I wanted to ask your opinion about it.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
I'd also suggest sticking with DX9 for now, but I'd also suggest sticking to what DX10 will offer. DX10 has no fixed pipeline, so learn vertex and pixel shaders from the start, not the fixed pipeline. Most people have a hard time with TextureStageStates (roughly equal to pixel shader 1.1), so you may find pixel shaders simpler than the fixed pixel processing. Most vertex processing is trivial. Once you've got a basic shader up, you can learn lighting and creating reflection vectors (for cubemap lookups) at your own pace, worry about it later, or whatever. Use the ID3DXEffect system. It makes using shaders quite easy and painless.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!