Splitting a game into different dll's

Started by
6 comments, last by M4573R 14 years, 11 months ago
I'm currently writing my second game from scratch. I'm wondering about the benefits of splitting up different core sections like graphics and audio into separate Visual Studio projects and compiling them as dll's ( with import libraries ). I heard that you can do things such as having individual precompiled headers for each project, and having the ability to run individual projects in release/debug mode. Never having done this before, I'm wondering what pitfalls I may face. One problem I've encountered is that I have code that I want to use in multiple projects such as utility functions. I don't know how this works when I'm compiling a dll that uses code not included in the project. Do I have to tack on the extra utility headers whenever I want to move my dll around? Thanks in advance
Advertisement
Unless you intend to be able to change the dlls at a later date or somthing, your most likly better off making the components into static libaries.

To use a static library simply include the headers that declare the functions/classes etc, and tell VS that the libary is an addition dependecy (select your project -> properties -> linker -> additional depencies).

Or you could use #pragma comment(lib, "mylibrary.lib") somewhere in your code. I perosnally prefer this is VS cause its easier as to not have to explicitly add the dependecies to each project, includeing the header does it.

Eg my utill.h looks like:
#pragma once#ifdef _DEBUG    #pragma comment(lib, "utill_d.lib")//link debug version of static lib#else    #pragma comment(lib, "utill.lib")  //link release versuib of static lib#endif//class/method declarations...
Although I would need to use dll's if I wanted to patch just part of the game. I might end up going with static libraries, but if I did use dll's, how would my described problem work out? I can see this happening in many other applications. My first thought would be to move to code used in multiple places to yet another dll, but from what I know, you can't do this with templated functions.
If you have common code that you want to share between binaries, you can move them out into a library - either static or another DLL. Doing it statically will waste a little bit of memory (since, for example, you'd be loading the same utility code for both your graphics and audio DLLs). Windows should, IIRC, only load a DLL once - so you save a small amount of memory that way.
NextWar: The Quest for Earth available now for Windows Phone 7.
What if I have just a few templated functions implemented entirely in some header files?
Quote:Original post by M4573R
What if I have just a few templated functions implemented entirely in some header files?


Then you just include the header files where necessary in your code.
Last I checked you cant use templates through a dll, static lib or even another cpp file. They must be defined in the file that uses them (headers are effectivly copied directly into the cpp file when included). So templates dont really effect your choice of stats vs dynamic libs.
Okay then. Hopefully I wont need any more shared code than that. Thanks.

This topic is closed to new replies.

Advertisement