Skip to main content
GameDev.net gamedev.net
🔒 Locked

Game Engine DLL Confusion

Started by Chacha Jul 10, 2004 at 11:27 PM 7 replies 6.4k views
Original Post
Chacha
Chacha
Hey everyone, I have been researching into DLL design for my new game engine, but I have run into a design confusion about the use of DLLs. I want the engine specific code of my game engine to be in a DLL, and the game specific code to be in the EXE. I know there are other ways of going about this (such as engine in EXE and game in DLL) but I am sticking with this method because it seems logical to me, and it is simple enough for my first game engine. But I am confused, what is the point of using a DLL in this case? From what I've learned, DLLs can be either statically linked to or dynamically linked to. In my case, I don't see any reason to dynamically load the DLL (unless I use multiple APIs, but I'm not), and so that leaves me with the other option of statically loading the DLL. But if I statically load the DLL, then why use a DLL in the first place? Wouldn't I be better off just using a static LIB for my engine in this case? So basicly, I am asking two things: 1) What are the benefits of dynamically loading the engine DLL over statically loading it? Is there any real point of loading the engine DLL dynamically in my case? 2) If I don't need to dynamically load my engine DLL, then I will statically load it. But in this case, why not simply use a static LIB? Are there any advantages and/or disadvantages of using a DLL statically VS using a static LIB? Any comments, suggestions and advice would be greatly appreciated. Thanks in advance.
helix
helix
The engine I am building has both the engine and the game code as dlls. This way I can load whichever version I want (for debugging, upgrading, etc) of both the engine and the game code. This also leaves room for the user to easily mod the game code, etc. Plus I simply like the modular design (which fits into the OOP paradigm I've grown to love). Another benefit could be for tools. With the engine as a dll instead of being married to your game exe, you could write a program to build your world (or whatever) that uses your game engine so "what you see is what you get". Then, whenever you update your engine, you could just drop in the dll and update the editor. So by decoupling your engine, you could potentially increase your productivity in the long run.

But if you aren't looking for or don't need such a robust design, just statically link it.

I'm sure there are other features and drawbacks, but these are the main reasons I chose this design for my engine.
mikeman
mikeman
First of all,you can't statically link to a DLL(I think).DLL stands for "dynamic-link library".The advantage for dynamic linking is that,if you want to upgrade your engine,you have just to rebuild the engine DLL.With static linking,you'll have to rebuild the whole project,game and engine.
Chacha
Chacha
Quote:
Original post by mikeman
First of all, you can't statically link to a DLL (I think).

No, what I meant by 'statically linking to a DLL' is loading the DLL at loadtime (by linking to the DLL's LIB file).
mikeman
mikeman
Quote:
Original post by Chacha
Quote:
Original post by mikeman
First of all, you can't statically link to a DLL (I think).

No, what I meant by 'statically linking to a DLL' is loading the DLL at loadtime (by linking to the DLL's LIB file).


Ok,but dynamic linking at loadtime is not the same as statically linking to a LIB.As I said,static linking requires you to build the whole project again.Loadtime dynamic linking allows you to only rebuild the DLL,and use the exact same executable.For instance,the 0.2 version of DLL does not support shaders,so your game runs without them.You build the 0.3 that supports shaders,and without making a single change in the .exe,your game runs with per-pixel lighting or whatever.With a static LIB,you would have to rebuild the lib source,and then rebuild the game source.
Now,dynamic linking at runtime has the extra advantage that you can free the DLL when you don't need it anymore,but since it contains the engine,I don't think it's an issue.I would go for the DLL(loadtime or runtime) solution,since it's more flexible.
markr
markr
You are suffering from what is known as "Gamedev.net" chronic DLL-itis.

Unfortunately it is often incurable, as people affected seem to have their judgement clouded to the point that they cannot be convinced, by any means, that DLLs are not important or desirable mostly.

Make the engine by the simplest method you can first (i.e. as an EXE), then if you have a really good reason to do so, convert it into a DLL.

Make it work, then worry about DLLs. Really.

Mark
Chacha
Chacha
Quote:
Original post by mikeman
Quote:
Original post by Chacha
Quote:
Original post by mikeman
First of all, you can't statically link to a DLL (I think).

No, what I meant by 'statically linking to a DLL' is loading the DLL at loadtime (by linking to the DLL's LIB file).


Ok,but dynamic linking at loadtime is not the same as statically linking to a LIB.As I said,static linking requires you to build the whole project again.Loadtime dynamic linking allows you to only rebuild the DLL,and use the exact same executable.For instance,the 0.2 version of DLL does not support shaders,so your game runs without them.You build the 0.3 that supports shaders,and without making a single change in the .exe,your game runs with per-pixel lighting or whatever.With a static LIB,you would have to rebuild the lib source,and then rebuild the game source.
Now,dynamic linking at runtime has the extra advantage that you can free the DLL when you don't need it anymore,but since it contains the engine,I don't think it's an issue.I would go for the DLL(loadtime or runtime) solution,since it's more flexible.

Thankyou, that helps a lot. You said that you can change a DLL without having to recompile the client EXE, no matter whether the DLL is linked to at load-time or run-time. But, when loading a DLL at load-time, you are linking to the LIB file. And if you change a DLL, then you're also changing the LIB file. So how is it possible that you don't have to recompile the EXE when the DLL is changed (I'm talking about load-time linking only)?
mikeman
mikeman
Yes,when you use a DLL at loadtime,you have to link to LIB.However,that LIB does not contain the actual code,but info about where the functions are in the DLL.If you rename a function,add a new one or change the parameter list,you have to rebuild the project and link it to the new LIB.
However,if you don't change the name of the functions or the parameters,and you just change the code of the functions,it will be fine.
Chacha
Chacha
markr - That's a really good suggestion you have there. And I'll try my best to cure myself!

mikeman - Ok, I understand now. Thanks a lot.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.