Supporting multiple graphics apis
Some time ago I asked a simeler question http://www.gamedev.net/community/forums/topic.asp?topic_id=506645. Based on the answers I got there Ive now implemented a fairly fully featured object orientated system with support for D3D9 and D3D10.
The actaul implementations are implemented in dlls (Direct3D9.dll, and Direct3D10.dll), which I load dynamically with LoadLibrary (which one depending on which the user selected in options/or the highest supported version by default), do a bunch of checks to help stop bad things from happening (version, debug, etc) before finally calling "IGraphics *CreateGraphics(Size2<unsigned> size, HWND window)" which is a exported function with the C calling convention (cause it easy to use GetProcAddress on).
This all works very nicely, with the implementation hidden away in a dll and well defined behaivours for the diffrent interfaces.
However recently I saw several people complaining about other libraries (I think ORGE3D was a major one) which used interfaces in a simeler way resulting in almost all graphics calls by a program requireing a virtual call. Having thaught about it I still really cannot see another way of implementing more than one graphics system in a given app...Is there some method that avoids the virtual calls for graphics methods but still allows a game to support more than one graphics backend?
You can avoid the virtual calls, but only by selecting the backend at compile-time or link-time.
If you want the ability to choose the backend at runtime, you will need virtual calls.
Alternatively, you can compile your app for all cases and choose which app to launch at runtime.
If you want the ability to choose the backend at runtime, you will need virtual calls.
Alternatively, you can compile your app for all cases and choose which app to launch at runtime.
Last time I looked at Ogre they had a prolific use of virtual functions, naturally if you want to select the backend at runtime then runtime dispatch is necessary but it can get to a point at which you're losing a lot of cycles just to make these calls, like when you end up having three virtual calls to identify a texture, another couple in order to bind it, and so on.
The higher you build your abstraction then the fewer virtual calls you need to have, but at the cost of reduced fine grain control over lower level resources.
[Edited by - dmatter on May 21, 2009 1:12:10 PM]
The higher you build your abstraction then the fewer virtual calls you need to have, but at the cost of reduced fine grain control over lower level resources.
[Edited by - dmatter on May 21, 2009 1:12:10 PM]
I think one of the big complaints going around lately has been about how Ogre makes heavy use of dynamic polymorphism with all their resources. Things like textures having a common base class and then deriving an openGL texture or a directx texture and having all the interfaces virtual. Things like this could have been avoided by using static polymorphism. It's all about the templates for this sort of thing so that things can be resolved at compile time. Just have to be smart with it so you don't get template code bloat.
Well currently the virtual calls are mainly just across the interfaces, which are not used within the implementations themselves (ie the sprite implementation calls the texture implementation methods directly).
So I guess its as good as it can be in that case. Since the gam/app doesnt know about the implementations at all beyond being given the name of a dll to load.
So I guess its as good as it can be in that case. Since the gam/app doesnt know about the implementations at all beyond being given the name of a dll to load.
You could avoid some virtual calls by abstracting things in a different way.
For example if you wanted setting render states to be non virtual you can make your engines render state setting calls just update some API neutral data structure, and only do the actual setting when you get to a draw call (which is virtual).
For example if you wanted setting render states to be non virtual you can make your engines render state setting calls just update some API neutral data structure, and only do the actual setting when you get to a draw call (which is virtual).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement