Jump to content
  • Advertisement
Sign in to follow this  
xorjesus

Programming with multiple graphic apis, whats are your styles?

This topic is 5404 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

Recently I've taken my gdi project and expanded it to both directx and opengl. I currently have a very large, bloated, and yet efficient project set up. All 3 variations of the game are in one project. The game switches between gdi/directx/opengl through commenting out a line and uncommenting another at compile time, and through variables during run time. I'm quite proud of it, but as I raise my goals higher and higher, I'll of course be needing to work on a team in the future, and readability is very important. Well that's what I'm told :) Do you think its wiser to make three different projects of essentially the same game, if your working with multiple graphic apis? Or should you try and keep it all in the same project by using the methods I mentioned above? 80% of the game is generic game programming code, and 20% is OS and graphics api code. Would you guys and gals suggest?

p.s. How do you do indents in this thing?

Share this post


Link to post
Share on other sites
Advertisement
It sounds like you are abstrating the graphics very well, have you considered putting the abstration in its own library and seperating it from the system in its entirety? Possiably have the implementations in there own .dll, and have the system call which one at runtime.

Share this post


Link to post
Share on other sites
make one single library and use #ifdefs based on the base defines in each library (though i couldn't tell you what they are, look at top of headers usually). use these #ifdefs to sort out what compiles and what is left out.

Share this post


Link to post
Share on other sites
What I would do is define an abstract base class defining your rendering interface, I assume you have some simple wrapper calls already set up if you're using the 3 APIs already. Once you have the base class derive out three sub-classes for GDI, OGL, and DX. Then move all those api-specific elements into the derived classes.

The neat thing about this is that you can then define a pointer to the base class as your renderer, and using that, dynamically instantiate a rendering class at run time. You can choose which API gets started up during each run of the game; there won't be 3 essentially different versions, but one unified version. This is how most(all?) games work which allow you to choose which rendering technology is used as a setting.

I'm doing something similar now with my software renderer. While the actuall graphic routines are my own and the same across all platforms, I've derived out sub-classes to contain the API specific initialization and final blitting. It works great, this is the type of thing that C++ (or OOP, more generally) was designed to do.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravyne
What I would do is define an abstract base class defining your rendering interface, I assume you have some simple wrapper calls already set up if you're using the 3 APIs already. Once you have the base class derive out three sub-classes for GDI, OGL, and DX. Then move all those api-specific elements into the derived classes.

The neat thing about this is that you can then define a pointer to the base class as your renderer, and using that, dynamically instantiate a rendering class at run time. You can choose which API gets started up during each run of the game; there won't be 3 essentially different versions, but one unified version. This is how most(all?) games work which allow you to choose which rendering technology is used as a setting.

I'm doing something similar now with my software renderer. While the actuall graphic routines are my own and the same across all platforms, I've derived out sub-classes to contain the API specific initialization and final blitting. It works great, this is the type of thing that C++ (or OOP, more generally) was designed to do.


but you'd still have to link to OGL and DX. this could make a .exe quite large. not that it's a bad way to implement, but if you're going to do it right you'll need to make sure that OGL is not invloved in DX runs at all and vice versa.

Share this post


Link to post
Share on other sites
What i've done:

I also implemented an abstract renderer interface and but the implementation for DX8, DX9 or OpenGL in a seperate DLL. On runtime i can switch the renderer (unloads dll, loads new) and start up a new instance.

Share this post


Link to post
Share on other sites
Quote:
have you considered putting the abstration in its own library and seperating it from the system in its entirety?

Yes I have, but while I'm still learning the apis, its easier to keep it in source. That way I dont have to rebuild the library everytime I want to to make a change to the sub-renderer and then compile. It's a great idea for alpha,beta and release though.



Wow Ravyne, my system is very close to yours already. Though there is no Abstract Base Class, I have a pointer whose type is that of the currently selected api. After I get my apis a little more organized, I will design and implement a nice abstract class. All the apis are indeed wrapped up into my own simple design scheme. Anist does bring up a good point, and i see why I must put the abstraction in its own library for beta/release builds



Share this post


Link to post
Share on other sites
Quote:
Original post by anist
but you'd still have to link to OGL and DX. this could make a .exe quite large. not that it's a bad way to implement, but if you're going to do it right you'll need to make sure that OGL is not invloved in DX runs at all and vice versa.


Yes, absolutely that would be the way to go. Sorry I neglected to point that out in the first place. You'd want to seperate out the sub-classes into DLLs.

Thanks for pointing that out Anist

Share this post


Link to post
Share on other sites
I abstract the APIs to compile-time pure abstractions which are injected as template parameters to types which build more high-level functionality, that way there is no runtime overhead if you want to use one API for your application. So, for instance, you can make a series of Direct3D types that meet the pure abstraction and a set of OpenGL ones, then just change what type you pass to the template to switch between them. As well, if you need to dynamically switch between Direct3D and OpenGL runtime you just use a type which matches the pure abstraction that internally has a pointer to types which are the afformentioned pure abstractions encapsulated into a type which is derived from an abstract base class.

This way, if you don't need to switch between APIs at runtime, you have optimal code (no need for runtime polymorphism at all, no virtual functions), whereas if you want to switch between opengl and direct3d at runtime, you just change the type passed to the template and don't have to make any changes to high-level code. Since they both match the pure abstraction, they can be used in the same template to construct higher-level game concepts without having to change any code whatsoever. I'm developing an audio API I'm going to be uploading within the next week that uses this concept if anyone cares.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!