ec-/Quake3e: Modern Vulkan and OpenGL Build of Quake III Arena

What ec-/Quake3e Changes for Existing Q3A Installations

ec-/Quake3e solves the problem of running Quake III Arena with an engine codebase that is newer than the classic renderer while preserving compatibility with existing Quake III Arena mods. The README describes it as a modern engine based on the last non-SDL source dump of ioquake3, with upstream fixes applied. That makes it an engine replacement, not a new game or a separate content distribution. The repository explicitly contains no game content, so the expected workflow is to obtain the engine binaries and copy them into an existing Quake III Arena installation.

The intended users are players, mod users, server operators, and developers who need the familiar Quake III engine model but want additional renderer choices and engine fixes. The repository topics include OpenGL, Vulkan, and QVM, while the README highlights raw mouse input, a minimize and restore hotkey, external FFmpeg encoding through `\video-pipe`, expanded filesystem limits, server-side denial-of-service protections, and a reworked QVM. These are targeted changes to an existing engine rather than a new game framework. A user who needs game assets, a fresh copy of Quake III Arena, or an installer that creates an installation from nothing will not get that from this repository alone.

Renderer Selection and Rendering Architecture

The repository Makefile exposes three renderer names: `opengl`, `vulkan`, and `opengl2`. In the repository Makefile, `RENDERER_DEFAULT = opengl`, while `USE_VULKAN = 1` and `USE_OPENGL = 1` show that Vulkan and OpenGL are enabled in the Unix build configuration. The OpenGL2 renderer is disabled by default, and the README calls it the original ioquake3 renderer with poor performance on non-NVIDIA systems and no maintenance. That is a direct warning for anyone considering OpenGL2.

The Vulkan renderer is based on Quake-III-Arena-Kenny-Edition and adds per-pixel dynamic lighting, anisotropic filtering, reduced API overhead, flexible vertex-buffer memory management, multiple command buffers, a reversed depth buffer, merged lightmaps, multitexture optimizations, static world surfaces cached in a VBO, debug markers for RenderDoc, and a framebuffer-corruption fix for some Intel integrated GPUs. It also includes offscreen rendering through `\r_fbo 1`. The offscreen path supports screen-map reflections, multisample and supersample anti-aliasing, per-window gamma correction, HDR render targets, bloom, arbitrary resolutions, and greyscale rendering.

The OpenGL renderer remains compatible with OpenGL 1.1 and uses newer features when available. It includes dynamic lighting controlled by `\r_dlightMode`, merged lightmaps, VBO caching, and the offscreen features listed for Vulkan, with a bloom reflection post-processing effect. The architectural point is that Quake3e offers several rendering paths in one engine tree, but the available cvars do not imply identical behavior across every GPU or driver. The README does not document a compatibility matrix, so users should verify renderer behavior on their own hardware.

Downloading ec-/Quake3e and Preparing an Existing Installation

The README provides a download route rather than a complete self-contained installation procedure. It directs users to the repository Releases section for the latest binaries for their platform, or to the Build Instructions in `BUILD.md`. The repository includes `BUILD.md`, `CMakeLists.txt`, `Makefile`, and build-related files, but the contents of `BUILD.md` are not included here. Consequently, no dependency list or build command can be reproduced reliably from the available documentation.

For a binary release, the documented first use is straightforward. Download the build that matches the target platform, locate an existing Quake III Arena installation, and copy the resulting engine binaries into it. The repository warns that the binaries do not contain game content. Do not expect the release to provide maps, sounds, models, or the base Quake III Arena executable unless those files are already present in the installation.

The first real use then depends on the selected renderer. Start from the copied installation using its normal Quake III Arena launcher or executable flow, then select the intended renderer through the engine's supported configuration mechanism. The README specifically names `\r_vbo 1` for static world-surface caching, `\r_flares 1` for Vulkan flares, `\r_fbo 1` for offscreen rendering, `\r_hdr 1` for high dynamic range render targets, and `\r_dlightMode` for OpenGL dynamic lighting. The README does not document the exact menu path, command-line syntax, or first-launch prompt for renderer selection, so those details should be taken from the shipped build or `BUILD.md`.

QVM, Server Protection, and Mod Compatibility

A significant part of Quake3e is work below the renderer. The README describes a significantly reworked QVM, or Quake Virtual Machine, improved server-side denial-of-service protection, and reduced memory usage. For server operators, that means the engine is intended to improve protection against hostile traffic and to lower memory pressure compared with the source basis. The repository also raises the filesystem limit to as many as 20,000 maps in one directory and reworks the Zone memory allocator, with the README stating that it no longer produces out-of-memory errors.

Compatibility with existing Q3A mods is a central design goal, but the available documentation does not enumerate tested mods or describe a compatibility matrix. Mods that depend on renderer internals, custom QVM behavior, or engine console variables may not behave identically even when the mod loads. The dynamic-lighting cvar, VBO caching, HDR, and offscreen rendering all change rendering state rather than merely changing the executable name. A mod that assumes the original renderer path should therefore be checked carefully before it is used as the primary environment.

The distinction between QVM behavior and normal game code matters for administrators. The README gives no migration procedure, QVM packaging instructions, or server configuration examples. It establishes that QVM support was reworked, but not how operators should validate a particular mod or distribute updated virtual-machine files.

Platform Choices and Build Configuration

The top-level Unix Makefile shows that the default configuration builds both a client and a server, enables SDL, CURL, Ogg Vorbis, OpenGL, and Vulkan, and enables renderer dynamic loading. It also sets `USE_OPENGL2 = 0`. This is useful evidence about intended build breadth, but it is not a complete support declaration. The README refers to platform binaries in Releases, and the repository includes macOS scripts named `make-macosx-app.sh` and `make-macosx-ub2.sh`, but it does not enumerate every supported operating system or graphics driver.

The renderer is selected through build-time names and configuration rather than only through the README. The Makefile documents `RENDERER_DEFAULT = opengl` and names the valid options as `opengl`, `vulkan`, and `opengl2`. Teams maintaining local build settings can use `Makefile.local`, which the Makefile includes when present. This allows configuration changes without editing the tracked Makefile directly. The repository includes `CMakeLists.txt` as an additional build entry point, but no CMake instructions are present in the README, so its exact usage cannot be described without guessing.

The practical consequence is that installation is easier for users who choose a release binary and harder for users who need custom renderer combinations or unsupported platforms. Build documentation completeness is the first limitation to check before committing to this engine.

How Quake3e Differs from ioquake3

ec-/Quake3e is directly comparable with ioquake3 because the README identifies ioquake3 as its source basis. The difference is not a new game format or a replacement mod API. Quake3e takes the last non-SDL ioquake3 source dump, applies upstream fixes, and adds renderer and engine changes. Its Vulkan renderer comes from Quake-III-Arena-Kenny-Edition, while its OpenGL renderer draws on classic renderers associated with idq3, ioquake3, cnq3, and OpenArena.

Compared with vanilla ioquake3, Quake3e emphasizes a maintained Vulkan path, updated OpenGL behavior, raw mouse input, expanded filesystem limits, QVM work, server-side DoS protection, memory-usage improvements, and optional SDL2 support. The repository also supports an external FFmpeg binary through `\video-pipe`, which differs from simply relying on an internal recording path. These features target users who want an established Quake III ecosystem with additional engine capabilities.

The trade-off is distribution and documentation. ioquake3 is named as the upstream foundation, while Quake3e adds a separate configuration surface and multiple renderer implementations. A user choosing ioquake3 may prefer the simpler upstream lineage or its own build documentation. A user choosing Quake3e accepts a broader feature set and a codebase that combines several source traditions. Neither the README nor the repository files provide a side-by-side compatibility or benchmark report.

Maintenance Status, Licensing, and Adoption Limits

The repository is not archived, and its last push was on 2026-10-14. Recent releases include `Latest Build` dated 2026-10-14 and a release also dated 2026-10-14. This indicates recent repository activity at the time represented by the release information, but the README does not provide a release policy, supported-version policy, or long-term compatibility promise. The last push date and release dates should be checked against the target platform when selecting a binary.

The repository identifies its license as `GPL-2.0`, with license material present in `COPYING.txt`. Users distributing modified binaries or incorporating code must account for the GPL obligations that apply to their distribution. This is a licensing notice rather than legal advice, and the license file should be reviewed for the exact terms and notices required by the intended distribution model.

The main adoption limits are practical. There is no game content, no homepage supplied, no documented hardware support matrix, and no complete build instructions in the available text. Vulkan features may still depend on GPU, driver, and framebuffer behavior, while mods can expose compatibility problems not covered by the documentation. Treat a release as an engine overlay for an existing installation, verify the binary and renderer first, and keep the original game data separate.

Editorial conclusion

ec-/Quake3e suits players who already own Quake III Arena and want an improved renderer, QVM work, or server-side protection without replacing the game assets. It is less suitable for users expecting a standalone game package or a fully documented build path. Before adoption, verify that your platform has a matching binary, confirm how the release is configured, and check that copying the engine binaries into an existing installation is compatible with your mod setup.

Frequently asked questions

Official sources

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