idTech editing hints & tips

Below is a list of essential editing hints and tips for idTech4 powered games (formally known as the 'Doom 3' engine); currently Quake Wars, Quake 4, Prey and Doom 3, but future idTech games may be support. For full list click here ».

The better way to change the name of the *.exe produced by compiling doom3.gpl is to modify the compiler output so it writes the name(space) correctly - changing the program executable or shortcut is possible but not the correct approach to use, neither is renaming any part of the project Visual Studio's Solution Explorer (in relation to naming the *.exe this does nothing, it only changes the name of the Solution project).

Changing the name of 'projects' in the Solution Explorer don't effect the name of the executable

To correctly change the exe name, in the Solution Explorer;

Step 1

Under "exes" right-click "DoomDLL" to open "DoomDLL Properties Pages".

To the right of "Command" (not "Commend Arguments") click "$(OutDir)DOOM3.exe" to highlight for editing, replace "DOOM3" with the name of choice, e.g. "Catacombs" - string should read "$(OutDir)[custom name].exe", i.e. "$(OutDir)Catacombs.exe".

Click "Apply", then optionally if not continuing to 'Step 2', click "OK" to exit the Properties Page manage.

To the right of "Output File" select "$(OutDir)DOOM3.exe" to highlight for editing, replace "DOOM3" with the name of choice, e.g. "Catacombs" - string should read "$(OutDir)[custom name].exe", i.e. "$(OutDir)Catacombs.exe".

Click "Apply", then "OK" to exit the Properties Page manage.

Change "Linker" properties to reflect the name of the executable to be compiled

The doom3.gpl source code uses a standard 'icon' bitmap image to illustrate the compiled exe. To change this replace the respective 'icon' files, i.e. *.ico/Win, *.icns/OSx, *.png/Linux, in the following locations;

Images can be 24bit or 32 bit, the latter being required if the icon is to appear shaped or 'masked' in some way, a function that requires the use of image based alpha mask/channels, or where black (0,0,0) represents 0% opaque (100% transparent) pixels.

Instructions below relate to using Windows 7 to compile Doom3.gpl using Microsoft Visual Studio 2013 Community edition (not tested or checked on Windows 8/8.1 or Windows 10 - modified code as per below DOES NOT build with Visual Studio 2015). Code is extracted and used with minor modification (explained below).

How to installThe installation process for Visual Studio 2013 differs slightly to that of Visual Studio 2010 in that a number of components previously requiring separate download are now included by default during install (although still optional so need to be selected for inclusion), i.e. Microsoft Visual C++ library.

Install Visual Studio Community 2013, Multibyte MFC Library and the DirectX SDK to the suggested location(s) - typically "C:\Program Files (x86)\[path to install]" which allows the software to set up default system paths for reference within the project.

Create a separate project/development folder and in to it unpack/extract the contents of Doom3.gpl.zip (this should be a completely separate folder/location to the Visual Studio 2013 installation files/directories, the location the eventual game/project is to be worked upon).

How to useThe source code likely won't compile without error by default but it shouldn't need any modification itself, all necessary changes are typically simple edits to the projects properties and settings.

Step 1: project updateThe below loads the *.sln file into Visual Studio (may need to be opened from the application if more than one version of Visual Studio is available) and updates the data to be fully compatible with 2013.

Browse the 'doom3' project/development folder just created and find "\neo".

Double-click "doom.sln" (.solution file).

Visual Studio 2013 will open the project asking if it's OK to update to latest version. Click "Yes/Agree" (this is necessary for the files to be compiled with VS2013, without it build fails).

When the *.sln project file opens in Visual Studio the program will want to update the selected files

Files are displayed in the status bar as they are parsed and updated

Step 2: project propertiesSetting up the projects environment, settings and properties. Once the project is loaded and updated, next;

In the Solution Explorer (panel on the right) right-click "Game" (under "dlls") and select "Properties" from the menu, then;

- In "Configuration Properties" expand "C/C++" properties and left-click "Preprocessor".- To the right, click "Preprocessor Definitions" - currently displaying "DEBUG;%(PreprocessorDefinitions)".- Type "_XKEYCHECK_H;" between "DEBUG;" and "%(PreprocessorDefinitions)", i.e. "DEBUG;_XKEYCHECK_H;%(PreprocessorDefinitions)" (important note: "DEBUG;" may display as "_DEBUG;", "DEBUG;", "_NDEBUG;" or "NDEBUG;" et al if the project has been previously built and/or cleaned, or depending upon the build type selected [see below]).- Click "Apply" then "OK".

Ensure Visual Studio 2013 lists the correct 'version' data in 'debug' settings, the "VC" (Visual C/C++) version used should be shown as "12" for Visual Studio 2013 (optional may not be required). To access, in the Solution Explorer right-click "Solution 'doom3' (7 projects)" and select "Properties" from the menu that appears. Expand "Common Properties" and select "Debug Source Files".

Make sure the correct "VC" is listed, for 2013 it should be "12"

Step 3: modify snd_system.cpp

In the Solution Explorer, expand "DoomDLL", then "Sound". Double-click "snd_system.cpp" to edit and scroll down to line 167;

Step 4: BuildIf the code is to be used as is without modifying anything, before compiling the 'build type' should be set to "Release" or "Dedicated Release" to ensure all the files and data are included in the appropriate *.exe, *.dll and other core files.

Successful compileIf successful a series of files are produced and saved to "build\Win32\Dedicated Release" in the project directory (where the source files were unpacked and the *.sln was double-clicked - note: a separate folder is created per build type within which output is saved). These are;

DOOM3.exe

Game.exp

Game.lib

gamex86.dll

idLib.lib

TypeInfo.exe

Once available copy to actual development folder (should contain folder/directory structure replicating that of Doom 3).

How to compile doom 3 with visual studio 2010 [Obsolete: Visual Studio 2010 is no longer supported/provided by Microsoft directly (2012 is the last archive available). In addition, some of the 'Properties' management requirements, i.e. providing path information, may not be required as Visual Studio should pull that data in from Windows Systems paths defined during component installation].

ProblemAlthough 'volume' based levels can be made using 3DS Max, because the eventual format used needs to be specially compiled, it's not possible to export content from Max directly to *.bsp. BSP is a data structure rather than just a file-dump. This means the contents of a working file are analysed and broken down into a series of structures that are optimised in a way that removes some material. This isn't possible through a simple 'export' mechanism, so content has to exported to another format. However, it's not possible to simply export the contents of a Scene to a single model because the way those are handled in game would result in an unusable level (models are processes and culled based on bounding-box not surfaces). That being said models can still be used...

SolutionThe general solution to exporting volume based content from 3DS Max is essentially two-fold;

use a *.map export script.

section the level and export a series of models.

If a *.map export script exists divide the level into simple 'convex' shapes and complex molded structures, i.e. flat walls, floors and other architectural features that describe the level versus statues, shaped fittings and features. Export the former group to *.map and the latter to a supported mesh format such as *.ase, *.obj etc. Both can then be opened in a level-editor like GtkRadiant and once rebuilt as the content was originally in Max, can then be properly compiled to BSP using a MAP2BSP compiler (dmap, q3map2 etc.).

An alternative to the above is to export content from Max to *.3ds which can then be opened and processed in Gmax before being compiled using the BSP compiler included with the Tempest Gamepack. This approach woul typically mean rebuilding certain elements of the level and retagging content so the Tempest gamepack knows what to do with certain structures.

KatsBits provides freely available game and content making tutorials and resources, helping Visitors build their own games, or go further, Game Design Studios!. At KatsBits we strive to bring relevant material to our Readers and forefront Blender as a general game development tool.