Feal87's Blog

Just another programming weblog.

Posts Tagged ‘Automatic Build System’

Walkway to a MultiAPI Engine (Automatic Build System)

Posted by feal87 on May 28, 2009

When I decided that the game engine I was about to create would support multiple APIs, I had a few ideas about how to structure the game engine and its build management, all with pros and contros. This post will analyze the possible choices that I had without showing actual code, but examining the ideas behind it and their reasoning.

I identified while thinking three possible way to manage the game engine and its build management in simplicity :

1) Have single class with one codepath for each API.
2) Have multiple class, one for each API. (Device9, Device10, DeviceGL, Texture9, Texture10, TextureGL, etc…)
3) Have single class with preprocessor directives for conditional compiling. (#define DX9, #if DX9…#else…#endif, etc…)

The first one while permitting the use and switch between multiple engines from even ingame, it added useless checks every operation to know what engine are we using. Imagine an if…then…else each operation, it would have added a very big and useless overhead to the game engine.

Example of a Type 1 Engine Function

Example of a Type 1 Engine Function

The second one had no overhead by useless checks, but losed the real meaning of a transparent MultiAPI engine, because i would have to write multiple code for using each API in the various games while the objective is to write less code as possible.

The third one, the one I choose, was perfect for a transparent game engine. With conditional compiling I would have a slim DLL for each of the APIs, and all these DLL’s would have the same identical behaviour making them interchangeable.
However I encountered some problems while designing the solution.
The question was, how to actually use different DLL from inside C# in a simple and straightforward way? How to distribute all these different DLL’s and executables with an automatic system?
After a bit of tinkering I found out the solution I’m still using even today.

Engine example solution

Engine Type 3 Example solution

Basically the Visual Studio Solution is divided in multiple project and each project has multiple build configuration, one for each API. Each of this configuration have a preprocessor symbol to identify what needs to be compiled. When the game is build Visual Studio run the PostBuild event that merge the game engine library compiled (depending of the configuration) with the game executable and copy/rename the generated executable in the bin directory.
This has been possible thanks to a very nice tools created by Microsoft Research called ILMerge. ILMerge is an utility that can be used to merge multiple .NET assemblies into a single assembly.

Here it is an example PostBuild script that copies the SlimDX DLL and use ILMerge to create a single assembly with everything in it. (Only for Release DX9, but adding the others is just a work of copy&paste)

mkdir .\Build\Eseguibili\$(ProjectName)\
copy .\Library\SlimDX.dll .\Build\$(ProjectName)
IF "$(ConfigurationName)" == "Release DirectX9"
   (.\BuildTools\ILMerge.exe /out:.\Build\$(ProjectName)\$(ProjectName)DX9.exe
   "$(TargetDir)$(ProjectName).exe" "$(TargetDir)gamelibrary.dll")
IF "$(ConfigurationName)" == "Release DirectX9"
   (del .\Build\$(ProjectName)\$(ProjectName)DX9.pdb)

This way using the example solution I posted above we would have as result of the compilation two executables, PongDX9.Exe and PongDX10.Exe. Each one containing everything needed to be run, game engine dll included, inside the executable. (Except the game assets obviously)

I hope to have covered enough ground to let you make a general idea behind the managing of a MultiAPI engine.
The next article will be more technical. We’ll talk about the structure of the game engine i’m developing, its gameloop and lots more.

See you later. 😉


Posted in General | Tagged: , , , , | Leave a Comment »