multi-api rendering engine question
Author
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.
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.
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.
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.
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.
Author
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.
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.
Author
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.
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.
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.
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).
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
