# vkQuake: a Vulkan Quake port carrying QuakeSpasm's mods, Ironwail's console, and one unsupported CPU

> The feature list is long and the README is honest about the limits: little-endian only, three build systems, and Windows arm64 binaries shipped untested.

**Novum/vkQuake** — Vulkan Quake port based on QuakeSpasm

- Repository: https://github.com/Novum/vkQuake
- Stars: 2,289 · Forks: 285
- Language: C
- License: GPL-2.0
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/novum-vkquake

## What the port is, stated plainly

The README's first paragraph is a two-sentence description and it is accurate. vkQuake is a port of id Software's Quake using Vulkan instead of OpenGL, and it is based on QuakeSpasm and QuakeSpasm-Spiked, which are themselves long-standing community ports. It states that it runs all mods compatible with QuakeSpasm.

That last clause is the sentence that should drive your evaluation, and it sits slightly less prominent than the improvement list that follows it. A Vulkan renderer is a nice-to-have. Mod compatibility is a hard requirement for anyone with an existing Quake installation, because a total conversion can depend on engine behaviour that a rewritten renderer changes. By naming QuakeSpasm and QuakeSpiked as the bases rather than describing itself as a fork of the original engine, the README tells you the lineage and lets you reason about what likely broke and what likely did not.

The third base matters too, and it is easy to miss. Several entries in the improvement list are attributed to QSS, the QuakeSpasm-Spiked fork, rather than to this project: a more modern protocol to avoid certain movement issues, support for custom mod HUDs, support for scriptable particles, and true colour skin support including fullbrights. So the feature list is a mixture of work by three projects, and when you later read a changelog entry you will need to know which fork a change came from to reason about whether a mod will work.

The licence is GPL 2.0 and the language is C, and the repository is a descendant of a codebase that predates most of the tooling you would use today.

## The feature list, sorted by what it costs you

There are around twenty entries in the improvements list, and they are not equal. Sorting them by what they cost the user produces a much shorter list than sorting them by how visible they are.

Free on any machine: a software underwater effect, 8-bit colour emulation, scaling for a pixelated look, native anti-aliasing and anisotropic filtering, better colour precision to reduce banding in dark areas, a mods menu for easier mod loading, true colour support for level textures and static models in PNG, TGA, and JPG, and external WAD support. That last one carries a pull request reference in the README, as does WAD3 format support for per-texture palettes, which is how mods get more colourful levels.

Free but structural: the game can run at frame rates above 72Hz without breaking physics. This is the one most likely to be misread. The original engine's movement was tied to the server tick, so a higher render rate did not simply mean a smoother picture, it changed how movement was simulated. A port that decouples the two is making a claim about netcode correctness, not about graphics, and it is the kind of claim that shows up as a subtle desync bug rather than a crash.

Conditional on hardware: dynamic shadows and dynamic lights both say in the README that they require a GPU with ray tracing support, and dynamic lights additionally require the Dynamic Shadows setting to be medium or higher. Two of the flashiest features on the list are gated behind hardware that a large share of machines playing a 1996 game will not have.

Content-related: support for Classic and Enhanced models, where Enhanced means either MD5 from the 2021 re-release or MD3 as used by Quake 3, with a Models menu option to switch between them when both exist, plus a models menu entry for true colour skins on MD3 and MD5 with fullbrights.

## Ray tracing is both the feature and the compatibility risk

The two ray-traced features and the release history together tell you the real state of things, and they are more informative than any single document in the repository.

The features are recent. The 1.35.0 release notes, published 2026-07-08, add support for the 2021 rerelease dynamiclight entities including spotlight cones using the exact KEX formula, and that note repeats the hardware requirement in its own words. So a rerelease dynamic light and a dynamic light are the same feature, arriving together, with the formula taken from KEX, the unofficial engine extension for enhanced Quake releases. Taking a formula verbatim from another engine is the right call for fidelity and it also means behaviour differences from the enhanced engine are inherited rather than designed.

Then 1.34.1, published 2026-04-02, is described as a fix release addressing a blocking bug where AMD RT-capable cards were unable to start the game. The fix is listed as working around an AMD driver bug, and it shares a release with a GCC 15 and C23 compatibility fix.

Read those two releases next to each other and the pattern is clear enough to plan around. A ray tracing feature introduced an AMD startup failure that took a patch release to work around, and it was worked around rather than made optional. If you have an AMD card and you want dynamic lights, you should install the newest release rather than an older one, and you should be aware that the fix is a workaround against a driver bug whose behaviour may change with future driver versions. If you do not have ray tracing, none of this touches you, which is the practical reason to check the capability before caring about the feature.

Version 1.36.0, from 2026-08-29, is the newest. It adds compatibility for Dawn of the Machine and the 2026 rerelease update, fixes MD5 animation and skinning including the rocket ogres, improves handling of invalid replacement models, corrects localization priority and centerprint wrapping, and adds a laser-cannon binding credited from Ironwail. It also adds a searchable level-selection menu with map descriptions and a skill-selection screen, five new crosshair styles, Classic, Smooth, and xBR filtering options for UI graphics, and a set of console improvements including mouse text selection, clipboard copying, clickable file links, better line editing, tab completion, and a larger command history.

## Ironwail is a second upstream, and the README never says so

Here is a dependency the README does not mention. Multiple entries across the 1.35.0 and 1.36.0 release notes are attributed to Ironwail rather than to this project, and they are substantial rather than cosmetic.

From 1.35.0: order-independent transparency, where overlapping transparent surfaces such as water, glass, sprites, and particles are handled with weighted blended order-independent transparency as the new default and higher quality moment-based transparency available when the option is set to High; Steam integration covering achievements, rich presence, screenshots sent to the Steam library, and automatic location of Steam, GOG, and Epic Quake installations at startup; and mounting the Nightdive add-on directory as an extra content root with friendly mod names in the mods menu.

From 1.36.0: the searchable level-selection menu, the console improvements, and the laser-cannon binding.

So vkQuake is tracking two upstreams at once, QuakeSpasm for the mod ecosystem and Ironwail for quality-of-life work. The README credits QuakeSpasm, QuakeSpasm-Spiked, and lists features attributed to QSS, but Ironwail appears nowhere in it. That is a documentation gap rather than a defect, and it has a concrete consequence for anyone who wants to predict what will arrive next: a feature you want may already exist in the sibling project, and the way to find out is to read the release notes rather than the README.

It also explains the Steam integration the README never mentions. The README does say the Windows installer finds Steam, GOG, and Epic Games Store installs automatically, but the achievement and rich presence support in 1.35.0 is a different thing and only appears in the release notes. If you play on Steam and care about achievements, that support exists and the README is not where you will find out.

## Linux file case, an installer that writes elsewhere, and other install traps

The installation section is short and contains two traps that will cost you an evening.

The first is file name case, called out in a note under Linux.

> Make sure all data files are lowercase, e.g. "id1", not "ID1" and "pak0.pak", not "PAK0.PAK". Some distributions of the game have upper case file names, e.g. from GOG.com.

A case-sensitive filesystem will not find uppercase data files, and the note correctly identifies GOG as a source of them. The workaround is mechanical, rename to lowercase, but you have to know it exists first because the failure presents as the engine finding no game rather than as a case mismatch.

The second is where the installer puts your files. The README recommends the Windows installer because it sets up start menu entries for both the classic and remastered Quake versions and finds store installs automatically, but it also says that save data and config files are written to the user folder, `%APPDATA%\vkQuake`, instead of the Quake data folder. That is the standard Windows convention and also a departure from the source-engine behaviour some players expect, so if you are moving an existing save from an older port, that folder is where the engine is looking and it will not be looking in the old place.

Platform coverage is uneven and the README's structure hides it. Windows and Linux binaries are in Releases. macOS binaries, for both Apple Silicon and 64-bit Intel, are at Mac Source Ports rather than in Releases, and 1.34.1 says they are regularly updated there. OpenBSD has carried it in the standard package repositories since 6.6, and FreeBSD since 11.3, with both offering a package install and FreeBSD additionally offering the ports collection.

And then the arm64 line. The 1.34.1 notes say Windows arm64 binaries are not tested, not supported, and provided as-is. The README's Windows section, by contrast, walks you through copying files from the arm64 zip and executing vkQuake.exe with no mention of any caveat.

```console
$ pkg_add vkquake
```

```
Windows\VisualStudio\vkquake.sln
```

Those two blocks are the README at its most literal, and neither mentions the arm64 position. Both facts come from the project itself and both are current in their own right, so rather than choosing one, the actionable step is specific: if you are on Windows on Arm, read the release notes for the exact version you are downloading, and use the release notes as the authority on support while treating the README's copy instructions as instructions for the x64 build.

## Three build systems, and the README only teaches two

The tree is short and it immediately shows a mismatch with the documentation.

```
meson.build
meson_options.txt
Packaging/
Quake/
Shaders/
Windows/
format.sh
.helgrind.supp
```

There is a Meson build at the root, complete with an options file, and there is a Packaging directory alongside it. Neither is mentioned in the README's Building section, which covers a Visual Studio solution on Windows, MinGW makefiles on Windows, and a Linux and macOS path further down.

So the repository carries three build systems: Meson at the root, a Visual Studio solution under Windows, and GNU make files for MinGW and cross-compilation. Only two of the three are documented. This is a normal state for a project that inherited a build system and added another, and Meson is the modern one, so the most likely reading is that Meson is where new work happens while the makefiles remain for the cross-compilation paths they already handle.

What you should take from it is a question rather than a conclusion. If you are building on Linux, check meson.build before following the README's make instructions, because the options file is where you will find out what can be toggled, and a project that ships an options file is inviting configuration rather than a single default build. If you are on Windows and have Visual Studio, the solution is the documented path and there is no reason to go further.

The build prerequisites section has one detail worth flagging: the Vulkan SDK minimum version differs by platform, at least 1.4.321.1 on Windows and at least 1.2.162 on Linux, with a note that distribution-provided Linux SDKs are often older and that you may need to install the LunarG SDK directly. Two different floors for the same dependency is a normal consequence of building on two toolchains, but it means the SDK version you have installed for one platform may not satisfy the other.

The MSVC-built Windows x64 binaries also carry a runtime dependency: the 1.34.1 notes state that Windows x64 binaries require the Microsoft Visual C++ Redistributable. The Linux AppImage requires glibc 2.31 or newer, and FUSE must be enabled.

## Little-endian, and the one decision with no way back

There is a short section on endianness, and it is worth reading twice because the answer is a hard no.

vkQuake only supports little-endian systems. The stated reason is that all known Vulkan-capable systems in the wild are little-endian, and the consequence given is severe: all big-endian support from QuakeSpasm has been effectively removed, and the game would not even start on a big-endian system, outputing a fatal error.

This is a case where a feature was deliberately taken away from the inherited codebase. QuakeSpasm supported big-endian, and that support is gone rather than merely unbuilt. A port that removes a capability is making a statement about its own priorities, and this one is saying that no real user can reach the removed code path, which is defensible on the evidence offered.

For almost every reader this is a non-issue, and that is the point of writing it down: it tells you the codebase has been reduced to one byte order, which means fewer conditional compilation paths to worry about, and it tells you the author considered and rejected a portability goal rather than never having thought about it.

It also connects to the arm64 caveat in a way worth noticing. Little-endian is a property of the byte order, and ARM is a different architecture from x86 regardless of byte order, so declaring the engine little-endian says nothing about which instruction sets it will run on. Those are separate support questions, and this repository treats them separately: byte order is handled by refusing to start, and ARM on Windows is handled by shipping a binary and saying in the release notes that it is untested.

## Conclusion

vkQuake is the port to reach for if you want modern rendering on original Quake and you have a QuakeSpasm mod setup you cannot break. Compatibility is its real argument rather than the pixel effects, because the README states the port runs all mods compatible with QuakeSpasm and names Arcane Dimensions as the example, and the dynamic shadow and dynamic light features are additions on top of a base whose mod ecosystem came with it. Two things decide whether it fits your machine. Check whether your GPU can do ray tracing, because two of the advertised features, dynamic shadows and dynamic lights, are conditioned on it in the README, and the 1.34.1 release shows what happens at the boundary when an AMD driver bug stopped the game from starting at all. Then check your platform against the support list, which is uneven in a way the README's structure does not make obvious: Windows and Linux binaries come from Releases, macOS comes from Mac Source Ports, OpenBSD and FreeBSD have packages, and Windows arm64 is labelled provided as-is. Skip it entirely if you are on a big-endian system, because the engine deliberately refuses to start there.

## FAQ

### What is vkQuake and what is it based on?

It is a port of Quake that renders through Vulkan instead of OpenGL. It is based on QuakeSpasm and QuakeSpasm-Spiked rather than on the original engine, and it runs mods compatible with QuakeSpasm. Several listed features come from QSS, and the more recent release notes credit substantial work from Ironwail, so it tracks more than one upstream.

### Does dynamic lighting in vkQuake require ray tracing hardware?

Yes for both features. The README conditions dynamic shadows and dynamic lights on a GPU with ray tracing support, and dynamic lights additionally require the Dynamic Shadows setting to be medium or higher. Version 1.35.0 added support for 2021 rerelease dynamiclight entities including spotlight cones and repeated the requirement.

### Where do I get vkQuake on macOS?

Not from the project's Releases page. The README sends macOS, for both Apple Silicon and 64-bit Intel, to Mac Source Ports, and the 1.34.1 release notes say binaries there are regularly updated. Windows and Linux binaries are in Releases, while OpenBSD and FreeBSD carry it in their own package repositories.

### Are the Windows ARM64 builds of vkQuake supported?

The 1.34.1 release notes say Windows arm64 binaries are not tested, not supported, and provided as-is, while the README walks through copying files from the arm64 archive without mentioning that caveat. Both come from the project. Treat the release notes as the authority on support for the version you download.

### Can vkQuake run on a big-endian system?

No, and it will not try. The README states that only little-endian is supported, that big-endian support from QuakeSpasm has been removed, and that the game outputs a fatal error rather than starting. The stated reason is that all known Vulkan-capable systems are little-endian.

### Why does Quake fail to start for me on Linux?

Check file name case first. The README warns that all data files must be lowercase, id1 rather than ID1 and pak0.pak rather than PAK0.PAK, and names GOG as a source of uppercase names. A case-sensitive filesystem will not find them and the engine will appear to find no game at all.

## Sources

- [Issues](https://github.com/Novum/vkQuake/issues)
- [License: GPL-2.0](https://github.com/Novum/vkQuake/blob/master/LICENSE)
- [Novum/vkQuake on GitHub](https://github.com/Novum/vkQuake)
- [README](https://github.com/Novum/vkQuake/blob/master/README.md)
- [Releases](https://github.com/Novum/vkQuake/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/novum-vkquake