Jump to content
  • Advertisement
Sign in to follow this  
andreialex

DLL or Static Library

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

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?

Share this post


Link to post
Share on other sites
Advertisement

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.

Edited by SyncViews

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:
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.

Share this post


Link to post
Share on other sites

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/

https://handmadehero.org/

http://www.3dgep.com/using-dynamic-link-libraries-dll-to-create-plug-ins/

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Always go DLLs for development.

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. smile.png

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.

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

 


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.

Edited by Oberon_Command

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!