Sign in to follow this  
Dakiar

DirectX 10 to use or not to use?

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
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
Quote:
Original post by circlesoft
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?
Yes, thats the impression I got.

Quote:
Original post by circlesoft
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).
Yup, it can be done like this. If you go for a data-driven effects-like approach you could just reject any effects that aren't supported. But it effectively moves the problem further down the path - rather than the core engine code dealing with it, it's the effect-writers and/or artists that will deal with it.

Quote:
Original post by circlesoft
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.
Agreed, can't really think of a particularly good solution to this sort of hybrid idea. I've been giving it a bit of thought lately and everything I come up with has at least one weakness or annoying complication [lol]

Cheers,
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by sipickles
DX10?
Well, technically, there is no DirectX 10 - just Direct3D 10 [wink]

Quote:
Original post by sipickles
Crikey! I'm still trying to get my head round DX9, HLSL, C++, Boost, Python....
hehe, thats the fun part of the IT industry - never stays still for long [lol] Although, if you're learning DX9/HLSL you don't really need to worry about D3D10 just yet...

Cheers,
Jack

Share this post


Link to post
Share on other sites
1) A big part of the decision about whether or not to target D3D10 exclusively for the Windows PC version of your game depends on a)when you're planning on releasing it, and b)who your target audience/market is.

When Vista ships, there probably won't be many (if any) graphics cards which support the minimum required feature set of D3D10 (remember, there are no caps...), and those that do will be pretty much "high end".

If most of your target audience/market are the hardcore who always have the latest and greatest of everything (including Vista) and want graphics that'll push their hardware (e.g. the hardcore end of the PC first person shooter market), there's far more incentive to go for the newer API that'll get them the coolest graphics features to show off their liquid-nitrogen-cooled overclocked beast machines (and shiny new D3D10 capable graphics cards).

If you're targetting the most "casual" end of the casual market today, then you should probably be targetting Windows 98 and D3D6 level hardware using the D3D7 API as a minimum spec [wink].

That's the scale, it depends where your game falls on it. IMO it'll be quite a while (in years) before D3D10 capable hardware covers even half of the scale between high-end and casual (look at history to guess time frames). Adoption of Vista itself as a gaming platform might be a bit quicker than usual if people take well to the new gaming features and incentives.

I'd say it's very likely that many of the top-tier PC specialist developers (FPS ones in particular) are planning if not already working on D3D10 versions of their renderers now, though they're unlikely to be scrapping their D3D9/OpenGL codebases just yet.



2) Another thing to consider is whether your game actually needs D3D10 features and/or whether you have the (development, art, time) resources available to exploit those features.

If your game design (or current game or engine) can be achieved easily with D3D9 or even D3D8 level features, then using the D3D10 API just for the sake of using something new doesn't seem worth it just yet, particularly if you already have any code using D3D9.

As has already been mentioned (I think), I'd keep the D3D10 spec in mind when designing your game and its engine - if only to keep your design platform neutral (it's a similar process when designing a cross platform Xbox/PS2/PC game or engine - you have to keep them all in mind).



3) If you have tons of high end ideas (and the resources to implement them) that really aren't practical in D3D9, then you have more of an incentive to target D3D10; If they're exclusive, killer-app features that really do show off D3D10, then you should probably be talking to IHVs and MS about OEM and other incentives [smile].

Until there is D3D10 hardware publically available, or you're working very closely with MS and/or an IHV, you'll be using the reference rasterizer - this is going to limit what you're going to be able to do with D3D10 - unless your game can practically be recorded as movies and played back non-interactively.



4) As well as a few specific enhancements to D3D9, Vista also has other gaming features.
If you already have a renderer codebase based on D3D9 (a new game shouldn't mean a new renderer, just some improvements and tidying of an existing one), then one thing I would advise is making your game aware of and take advantage of those new Vista features.



5) Watch out for the DirectX developer day presentations at GDC this year - IIRC there's a presentation from Relic about their experiences with making their engine D3D10. The presentation will no doubt be available somewhere online soon enough.



6) Entirely hypothetical plan... If I were personally starting from scratch right now on a mid-hardcorecasualness-scale PC game (e.g. arcade racing) due for release in the next 1-2 years and with limited manpower, where I intended on using the engine again, releasing a sequel, and/or releasing a D3D10 version in the future:

I'd design from the top-down, with platform neutral higher-level parts of the graphics engine with D3D10 features in mind. But I'd implement the lower-level parts of the engine using D3D9. The whole thing would be aware of Vista and XP specific features to improve user experience. TBH, most of the ""interesting" things would be either higher level than the code that talked to D3D or in FX/HLSL files.

Once the game/engine was released (or more manpower made available), I'd start work on a D3D10 port of the engine (which if designed right, really shouldn't be at all difficult IME), first just to the level of the D3D9 one (having debugged/working, real-world "test" code driving the engine makes life a hell of a lot easier when porting - particularly if still using the reference rasterizer). IMO it should take weeks if not days if everything is done right and you're used to cross-platform or cross-API development.

The longer, but fun part would be adding the new D3D10 specific effects/features. Summary: until I have D3D10 hardware, I'd personally prefer to start from a working D3D9 base, port to D3D10, add D3D10 features on top, then tune those features when the hardware appears.


</lots-o-waffle>

Share this post


Link to post
Share on other sites
Quote:
Original post by S1CA
When Vista ships, there probably won't be many (if any) graphics cards which support the minimum required feature set of D3D10 (remember, there are no caps...), and those that do will be pretty much "high end".

If most of your target audience/market are the hardcore who always have the latest and greatest of everything (including Vista) and want graphics that'll push their hardware (e.g. the hardcore end of the PC first person shooter market), there's far more incentive to go for the newer API that'll get them the coolest graphics features to show off their liquid-nitrogen-cooled overclocked beast machines (and shiny new D3D10 capable graphics cards).

I think that the high-profile launch titles that they already have contracted to be Vista-specific will really help to get D3D10 rolling. Namely, Halo 2 has such a large following that it should boost both hardware and software sales by a good bit.

Quote:
If you're targetting the most "casual" end of the casual market today, then you should probably be targetting Windows 98 and D3D6 level hardware using the D3D7 API as a minimum spec [wink].

[crying] I dunno what's up with Half-Life 2 lately...it won't play on my PII with an S3 Virge anymore hehe

Share this post


Link to post
Share on other sites
I think the obvious solution is to use D3D 6. It's completely 100% deprecated, and there's no way it can get any more deprecated, so you always know where you stand!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this