Archived

This topic is now archived and is closed to further replies.

Ratterbox

OpenGL AND DirectX Graphics

Recommended Posts

How easy is it to implement a graphics handler to handle BOTH OpenGL AND DirectX Graphics, and would it be worth the bother. I have experience in both API, but was wondering if anybody thought that it would be worth going to all the trouble to create an engine to handle both, and how easy it would actually be??

Share this post


Link to post
Share on other sites
hm.. the question is: if you already got it working with opengl, why do d3d? i can see a reason to do it the other way round, because you want it to run on more than just windows machines. how hard this is would most likely depend on how good your architecture is and how well you seperated api specific code from the rest.

Share this post


Link to post
Share on other sites
Unless it's something you're really ready to take under, you're better off just sticking to one API. The way I do it is I have a factory class, renderer interface, the specific renderers in seperate dlls. The API dlls inherit their functions from renderer interface (virtual voids). The factory get's a pointer to the api's renderer class inside the dll. I create a new instance of the renderer interface and make it equal the pointer that the factory just got from the dll. Then I'm able to do things like rInterface->SetFog(FM_EXP, 30, 210, rgbStruct) and they will tell the specified renderer what to do.

I hope that almost sort of cleared up what you can do to achieve api independence. It's a big undertaking and I'm still implementing things like vertex/index buffers lol

James Simmons
MindEngine Development
http://medev.sourceforge.net

[edited by - neurokaotix on July 28, 2003 7:31:56 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Trienco
hm.. the question is: if you already got it working with opengl, why do d3d?


D3D - specifically an older version, like 7 - is more widely supported on older video cards. It''s not an issue for hardcore gamers - who have the latest cards, which support OpenGL fine - but the casual user doesn''t upgrade very often (if at all) so they may well be using a TNT or a Rage type card, on which D3D support is generally better than OpenGL.



Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3

Share this post


Link to post
Share on other sites
quote:
Original post by Trienco
hm.. the question is: if you already got it working with opengl, why do d3d? i can see a reason to do it the other way round, because you want it to run on more than just windows machines. how hard this is would most likely depend on how good your architecture is and how well you seperated api specific code from the rest.


It''s not nessassaraly about choosing one over the other it''s about good design. With a good design you can do things like update your openGL code to version 1.4 or 1.5 and implement new features with out having to tear everything apart and re-write it all.

The goal of writing a renderer class which can either use D3d or OpenGL is to make a single graphics engine that you can maintain with out having to go in and modify all your game code. A new OpenGL api''s released or D3d API is released and with a few minimal code changes in your renderer class and maybe 10 or so lines in your game and now your game can support a new feature or two and you didn''t have to do much work to achieve this goal.

The second major goal of this is to have a re-useable graphics engine that can be used in any of your future projects instead of having to write OpenGL or D3d specific game code constantly. The ability to use D3d or OpenGL at your whim is just an added benefit of this design.

So basically it comes down to this:

If you''ve got a call in your GAME code (note I didn''t say engine code) that calls either a direct3d or openGL function DIRECTLY then your not making a game engine your creating a hacked togeather game. Propper abstraction of D3d and OpenGL into a rendering subsystem will give you the ease of re-use, the ability to make future modifications with out effecting large parts of your core game code, and the ability to change API''s on the fly to accomidate the end user and give them the best preformance they can have in the game.

So why would you want to do this? Well I think it''s pretty self explanatory don''t you?

Share this post


Link to post
Share on other sites
There are some things that d3d can''t do and can put a cap on your gfx algos. I had this happen with multitexturing units. In gl the algo worked because I had crossbar while d3d didn''t. This probably happens in reverse also but I''m unaware where gl might be lacking. If you do decide to implement both apis then you can either expose both apis and let user choose which features to use like you see in windowing frameworks or you can expose a common gfx layer and dumb down to lowest common denominator. At least this way the game looks about the same with either api. I don''t think it''s trivial to implement both apis and I would recommend against it unless you can explain to yourself why this is a good reason in the first place. You might find that by choosing gl you can avoid d3d altogether as was in my case.

Forged3D world editor

Share this post


Link to post
Share on other sites
If you already know both api''s then i dont think its too difficult to implement an api independent rendering library. I think its a good idea to do this, as you learn a lot of good design principles, and it helps hilight the differences between the api''s.
Plus, if you ever decide to write a software renderer, then you can run all your old programs that you wrote for hardware accelerated systems with no rewrite....

If you are going to choose just one api, I would stick to D3D, because eventually you might want to do things such as video capture, avi playback, etc which you are probably going to need to use directshow for anyway.. (not to mention user input, sound, networking etc..)

Share this post


Link to post
Share on other sites
If I was you I would scroll through the GameDev articles. There are some articles on using a render interface. Its a good thing to do I think for it gives you the code you need if you wish to make the engine open to user mods and plugins. Also have a look at Ogre and XEngine : ogre.sourceforge.net , xengine.sourceforge.net . They both implant both APIs.

Share this post


Link to post
Share on other sites