GZDoom: the OpenGL and Vulkan source port carrying the Doom modding scene

What separates GZDoom from the plain Doom engine

The README describes GZDoom as a modder-friendly OpenGL and Vulkan source port based on the DOOM engine, and that phrase is doing a lot of work in a small space. A source port is not a game. It is the machinery that loads data files and runs them, and the base engine it is built on is what the original 1993 Doom release shipped. GZDoom is a fork of ZDoom, which was itself the community continuation of that engine.

What it adds is a hardware renderer and a scripting layer. The engine keeps the original game's data format working, which is the whole point for a modding scene, and adds modern display output on top. The README credits the copyright to the ZDoom and GZDoom teams from 1998 to 2025 and, separately, to id Software and Raven Software for the Doom source from 1997, which is the usual shape of attribution for a project that carries forward decades of community work.

The repository description in the metadata says it is feature centric, and the tree backs that up with dedicated directories for the interesting parts rather than a flat engine dump.

The directories that show how the engine is organized

There are five `wadsrc` directories at the top level: `wadsrc/`, `wadsrc_bm/`, `wadsrc_extra/`, `wadsrc_lights/` and `wadsrc_widepix/`. Those hold the source material for the bundled game content, split up by purpose, which is a good sign about how the project is organised. A renderer with only one source tree tends to accumulate variants in the same place over years.

`src/` is the engine itself and is where the changes live. `libraries/` holds vendored third-party code, and `vcpkg.json` at the root is the C++ dependency manifest, which is how modern Windows builds resolve their libraries rather than by hand-listing them.

`cmake/` alongside a root `CMakeLists.txt` is the build system. There is also `tools/`, which holds command-line utilities rather than engine code, `specs/` for the engine's behavioural specifications, `fm_banks/` for sound banks, and `soundfont/` for the MIDI soundfont handling. Two entries stand out as signals of intent rather than structure: `unused/` suggests dead code that is kept for reference instead of deleted, and `options.checklist` at the root looks like a tracking file for command-line options. `SECURITY.md` and `.devcontainer/` round out a repository that has settled into a normal open source project shape.

Building it means going to the wiki

The build section of the README is four lines long and none of them is a command. It says to see the wiki, then to look for Programmer's Corner at the bottom right of the page, to build for your platform. That is the entire instruction.

This is unusual for a project of this size and it is worth being clear about what it means. There is no `make install` line to copy, no toolchain version pinned in the README, and no list of build dependencies. Everything a new contributor needs is behind a link to zdoom.org, and the wiki is a separate property that can change independently of the repository.

For an established contributor that is fine. The wiki has presumably been maintained alongside the code for years, and a link to a living document beats a command list that rots. For someone evaluating the project, the practical test is whether the Programmer's Corner still has current instructions for your platform, and whether its toolchain requirements match what the `cmake/` directory and `vcpkg.json` expect. The repository gives you no way to check that from the README alone.

The one thing the repository does give you is the dependency manifest. `vcpkg.json` is a real, inspectable answer to what the engine expects to link against, and it is the better starting point for a build attempt than guessing from the wiki.

Release cadence and what the version tags say

Three releases are on record: `g4.14.0` on 2024-12-17, `g4.14.1` on 2025-03-01, and `g4.14.2` on 2025-05-03. The patch numbering within 4.14 is normal for an engine, where the 4.x major tracks the engine generation and patches fix things without breaking mod compatibility.

The gaps are what matter. Four and a half months between 4.14.0 and 4.14.1, then two months to 4.14.2, and then nothing tagged for the roughly fifteen months between 2025-05-03 and the last push on 2026-08-10. Development is clearly still happening. The commits are landing and no release has been cut from them.

That is a meaningful distinction for someone pinning a version, and the repository gives you no changelog to check it against. There is no `CHANGELOG.md` in the tree, so what changed between 4.14.2 and the current `master` is only visible in the commit history and in the release notes on the site. The `g` prefix on the tags is itself informative, marking them as GZDoom releases rather than engine-wide ones.

Anyone shipping a mod distribution should decide deliberately between the last tagged build and `master`, because the gap is long enough that `master` contains real work.

Where GZDoom is the right tool and where it is not

The case for it is specific: you are making a Doom engine mod and you need something beyond vanilla rendering and behaviour. The hardware renderer, the scripting layer and the community's existing mod corpus all point the same way, and the fact that the engine is still being worked on in 2026 says the format is not frozen.

The case against is equally specific. If your goal is to play existing mods, you do not need a source port at all, and the wiki links to a Discord and a download page that serve that audience. Compiling a C++ engine with CMake and a Windows dependency manifest is a poor way to install something.

There is also a licensing dimension worth stating plainly rather than advising on. The README puts the source under GPL v3, and notes that individual contributors hold their own licences, which is the usual arrangement for a project of this age and composition. A game or commercial product that bundles the port inherits the copyleft conditions attached to it. That is a fact about the licence, not legal advice, and it is the kind of thing that belongs in an evaluation rather than discovered after release.

The project description calls GZDoom feature centric, and the same README asks users to check the Programmer's Corner before building. Both statements are consistent: this is a capable engine maintained for people who intend to build on it, not a convenience wrapper.

Editorial conclusion

GZDoom suits anyone who wants to write or run Doom engine mods and needs a renderer beyond the original 320x200 software output, and the repository is genuinely active, with the last push on 2026-08-10 following the g4.14.2 release on 2025-05-03. Its limits are real: the README does not contain a single build command, so the wiki's Programmer's Corner is a hard dependency rather than a convenience, and the GPL v3 licence means a game that ships the port inherits copyleft obligations. If you only want to play Doom mods, a packaged binary is the better route. If you want to change the engine, start from the Programmer's Corner build path and read the specs directory, which is where the engine's actual contracts live.

Frequently asked questions

Official sources

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