qengine: the Quake II fork stripped down to a software-rendered game engine

A fork whose main feature is what was deleted

qengine is described as a cross-platform retro game engine aimed at nostalgic game developers that miss simple times and enjoy creating games like it's 1997.

What makes it interesting is that the project describes its own diff as the feature. The software renderer provides the aesthetic that we all love and the engine limitations exist to make your creativity shine. The engine is a fork of the Quake II codebase that focuses on serving as a base for standalone games. Unlike other ports, it does not aim at being compatible with mods or the base Quake II game. In fact, many features were removed to reduce the complexity of the codebase and make the process of creating new games on top of the engine easier and faster.

That is a rare and legitimate position for a game engine fork. Most Quake II forks exist to keep a game alive with better hardware support, and they retain the original game so the community can keep playing it. This one goes the other way: the Quake II game is a liability, because the enemies, the weapons and the level design are exactly the parts a new developer has to delete before they can build anything.

The list of notable changes is short and decisive. Removal of overly specific gameplay code, such as enemies and weapons. Merge of modules into a single package, so there are no more DLLs, just a single executable for the client and another for the server. Removal of OpenGL. And minimal dependencies.

The screenshot linked in the README shows the result, and the topics attached to the repository name the target: 3d-engine, 3d-game, fps, game-development, game-engine, gamedev and linux.

No OpenGL means one renderer to reason about, and a cost

The OpenGL removal is the decision with the widest consequences, and it deserves more than a line.

Modern Quake II ports carry two renderers, a hardware one and a software one, and the hardware one is where the platform churn lives. Every driver update, every windowing system change, every API deprecation lands in that path, and it is the reason the lineage of Quake II forks is a long list of graphics fixes. Removing OpenGL removes that entire surface.

What is left is a software renderer that draws the same geometry, which means the engine behaves the same on every machine. A game built on qengine looks like a 1997 game on every computer, including a laptop from 2026 with a GPU it will never use. For a project whose stated purpose is the aesthetic of that era, that is a coherent trade rather than a limitation.

The cost is that you get the old look by default. There is no hardware accelerated path in the engine, so a modern game with high resolution textures, dynamic lighting and thousands of sprites is not what this renderer is for. The engine limitations exist to make your creativity shine, as the documentation puts it, and the renderer is one of the most visible of them.

The minimal dependencies line follows from the same logic. Fewer libraries means fewer ports to maintain, and the project goal of improving stability across different platforms is easier to hold when there is less platform-specific code to hold stable. The fork descends from Yamagi Quake II, which the documentation credits as the code it is built upon, and that in turn contains code from Hecatomb, Icculus Quake 2, KMQuake2, Q2Pro, QuDoS, r1q2, stereo quake and zeq2. The project is explicit that it stands on the shoulders of giants from the Quake II community, and the list of ancestors is long enough that the credit is not decorative.

Building it is CMake, and Windows binaries come from Linux

The build is a plain CMake project, and the documentation gives the sequence without much ceremony. You make a build directory, change into it, run cmake against the parent, then make.

$ mkdir build
$ cd build
$ cmake ..
$ make

There is one option worth knowing about. If you do not want to build the docs, or you do not want to install the dependencies they require, you can pass -DBUILD_DOCS=OFF to cmake, and then run make as usual.

$ cmake -DBUILD_DOCS=OFF ..
$ make

The Windows build is where the project adds something specific. Windows binaries are built from Linux with mingw-w64, and on Debian and Ubuntu the toolchain comes from the gcc-mingw-w64-x86-64 and g++-mingw-w64-x86-64 packages.

$ cmake -B build -DCMAKE_TOOLCHAIN_FILE=cmake/mingw-w64.cmake
$ cmake --build build

Two details in the documentation matter for a release. This creates client.exe, server.exe and the tools under build/tools. And SDL2.dll is copied next to client.exe and has to ship with it. That second point is the kind of packaging detail that trips up a release, since a missing DLL turns a working game into an error dialog on somebody else's machine.

The repository layout is consistent with a conventional C project: a CMakeLists.txt at the root, a cmake directory for the toolchain files, a src directory, a docs directory, an assets directory, a vendor directory, a .clang-format file, and a .github directory holding the build workflow that the README's build status badge points at.

The asset pipeline is the part you inherit whole

The tools section is what makes this fork genuinely useful rather than merely interesting, and it is worth reading as a list of jobs you would otherwise have to do.

The mapping tools are qbsp3, qrad3, qvis3 and bspinfo. The texture tools are pcx2wal, pcx2pal, colormap and 16to8. The user interface tools are uigen and fontgen. And there is a packaging tool called pak.

The texture tools are the ones that show how the 1997 look is produced rather than imitated. The engine works with a 256 colour palette, and the colormap.pcx file is a 256x320 colour re-arrangement of those colours, resulting in 64 shades of each. So a base palette of 256 hues becomes a 256 by 320 table giving each hue 64 brightness levels, and the software renderer samples that table.

That is the trick, and it is exactly the trick the era used. A GIMP palette is included at assets/palette.gpl to facilitate creation of new graphics, and if you want more creative freedom you create a PCX file with the 256 colours you have chosen and then run two tools:

$ tools/pcx2pal palette.pcx palette.pal
$ tools/colormap palette.pal colormap.pcx

The map pipeline is the standard Quake II one, and the documentation shows the order:

$ tools/qbsp3 assets/maps/sample.map
$ tools/qvis3 assets/maps/sample.bsp
$ tools/qrad3 assets/maps/sample.bsp

First the map is compiled into a BSP, then visibility is computed, then the lightmaps are radiated. Getting that order right matters, because qrad3 needs the visibility data that qvis3 produced, and the documentation lists them in the right sequence.

In order to run, the engine needs a few base assets, such as sounds, models and UI textures, and most of them are already included in the assets folder. The remaining gap is the game data itself, which is where the licence question comes up, and it is covered separately.

Game data is the part you have to bring yourself

The running section is two sentences and one condition.

The engine will look for game data in the assets folder. You can start from scratch, or use the original Quake II game data if you own it.

That conditional clause is the whole of the licensing story for the data, and it is worth being precise about what it does and does not say. The engine code is GPL version 2, and the LICENSE file is in the repository. The original Quake II game data is a separate thing, owned by its rights holders, and the documentation is careful to say you may use it only if you own it. It does not say the data is GPL, and it is not.

So a developer building a standalone game on qengine has two clean paths and one to avoid. The first path is to start from scratch, authoring your own sounds, models, textures and maps, which the included assets give you a head start on for the engine's own needs. The second is to use the original game data, which requires owning it and means your distribution is now carrying data you did not author and did not license under the GPL.

The third path is the one to avoid, and it is the one people take by accident. Because the fork descends from Quake II, the engine's format expectations match the original data formats exactly, which makes it easy to find and drop in data without owning it. The documentation does not license that data, and the engine licence does not cover it.

The stated goals of the project are worth quoting because they show where the effort goes. Provide a clean and maintainable base game engine. Improve stability across different platforms. Enhance the software renderer. And improve documentation of asset pipeline. The last one is the most telling: a project that expects people to author their own assets is a project that has to make the asset pipeline legible, and the four goals in order of emphasis say the base engine and the pipeline matter more than the renderer.

A project whose release history says almost nothing

The version history is the thing to weigh before you adopt this, and it deserves to be read carefully rather than charitably.

The recent releases are 0.1.1 and a nightly build, both dated 2022-07-25, and before that 0.1.0 from 2018-07-22. So the project has two tagged versions in its history, one of them in 2018 and one in 2022, and a nightly tag published the same minute as 0.1.1.

The last push to the repository was on 2026-08-24 and the repository is not archived. So there is activity, four years after the last tag. That combination is a specific situation: a codebase that still receives commits but has no release process you can rely on for a version number, no changelog to check against, and no binary to download.

For a game engine that is a different kind of risk than for a library. A library you pin, a game engine you build. If you take qengine as a base for a game you intend to ship, you are forking a project at whatever commit you choose, and you are responsible for the security, the platform support and the fixes from that point. The GPL-2.0 terms permit that without any special arrangement.

The project goals, a clean and maintainable base engine and improved stability across platforms, are the right goals for a project in that position, and the fact that the goals include improving documentation of the asset pipeline suggests a maintainer who knows the engine's usefulness depends on people being able to author for it.

The build status badge points at a GitHub Actions workflow, so the code does at least compile somewhere automatically. Whether a fork should rely on that, given the release history, is a decision you have to make for yourself.

Where qengine is the wrong base

Three situations rule it out, and none of them is about the quality of the fork.

The first is if you want Quake II. The project is explicit that it does not aim at being compatible with mods or the base Quake II game, and the removal of enemies and weapons is not a bug to be fixed, it is the point. A player who wants the original game with better hardware support wants a different fork entirely, one of the many in the Quake II family that the documentation credits.

The second is if you need hardware rendering. There is no OpenGL in this engine, by design, and the software renderer is a deliberate aesthetic choice rather than a placeholder. A modern game, or a VR title, or anything with a large asset budget, is out of scope for a renderer that draws through a 256 by 320 colour map.

The third is if you need a maintained engine with a community behind it and a documented release cadence. Two tags in eight years is not a cadence, and a game project with a release deadline cannot wait for the next version. Anyone in that position should pick a fork that still ships releases, and the credits section of the README is a good place to find the candidates.

The alternative that is worth naming is not another fork but the original codebase. If you want the Quake II engine as a base and are prepared to do the cleanup yourself, taking Yamagi Quake II and removing the parts you do not want is the same work qengine has already done, and it comes with a project that does publish releases. qengine's value is that the deletion is done, the tools are documented, and the software renderer is the point rather than a fallback.

Editorial conclusion

qengine fits a developer who wants to build a standalone first person game with a 1997 look and does not want to write a renderer, a BSP pipeline, a texture converter and a client from scratch, because all of that arrives with the fork. It is the wrong choice for a project that needs the Quake II game itself, its mods or its assets, since the project explicitly does not aim at compatibility and removed the gameplay code, and it is the wrong choice if you need a maintained engine with a community behind it. Before building on it, check the last push on 2026-08-24 against the 0.1.1 release from 2022, decide whether the GPL-2.0 terms fit your distribution plans, and confirm your own assets, because the engine needs base assets and the documentation says you may use the original Quake II game data only if you own it.

Frequently asked questions

Official sources

1. Issues
2. klaussilveira/qengine on GitHub
3. License: GPL-2.0
4. README
5. Releases