Archived

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

dave

What part Do DLLs play in game engines?

Recommended Posts

Unless I missed a lot recently, it works out like this:

Ok, just in case you don't even know what a DLL is, it's a sort of program module if you will, you specify in your program to use the DLL at run time, and the you can make calls to functions that are defined in it. Libraries work like this too, except they are included into the program, their code being added to it, requiring a recompile of the whole thing when changes are needed. Both are useful for rapid addition of functionality, such as physics libraries, and graphics libraries.

DLLs are useful for several reasons. Primarily, they take some of the code out of your executables. This is for situations where you want to modify a function without changing input or outputs, then you can just recompile the DLL with the modifications without having to recompile a monster-sized executable. This is also useful in the situation you need to patch a problem in the game, you may be able to do it by only changing a small DLL. Also, since the DLL is maintained by the OS, it can be written in any language as far as I know, so a DLL written in BASIC will work with a program in C++. It's possible that some libraries may be able to work like this too, but I don't know.

I'm sure there's other legitimate reasons, but these are the only one I can think of as opposed to using libraries.

----------------------------------------------------------
You know, I might as well go ahead and say I can't fix the problem... because that's when I figure out how.

[edited by - Zealot on March 29, 2004 3:18:16 PM]

Share this post


Link to post
Share on other sites
Another example is plugins. Lots of programs have the ability to load plugins which add more features to the program. This is usually done through DLLs. Basically, a program can be made to load functions from a DLL at run-time if they follow a certain structure. If you know the structure that the program expects, you can write a plugin (DLL) with functions that conform to that structure. The main program can then load in your DLL at run-time and execute the code you provided in those functions.

Share this post


Link to post
Share on other sites
Using DLLs is frequently overrated. A game engine need not be a DLL at all, and it may be convenient for it not to be.

Obviously you can use them - but there is some overhead setting up the build process, deployment etc.

I''ve noticed that a lot of commercial games tend to be relatively monolithic executables.

The "Monster exe" argument doesn''t really carry much weight either, because even relatively complex games still tend to have fairly small .exes

Using DLLs unnecessarily just adds complexity, provides more scope for failures at runtime and makes it easier to reverse engineer your software.

---

One possible scenario you might think of, is if you are going to write a game level editor which uses some parts of the game engine at runtime. Might you be tempted to use a DLL?

It would be equally easy to have some command-line parameter to the game .exe to tell it whether to play the game or fire up the level editor.

Mark

Share this post


Link to post
Share on other sites
quote:
Dll''s are Windows-specific, aren''t they?


nope, I don''t think they work in exactly the same way under all OS''s, but the general concept exists.

Jack

Share this post


Link to post
Share on other sites
quote:
Original post by markr
Using DLLs is frequently overrated. A game engine need not be a DLL at all, and it may be convenient for it not to be.

Obviously you can use them - but there is some overhead setting up the build process, deployment etc.

I've noticed that a lot of commercial games tend to be relatively monolithic executables.

The "Monster exe" argument doesn't really carry much weight either, because even relatively complex games still tend to have fairly small .exes

Using DLLs unnecessarily just adds complexity, provides more scope for failures at runtime and makes it easier to reverse engineer your software.

---

One possible scenario you might think of, is if you are going to write a game level editor which uses some parts of the game engine at runtime. Might you be tempted to use a DLL?

It would be equally easy to have some command-line parameter to the game .exe to tell it whether to play the game or fire up the level editor.

Mark


You really don't carry any good arguments there.

Food for your thought:

Middleware?

Working with a large group of people on an engine with many subsystems that are divided among groups?

Not having to rebuild 150+ source files for a rebuild of one system because of an interface change that only affects one portion of the engine?

MindEngine Development
http://medev.sourceforge.net

[edited by - neurokaotix on March 29, 2004 3:45:07 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Enselic
Dll''s are Windows-specific, aren''t they?



It''s more complicated than that. Windows has several types of DLLs (not all of which are always called *.dll). Some of them are used with other platforms (.NET, Win16, WinCE)

quote:
Does Linux have something similar?


Yes, Linux has something extremely similar. I have no idea what the difference is (except of course that they are different format), to the programmer they behave pretty much identically.

They''re called ".so" files or "Shared objects". There are functions in the Linux dynamic linker which behave semantically similarly to win32''s LoadLibrary and GetProcAddress

Mark

Share this post


Link to post
Share on other sites
quote:
Original post by Enselic
Dll''s are Windows-specific, aren''t they?

Does Linux have something similar?
.so files are kinda-sorta the same. They export all symbols, much like a static library (and unlike a normal DLL, which only exports what you specify), and have better versioning, which avoids most (all?) cases of DLL Hell. They can be treated the same using dlopen() instead of LoadLibrary(), etc. Consult the man pages for more info.

Share this post


Link to post
Share on other sites
Ok so in my engine the trend for the names of the different classes (cpp files) is CBase....CPP. supposing that i want to make all of these classes into a dll and only have the c file with the window and direct 3d initiation stuff in(not a class) as the exe, how do i do it.

Do i have to change a VS6 C++ link and compile settings

regards,

ace

Share this post


Link to post
Share on other sites

Some games have their AI specific code in dlls for each nation as example. And as I have understand some games uses them for addons(modding).

Maybe the most common reason for Dlls is that people like to share/sell their game engines whit out exposing its contents the code I mean. All they need to do is share the .h .lib and .dll files. Like DirectX works.

Share this post


Link to post
Share on other sites
quote:
Original post by ace_lovegrove
Ok so in my engine the trend for the names of the different classes (cpp files) is CBase....CPP. supposing that i want to make all of these classes into a dll and only have the c file with the window and direct 3d initiation stuff in(not a class) as the exe, how do i do it.

Do i have to change a VS6 C++ link and compile settings

regards,

ace



Well, _a way_ that it can be done is to add all of the class to a dll project, and use class __declspec(dllexport) CMyClass when you declare the class structure in your .h files. For example:

CMyClass.h

class __declspec(dllexport) CMyClass
{
public:

CMyClass(){};
~CMyClass(){};

};


In your .exe you''ll import the .lib file that is produced when the dll is made. You''ll do that with:

#pragma comment(lib, "MyEngineDLL.lib")

Then you''ll need to include the .h files from the dll classes in your exe project so it knows what you''re importing (oversimplified, but you get it).

After that you''re able to create an instance of whatever class you wanted to export from the dll.


MindEngine Development
http://medev.sourceforge.net

Share this post


Link to post
Share on other sites