• Advertisement
Sign in to follow this  

Implementing renderer DLL

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

Hi everyone, What's the most common way of connecting to a renderer DLL - implementing renderer as an inproc COM-server and obtaining an interface pointer, or simply loading a DLL with LoadLibrary? I've just spent quite some time on OGRE engine site, but didn't find the answer ;) Thank you

Share this post


Link to post
Share on other sites
Advertisement
In the situation where you have control over the compilation environment for both the renderer DLL and the host program, most of the benefits of COM are mooted.

Share this post


Link to post
Share on other sites
Suppose that my renderer is a huge class hierarchy consisting of dozens of classes. When creating a traditional DLL, I have to include all of those base classes headers into the host application. Isn't it much better to use a COM server and just show the very tip of an iceberg to the host application?

Share this post


Link to post
Share on other sites

Hi,

You could use an abstract interface class with the DLL. This would make the implementation invisible which would keep your program cleaner. I don't really see a reason tu use COM etc.

Of course, you'll need to manage the DLL version.

Just my 1 cent,

Cheers!

Share this post


Link to post
Share on other sites
Do you even need a renderer DLL? Are you planning to support multiple renderers?

Share this post


Link to post
Share on other sites
Quote:
Original post by tokaplan
Suppose that my renderer is a huge class hierarchy consisting of dozens of classes. When creating a traditional DLL, I have to include all of those base classes headers into the host application. Isn't it much better to use a COM server and just show the very tip of an iceberg to the host application?

The only "tip" you need to be showing to the host application is the pure virtual class interface to whatever class you're exporting. There's no need to show it the entire class hierarchy. There's no difference in this respect between COM and traditional DLLs.

Share this post


Link to post
Share on other sites
Ogre's plugin works by using LoadLibrary and then GetProcAddress just two functions - the start function and the stop function. When start is called, Ogre uses the pluggable factory pattern to register the renderer, and also to provide some basic information about the renderer such as a name. Once the renderer factory is registered the host can create an instance of the renderer by using a standard interface. The stop function performs memory cleanup in preparation for the host to shut down.

Share this post


Link to post
Share on other sites
The question is, why do you want to make the renderer a DLL? First, a monolithic renderer is A Bad Idea, because porting it will be an equally monolithic task, and few different renderers will be made anyway. A thin wrapper is the way to go (abstract buffer creation over OGL or D3D), with all the non-directly-api-interacting remnants of the monolithic renderer implemented on top of that, so porting the renderer would be a relatively simple task. Now for another argument: Why pay for the renderer indirection, anyway? If you're working on a console platform, you won't have dynamic linking to begin with; if you're working on PCs, that thin layer of behavior can be basically implemented with OGL or D3D, so choose one and stick with it, avoiding the virtual function call overhead (Yes, I know how many 'but it's not that significant' arguments are gonna pop to mind, but in games, any cycle saved is A Good Thing).

Share this post


Link to post
Share on other sites
Quote:
Original post by Starfox
The question is, why do you want to make the renderer a DLL? First, a monolithic renderer is A Bad Idea, because porting it will be an equally monolithic task, and few different renderers will be made anyway. A thin wrapper is the way to go (abstract buffer creation over OGL or D3D), with all the non-directly-api-interacting remnants of the monolithic renderer implemented on top of that, so porting the renderer would be a relatively simple task. Now for another argument: Why pay for the renderer indirection, anyway? If you're working on a console platform, you won't have dynamic linking to begin with; if you're working on PCs, that thin layer of behavior can be basically implemented with OGL or D3D, so choose one and stick with it, avoiding the virtual function call overhead (Yes, I know how many 'but it's not that significant' arguments are gonna pop to mind, but in games, any cycle saved is A Good Thing).
Well you already mentioned at the start but personally it's better to keep all the api dependent code behind some interface (it's much easier to change from virtual to inlined than the other way [wink]) than sprinkle it all around, it's an absolute nightmare to port/patch/refactor if it's everywhere.

If you want to get rid off the overhead of virtual calls (why the phuck are people advising smart pointers?) and if it really is down to the ground unification of apis then it can be implemented without any inheritance and mostly inlined easily [smile].

Share this post


Link to post
Share on other sites
My point was, you won't really find it that useful to do D3D renderer AND OpenGL Renderer. Instead of making a virtual renderer interface, just make it concrete, and use #ifdef-s. On PC, go OGL (or D3D, if you prefer), on other platforms go with their respective APIs. Pete Isensee mentioned a similar point in one of his talks (can't remember which). While he recommended making the PC renderer virtual and implement separate D3D9 and D3D10, and making the console renderers concrete from the start, IMO I'd make the PC version concrete too (OGL, and use optional extensions for the SM4 part instead of a total rewrite. Or wait for OGGL3 :D).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement