Dethrace: rebuilding the 1997 Carmageddon engine in modern C

Watcom symbols that pointed at nothing

The story of how the project started is the most interesting part of it, and the documentation tells it plainly.

Watcom debug symbols for an earlier internal build were discovered, and they were named `DETHRSC.SYM` on the Carmageddon Splat Pack expansion CD release. The symbols unfortunately did not match any known released executable, meaning they were interesting but not immediately usable to reverse engineer the game.

What they looked like from the Watcom debugger is described in the documentation: the names of all the methods were present, but the code location they were pointing to was junk. So you had a complete list of function names for the game and no usable addresses, which is the worst possible shape of information. It tells you the original developer had a sound routine here and a camera routine there, and it does not tell you where any of it lives in the binary.

CrayzKirk gets the credit for doing the first manual matching of functions and data structures in the DOS executable to the debugging symbols, and the documentation says outright that this proved it was possible. The credit list also names the developer at Stainless Software who left the old debugging file on the Splat Pack CD, which is one of the more remarkable accidents in software archaeology.

The approach from there is incremental and honest: the project is slowly replacing the original assembly code with equivalent C code, function by function. That is a slow method, and it is the only method that produces a result you can read, compile and profile.

Building it is a normal CMake project with SDL2 at runtime

The build system is unremarkable in the best way. Dethrace uses CMake to build and SDL2 at runtime, and the documentation says the easiest way to install the dependencies is via your favourite package manager.

On macOS:

brew install SDL2 cmake

On Linux:

apt-get install libsdl2-dev cmake

The clone step has an extra requirement. Dethrace uses git submodules, so they must be pulled after the initial clone:

git clone https://github.com/dethrace-labs/dethrace
cd dethrace
git submodule update --init --recursive

Then the standard CMake dance to generate the build files:

mkdir build
cd build
cmake ..

And the build itself, which the documentation gives as an example per platform:

make

The repository layout matches a project with tooling of its own. Alongside `src/` and `lib/` C sources there is a `reccmp/` directory and a `reccmp-project.yml` at the top level, a `tools/` directory, a `cmake/` directory, a `packaging/` directory, and a `docs/` directory holding the configuration reference, the contributing guide and the changelog. The `.clang-format` file at the root means the code style is machine-enforced, which is the right call for a codebase where every line is a rewrite of someone else's assembly.

reccmp is how a replacement proves it matches

The credit list names the isledecomp reccmp tooling, and the repository carries both a `reccmp/` directory and a `reccmp-project.yml` file, which is where the verification story lives.

The concept behind that tooling is what makes this project possible in practice. When you replace a chunk of assembly with C, the claim you need to support is that the new code behaves identically to the old, down to the register and memory effects. A project like this cannot prove that by inspection, so it needs a comparison mechanism that runs the original and the replacement and checks that the results agree.

That is also why the status display is hosted as a separate artefact. The progress image in the documentation is pulled from a different repository, dethrace-labs/reccmp-report, on a main branch, which is a report rather than a build of the game itself. The percentage of the game that has been translated is therefore measured output, not a claim in a readme, and it is generated by comparing the two implementations.

This is the design decision that separates Dethrace from a typical game engine reimplementation project. The goal is not a similar game, it is the same game with the same observable behaviour, verified function by function. That standard is why the project can be trusted as a reference for how the original engine worked rather than only as a playable build.

No content ships, and the data files have to come from somewhere

Dethrace does not ship with any content. You need access to the data from the original game, and the documentation points to buying Carmageddon from GOG.com if you do not have an original CD.

The project also supports the various freeware demos, and three are linked: the original Carmageddon demo, the Splat Pack demo and the Splat Pack Christmas demo. Those are the sensible starting point for a first build, since they are small and free.

Placement is specific. Dethrace generally expects to be placed into the top level Carmageddon folder, and you know you have the right folder when you see the original `CARMA.EXE` there. On Windows you must also place `SDL2.dll` in the same folder.

Two optional pieces of configuration sit on top of that. A dethrace.ini file lets you configure a different Carmageddon directory and settings, with the details in the configuration documentation. And there is CD audio support following the GOG cd audio convention: if there is a `MUSIC` folder in the Carmageddon folder containing files named `Track02.ogg`, `Track03.ogg` and so on, Dethrace will use those in place of the original CD audio functions.

That last detail is a good example of the project's character. Rather than trying to emulate a CD audio driver, it accepts a modern file layout that the community already has, which is the kind of pragmatic accommodation that decides whether a reimplementation is pleasant to use or merely correct.

dethrace is very likely not a typo

There is a short section in the documentation devoted to whether the project's name is a mistake, and the answer is a good example of how reverse engineering actually works.

According to the symbol dump, the original files were stored in `c:\DETHRACE`, and the symbol file is called `DETHSRC.SYM`. The author's own guess is that maybe the a was removed to be compatible with 8.3 filenames, the old DOS naming scheme with an eight character name and a three character extension. There is also a note that the symbol file was found as `DETHRSC.SYM` on the CD, which is a slightly different spelling again.

The name therefore comes from the evidence rather than from a brand decision, which is the right way round for a project whose entire premise is that the artifacts tell you what the original developers did.

The release history shows a project still moving. Version 0.9.0 came on 2025-09-21, and 0.10.0 and 0.10.1 followed on 2026-02-21 and 2026-02-22, which suggests the 0.10 line was a concentrated push. The last push was on 2026-10-19 and the repository is not archived. The version numbers are honest about the state of the work, since a 0.x line in a reimplementation means the game is not yet complete, and the progress image in the documentation is the better indicator of how far along it is.

The legal terms are not a standard open source licence

The legal section deserves close reading, because it does not match what a licence badge would suggest.

Dethrace is released to the Public Domain. The documentation and function provided by Dethrace may only be utilised with assets provided by ownership of Carmageddon. And the source code in the repository is for non-commercial use only. If you use the source code you may not charge others for access to it or any derivative work of it.

That is a three-part statement rather than one licence, and the parts constrain different things. The public domain release covers the work itself. The assets condition means the reimplemented engine is only useful with game data you own. The non-commercial clause limits how the source itself can be used, and it is narrower than a standard open source grant, because a permissive licence like MIT would let you charge for access to a derivative, and this one does not.

There is also a disclaimer of association. Dethrace and its maintainers are in no way associated with or endorsed by SCi, Stainless Software or THQ Nordic, the companies behind the original game. That is a normal and necessary statement in a reverse engineering project, since a reimplementation of a commercial title inevitably raises questions about trademark and endorsement.

The metadata for the repository records a GPL-3.0 licence, while the legal section in the documentation states public domain plus these restrictions. Where the two descriptions differ, the documentation is the more specific statement, and the practical advice is to read the LICENSE file and the legal section before you build on it, particularly if your interest is commercial. A brief chat with a lawyer is a reasonable step if you intend to do anything with the code beyond running the game for yourself.

Editorial conclusion

Dethrace fits reverse engineers who want to study how a 1997 DOS game engine was assembled and who want a native, debuggable C reimplementation rather than a patched binary, because the recovered Watcom symbols give the project real function names to work from and reccmp automates the comparison against the original. Skip it if you want a playable game today, since the project ships no content and needs the original data files, and skip it for commercial use, because the documentation restricts the source to non-commercial use. Before you start, read the legal section carefully, since the terms differ from a standard open source licence, and set up reccmp against the original executable early, because the whole workflow depends on proving each replacement matches. The last push was on 2026-10-19 and version 0.10.1 was released on 2026-02-22.

Frequently asked questions

Official sources

1. dethrace-labs/dethrace on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases