porting from DX7 to DX9...advantages...?
Author
Hi all... I am quite new to this forum, and this is my 1st thread... looked round here but found not answer to my question...
I and some Friends are managing sources of a Free Game on the net, and now for the community we are wondering if it's worth porting from old DX7 already used by the game, to DX9...
The game is kinda 1st person role game, with a lot of graphics and SFXs... and I know we r already at limit with DX7 about fps...
before starting, as it is a huge work, and no1 pay us for doing it, we r asking ourselves where will we arrive, as we never have worked with DX9s...
I have some questions like,
Does DX9 allow lighting of objects by VCard Hardware ( of course if DX9 complaining )...actually is done by SW in our game...
And transformations...? if VCard supports them can it be done by HW, or DX9 just manage them doing itself by SW...
could we expect a nice speed improvement in rendering objects and so on...?
I have read DX9 Specs in the DX9 SDK...but these are doubts never explained in them...
so... need some more infos about what I could expect ( to use also as argument with my job mates ) in a such big work...
tnx for any answer/advice...
cheers
[R]ed
Well the DX7 interfaces do use DX9 internally if DX9 is installed. Remember the DX7 interfaces are just a contract, the implementation details may (and have) changed, even if the end results are the same.
If you do want to target hardware that was not around and not directly supported when DX7 was created, things like shader languages too - then there is a point to using the newer interfaces.
Anything you can shift from software to hardware you are very likely to get speedier results.
Whatever happens though, it could mean considerable work. If your frame-rate is acceptable then the old saying "if it's not broken, don't fix it" probably applies.
Also remember that you can ask DX if it supports DX9 device at the same time as DX7 - though I've never tried mixing DX7 and DX9 code perhaps it is possible? Perhaps something worth experimenting with (eg only using the DX9 interfaces where you want the extra functionality). I know Half Life 2 can use DX8 or DX9 paths, but I do not know if they are ever mixed.
If you do want to target hardware that was not around and not directly supported when DX7 was created, things like shader languages too - then there is a point to using the newer interfaces.
Anything you can shift from software to hardware you are very likely to get speedier results.
Whatever happens though, it could mean considerable work. If your frame-rate is acceptable then the old saying "if it's not broken, don't fix it" probably applies.
Also remember that you can ask DX if it supports DX9 device at the same time as DX7 - though I've never tried mixing DX7 and DX9 code perhaps it is possible? Perhaps something worth experimenting with (eg only using the DX9 interfaces where you want the extra functionality). I know Half Life 2 can use DX8 or DX9 paths, but I do not know if they are ever mixed.
Quote:Original post by Alex RedYes.
Does DX9 allow lighting of objects by VCard Hardware ( of course if DX9 complaining )...actually is done by SW in our game...
Quote:And transformations...? if VCard supports them can it be done by HW, or DX9 just manage them doing itself by SW...Yes.
Quote:could we expect a nice speed improvement in rendering objects and so on...?No, not by simply changing the DX7 functions to DX9 ones. Speed is less a question of which API you use and more a question of how you use it. DX9 would give you more flexibility in how you implement things (for example, you could use vertex shaders, which might be faster than the standard fixed function TnL on newer cards), but you need to start by figuring out which changes you want to make that will improve performance. Then decide whether those changes are going to require DX9.
Of course, one big advantage of DX9 is the toolkit - PIXfW will help you figure out where your app's time is being spent from a graphics point of view (other tools will too, like NVPerfHUD). Profile using tools like these, and profile your CPU time using something like VTune (or roll your own crude profiler for a quick general overview of things).
Author
tnx All...
well... our Frame rate is after an hard optimization work on code quite acceptable... but as we would like to make a more 'modern' graphics we considering the porting...
just to tell u, lighting and speculars is done in the code by SW, all rotations too, and not in a 'array-like' fashion like I have seen doing in DX9...
that why I have to understand if going making lighting and such things like movements under DX9 would be passed under HW ( of course if supported )or just performed by SW by DX9 itself, so we r sure to gain a lot of speed... or would be better to stay under DX7 and still improve the G Engine...
tnx...
[Edited by - Alex Red on May 27, 2005 7:48:07 AM]
well... our Frame rate is after an hard optimization work on code quite acceptable... but as we would like to make a more 'modern' graphics we considering the porting...
just to tell u, lighting and speculars is done in the code by SW, all rotations too, and not in a 'array-like' fashion like I have seen doing in DX9...
that why I have to understand if going making lighting and such things like movements under DX9 would be passed under HW ( of course if supported )or just performed by SW by DX9 itself, so we r sure to gain a lot of speed... or would be better to stay under DX7 and still improve the G Engine...
tnx...
[Edited by - Alex Red on May 27, 2005 7:48:07 AM]
Author
Tnx SuperPig... u wrote the meantime of me it seems... so have seen now...
well... I know the code of ur G Engine should be improved... I already studied about it, and I know we could improve... but, as I have to do it I am quite wondering if just a code rewrite is enough, or it will be better to change all once for all...latest code and latest interface...
u giving me Idea of this last option... ;)
tnx...
well... I know the code of ur G Engine should be improved... I already studied about it, and I know we could improve... but, as I have to do it I am quite wondering if just a code rewrite is enough, or it will be better to change all once for all...latest code and latest interface...
u giving me Idea of this last option... ;)
tnx...
As a general rule, optimizing the way you do things - algorithms and approaches - will always be a bigger win than code-tweaking and polishing.
Vertex transform and lighting has been available in hardware since before the GeForce 1 came out. Replacing your software TnL with hardware TnL is definitely going to help you - assuming that you're vertex-bound. Also look into the way you pass triangles to the hardware; today's cards favour huge numbers of triangles packed into a few draw calls, with minimal state changes between them. If you're doing something crazy like passing things to the card one triangle at a time, you want to change that too.
Vertex transform and lighting has been available in hardware since before the GeForce 1 came out. Replacing your software TnL with hardware TnL is definitely going to help you - assuming that you're vertex-bound. Also look into the way you pass triangles to the hardware; today's cards favour huge numbers of triangles packed into a few draw calls, with minimal state changes between them. If you're doing something crazy like passing things to the card one triangle at a time, you want to change that too.
Author
In fact... I am not the writer of original code...
and what I found is that these crazy things like passing single triangles with few vertices are already done...and that's for sure one of the problems...
that's why I think...if changing smthing... why not all...?
tnx for ur clear spcifications...
and what I found is that these crazy things like passing single triangles with few vertices are already done...and that's for sure one of the problems...
that's why I think...if changing smthing... why not all...?
tnx for ur clear spcifications...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
