7

I wonder about create every game engine module (render, input, sound, etc...) into dlls (renderer.dll, input.dll, etc...). What are pros and cons in your opinion of divide game into set of dlls ? I see only need to write game module in separate dll, to have posibility to create mods.

piotrek
  • 1,388
  • 1
  • 14
  • 23

4 Answers4

4

Pros

  • You can build DLLs separately.
  • It could be faster to re-build one DLL

Cons

  • Calling code from DLL is slower
  • It would be slower to re-build hole project with all DLLs
  • Function names are visible. It is easier to reverse code that uses dynamic DLLs

I do not see sense to have render.dll and input.dll But some RareUsedJoystick.DLL could be made as loadable module to release memory for those who do not use that RareUsedJoystick

Max
  • 456
  • 2
  • 7
  • 1
    Have you any sources on this? From my understanding and experience of compiling and linking I would say nothing but the last point is true. – API-Beast Oct 07 '12 at 16:55
  • 1
    In huge projects linking is much faster when you use dlls. Also note that it is harder to debug complex types in a dll. – Jonathan Connell Oct 07 '12 at 16:59
  • 1
    Static linking may inline functions. It is not possible to inline DLL function because DLL may change in future. It is also a reason why DLL linking is faster. I was saying it would be slower to compile all DLLs separately then compile all code in single EXE – Max Oct 07 '12 at 17:14
  • 1
    The compiler/linker can optimize better when linking statically. But that doesn't mean that calling functions is generally slower. – API-Beast Oct 07 '12 at 17:56
  • function in dynamic link library is called slower. Because your code calls function by index in array. It is extra 1-3 operations but many functions are just getter/setters that it self are 1-3 ops. I case of static linking and inlining it could 1 CPU op. Without inlining static lib could use registers to pass function args. In case of DLL. it uses stack to pass args. It takes function address by index in array. There is a lot of extra ops that static linking removes. – Max Oct 07 '12 at 20:25
  • http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking "To address the performance and efficiency issues: it depends." – API-Beast Oct 07 '12 at 21:47
  • @Mr.Beast: That only applies if many processes are using the same library, and I'm not sure it applies to any operating systems using ASLR (which today is all of them). I'd also a priori disbelieve a cache line would survive a context switch into another process anyway (but evidence would convince me otherwise). At best the performance difference is negligible. In the real world I feel comfortable saying you will never see faster (unless you risk actually running out of physical memory). –  Oct 07 '12 at 22:22
3

Putting code into seperate Windows DLLs sounds promosing in theory, but in practice you should be aware of certain limitations.

  1. You have to declare all your classes and global functions you want to use from outside as "exportable" using

    __declspec( dllexport ) class Foo {};

    when building the library. Clients of your DLL must "see" the include like this:

    __declspec( dllimport ) class Foo {};

    That is why you see a makro infront of class declarations in DLL headers.

  2. Resources like FILE* pointers can not be shared under all circumstances (different CRTs) between DLLs. That means if you open the file in one DLL, you cannot write to it from the client app or another DLL, nor close it.

    http://msdn.microsoft.com/en-us/library/ms235460%28VS.80%29.aspx

  3. Memory management: You cannot allocate memory in the DLL and free it in another DLL or in client application under all circumstances (different CRTs).

  4. Exporting template classes can be a real pain, especially if they use static member variables.

If you just want to reuse your code without recompiling, there is another option, static libraries (.lib). It is precompiled code (as in the DLL) but it is linked into your application and has no such limitations as the ones mentioned above, plus Link Time Code Generation still works with the library code.

Update: As Sean pointed out in the comments, point 2 and 3 can work when using the same CRT version, as the MSDN link in 2 also shows. However, my advice is to design the DLL without relying on it at all, since there are so many cases where it won't work, like using 2 DLLs with different CRT's or compiled with different Visual Studio versions.

Maik Semder
  • 4,718
  • 1
  • 26
  • 24
  • The memory and FILE* claims (2 and 3) are not quite true. Those problems occur when the DLL uses a different CRT version. If built with the app itself, this is not a problem. – Sean Middleditch Oct 07 '12 at 19:04
  • @Sean right, in theory. In practice there are many cases where it won't work (see the MSDN link), like DLLs from different VS versions, linking with 2 DLLs with different CRTs, so it's safer to design the DLL to not to rely on it. It's an important limitation to keep in mind and should be listed here. However, I put an update in my answer reflecting your comment, thanks Sean – Maik Semder Oct 07 '12 at 19:40
  • I'd argue it's not "just theory." Sure, if you're designing DLLs as standalone components, it's a problem. The original question is about just breaking up a single app into DLLs, which implies that the DLLs are built together at the same time with the same compiler. This is actually somewhat common in game engines for a variety of reasons (e.g., loading different optimized versions of code for different CPU instruction set variants), and in these cases, it is in practice totally safe to assume those problems won't happen. :) – Sean Middleditch Oct 07 '12 at 20:40
  • It should be also noted that this only applies if you use MSVC. GCC (MinGW) exports everything per default. – API-Beast Oct 07 '12 at 20:58
  • @Mr.Beast Would that be export or import? I'm using MinGW myself. But got rather confused about the default settings for DLLs. – Sidar Oct 08 '12 at 10:07
1

Most differences are negligible. DLL's are more flexible but make the building process more complex. I would only use DLL's if:

  • Multiple applications need to access the same functionality. For example if you have separate binaries for a editor and the game itself.
  • You want yourself or other people be able to replace certain components. For example in Civ IV modders could ship replacement for the game's DLL's to fundamentally change parts of the gameplay.
  • You want to load them at runtime to allow to extend the application by third party plugins.
API-Beast
  • 6,839
  • 1
  • 27
  • 43
0

Another advantage is that it can help you structure your code correctly. Any non-logical dependencies between modules will stand out more and it will be more difficult to use such hacks.

Tomas Andrle
  • 233
  • 2
  • 9