Jump to content
  • Advertisement
Sign in to follow this  
Fire Lancer

Unity Supporting multiple graphics apis

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

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

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!