• ### Announcements

#### Archived

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

## Recommended Posts

##### Share on other sites
Don''t even mess around with DLL''s. They aren''t very stable.

##### Share on other sites
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 on other sites
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 on other sites
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 on other sites
how 3d studio max does to load all windows ressources and function from an unknow dll ? its very powerfull, but seem to be very hard.

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

##### Share on other sites
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 on other sites
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 on other sites
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 on other sites
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 on other sites
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 on other sites
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 on other sites
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 functionbool initPlugins(){   // parse the config file, ensure required plugins are loaded,   // load optional plugins   ...   char *audioName = ConfigGetValue("IAudio");   loadAudio(audioName);   return true;}// global NewAudio functionIAudio *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 on other sites
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 on other sites
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

• ### Forum Statistics

• Total Topics
627708
• Total Posts
2978730

• 21
• 14
• 12
• 22
• 35