# Yamagi Quake II: a conservative, 64-bit clean Quake II client > Yamagi Quake II is a C source port of id Software's Quake II maintained by the Yamagi community, focused on offline and coop play, with an OpenGL 3.2 renderer, an OpenAL sound backend and modern controller support. It descends from Icculus Quake II and Quake II 3.21, is fully 64-bit clean, and refuses breaking changes by policy. The build is a plain make against SDL 2 or SDL 3, and official releases are irregular while CI produces unsupported binaries on every commit. **yquake2/yquake2** — The Yamagi Quake II client - Repository: https://github.com/yquake2/yquake2 - Website: https://www.yamagi.org/quake2/ - Stars: 1,014 · Forks: 255 - Language: C - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/yquake2-yquake2 ## What Yamagi Quake II is and where it came from Yamagi Quake II is an enhanced client for id Software's Quake II with a focus on offline and coop gameplay. That framing is deliberate. The project is not trying to be a remaster, a rebalance or a re-release. The gameplay and the graphics are unchanged, and what you get instead is a client that runs correctly on modern machines. The lineage is stated plainly in the README. The code is built upon Icculus Quake II, which itself is based on Quake II 3.21. So this is a maintained fork of an existing source port rather than a from-scratch reimplementation, and every bug fixed upstream in Icculus arrives as a starting point rather than as work to be repeated. The headline engineering claim is that, unlike most other Quake II source ports, Yamagi Quake II is fully 64-bit clean, and that it works perfectly on modern processors and operating systems. A 64-bit clean build is not just a compiler flag. It means the data types, the pointer arithmetic and the file format handling were converted rather than cast, which removes the class of bugs where a 32-bit assumption quietly truncates a value on a system that no longer has that limit. The officially supported operating systems are FreeBSD, Linux and Windows, and beyond those there is community support for macOS and most other unixoid systems, including NetBSD, OpenBSD and Solaris. ## The features that were added on top of the original release The README states that many bugs in the last official release were fixed, and that a set of nice to have features were added. Listing them is the fastest way to understand what the port is for. Widescreen support is one of them, which matters because the original Quake II assumed a 4:3 display and either letterboxed or stretched on anything else. Reliable support for high framerates is another, and the word reliable is doing work there: the original game was tied to a timer that produced stutter and timing artefacts on modern hardware. The sound backend was rewritten on OpenAL, and support for modern game controllers was added, both of which address input and output devices that no longer exist in their original form. The renderer is the largest change. A modern OpenGL 3.2 renderer was added, and the build produces several renderer libraries, gl1 for the original style, gl3 for the modern OpenGL path and soft for a software fallback. Keeping gl1 is a good sign for a project with a conservative policy, because it means the behaviour players remember is still reachable. The set of changes is a compatibility list rather than a feature list. Nothing in the README suggests that the goal was to make Quake II play differently. ## Building the client, the server and the three renderers The Makefile header tells you exactly what a plain build produces. Typing make compiles the client, the server, the game and the renderer libraries. ```bash make ``` The outputs are the quake2 client, the q2ded dedicated server, the baseq2 game module and the renderer libraries gl1, gl3 and soft. Having a dedicated server in the same build tree as the client is unusual for a game of this age and is what makes the coop focus practical, since q2ded gives you a headless server for a LAN session or a community server without giving up the client. The dependency list is short. The base dependencies are SDL 2 or SDL 3, libGL and Vulkan headers, and the optional ones are CURL and OpenAL. ```bash # Base dependencies: # - SDL 2 or SDL 3 # - libGL # - Vulkan headers # Optional dependencies: # - CURL # - OpenAL ``` The Vulkan headers are a base dependency even though the renderer described in the README is OpenGL 3.2, which suggests a Vulkan path exists in the tree or is being prepared. The Makefile also exposes build switches worth knowing. An ASAN option builds with the address sanitizer and includes DEBUG, a DEBUG option forces -O0 and adds debug symbols, and MINGW_CHOST sets the architecture when cross-compiling on MinGW, with x86_64-w64-mingw32 given as the example. A CMakeLists.txt sits at the repository root as well, so a CMake path exists alongside the Makefile for platforms where that is the more natural route. ## A conservative policy that shapes what you can expect The README is unusually direct about how the project handles contributions. It is a community driven project that lives from community involvement, and it is always open to code contributions, whether they are small bug fixes or bigger features. The qualifier that follows is the important part: the project is conservative, with a big focus on stability and backward compatibility, and it does not accept breaking changes. That single sentence explains a lot of the repository's character. A port that promises backward compatibility cannot change configuration file formats, cannot change the game protocol, and cannot remove the old renderer without a migration path. It also means the upstream contribution bar is about not breaking other people, and the README tells contributors to open an issue and ask before investing a lot of work in a patch. The documentation reflects the same care. There is an extensive documentation set covering installation, configuration and package building, indexed at doc/010_index.md in the repository, plus a dedicated contributors guide at doc/080_contributing.md, and the numbering shows a curated structure rather than an accumulated pile of notes. For a user, the practical effect is that a Yamagi build is predictable. It will not surprise you with a config format change, and a packaged distribution from a Linux distribution is a safe bet for a long-lived installation. ## Where Yamagi Quake II is the wrong choice The first limitation is that the content is not here. This repository is the client, the dedicated server and the game module. The official addons live in their own repositories, The Reckoning, Ground Zero and ThreeWave's Capture The Flag, each under the yquake2 organisation, and Quake II Remaster asset support lives in a separate Yamagi Quake II Remaster repository. If what you want is the add-on content, you are assembling several repositories, and if you want the Remaster assets you are choosing a different project with a less conservative approach to new features. The second limitation is the release cadence. The README says the project releases at an irregular schedule, and the official releases with source tarballs and prebuilt Windows binaries are on the project homepage rather than in the repository, which has no GitHub releases. The mitigation offered is the CI, which builds unsupported Linux, macOS and Windows binaries at every commit and publishes them as GitHub Actions artifacts. Useful for testing, explicitly not supported for daily play. The third limitation is the unchanged content. The README is clear that the gameplay and the graphics are unchanged, so if you wanted something new to play, this is not the source port. The Remaster project exists precisely because that conservatism holds back newer features. The fourth limitation is the dependency floor. SDL 2 or SDL 3, libGL and Vulkan headers are required, so a headless or minimal container needs those libraries present even for the dedicated server build. ## Yamagi Quake II next to Icculus Quake II and the Remaster branch The comparison that clarifies the choice is against the other source ports of the same game, because they solve the same problem with different priorities. Icculus Quake II is the direct ancestor named in the README, and the relationship is a fork rather than a rival. Anything Icculus fixes, Yamagi inherits, and Yamagi adds on top in the form of the 64-bit clean build, the modern renderer, the OpenAL backend and the controller support. If you already run Icculus and it works on your hardware, the reason to switch is one of those additions or the 64-bit work, and the reason to stay is that Icculus is upstream for the codebase and you would be tracking a fork's additional churn. The Remaster project is the fork in the other direction, and the README describes it as taking a less conservative approach in regards to new features while providing optional support for the assets of Quake II Remaster by Nightdive Studios. Same codebase, different policy about how far the feature set may move. The third path is a modern engine rather than a source port, the kind of project that re-implements Quake II on a current renderer with new assets. That approach gives you a maintained codebase on modern graphics APIs and none of the original game's constraints, and it also abandons the exact gameplay and the coop netcode that the original release defined. Yamagi sits deliberately on the near side of that divide, and the point of it is that a game you remember runs on the machine in front of you. ## Licence, support and the state of the tree The README states that Yamagi Quake II is released under the terms of the GPL version 2, with the LICENSE file in the repository root holding the full text. GitHub's own licence classifier does not recognise the licence field for this repository, so the LICENSE file is the authoritative source for the terms rather than a label shown on the repository page. A GPL v2 grant on a source port means the modified source has to be offered alongside any binary you distribute, which is a normal condition for this class of project and not a complication for the ordinary case of running the official build yourself. The code is C, and the project is not archived, with the last push on 2026-10-15, so the tree is actively worked on even though the release tags are irregular. Bugs go to the issue tracker, patches go through pull requests, and the README invites contributions of any size while asking that large ones be discussed first. The CHANGELOG file at the repository root and the numbered documentation set give you the two things you need when picking up a build from an unofficial channel: a record of what changed, and the configuration and packaging notes that the documentation index points to. The doc/010_index.md entry is the right first stop if you are packaging the client for a distribution or a container, because the README says the documentation covers installation, configuration and package building. ## Conclusion Adopt Yamagi Quake II if you want to run the original Quake II and its official addons on a current 64-bit system with modern controllers, a widescreen option and no source port churn, and if you are comfortable compiling it or waiting for an irregular release. Skip it if you want the newest Quake II derived game, since the project deliberately keeps gameplay unchanged. Before building, run make in a checkout and check the doc/010_index.md documentation index for the client configuration, because the client and the three official addons ship as separate repositories. ## FAQ ### What is Yamagi Quake II and what does it add to the original game? It is a source port of id Software's Quake II that keeps the gameplay and graphics unchanged while fixing bugs from the last official release and adding widescreen support, reliable high framerates, an OpenAL sound backend, modern controller support and an OpenGL 3.2 renderer. ### How do you build Yamagi Quake II from source? Type make in the repository root. That compiles the quake2 client, the q2ded dedicated server, the baseq2 game module and the gl1, gl3 and soft renderer libraries, and it needs SDL 2 or SDL 3, libGL and Vulkan headers. ### Which operating systems does Yamagi Quake II support? FreeBSD, Linux and Windows are officially supported, and there is community support for macOS and other unixoid systems including NetBSD, OpenBSD and Solaris. ### What licence is Yamagi Quake II released under? The README states the GPL version 2, and the LICENSE file in the repository root holds the full text, since GitHub does not classify the licence field for this repository. ### Where are the Quake II addons and the Remaster support? The official addons, The Reckoning, Ground Zero and ThreeWave's Capture The Flag, each live in their own repositories under the yquake2 organisation, and Quake II Remaster asset support lives in the separate Yamagi Quake II Remaster repository. ## Sources - [Issues](https://github.com/yquake2/yquake2/issues) - [Project website](https://www.yamagi.org/quake2/) - [README](https://github.com/yquake2/yquake2/blob/master/README.md) - [yquake2/yquake2 on GitHub](https://github.com/yquake2/yquake2) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yquake2-yquake2