idTech4A++ puts the idTech4 games on a phone

An idTech runtime collection, not a new engine

The project presents itself as idTech engine games for Android, an idTech games runtime libraries collection on Android, and the repository name is com.n0n3m4.diii4a, with the current edition called idTech4A++, Harmattan Edition. The README states the relationship plainly: it is originally named DIII4A++, based on the OpenGLES version of com.n0n3m4.diii4a.

The scope is enormous and the mechanism is worth understanding before you judge it. The idTech4 titles, DOOM 3, Quake 4, Prey 2006 and Enemy Territory Quake Wars, run on OpenGL ES on Android, Windows and Linux, and on top of that sit DOOM 3 BFG, The Dark Mod, Return to Castle Wolfenstein, Quake 1, 2 and 3, GZDOOM, Enemy Territory, RealRTCW, OpenJK, Serious Sam Classic, Urban Terror, OpenMOHAA and more, each of them a different engine lineage.

The listed platform targets are arm64 and armv7-a, with Android 4.4 as the floor, and the licence is GPLv3. The latest version named in the README is 1.1.0harmattan73, with the last update dated 2026-09-25.

So the shape of the project is a launcher and a runtime that adapts many upstream engines to one mobile graphics stack, rather than a game engine written from scratch. That is the key to the rest of the design.

The idTech4 feature list the port carries over

The README lists the idTech4 features explicitly, and the list is where you can judge what has been ported rather than dropped.

On the rendering side there is a multi-threading renderer, pure soft shadow with shadow mapping, soft shadow with stencil shadow and translucent stencil shadow, global illumination rendering, and a lighting model selectable between Phong, Blinn-phong, PBR, ambient and no lighting. Debug render tools are supported with a programmable render pipeline, and both OpenGL ES 2.0 and 3.0 are targeted.

Assets are handled in the formats the original games used, with png, dds and bimage for textures, obj, dae and md5mesh for static models, and psk, psa, iqm, gltf, glb and fbx for animation and static models. Screenshots can be written as jpeg, png, bmp or dds. Audio is OpenAL with EFX reverb, and the console is a float console.

There is also a list of specific mod support, including the DOOM 3 full body awareness, view body, bot and view flashlight mods, and the corresponding Quake 4 mods, plus the Prey 2006 full body awareness mod.

The feature list covers the idTech4 titles in detail. The other engines in the table come from their own upstreams and inherit their own capabilities, which is why the support table is the more useful document to read.

The support table is the compatibility contract

The table lists every supported game with its engine, the engine version, the required OpenGL ES version, the Vulkan version where the upstream has one, the standalone folder name and the mods that work. The last column is the only part that is long.

The rows read as a catalogue of upstream forks rather than as a single engine:

| Game | Engine | Version | OpenGL ES version | Vulkan version | Standalone folder<br/>(* means always enabled) | Mods/Plugins |
|:-----|:-----:|:-----:|:-----:|:-----:|:-----:|:-----|
| Prey(2006) | n0n3m4's dante | - | 2.0/3.0 |  | prey |  |
| Return to Castle Wolfenstein | [iortcw](https://github.com/iortcw/iortcw) | 1.51d | 1.1 |  | rtcw |  |
| Quake I | [Darkplaces](https://github.com/DarkPlacesEngine/darkplaces) | - | 2.0 | |  quake1 |  |
| RealRTCW | [RealRTCW](https://github.com/wolfetplayer/RealRTCW) | 5.3 | 1.1 |  | realrtcw |  |

Each row names the engine it uses, and the versions are the upstream ones at the time the table was written: ioquake3 1.36 for Quake III Arena, Yamagi Quake II 8.60, UZDOOM 4.14.2, ET Legacy 2.83.2, RBDOOM-3-BFG 1.4.0 described as the last OpenGL renderer version, and OpenJK 1.0.1.1 for the Jedi Knight games.

The OpenGL ES column is the one that matters on a phone, and it is not uniform. Quake I needs 2.0, Wolfenstein titles need 1.1, UZDOOM is listed as 2.0/3.2, and The Dark Mod is listed as 3.2 with the note that it requires geometry shader support. The Vulkan column refers to the upstream engines, so it tells you what the source engine can do on a desktop, not what this port does on a phone.

Two build systems for one repository

The repository is a hybrid, and the tree shows it: CMakeLists.txt at the root for the engine side, build.gradle with settings.gradle, gradle.properties, local.properties and the gradle wrapper for the Android side, plus a .gitmodules file for the engine sources pulled in as submodules.

The Android application lives in the idTech4Amm/ directory, the shared engine code appears in a Q3E/ directory and a doom3/ directory, there is a bin/ directory for built output and a doc/ directory for documentation. The Q3E directory name is a giveaway about the approach, since the classic Quake III engine is the common ancestor for a large part of the idTech family.

The consequence of the two build systems is a two-step build for a developer: the native engine has to be compiled with CMake for the target ABI, and the Android application has to be built with Gradle and packaged. That is a heavier build than a single command, and it is why the project publishes prebuilt artefacts rather than expecting every user to compile.

The CI badges confirm the split, with separate workflows for Android builds and for Windows and Linux builds, so both targets are built continuously even though the releases are packaged by hand.

Where the builds come from, and the difference between a release and a testing build

There are three practical ways to get the thing onto a device, and the README distinguishes them.

The F-Droid route is the one aimed at ordinary Android users, with the project listed in the F-Droid catalogue as com.karin.idTech4Amm and a get it on F-Droid badge in the README. F-Droid builds from source, which means the artefact is reproducible and auditable, which is a meaningful advantage over a sideloaded binary for anyone who cares about what they install.

The second route is the release tags. The most recent is v1.1.0harmattan73, titled as ETQW support, and the repository also carries two rolling tags: android_testing and win_linux_testing, described as non-release automatic CI builds, with Android testing tags for arm64-v8a 64-bit and for armeabi-v7a 32-bit, alongside a win_linux_testing tag.

That distinction is the one to respect. The testing tags are CI output, rebuilt continuously, with a timestamped name in the form of a build date and time, so they are for testing a change and for catching a regression quickly, not for a stable installation. A user who installs a testing build and finds a broken level has installed the current state of the main branch, not a curated release.

There is also a Discord badge in the README for chat, and a Latest Release download badge, which is the fastest way to find the newest curated build.

Where this is the wrong tool

The first case is someone who wants a maintained upstream of a single game. If what you want is the best Quake III engine, this is not it, because Quake III Arena here is ioquake3 1.36 as that fork was, and the table shows a fixed version rather than a tracked one. The same applies to every other row: the port consumes upstream engines, it does not maintain them, and it does not carry their bug fixes forward.

The second case is a device with an unusual GPU. The port targets OpenGL ES 2.0 and 3.0, and the table records the required version per game. A phone with only ES 2.0 support cannot run the entries marked 3.2, and The Dark Mod explicitly needs geometry shader support, which is a further subset of ES 3.x hardware. The requirement column exists because these are real limits rather than paperwork.

The third case is a developer who wants a Vulkan path. The Vulkan column in the table refers to the upstream engines' own support, and the port's own feature list names only OpenGL ES 2.0 and 3.0, so there is no indication here of Vulkan rendering in this runtime.

The fourth case is a mod author. The mod column is a list of mods known to work, with links to their pages, and the DOOM 3 and Quake 4 rows show how long those lists are. A mod not on the list may work, may not, and there is no compatibility statement in the documentation to fall back on.

GPL-3.0 terms, an active repository, and what the project actually is

The licence is GPLv3, stated in the README, with the LICENSE file at the repository root. For a runtime that links a dozen engine forks, the copyleft terms are the practical constraint on redistribution: anyone shipping a modified build of this runtime has obligations that a permissive licence would not impose. That is a licensing observation rather than advice.

The repository is not archived and the last push was on 2026-09-30, the same day as the v1.1.0harmattan73 release, and the README records a last update of 2026-09-25, so the work is current.

The honest summary of the project is that it is a porting and packaging effort with a launcher attached. The hard problem was never the physics or the scripting, it was getting idTech-era engines to talk to a mobile GPU through OpenGL ES, and that problem is solved for a long list of games, including several that had no mobile version at all.

What you are not getting is a new engine, a new renderer or a maintained fork of any of the upstreams. The value is the same set of games you can already run on a desktop, running on the device in your pocket, with the touch-era assumptions of a phone rather than the keyboard-and-mouse assumptions of a workstation.

Editorial conclusion

idTech4A++ fits a player who wants the idTech4 games on an Android device, or a developer who wants a working idTech engine on a mobile GPU, since it solves the OpenGL ES porting problem that the desktop sources never had to solve. It does not fit someone looking for a maintained upstream of any single engine, since each entry in the support table is a third party fork at a pinned version that the project does not maintain. Before installing, pick the game from the support table and read the OpenGL ES column, because the requirement varies from 1.1 to 3.2 and The Dark Mod needs geometry shader support, and take the build from F-Droid or a release tag rather than an automatic testing build.

Frequently asked questions

Official sources

1. glKarin/com.n0n3m4.diii4a on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases