dhewm3, a Doom 3 source port whose build system lives in neo/

A source port with one non-negotiable rule: no gameplay changes

dhewm 3 is a Doom 3 source port, and the README is unusually clear about what that means in practice. The goal is to bring Doom 3, with the help of SDL, to all suitable platforms, and the project states that it is known to work on at least Windows, Linux, macOS and FreeBSD.

The constraint that shapes everything else is the second sentence: bugs present in the original Doom 3 will be fixed when identified, without altering the original gameplay. That is the line between a source port and a remaster, and it is worth holding the project to it as a test. Rendering fixes, collision corrections, crash repairs and the like are in scope. Enemy behaviour, weapon balance, level design and difficulty tuning are not, and a port that starts rebalancing is no longer comparable to the original for anyone who cares about speedrun categories, demo compatibility or reproducing a 2005 playthrough.

The concrete changes the README lists all sit on the platform side of that line. There is a 64-bit port. SDL handles low-level OS support, OpenGL and input. OpenAL handles audio output and all OS-specific audio backends are gone, with OpenAL EFX standing in for EAX reverb so the effects work on all platforms and hardware. Gamepads are supported, with the caveat stated plainly that rumble is not. Widescreen and arbitrary display resolutions are better supported. The build system is portable CMake, cross-compilation works with MinGW-w64, and there is an advanced settings menu that is independent of any mod, opened with F10 by default.

The mod-independent settings menu is a good example of the philosophy. A settings menu that a mod cannot break is a concession to the community, and the separate Mod SDK repository exists for the same reason: people extend the game, and the port's job is to stay out of the way.

The CMake project is in neo/, so the build folder matters

The first thing that catches people is where the build system lives. The README instructs you to create a distinct build folder outside of this source repository and point the cmake command at the `neo/` folder, not at the repository root. Everything else follows from that.

The Ubuntu walkthrough is the shortest complete path:

sudo apt install git cmake build-essential libsdl2-dev libopenal-dev libcurl4-openssl-dev
git clone https://github.com/dhewm/dhewm3.git
cd dhewm3
mkdir build
cd build
cmake ../neo/
make -j8

Note what that sequence does and does not include. There is no configure step, no autotools, no dependency vendoring and no install target before the build. The dependency install is a single apt line, and the compiler step is `make -j8` where the 8 is just the thread count of the example machine, so any reasonable number works.

The CMake options are where the interesting builds live, and the README gives you three ways to see them. You can pass options directly, as with `-DDEDICATED=ON` to enable the dedicated server. You can list everything supported with:

cmake -LH ../neo/

Or you can install the `cmake-qt-gui` package and configure in a window instead of typing `-D` arguments. One behaviour is worth knowing before you experiment: previously set options are remembered when you re-run CMake, unless you remove the contents of the build directory. That is convenient for incremental work and a trap for a reproducible build, because a stale cache in a directory you thought was clean will silently keep an old configuration.

The run command uses the engine's original console syntax rather than a set of new flags:

./dhewm3 +set fs_basepath /path/to/your/doom3/

That `+set` prefix and the `fs_basepath` variable are inherited from the id engine of that era, which is a small sign of how faithful the port is to the original's conventions.

OpenAL Soft is mandatory, libcurl is not, libbacktrace only helps you debug

The dependency list is short, and the reasons the README gives are more useful than the list itself.

OpenAL is required, and the implementation matters. The README is blunt about it: OpenAL Soft is required, and Creative's and Apple's versions are made of fail. That is an unusual thing to find in a build document and it saves an afternoon, because both of those are the implementations you would otherwise get by default on the two most common desktops. The failure mode without a working OpenAL is also not subtle, but knowing it in advance saves the debugging.

SDL is required at version 1.2 or 2.0, with 2.0 recommended, and it is what replaced Doom 3's original windowing, OpenGL and input layers. libcurl is optional and only matters for server downloads, so a build without it is a build that cannot fetch anything over the network and is otherwise complete. The apt line above installs `libcurl4-openssl-dev`, and the README notes that other `libcurl*-dev` packages work or that you can omit it entirely.

The third dependency is the one most people have never heard of. On non-Windows systems, libbacktrace is optional, usually linked statically, and its only effect is diagnostic: if it is available, dhewm3 prints more useful backtraces when it crashes. Where it comes from varies by distribution, which the README spells out because getting it wrong is a common source of confusion. On Debian-derived systems such as Ubuntu it is part of libgcc, so it is always there. On Arch Linux and openSUSE it is a separate package that you may have to install by hand.

That is a reasonable design for an optional crash reporter, and it also tells you something about the port's priorities. The dependency set is deliberately minimal so that dhewm3 builds on a POSIX system with a package manager, which is the whole portability claim.

No game data, a required 1.3.1 patch, and the BFG Edition gap

The legal and packaging boundary of this project is stated early and clearly, and it is the part of the README most likely to save you time.

The source release contains no game data. The data is still covered by the original EULA and must be obeyed as usual, which means dhewm3 ships code and you supply the content you are entitled to. Beyond that, there is a hard requirement: you must patch the game to the latest version, 1.3.1, and the FAQ covers the details including how to get the game data from Steam on Linux and macOS, which is a non-obvious procedure because Steam's copy is not laid out the way the engine expects.

What you need on disk is specific. The path you pass to `fs_basepath` is your Doom 3 installation, and it must contain a `base/` directory holding `pak000.pk4` through `pak008.pk4`. Nine archive files, and the engine wants them laid out in the original arrangement rather than in whatever form your store delivers.

The one hard incompatibility is the BFG Edition. The README notes that the original Doom 3 and Doom 3: Resurrection of Evil are available from the Steam Store, and groups the BFG Edition with them while stating in the same breath that it is not supported by dhewm3. That is a code-line difference rather than a data difference, so no amount of patching or file arrangement gets you there.

For anyone deciding whether to use this port, that single fact settles the question in one direction or the other. If your copy is the BFG Edition, dhewm3 is the wrong port and no amount of build work changes that. If it is Doom 3 or Resurrection of Evil, the port covers it, and the FAQ plus the Mod SDK repository are where the remaining questions live.

Windows has three routes, and the prebuilt libraries are a separate repository

Windows is the one platform where the README offers a genuine choice, and the choice is about dependencies rather than about the port itself.

The first option is to use the provided binaries, which the README marks as recommended, and those binaries do not live in this repository. They are in `dhewm3-libs`, a separate repository to clone, and it is organised by target architecture with an `i686-w64-mingw32` folder for 32-bit and an `x86_64-w64-mingw32` folder for 64-bit. You point CMake at the appropriate one with the `DHEWM3LIBS` variable:

cmake -G "Visual Studio 16 2019" -A Win32 -DDHEWM3LIBS=/path/to/dhewm3-libs/i686-w64-mingw32 /path/to/repository/neo

For 64-bit output the same command takes `-A x64` and the `x86_64-w64-mingw32` path instead. Note the shape of this: the generator is a Visual Studio generator, while the libraries being linked are MinGW-w64 builds, so you are producing Visual Studio output against prebuilt cross-compiled dependencies.

The second option is to compile those libraries yourself, which is the path to take if you need a version of a dependency that the repository does not carry, and it is the one that turns a Windows build into a real project.

The third is vcpkg, Microsoft's own C++ package manager, with one instruction attached: set `CMAKE_TOOLCHAIN_FILE` as described in the vcpkg getting started guide. That is the option a Windows developer is most likely to already have set up, and it is also the only one of the three that gives you version resolution rather than a fixed set of binaries.

Across all three, the build stays out of source and keeps pointing at `neo/`, which is the one convention that does not change between platforms.

dhewm3 against stock Doom 3, and against the BFG Edition

Two comparisons, and the first one is not really a comparison.

Against the original Doom 3, dhewm3 does the same thing with different plumbing. The original has per-platform audio backends, no 64-bit mode, narrower display support, a build system that is not portable, and no gamepad support. dhewm3 replaces the audio layer with OpenAL, adds a 64-bit port, replaces the platform layers with SDL, and builds with CMake anywhere CMake runs. If you are on Windows and your copy of Doom 3 runs, the question is why you would switch, and the honest answers are the 64-bit build, the settings menu, widescreen support, or the dedicated server. If you are on Linux, macOS or FreeBSD, the original is not a practical option and dhewm3 is the only one of the two.

Against the BFG Edition, the answer is that dhewm3 is not an option, as the README says outright. That edition is a different line of code, and dhewm3's rule about not altering the original gameplay is anchored to the Doom 3 and Resurrection of Evil codebase. Someone who owns the BFG Edition and wants a modern port has to look elsewhere, and pretending otherwise wastes their time.

There is a third comparison that is not about a competing port but about scope. dhewm3 is a source port with a mod SDK and a supported mods list on its website. It is not a total conversion, not a remaster, and not a re-release. If what you want is the original 2005 experience preserved while running on a current operating system, it is a good fit. If you want remastered visuals, a new campaign, or modern netcode expectations, it is the wrong project, and the rule about not altering gameplay means it will never become that project.

GPL-3.0 in COPYING.txt, and five months between a release candidate and the release

The licence is the GNU General Public License version 3, and the file carrying the text is named `COPYING.txt` rather than `LICENSE`. That is the GNU convention and it is the correct name for a GPL project, but it is worth knowing if you run a licence scanner over your dependencies looking for a file called LICENSE, because this one will be reported as missing. `Changelog.md` and `Configuration.md` are both in the tree as well, which means the changelog and the gamepad and settings-menu documentation live in the repository rather than on the wiki.

The release process is unusually visible. The three most recent tags are 1.5.5_RC2 on 2026-01-26, 1.5.5_RC3 on 2026-03-16, and 1.5.5 on 2026-06-08, with the last push to the repository on the same day as the final release. Three release candidates across five months is a long stabilisation window for a single-player game engine, and the reason is not hard to guess: this is software that has to run correctly on four operating systems, against two OpenGL generations, with optional dependencies, on hardware ranging from x86 laptops to Raspberry Pi class ARM boards.

The tag naming is inconsistent while doing it. The candidates use an underscore, `1.5.5_RC2`, while the final tag is plain `1.5.5`. Any script that parses these tags has to handle both forms, and a user looking for the newest build by sorting tags as plain version strings will order the candidates and the release incorrectly.

The maintenance picture otherwise reads as steady. A source port with an active release process, a documented build, separate repositories for the SDK and the Windows libraries, and a website carrying the supported mods list has more institutional structure than most ports of this age. The one thing to keep in mind when you read the numbers is that the project is under active release work, so what you compile from master today is not necessarily what 1.5.5 contains.

Editorial conclusion

Build dhewm3 from source when you want Doom 3 on a platform the original does not handle, or when you want the dedicated server built with -DDEDICATED=ON, and follow the README's own path of pointing CMake at the neo/ directory from a build folder outside the repository. Do not start from the BFG Edition, which the README states dhewm3 does not support, and do not expect the source tree to contain playable data, because it contains none and the data remains under the original EULA. Verify first by running cmake -LH ../neo/ to see the available options, installing OpenAL Soft rather than the platform implementation, and confirming your Doom 3 installation is patched to 1.3.1 with base/ containing pak000.pk4 through pak008.pk4.

Frequently asked questions

Official sources

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