Sign in to follow this  

plugin - based engine

This topic is 3727 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 all, I' m going to organize my engine and I' d like to build it with a plugin architecture... I' ve read the souce of Nebula Device 2 and Ogre, but I don' t understand how their plugin systems are based ( in particular nebula device ).. I think that my window and rendering classes should be based as plugin... Please, could you help me to build a plugin architecture from the ground ? Just some ideas... Thanks ! Bye.

Share this post


Link to post
Share on other sites
You are going to have to be a bit more specific about what you want this plugin system to accomplish...

In general, I am not very fond of these overly plugin-based engines. I can see using plugins for render effects, AI behaviours, etc. but I don't see using it for platform managers and renderers.

My reasoning is that at compile time, you already know the target platform, and you should know the supported rendering APIs, so you may as well just compile them in, and not bother with all the problems resulting from DLLs in a Window's environment. In the rare case that you need to add a new renderer after your product launches, distributing a new renderer plugin is really not any easier than distributing an updated binary.

Share this post


Link to post
Share on other sites
That's all a matter of taste ...

In my system (an editor/engine combination) a plug-in (better termed a "module" here) is a runtime-loadable provider of Extensions. An Extension provides some informations like a name, a human readable description, an optional revision. It is of a specific type and is to be registered with the belonging Extension::Registry. Those registries allow to enumerate all attached extensions and to find them by name. Concrete types of Extension are PlugIn (yes, a PlugIn provides Extensions and is itself one), IOFormat, CompressionFormat, Graphics (a graphics sub-system), Audio (sub-system for sound), Shader, Effect, and so on.

Yep, I have some higher level stuff loaded from modules, e.g. some sub-systems (but not a window manager or the like). The reasoning for this is that I don't distribute libraries that are closely related to hardware, like OpenGL or OpenAL. On the other hand I can't rely that they are all installed (on Windows, Linux, Mac OS X; not to speak of different library versions that may force to have several implementations of e.g. renderers). So I link those libraries hard with the modules and try to load the modules from inside the application. If the libaries aren't installed then loading the plug-in will fail since the DyLd can't resolve all of the symbols, but the application itself will run. Other libraries may be included in the distribution (e.g. freetype) and hence need not be loaded lazily.

As said, the managing unit inside a module is a PlugIn (or several PlugIns). Just after loading the module the PlugIn becomes instantiated and registers self. With the registration the Registry requests the PlugIn to register all of its managed Extensions. After that it iterates all already earlier registered PlugIns and requests each one to complete their Extension registration if still necessary. This way I resolve any inter-extension dependency that is scattered among several modules. Extensions that remain unregistered are, well, not useable then.

Another aspect is that due to the dual usage as editor/engine some amount of stuff makes no sense to be loaded at all or at least until specific situations are encountered (like in-level editing). So post-loading plug-ins help to reduce memory consumption and start-up time.

The backside is truly that some code must be written to manage all this.

Share this post


Link to post
Share on other sites
Hi, so do you think an engine should not be based on plugins ?
The problem is that if i don't use plugins who use the engine can't enhance and add more renderers without editing the code...

Share this post


Link to post
Share on other sites
Quote:
Original post by jwein
Hi, so do you think an engine should not be based on plugins ?

Err, whom do you meant, swiftcoder or me??

However, none of both of us has denied to use plug-ins. We just differ a bit in the definition where the borderline should be between what is sensefully to be loaded as plug-in and what not.

Quote:
Original post by jwein
The problem is that if i don't use plugins who use the engine can't enhance and add more renderers without editing the code...

Enhancing the engine by adding a renderer may be a big task at all. But plug-ins are not the only way: Small enhancements are more common, and those are often reachable by scripting. But nevertheless in such cases also scripts need to be bound to effective places in order to fulfil a specific kind of functionality, and hence can be understood as plug-ins (but not necessarily as DSO modules).

Share this post


Link to post
Share on other sites
Hi, I meant everybody :)
I understand your positions, so I try to be a bit more specific:

1) Do you suggest to use plugins for the "create window" classes ?
I don't think they should be dynamic ( there will be a class for every platform ), so should i use something like polymorphic templates ?

2) Do you suggest to usue plugins for the rendering classes ?
I think they' ll be static ones, because there will be a renderer for every platform...

Thanks for the answer, they are very important for me :)

Share this post


Link to post
Share on other sites
Quote:
Original post by jwein
1) Do you suggest to use plugins for the "create window" classes ?
I don't think they should be dynamic ( there will be a class for every platform ), so should i use something like polymorphic templates ?

Here I don't suggest to use plug-ins. It is most likely to have just a single and defined window system per platform (w/ the exception of Mac OS X). I suggest to use selective compilation and linking here, or to use a 3rd party abstraction (SDL or the like).

Quote:
Original post by jwein
2) Do you suggest to usue plugins for the rendering classes ?
I think they' ll be static ones, because there will be a renderer for every platform...

The answer is ... it depends. What do you exactly mean with "rendering classes"? Sorry for my nitpicking ;) E.g. in my engine, Graphics is a graphics sub-system. It consists of GfxMedia (an abstraction of render targets with the ability of multiple render layers simply called "views"), RenderJob to allow sorting into a render queue before actually rendering, GfxRenderer to transfer RenderJobs into API calls, and some more stuff. From these GfxMedia and GfxRenderer are API dependent. They are provided by a plug-in lazily loaded from a module: e.g. for OpenGL is libArtyGL the module, containing a plug-in that provides GLGraphics as a concrete sub-class of Graphics. By using GLGraphics as the active Graphics sub-system, you automatically get GLMedia instances from it when asking for a concrete GfxMedia (runtime polymorphism). To be precise, there is additionally a selective compilation under the hoods: You get a GLXMedia if running linux/X11, AGLMedia if running Mac OS X Carbon, WGLMedia if running windows. Other classes (e.g. RenderJob) are platform and graphics API independent and hence part of the main binary, i.e. not provided by a plug-in.

In early releases often rendering is implemented into mesh classes or the like. Such a concept has some drawbacks, and hence I avoid it. But if you meant that with the term "the rendering classes" then I suggest you to write them API independent, so that they also can be linked ito the main application.

EDIT: Stuff like effects or shaders (can also be understood as "rendering classes") may be implemented so close to a graphics API that providing them by plug-ins loaded from modules would be fine.

[Edited by - haegarr on November 3, 2007 2:14:44 PM]

Share this post


Link to post
Share on other sites
For rendering classes I mean classes which define some api-dependent function like drawtriangle() drawvertices() etc...
Shouldn't a window class be a plugin ?
Users could write a plugin if a new platform has been released without seeing the source code...
Thanks for the answers. Bye !

Share this post


Link to post
Share on other sites
Quote:
Original post by jwein
For rendering classes I mean classes which define some api-dependent function like drawtriangle() drawvertices() etc...

Besides the fact that "drawtriangle()" would never lead to an efficient implementation: Yes, IMHO that is functionality that could/should be pluggable. (It is the equivalent of the GfxRenderer I mentioned above.) The reasoning is, as also already said, to decouple the application start from the requirement of the availability of libraries. It is _not_ necessarily needed for the runtime decision what external graphics API to use, as swiftcoder has mentioned.

Quote:
Original post by jwein
Shouldn't a window class be a plugin ?

IMHO no. But perhaps it is a question of what one understands as "plug-in". I personally think of a piece of compiled code lazily loadable from a library as "module". In my project I have dozens of small test and demo applications. They all mainly consist of a main() and sometimes of a derived Application object. Depending on their needs, the executables are linked dynamically with libCore and libArty and ... Now libArty itself provides the Video sub-system (which is OS dependend), the Input sub-system (which is OS dependend), and other stuff. Since I don't think that anybody will extend Arty on that low level, I link the OS dependend stuff hard into the library (the makefile does the job here). So I get a libArty for Linux if compiling on my main development environment, but a libArty suitable for Mac OS X when compiling on an Apple Mac.

Nevertheless, libArty provides OS independend access to the said sub-systems by using appropriate wrappers. This allows all of the mentioned small test and demo applications to be absolutely the same on all platforms. However, if an applications _knows_ that it is running on e.g. Linux, then it is able to use the wrapped stuff also with their native types! It becomes OS dependent by this step, of course.

Now, after that many words ;), I come to the point. While letting the Video and Input (and other) base functionality still reside in libArty (so that an application can get access to it), it is absolutely legal to externalize their concrete instances into another library. E.g. the X11Input and X11Video stuff can be baked into the libArtyOS module on linux, and the QuartzVideo and CarbonInput stuff can be baked into the libArtyOS module on Mac OS. Notice please that the library name is the same. Then the libArty would be linked against the libArtyOS, whatever it contains. When deploying the application, it is equipped with exactly 1 libArtyOS that has to match the running OS, of course.

That would open the possibilities you mentioned, but I would not define this as a plug-in! It is just an external module. (No sense to exhange it during runtime, for example.) However, as swiftcoder said whether it is worth to "bother with all the problems resulting from DLLs in a Window's environment" (or others) is your personal choice.

Quote:
Original post by jwein
Users could write a plugin if a new platform has been released without seeing the source code...

Writing plug-ins ever requires the knowledge of the API of your engine. It doesn't require to look at your implementation code. That is exactly what makes the essentials of an SDK: Give the developer the headers (so s/he knows the API), and the binaries. Giving him/her documentation and code examples makes him/her happy. No need to give him/her your implementation code.

Share this post


Link to post
Share on other sites

This topic is 3727 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this