Sign in to follow this  

DLL/Lib or single project?

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

When you guys are working on your game engines are you breaking them down into library's or going as far as putting them into a DLL? Or just single projects with a single exe?

Share this post


Link to post
Share on other sites
For initial development, I would say just keep it simple- make it a single project and a single exe.

Later, when the project is mature, you can always change it to use libs/dlls. It only takes a few minutes to make the change.

Share this post


Link to post
Share on other sites
If you put it in a DLL, it could take longer to load, plus all the functions you are exporting for client use will have to exist - none of them can be inlined. That could lead to poor performance. DLLs are also harder to use as opposed to static libraries or directly included code. In addition to that, DLLs also get their own memory area, and if the DLL is unloaded all that memory gets freed instantly, which could lead to debugging problems (if your EXE tries to access memory that just got freed).

My engine used to have three modules:
- Launcher EXE
- Engine DLL
- Client DLL

Launcher would create an instance of the engine (linked to Engine DLL), then find game information file in the current directory with the same name as itself, read that game info file to find out the name of Client DLL. Then load client DLL with LoadLibrary and call the instance creation handler, to create an instance of the client, passing it the pointer to the initialized engine. The Client DLL would contain all the game-specific code, like GUI handlers and handlers for actors and levels. It also had one global handler for global events. The event mechanism was a simple OnEvent function that objects who derived from EventTarget had. It received one argument, Event, which was a structure with event ID and four event parameters. And that's pretty much it.

Now my engine is a static library, and it includes a special Game class, that acts as a link between Client and Engine. So client derives its own class from Game class and overrides virtual functions to handle global game events. To handle GUI events, client would derive its own class from the Screen class, and handle events by overloading virtual functions, just like in MFC. Same goes for the levels - to handle level events (like OnRender) client would derive their own class from Map class and overload virtuals. Same goes for AI - client would derive a class from Actor class and overload virtuals to handle events. Now my engine is also fully object oriented, so if I made it a DLL, there would be a ton of space wasted for function names in the export section, in addition to all of those functions not having a chance for being inlined.

Share this post


Link to post
Share on other sites
Depending on the complexity of the engine you are going to develop, it might not be that trivial to separate the code into parts later.

Putting systems and things together that belong together could be very valuable early on. At the very least it aids in avoiding tight coupling, allows reuse and leads therefor to a better design.

I'd break the engine up into static libs encapsulating the functionality at different levels/tiers.

Share this post


Link to post
Share on other sites
Quote:
Original post by ValMan
If you put it in a DLL, it could take longer to load, plus all the functions you are exporting for client use will have to exist - none of them can be inlined.

That is inaccurate. Yes, DLLs might increase load times, but if your options are to (1) have one big EXE or (2) one EXE and a couple of DLLs - it won't hurt the loading time that much (it will be just a fraction of a second). On the other hand - DLLs, in most cases, reduce the build times.

Another thing, inline functions can be exported from DLL. Read more about it here. Yes, it's Microsoft specific (I guess it means, that it only works on VC), but it can be done!

Quote:
Original post by ValMan
That could lead to poor performance. DLLs are also harder to use as opposed to static libraries or directly included code. In addition to that, DLLs also get their own memory area, and if the DLL is unloaded all that memory gets freed instantly, which could lead to debugging problems (if your EXE tries to access memory that just got freed).

I don't think that using DLLs is any harder than using LIBs. All you have to do, is to read once about how it works - when you understand that - it's actually quite easy to use them.
I'm not sure why you mention the memory... If EXE tries to access memory that is already deallocated - you have a serious bug in your code, and the program will, most likely, crash. It doesn't really matter how the memory got deallocated - it is still your bug that you have to fix.

Share this post


Link to post
Share on other sites

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