Hello,
As I am starting to create my basic engine I came across a little dilema.
I am thinking to make the whole engine in a DLL ( with the other modules as static library that will be added in the DLL ) and inport that in the game.
Is this a good practice or should I use other approach?
DLL or Static Library
Using a DLL is a common practice, but has some difficulties and drawbacks you need to address if you will use it.
For example: Passing exception from DLL to EXE is not possible, if you use std-containers like vectors or maps in your dll interface you have to make sure to use the same runtime and compiler version for the dll and the exe, memory needs always be freed were it is allocated (ok this belongs to basic programming ) and some other problems.
I guess you won't use more than one executeable using the engine at a time, therefore memory is also not a reason to use a dll. With a DLL you get one more indirection which could be bad for performance.
On the other hand a DLL makes it easy to patch just the engine an let the executeable be the same, or use multiple instances of the engine while the lib is loaded only once the RAM.
Personally i find compiling the engine into a static lib and link it into the executeable much more easier and less error prone.
static libs are far easier.
The problem with DLL's is there are a lot of traps because lots of things can cause binary incompatibilities even when you take the required steps to get the basic linking/calling convention right so that they load (e.g. using only C-API's with their standard ABI, or using the same C++ compiler everywhere) that will just cause memory corruption and then crashes (because of things being statically linked that should not have been, or mismatched DLL versions/binary interfaces).
Id only use DLL's if I had a need for the runtime linking aspect of them, e.g. for plugins. But that is a very advanced topic. LGPL licensed libraries also causes problems. Hopefully any you need to use have a plain C interface that is safe (e.g. the core Window's DLL's, and things like zlib, libpng, etc.) or other standardised ABI (e.g. the Window's Common Object Model stuff you will come across if you ever use DirectX), otherwise id avoid them.
Thank you both for the explanation.
I understood and for now I will make it a static library as I don't have that much experience in C/C++ and if I will defenetly want to make it in a DLL I will continue from there.
There are generally only two reasons to make something a DLL:if I will defenetly want to make it in a DLL I will continue from there
a) if you need to replace the DLL with a different one, without recompiling the application which uses it.
b) if so many applications on the same computer link to your library that static linking would represent a disk space issue.
Reason (b) is typically only applied to required system libraries (like libc). Reason (a) typically only applies to plugins - and it would be very strange to consider the entire game engine an optional plugin.
I would advise not to give up on using DLL's. They are tricky at first and there is a bit of learning curve... but once you start loading large amounts of data (textures, levels, audio).. your iteration times will go down. Using DLL's you can spread your project into more manageable chucks and if you are feeling adventurous you get get a simple hot-reload type system working to improve your iteration times.
Take a look at these resources if you are interested in finding out more + some good example codes:
http://runtimecompiledcplusplus.blogspot.com/
http://www.3dgep.com/using-dynamic-link-libraries-dll-to-create-plug-ins/
I would advise not to give up on using DLL's. They are tricky at first and there is a bit of learning curve... but once you start loading large amounts of data (textures, levels, audio).. your iteration times will go down. Using DLL's you can spread your project into more manageable chucks and if you are feeling adventurous you get get a simple hot-reload type system working to improve your iteration times.
I don't think that's a good reason to use dll's. It would probably be better to use other methods for these kinds of resources, the simplest being to just load the files directly from a subdir of the game directory.
As was said before, the main reason to consider using dll's would be some type of plugin. For an engine, you could consider making a dll for the audio engine, one for the graphics engine and so on. But here I'd still go for a static library myself.
Yes, it's a bit more complicated. And worth it. First, if you don't already know exactly what the ins and outs are and how to deal with, you better learn, and now's as good a time as any.
The biggest advantage for DLLs during development is iteration time. DLLs let you compile and link smaller chunks of the game and then get back into the game quicker, meaning you can test and iterate on your game faster. Which means you can make a better game with less time and money.
There are a few things to keep in mind. One, you don't really just want one big mega DLL. That defeats the purpose. You want several (or even many) smaller DLLs, e.g. a CoreEngine DLL, a GraphicsEngine DLL, a GameEngine DLL that ties those together, etc.
Second, realize that there is code you don't want in a DLL, and hence you either want that code to be in a header-only library (which I dislike, as they slow down compilation) or in a static library. Your math library is one such example. Compilers cannot optimize across DLL binaries, so things that really really need inter-procedural optimization for "fast" development builds should not be split into DLLs. The static library will let those bits be compiled into each DLL using them.
Finally, the DLLs are really only for development. There's not generally a good reason to actually ship your game with a bunch of DLLs. You probably want to make sure that you can compile both with and without the DLLs. Setting that up in something like VS is a little tricky, but doable, and tools like CMake or Premake make it much easier.
The only game engines I've worked on that relied on only static libraries ended up getting months of effort (and hence a lot of money) poured into them to fix that shortcoming. Nobody wants 2 minute link times just for simple one-line changes. Almost your most important job as an engine architect is to make that thing fast for development.
Nobody wants 2 minute link times just for simple one-line changes.
Jesus. What sort of volume of source code and libraries are you linking?
I have game, engine, and all ~15 dependent libraries statically linked, and link times are still imperceptible. But then again, I'm only dealing with low-thousands of source files, all told.
Nobody wants 2 minute link times just for simple one-line changes.Jesus. What sort of volume of source code and libraries are you linking?
It can get worse. I've worked on at least one project where linking - JUST linking one of the several executables in the project solution - took seven minutes or longer (I once waited 20 minutes for a link to complete) and the compiler sometimes ran out of heap space when you added more code or went too long without a clean and rebuild. As you might guess, the project had quite a few static libraries and link time optimization enabled.
I have game, engine, and all ~15 dependent libraries statically linked, and link times are still imperceptible. But then again, I'm only dealing with low-thousands of source files, all told.
Do you also have link-time optimization disabled? Just a hunch, but I bet that would make linking noticeably longer.