UZDoom, a GZDoom continuation split across five wadsrc trees

A continuation chain that ends on the trunk branch

UZDoom is a source port for Doom engine games written in C++, and it declares its ancestry in its own text: a continuation of ZDoom and GZDoom, with links back to https://github.com/rheit/zdoom/ and https://github.com/ZDoom/gzdoom/. The project description narrows the gap it means to close, calling it a feature centric port that adds an advanced renderer and scripting capabilities on top of GZDoom. For someone maintaining a large mod, the concrete list matters more than the pitch: high-resolution graphics, dynamic lighting, 3D floors and extensive modding support. Work lands on `trunk` rather than the master branch, which matters to anyone scripting a continuous integration job against the wrong branch name.

OpenGL and Vulkan, with no documented default between them

The renderer is the headline feature and the least documented part. The README names two modern backends, OpenGL and Vulkan, and stops there. Nothing in it says which one runs when a machine can do both, what driver versions are required, or how a user selects one, and no configuration key is shown for that choice anywhere in the repository listing. A host without a usable GPU therefore has no documented path: there is no named software-rendering fallback, no headless switch and no sample configuration file to copy. The same silence covers shader requirements and resolution limits, the two questions a server operator or a build runner would ask first.

The build recipe lives on a wiki, not in the repository

No install command appears in the README, so nothing here can be pasted into a terminal. Builders are sent to the project's own GitHub wiki for the dependency list and detailed instructions, split into one page per platform:

https://github.com/UZDoom/UZDoom/wiki/Compilation#linux
https://github.com/UZDoom/UZDoom/wiki/Compilation#windows
https://github.com/UZDoom/UZDoom/wiki/Compilation#macos

The root does hold the scaffolding those instructions consume: `CMakeLists.txt`, a `cmake/` directory, plus `libraries/` and `tools/` alongside it. Formatting and line-ending rules are committed as `.clang-format`, `.editorconfig` and `.gitattributes`, and a `continuous_integration.yml` workflow under `.github/` builds the tree on push. Expect to read the wiki page before the first build; the root listing shows what the build takes, not the order to feed it.

Five wadsrc trees split the resource data by purpose

Assets are divided across five sibling trees at the root: `wadsrc/`, `wadsrc_bm/`, `wadsrc_extra/`, `wadsrc_lights/` and `wadsrc_widepix/`. Two names echo the features the README advertises, since `wadsrc_lights/` sits beside dynamic lighting and `wadsrc_widepix/` beside high-resolution output, which gives a mod author an obvious first guess for where each resource belongs. The BM in `wadsrc_bm/` is expanded nowhere in the README or the root listing, and that definition has to be dug out of the wiki before files go in. A directory named `unused/` sits next to `src/`, and nothing at the root explains what was moved into it or whether the build still reads it. `soundfont/` and `fm_banks/` show bundled audio data, not a bare code layout.

Two Weblate projects split engine text from game strings

Localisation runs on Weblate through two separate projects, `uzdoom` for the engine and `doom-engine-games` for the text inside the games, each carrying its own status widget in the README. Splitting them lets a fork move engine strings and game strings on separate schedules, and it also means translator work happens on hosted.weblate.org rather than in a pull request. The support links tell the same story from the other side: the home page, wiki, Discord at `dsc.gg/zdoom` and forum at `forum.zdoom.org` all belong to the upstream community site, while build instructions for this codebase live on its own GitHub wiki. Two documentation homes, and only one of them describes this tree.

Where the stated terms and the platform label disagree

GitHub's own licence selector for this project reads as a custom licence it cannot classify, yet the Legal section of the README states GNU General Public License (GPL) version 3 or any later version (GPLv3+), so the label and the written terms disagree and only the LICENSE file at the root settles it. That section also disclaims any warranty and carries five copyright lines: 1993-1996 for id Software, 1999-2016 for Marisa Heit, 2002-2016 for Christoph Oelckers, 2017-2025 for the GZDoom maintainers and contributors, and 2025-2026 for the UZDoom maintainers and contributors. Artwork is handled apart from code, with the UZDoom Icon drawn by Carlos "Cardboard Marty" Sanchez, credited to the UZDoom Team and put under Creative Commons BY-SA 4.0.

Blame skips some commits, and trunk is where work lands

`trunk` is the default branch, and `.git-blame-ignore-revs` at the root holds the list of commits that blame is told to skip, which is how a repository-wide reformat or a bulk file move gets kept out of authorship history. The contents of that file are not visible from the root listing, so anyone auditing who last touched a line has to open it before trusting the blame output. The last push to `trunk` landed on 2026-09-28 at 00:08:24Z, the x-preview tag followed six seconds later at 00:08:30Z, and versions 5.0.2 and 5.0.3 were both published on 2026-09-23, about nineteen hours apart. Nothing in the README maps the 5.x numbering onto an upstream GZDoom build, which matters when comparing behaviour or writing a report against the wrong engine.

GZDoom stays the codebase to compare against

UZDoom names GZDoom as the base it builds on, and GZDoom remains the engine most existing mods target, which makes it the only fair alternative to weigh here. The difference is stated in a single sentence and then shown in the tree: UZDoom adds an advanced renderer plus scripting capabilities, carries its own `CMakeLists.txt`, its own `continuous_integration.yml` run, `SECURITY.md` and `CONTRIBUTING.md`, works on `trunk`, and splits assets into five trees. What no document settles is whether a mod written for GZDoom loads unchanged on UZDoom, or whether one backend draws frames faster than the other, since the README publishes no benchmark, frame time or compatibility matrix. For a port, measure that gap on your own assets first.

Editorial conclusion

UZDoom fits a modder who wants high-resolution rendering, dynamic lighting and Vulkan support inside a Doom engine and accepts a wiki as its build manual. It does not fit someone who needs a documented install command, a named default renderer, or a stated mapping between 5.0.3 and an upstream build. Open the terms file at the repository root, place each asset in the right wadsrc tree, and diff your branch against trunk before porting anything from GZDoom. The wiki, forum and Discord it links sit on the upstream community site, so answers found there can describe a different tree.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. UZDoom/UZDoom on GitHub