Jump to content
  • Advertisement
Sign in to follow this  
skalco6

multi-api rendering engine question

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

Do you guys bother about making your rendering engine able to dynamically switch between APIs (OpenGL, DirectX, ...) at runtime? For exemple, using an abstract interface and instanciating an implementation through a dynamically loaded librabry. A multi-plateform rendering engine must absolutely support many different implementations, but I really think the appropriate one for a specific case should only be chosen at compile time. I'm asking because I just started the design of a new highly customizable renderer, making use of templated based policies and static polymorphism, which will make the whole system very compile-time dependent.

Share this post


Link to post
Share on other sites
Advertisement
I experimented with it, then decided it wasn't worth the effort. So long as you seperate your render code from your game code reasonably well, you can always change the implementation at compile time.

Being able to change renderers at runtime is a nice feature, but it's by no means nessecary. If need be, you can even release several versions of the .exe, one for each renderer.

Share this post


Link to post
Share on other sites
Well, sometimes it makes sense to compile in the apropriate renderer, as except for Windows, allmost all other platforms have only a single renderer available (OpenGL on Mac and Unix etc., D3D on XBox).

But most Windows programmers seem to want to choose whether to use D3D or OpenGL at runtime [grin].

On the other hand, the renderer often needs patching (to utilize better techniques, new drivers, etc.), and it is nice to be able just to patch the renderer DLL and not the whole game.

Share this post


Link to post
Share on other sites
Quote:
But most Windows programmers seem to want to choose whether to use D3D or OpenGL at runtime.


Of course Windows programmers do, but gamers shouldn't even be aware of that possible choice...

I think I'll stick with my static design idea for now and see if I can really come with something sweet.

Share this post


Link to post
Share on other sites
I took a look at this option when a classmate and I started designing an engine we're building for school. The problem with including multiple APIs is that you need to be fairly well versed in both APIs, otherwise, you'll run into design problems (assuming, of course, you actually bother to design first). We ultimately decided to stick to using one API, and will only ever support the one. If we can get the techniques in that we want, then it doesn't matter which API we go with; but, keeping to a single API reduces our development and testing times by half. That way, we can spend the extra time making sure everything works how we wanted it to.

Share this post


Link to post
Share on other sites
Dorvo, my point is ultimately to build a multi-plateform rendering library. As many different APIs are available on different plateforms (including consoles, of course), I can't stick with one API... (unless I decide to implement OpenGL on every plateform that doesn't support it...)

I can't avoid the imperative design phase (which I did many times in the past, as everyone...).

My aim is to build a simple and generic basic interface, and then extend it with enriched policies as required by different implementations.

Share this post


Link to post
Share on other sites
Quote:
Original post by skalco6
Dorvo, my point is ultimately to build a multi-plateform rendering library. As many different APIs are available on different plateforms (including consoles, of course), I can't stick with one API... (unless I decide to implement OpenGL on every plateform that doesn't support it...)

I can't avoid the imperative design phase (which I did many times in the past, as everyone...).

My aim is to build a simple and generic basic interface, and then extend it with enriched policies as required by different implementations.


If that's the case, then check out the source code for Irrlicht and Ogre. Both of those have implemented OpenGL and DirectX, and should give you a good idea how they went about implementing multiple graphics APIs.

Share this post


Link to post
Share on other sites
Quote:
Original post by Dorvo
If that's the case, then check out the source code for Irrlicht and Ogre. Both of those have implemented OpenGL and DirectX, and should give you a good idea how they went about implementing multiple graphics APIs.


However, both of them implement it dynamically, Ogre through renderer DLLs, and IrrLicht through compiled in renderers.
I can't think offhand of an engine that statically compiles in only one API (and also supports multiple APIs).

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
However, both of them implement it dynamically, Ogre through renderer DLLs, and IrrLicht through compiled in renderers.
I can't think offhand of an engine that statically compiles in only one API (and also supports multiple APIs).


Even if they were to dynamically load DLLs, they should still give a good idea how to go about getting multiple graphics APIs working.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!