Archived

This topic is now archived and is closed to further replies.

FxMazter

DLL loading for an engine?

Recommended Posts

FxMazter    164
Hi I''ve been thinking about how to implement the loading of DLL''s - "Systems" - in my engine, but can''t come to a sollution yet :/ I have thought of two ways of implementing this: 1.) Making a DLLManager, which will load DLL''s and store an Interface loaded from that DLL in a Map. This will be a singleton. I find that this sollution is the simpliest for me to do, but somehow I don''t like this too much at all... Feels wrong saving all different Interfaces in one Manager... 2.) Making a class DLLLoader, from which other classes that want to be able to load Systems will need to inherit from. So If my BaseApplication wants to be able to load all different systems like MemoryManagerSystem or RenderingSystem it will need to derive from the DLLLoader and then be able to load different interfaces from DLL''s. This way it feels like I''m storing the Interfaces at the "right" places. (Feels more right that the SceneManager loads the TextureManager than the BaseApplication Loading the TextureManager...) But on the other hand it feels more complicated and it feels like it will be a hard time figuring from where to get a particualar interface etc... (is it in the SceneManager or is that interface stored in the BaseApplication...) Or maybe only the BaseApplication should be able to load DLL''s ? How would you guys implement a DLL loading system? Thank you all!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Don''t even mess around with DLL''s. They aren''t very stable.

Share this post


Link to post
Share on other sites
jonnii    122
wtf are you talking about? in what way arent dll''s stable?

As for an implementation it all depends what language your using. If your using C++ i guess the easiest way to do it is to have a standard interface for all the dlls (for example a function called StartDLL or something). That way you can execute that particular function and the dll can do whatever it has to do to get itself into the system, like adding a plugin to a manager...

Share this post


Link to post
Share on other sites
FxMazter    164
Yup, i'm using c++

And yes, every dll will have the same interface... with a CreateInterface function which will return a pointer to the wanted interface.

The thing is that my game engine will mostly consist of dll's. I will use the dll version of a main function and use the Core of the engine from a dll.

And all systems will be in dlls.

The RenderingSystem, the SceneManager, the TextureManager... everything will be in Dll's ... so I need a nice system for loading the dll's, and I'm not sure how to inplement it :/

thx!

(and of course dll's is a programmers friedn^^ ... unless you want to recompile everything for a simple change heh...)

[edited by - FxMazter on January 4, 2004 5:51:44 PM]

Share this post


Link to post
Share on other sites
jamessharpe    497
One way to do it would be to use an interface similar to COM. Look for some introduction to writing COM objects and use the general sturcture to write your own system. Of course you could just use COM, but that wouldn''t be very portable and would require registration of the dll''s. Also you probably don''t need to make the dll''s available through the COM system as you probably won''t be reusing the componenets in another app.

James

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
you''re over-engineering! you''ll be accesing the pointers in a local context anyway, so you''re not really "storing" anything.

Share this post


Link to post
Share on other sites
FxMazter    164
Nah, I don''t think i''m over engineering :/

I say it''s better to plan everything ahead, than making the project with crappy planning and in the middle of the project getting to the conclusion that the structure of the engine is too crappy to continue on it...

Anyway, I have already implemented the 1.) sollution. I made a SystemEnumerator that searches for any modules and then adds them to a list, while my SystemManager loads dlls from the SystemEnumerator. It''s all gonna work with interfaces, so the user may later change the MemoryManager or any other system to work the way they want... unless they change the interface

thx anyway guys, though I''m still interested how you guys have done this if you have made a system similar to this.

thx

Share this post


Link to post
Share on other sites
Aldacron    4544
I think you're overengineering, too. This is something you couls accomplish with one function call:

Init_Engine();

Put it in a class if it fits, but otherwise it's overkill. One function tucked away in a single source file, or in a lib, and you're good to go. The function loads all of the required DLLs one-by-one and you're good to go.


Unless I'm missing something and you're trying to architect a plugin system. Loading DLLs from a configuration script, for example. Even then there's no need to inherit from a DLLLoader interface.

[edited by - aldacron on January 5, 2004 11:47:47 AM]

Share this post


Link to post
Share on other sites
FxMazter    164
eh, k... now I got two against me , maybe I am overengineering a little then.

And yes, it is going to be a plugin system. The whole gameengine will consist of plugins. I was thinking of having maybe like 20 or 30 interfaces, covering the SceeneGraph, MemoryManager, LoggingSystem, the Renderer etc.

And the user of my engine will be able to modify the actual behaviour of the SceneGraph or the LoggingSystem by changing the classes, as long as the interfaces still apply.

And I am thinking of having some EditorTool to Enable and Disable different Systems, appart from the Core Systems like the MemoryManager which are mandatory. (some kind of script file that will be loaded...)

And I will also have a InitEngine function that will init all systems that are added...

So basically, I want to have a PreInit phase where I load the systems and retrieve the interfaces and then I actually Init the the systems from the InitEngin or whatever...

[edited by - FxMazter on January 5, 2004 12:16:30 PM]

[edited by - FxMazter on January 5, 2004 12:18:29 PM]

Share this post


Link to post
Share on other sites
Vich    142
Why don''t you just compile into .lib/.a libraries. These act like a dll, but are compiled within the executable. It allows you to work in the same way as a dll (keeping different pieces of code seperated) but less easier to hack (dll calls could be intercepted, hacked, etc; dlls would make your game easily cheatable/patchable).

"My basic needs in life are food, love and a C++ compiler"
[Project AlterNova] [Novanet]

Share this post


Link to post
Share on other sites
Stephen R    721
quote:
Original post by Vich
Why don''t you just compile into .lib/.a libraries. These act like a dll, but are compiled within the executable. It allows you to work in the same way as a dll (keeping different pieces of code seperated) but less easier to hack (dll calls could be intercepted, hacked, etc; dlls would make your game easily cheatable/patchable).



Because then he only has to change and redistribute a single DLL as opposed to the whole app.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
there is a difference between "planning ahead" and "over-engineering".

thinking up concepts like a "dll loader" is (in *most* cases) definitely overkill. what about a "function caller" or a "pointer storer" or a "variable holder"... you get the point.

Share this post


Link to post
Share on other sites
Aldacron    4544
What I would do is make abstract interfaces (pure virtual classes) for each class I want pluggable. Each DLL would be required to provide a common getInstance() function. Then I would use a config file (lua script, ini file, text file, whatever) to configure which interfaces point to which DLL. When the dlls are loaded, you point the appropriate functions (newRenderer(), for example) to the newInstance funciton of the DLL.

So at the very least you would only need ti call one function from the game to load the DLLs and set up the function pointers, and possible a mechanism for switching out the dlls at runtime. There''s no need to make a DLLManager class, really. The publically available functions could be global (or wrapped in a namespace) and all of the dll handles could be local static variables in that source module.

Of course, you could go further and have all of the pluggable interfaces inherit from a common base class (IPluggable for example), but unless your needs are super generic, that wouldn''t make much sense. For example, you would never load a Scenegraph in place of a Renderer. So it makes much better sense to have all of the newInstance functions return a pointer to the appropriate interface (IRenderer, IScengraph) rather than an IPluggable.

If your game does not require all of the interfaces to be loaded, then the only complexity you have to deal with is deciding which are required, and guarding against trying to get an instance of an interface that has not been loaded. It''s a safe bet that an IRenderer and an IScengraph will be required, but an IAudio might not be. So you might want something like this:


typedef IAudio *(* NEWAUDIO)();
static HANDLE s_audioDLL;
static NEWAUDIO s_newAudio = NULL;

static void loadAudio(const char *name)
{
s_audioDLL = LoadLibrary(name);
s_newAudio = GetProcAddress(audioDLL, "newInstance");
}

// global InitPlugIns function

bool initPlugins()
{
// parse the config file, ensure required plugins are loaded,

// load optional plugins

...
char *audioName = ConfigGetValue("IAudio");
loadAudio(audioName);
return true;
}

// global NewAudio function

IAudio *NewAudio()
{
if(NULL != s_newAudio)
return s_newAudio();
}


Simple. And again, a more generic, flexible system could be designed - but if you don''t really need a more flexible or generic system then it''s overkill.

Share this post


Link to post
Share on other sites
evolutional    1393
Depends what systems are likely to change. In my game engine, the DLL''d systems are Game and Render (and soon to be sound if I get round to doing sound, heh). The rest of them are bundled in the exe as I deemed that making them pluggable had no real advantage.

Share this post


Link to post
Share on other sites
FxMazter    164
Thank you Aldacron, thats somewhat the kind of posts I was hoping for

And currently my system works similar to the one you described, but it all happens in my SystemManager.

I have looked at the OGRE engine and also noticed that they have their dllloading functions global as you described it. So that may be a good way of doing it

But hence, I have already made the SystemManager and the SystemEnumerator... so I think I''m gonna let it be as it is, heh

Thank you guys for the posts anyway

Share this post


Link to post
Share on other sites