Walnut Games

Technical notes ยท Research

Part D: first-person shooters (Xonotic, Unvanquished, Red Eclipse 2, Warfork, OpenMoHAA, ET: Legacy)

Xonotic (DarkPlaces, release 0.8.6 of 2023-06-20 and engine git master of 2026-01-22)

Verdict: Xonotic 0.8.6 is NOT GL3-blocked: its own DarkPlaces still has the GL 1.1/1.3/2.0 renderpaths and runs on GL 2.1 + GLSL 1.20 as shipped (measured). Only engine master (and Debian’s darkplaces) dropped them for GL 3.2 core / GLES2. Route: build the 0.8.6 engine for ppc64 like darkplaces-gl2 (effort S-M), keep the GL20 path. The cost is memory (about 200 MB of textures, 850 MB PC RSS) and 450 draws/frame: a “needs cuts” game, not a port. FEATURES (0.8.6 GL20 path): glsl_min=120 core_only=n fallback=gl2 (also gl13, gl11) int_ops=no bitwise=no texelFetch=no textureSize=no ubo=no (guarded, 19 programs link at #version 120) instancing=no tex_arrays=no float_tex=opt float_rt=opt (HDR/bloom only) rg_tex=no mrt=1 vao=no sync=no geom=no tf=no compute=no derivatives=opt (offsetmapping, GLSL130 only) textureLod_fs=no vertexid=no flat=no arb_fbo=opt (EXT_fbo is enough; blit only for video capture) srgb_fb=no vtf=no dyn_loops=opt (blur/SSAO-style loops, bloom) big_shaders=opt (permutation uber-shader, 19 programs in the lowest preset, each of 74 KB source before preprocessing; the per-permutation size is UNVERIFIED on nv30; Nexuiz Classic’s older shader already needs the lean config) FEATURES (engine master, GL32 path): glsl_min=140 if available else 120 core_only=y (context request) fallback=none; GLES2 path exists, see section 1. int_ops=no ubo=opt (r_glsl_skeletal only, GLSL 140) vao=req (core profile) blit=opt SCORES: popularity=5 novelty=5 playability_256MB=2 effort=M ppc64=not-in-debian (no xonotic package in sid; engine builds on Debian ports as darkplaces 020180908+git20260122, which is GL32/GLES2 only) data=free size_MB=1180 (zip 1.24 GB; data pk3 317 + maps 626 + nexcompat 125 + music 111)

1. GL needs (source + trace)

  • Release 0.8.6 (source/darkplaces in the zip): vid.h RENDERPATH_GL11, GL13, GL20, D3D9/10/11, SOFT, GLES1, GLES2. vid_shared.c:1151 picks GL20 when vid_gl20 1 and gl20shaders are supported. Measured run of the shipped binary (xonotic-linux64-sdl) with Mesa forced to 2.1 compat and GLSL 120: log says “Detected GLSL #version 120” and “Using GL2.0 rendering path - 8 texture matrix, 16 texture images, 8 texcoords, shadowmapping supported”. Trace (761 frames, the-big-keybench plus the menu after it, effects-low.cfg): 36 shaders, all #version 120, 19 programs, GL_TEXTURE_2D/3D/CUBE only, one FBO attachment, max glDrawBuffers 1, no geometry/compute/TF. glGetUniformBlockIndex x19 is probed but sits in a GLSL140 branch.
  • Engine master (gitlab.com/xonotic/darkplaces, 2026-01-22): vid.h has only RENDERPATH_GL32 and RENDERPATH_GLES2. vid_sdl.c:1775-1790 requests a 3.2 core context (an ES 2.0 context when built with USE_GLES2). vid_shared.c GL_Setup: “Sys_Error: 3.2 is the minimum”. openglfuncs[] marks about 200 functions “core”, among them glBindBufferBase/Range, glGetUniformBlockIndex, glGetStringi, glGetIntegeri_v, glBlitFramebuffer, glFramebufferTextureLayer, glBindFragDataLocation, VAOs.
  • Yet the master shaders still select #version 120 when the context reports GLSL < 130 (gl_rmain.c:1052-1076), and the only engine uses of 3.x-only calls are small: VAO bound once (gl_backend.c:268), BindFragDataLocation (gl_backend.c:1712), UBO bind for skeletal (r_shadow.c:4495, gl_rmain.c:1511/1915), blit for video capture (gl_backend.c:1603), glGetStringi (vid_shared.c). So a GL 2.1 compat start of master is a short patch, but 0.8.6 needs none.
  • GLES2 path in master (USE_GLES2): GLSL 100 plus #define GLES (shader_glsl.h:49, gl_rmain.c:1082). It is a build-time switch, CI builds it only for wasm (Emscripten, -s FULL_ES3; makefile.inc:247). Measured here: master built on desktop Linux with -DUSE_GLES2 failed to compile (19 errors: ARB debug output, PBO video capture, GL_BGRA, glBlitFramebuffer in gl_backend.c). After guarding those and linking -lGLESv2 it runs on Mesa with an ES 2.0 context (“Using GLES2 rendering path”, GLSL 100) but stops: (a) R_GetTexTypeInfo fatal on any DXT texture, because the GLES2 type table has NO S3TC at all (gl_textures.c:257-266, only ETC1 on Android): every texture would be uncompressed RGBA; (b) after adding DXT types, R_UploadFullTexture "lightgrid": stretch uploads allowed only on 2D textures (the 3D lightgrid texture for Q3 BSP maps is unsupported on GLES2 unless GL_OES_texture_3D, which nv30 exposes only as EXT_texture3D sampling). The GLES2 trace is not usable (init error), no draws/frame number.
  • What the GLES2 path drops (read in source): 3D textures unless extension (vid_shared.c:810), cubemaps only with extension, depth textures replaced by renderbuffers so no shadowmaps and no deferred prepass (r_shadow.c:4061 #ifndef USE_GLES2 around the deferred lighting setup; gl_textures.c:87 comment), no occlusion-query coronas (r_shadow.c, gl_rmain.c:3152), no sRGB, no GL_BGRA readback, no multi-render-target (drawbuffers only in #ifndef USE_GLES2), no DDS save/cache (gl_textures.c:907, 1046). Realtime lights stay as shaderless-shadow lights; bloom and the postprocess use plain RGB565/RGBA8 targets.
  • Answer to “run through GLES2 on nv30”: possible only after patching (S3TC types, lightgrid fallback, compile fixes), and it loses compression, shadows and the 3D lightgrid. The 0.8.6 GL20 path is better on every axis.

2. Port to GL 2.1/GLES 2 on nv30

  • 0.8.6: nothing to port. Same family as Nexuiz Classic (darkplaces-gl2), whose GL20 path we have in build/src/darkplaces-gl2. Does Xonotic 0.8.6 data run on the 2018-04 snapshot? Of the 12 DP_/EXT_ extension names in qcsrc only DP_QC_FS_SEARCH_PACKFILE (and DP_GECKO_SUPPORT, removed) are absent from the snapshot; 78 files differ between the snapshot and the 0.8.6 engine, so the simplest route is to package the 0.8.6 engine from the zip’s source/darkplaces (it is GPL, shipped with the release) instead of the snapshot. Not run on the old snapshot: UNVERIFIED beyond the extension grep.
  • GL20 path on nv30: the shaders are the same permutation uber-shader as Nexuiz (r_glsl_*), so the lean config applies: no realtime lighting, bloom, water reflections, offsetmapping; vid_gl20 0 (GL13 combiner path) as the fallback. Driver-level emulation would help nothing here; the work items are the game-side cuts and memory.
  • Work items: (1) a debsrc package of the 0.8.6 engine for ppc64 (copy of darkplaces-gl2 packaging, M-S); (2) a Xonotic low config (picmip, r_texture_dds_save, gl_texturecompression, mono sound); (3) menu/data: xonotic-data.pk3 only, maps on demand; (4) measure which maps fit (Xonotic maps are large, 626 MB maps pk3).

3. Memory

Measured on llvmpipe (Mesa forced to GL 2.1, 1920x1080, effects-low.cfg, -nosound, the-big-keybench then the main menu, release binary): VmHWM 848 MB (same value without forced 2.1: 848 MB). Trace census: texture uploads 199 MB live at the end (mostly DXT1/DXT5 via gl_texturecompression, 5825 DXT1 + 967 DXT5 + 21 DXT3 uploads, 132+74 uncompressed), buffers 41.9 MB. PS3 estimate: 848 - ~100 llvmpipe baseline - 199 textures - 42 buffers = ~510 MB of CPU-side RSS, of which the benchmark map’s BSP, models, QuakeC (progs + csprogs) and the engine’s own texture copies dominate. That is far above the 160 MB stall-free budget; the ~1 GB “stretch” bar is met only for the RSS part. Cuts: gl_picmip 2-3 (about 4-16x less texture memory), drop the 100 MB music pk3, r_texture_dds_load of a precompressed cache, small maps. UNVERIFIED how much of the 510 MB is one-off load garbage; a second measure with a quit after the benchmark (not run) would tell.

4. CPU

Measured: 24.5 s of engine-thread CPU for ~100 s wall with the demo at 21.5 fps on llvmpipe (the engine thread is not the bottleneck on the PC; llvmpipe took 384 s of CPU). Draws: median 450 per frame, max 898, GL calls median 1945/frame (glVertexAttribPointer 388k and glUniformMatrix4fv 241k over 761 frames: the engine re-sets attribute pointers per draw, no VAOs on the GL20 path). On the PPE at 3.2 GHz with the nv30 driver cost of 30-55% this is the batch-count problem again (X-Moto went 3.7x with batching): expect 20-30 fps in a bot match at 1080p, below the 60 fps target; the QuakeC server (physics, bots) runs in the same process and is cheap on the PC. Nexuiz Classic is the closer proxy and is waiting for the user’s test.

5. ppc64 big-endian

DarkPlaces swaps through LittleLong/BigLong with a run-time mem_bigendian and Debian builds it on s390x; the Nexuiz dedicated server already loaded real data under qemu-user (gamedb/engines/darkplaces/technical.md). Xonotic adds QuakeC progs.dat/csprogs.dat (byte-swapped by the VM loader, same as Nexuiz), the map formats (Q3 BSP, with the lightgrid) and d0_blind_id crypto (used for player ids; needs a BE check, UNVERIFIED). Debian has no xonotic package (sid, ports), so the build is ours.

6. Data and licence

Engine GPLv2, game data free (GPL / CC-BY-SA mix, per-file credits). 1.24 GB zip; xonotic-*-data.pk3 317 MB + maps 626 MB are the minimum; music 111 MB and nexcompat 125 MB are optional.

7. Novelty

No Xonotic/Nexuiz-like FPS found on PS3 GameOS homebrew (web search 2026-10-19 found only a Doom port; a 2008 Ubuntu-PS3 wishlist named Nexuiz and Sauerbraten). Quake 3 ports on PS3 are UNVERIFIED here. Popular: the best-known free arena shooter.

Sources

Xonotic 0.8.6 zip (dl.xonotic.org/xonotic-0.8.6.zip, source/darkplaces inside), gitlab.com/xonotic/darkplaces master 2026-01-22; files cited above; measure/trace files in /mnt/data_linux/Temp/ps3/gl3census/traces/xon (gl20.mem.txt, gl20t.mem.txt, census/report.md, gles2.out.log).

Unvanquished (Daemon engine, git master 2026-10-16; game 0.55.x)

Verdict: the Daemon renderer officially supports “OpenGL 2.1 with EXT_framebuffer_object and ARB_vertex_array_object”, and nv30 has both, plus EXT_framebuffer_blit and S3TC (the other hard requirements). It is the best novel candidate in this part: the renderer has a GLSL 120 path, the tiled dynamic lights switch off by themselves. Blocked by: the game VM (native only on ppc64, vm.sgame.type 3), RAM (a big 3D game), CPU, and a ~600+ MB dpk data set. Effort L. FEATURES: glsl_min=120 core_only=n fallback=gl2 int_ops=opt bitwise=opt texelFetch=opt (light tiles, culling compute only) textureSize=no ubo=opt (realtime lights; auto-off) instancing=opt tex_arrays=no float_tex=opt rg_tex=opt mrt=opt (only deferred modes; 4 supported) vao=req (ARB_vertex_array_object, nv30 has it) sync=opt geom=no tf=no compute=opt (material system, GL 4.3) derivatives=no textureLod_fs=opt (fxaa only) vertexid=opt (screenSpace_vp) flat=opt arb_fbo=opt (EXT_fbo + EXT_framebuffer_blit accepted, sdl_glimp.cpp:2326-2348) srgb_fb=no vtf=no dyn_loops=opt big_shaders=opt (uber-shaders with feature defines; R300-class approximations exist, tr_init.cpp:1044) SCORES: popularity=3 novelty=5 playability_256MB=1 effort=L ppc64=not-in-debian (only NaCl/native build from the Daemon tree; ppc64 listed as an architecture, cmake/DaemonFlags.cmake:682, “POWER5 minimum”; no Debian package) data=free size_MB=about 800 (UNVERIFIED, not downloaded)

1. GL needs (source + trace)

Read in source: sys/sdl_glimp.cpp:1799 message “at least OpenGL 3.2 or OpenGL 2.1 with EXT_framebuffer_object and ARB_vertex_array_object”; the context loop asks 3.2 core first and goes down; line 1494 rejects only < 2.1. Required extensions: EXT_texture_compression_s3tc (2223), ARB_vertex_array_object (2245), ARB_vertex_buffer_object, EXT_framebuffer_object + EXT_framebuffer_blit when ARB_fbo is missing (2326-2348). Everything else is ExtFlag_NONE/CORE-optional (half-float, texture float/integer, rg, UBO, map_buffer_range, sync, gpu_shader4/5, texture_gather, buffer storage, compute). GLSL header: #version 120 with IN/OUT macros, outputColor as gl_FragColor, a smoothstep fallback (gl_shader.cpp:535-610). Nothing in glsl_source/.glsl (48 files) uses sampler2DArray, textureSize, dFdx or uniform blocks; texelFetch only in cull_cp/depthReduction_cp (compute). Realtime lighting (tiled lights) turns itself off without UBO, EXT_texture_integer, texture float, 3D textures (sdl_glimp.cpp:2684-2721): on nv30 that is UBO and integer textures absent. GPU skinning bones come from MAX_VERTEX_UNIFORM_COMPONENTS (sdl_glimp.cpp:2676; “OpenGL 2.1 hardware usually supports no more than 41 bones”, tr_init.cpp:1046). No trace: the game was not run, UNVERIFIED on nv30 shader limits (512 VS instructions; Daemon’s uber-shaders are likely over for lightMapping with deluxe/normal/parallax; reduce via r_ switches).

2. Port to GL 2.1/GLES 2 on nv30

1:1 for the base path (lightmapped world, MD5 models with GPU or CPU skinning, particles, sky, fog), drop realtime lights (auto), HDR/bloom/SSAO (need float targets), liquid reflections, relief mapping (already optional; GLSL 1.20 cannot do the loop forms on nv30 anyway). Looks like Unvanquished at “low”: lightmaps + normal maps, no dynamic lights (alien/human base lights are mostly baked). Driver-level help: ints as floats in the few shaders using uint, 3D-texture lightgrid (sampling is supported). Work items: first run on nv30 to see which uber-shader permutations exceed 4096 FS instructions / 32 temps; ship a feature-define set that stays below; GL 2.1 shader cache.

3. Memory

Not measured (no run). Source note: a Daemon process maps all textures of a level (hundreds of MB at default picmip) and has a heavy BSP/entity set. 2 GB PC RSS is typical for the game; the engine has r_picMip, r_imageMaxDimension and r_ignoreMaterialMinDimension cvars (tr_init.cpp). Estimated PS3: > 400 MB even at picmip 3: playability 1.

4. CPU

A 3D multiplayer FPS with a C++ engine (STL, OpenMP optional), game logic in a separate VM, bot AI and BSP/portal culling. On the PPE it is likely under 15 fps in a populated map (estimate). The Raspberry Pi 3B+ claim in the 0.55 release notes (60 fps on the lowest preset, gamingonlinux 2024-10) is the best sign it can be light, but the Pi’s A53 is out-of-order-ish and 4 cores.

5. ppc64 big-endian

Daemon has Endian.h with Q3_BIG_ENDIAN detection and 165 LittleLong/LittleShort/LittleFloat uses (src/common/Endian.h, src). Architecture.cmake names ppc64 (BE) and ppc64el. The NaCl VM does not exist for ppc64 (NaCl: x86, ARM): game logic must run as a native DLL (vm.sgame.type 3, vm.cgame.type 3; BUILD_GAME_NATIVE_DLL default ON, cmake/DaemonGame.cmake:36). Whether the engine-VM IPC and the cgame/sgame syscall marshalling is BE-clean is UNVERIFIED (no run); the engine is routinely built on ppc64el and the BE support is declared but unproven.

6. Data and licence

Engine GPLv3, Unvanquished assets CC-BY-SA (mostly), distributed as dpk archives (unvanquished_0.xx.dpk, textures, etc.). Size about 800 MB UNVERIFIED (not downloaded; the brief’s memory note).

7. Novelty

No PS3 GameOS port known (web search 2026-10-19 found none). Popular among open-source FPS/RTS-hybrids (gamingonlinux, phoronix coverage of 0.55 / 0.55.5).

Sources

DaemonEngine/Daemon master (shallow clone in src/daemon): src/engine/sys/sdl_glimp.cpp, renderer/gl_shader.cpp, tr_init.cpp, cmake/DaemonFlags.cmake, DaemonGame.cmake; gamingonlinux.com 2024/10 article on 0.55; github.com/DaemonEngine/Daemon/issues/344.

Red Eclipse 2 (Tesseract-derived engine, redeclipse/base master 2.0.9)

Verdict: XL. The renderer is deferred-only (G-buffer with 4 MRT, shadow atlas, radiance-hint GI, volumetrics, SMAA), no forward path. It does accept GL 2.0 contexts and EXT_framebuffer_object, and nv30 meets the hard limits (16 texture units, 4 draw buffers, PBO, half-float vertex), so it may even start, but every light is a fullscreen-class pass over a 1080p G-buffer: far beyond the RSX budget. Debian’s 1.6 (cube2) is the right Red Eclipse for the PS3 and is already in our tests. FEATURES: glsl_min=120 core_only=n fallback=gl2 (context list 4.0..3.0 then 2.0, main.cpp:549-558) int_ops=opt bitwise=opt texelFetch=opt textureSize=opt ubo=opt instancing=opt tex_arrays=no float_tex=opt (hasTF; falls back) float_rt=opt rg_tex=opt mrt=4 (required) vao=opt sync=opt geom=no tf=no compute=no derivatives=opt textureLod_fs=req (texture2DRectLod and texture2DLod in hud.cfg, init.cfg) vertexid=no flat=opt arb_fbo=opt (EXT accepted, rendergl.cpp:731-767) srgb_fb=opt vtf=no dyn_loops=req (23 for loops in config/glsl/*.cfg) big_shaders=req (350 KB of GLSL source in 17 files; world.cfg 40 KB, deferred lighting built in renderlights.cpp) SCORES: popularity=3 novelty=5 playability_256MB=1 effort=XL ppc64=not-in-debian (Debian has redeclipse 1.6 on ppc64) data=free size_MB=UNVERIFIED (repo data/ is only 164 KB; textures/maps/sounds ship separately, 1.6 data is the Debian redeclipse-data)

1-2. GL needs and port

Read in source (src/engine/rendergl.cpp): fatal if GL < 2.0 (398), GLSL < 1.20 (527), texture size < 2048, fewer than 16 texture units (539), fewer than 4 draw buffers (548), no PBO (555), no half-float vertex (707), no framebuffer object (767), no texture rectangle (797). All present on nv30 except possibly ARB_texture_rectangle exposure (UNVERIFIED). Not run. Fragment shaders use textureLod and rectangle textures and loops that NIR unrolls (dynamic counts fail), so GI, SSAO, shadow atlas filtering and SMAA would have to be dropped, leaving a G-buffer renderer without lights: that is a rewrite into a forward renderer (new code, XL). Driver-level emulation cannot fix the fillrate.

3-5.

Memory and CPU: a Tesseract-class G-buffer at 1080p is 4 x RGBA8 + depth ~ 40 MB of VRAM before any texture; not measured. Big-endian: cube2/Tesseract code is byte-order aware and 1.6 already runs on ppc64 in Debian; 2.0’s extras (new network/IRC/http, avif/webp, discord, steam libs in the repo’s bin/) are UNVERIFIED. Data: free (CC mixed), Debian’s redeclipse-data covers 1.6 only.

7. Novelty

Same engine family as Sauerbraten; we run BananaBread (Debian’s cube2) and Red Eclipse 1.6: nothing new for the user; no PS3 GameOS port known.

Sources

redeclipse/base master (src/engine/rendergl.cpp, main.cpp, shader.cpp, config/glsl/*.cfg, src/engine/version.h 2.0.9).

Warfork / Warsow (qfusion, TeamForbiddenLLC/warfork-qfusion master 2025-05-24)

Verdict: Warfork’s ref_gl renderer builds GLSL 120/130/140 (or ES 300/310) programs and treats texture arrays, gpu_shader5 etc. as optional: it should run on GL 2.1, so it is not GL3-blocked. A second renderer ref_nri (NVIDIA Render Interface: Vulkan/D3D12, behind USE_GRAPHICS_NRI, glsl_nri/ shaders) is the future path and out of scope. Novel, popular among arena shooters, but 1.6 GB of assets with an “absolute spaghetti of different licenses” and no Debian package; a plausible but not first candidate. Effort M (GL2 path to be verified on nv30, ppc64 build is ours). FEATURES: glsl_min=120 core_only=n fallback=gl2 int_ops=opt bitwise=opt texelFetch=opt (glsl_nri only) textureSize=no ubo=opt instancing=opt (gpu_shader5/instanced) tex_arrays=opt (r_register.c:609, 702: lightmap arrays with an atlas fallback; UNVERIFIED which) float_tex=opt float_rt=opt rg_tex=no mrt=1 vao=opt sync=no geom=no tf=no compute=no derivatives=no textureLod_fs=no vertexid=no flat=no arb_fbo=opt (EXT_framebuffer_object, r_register.c:295) srgb_fb=no vtf=no dyn_loops=no big_shaders=opt SCORES: popularity=4 novelty=5 playability_256MB=2 effort=M ppc64=not-in-debian data=mixed size_MB=1600 (assets/ folder 1.6 GB in the git tree; 249+498+121+138+559 MB in the data0/data1 directories)

Read in source: source/ref_gl/r_program.c:931-935 and 1708-1726 (version selection 120/130/140, ES 300/310); r_register.c:643 (glConfig.version) and the EXT_framebuffer_object/blit probes. Big-endian: gameshared/q_shared.h defines LittleLong via a byte-order switch (lines 49-65), Q3 lineage, likely OK but UNVERIFIED on ppc64. Not run: no memory/CPU numbers. Licence: engine GPLv2; assets “not suitable for use anywhere” per assets/README.md (mixed, unclear). Novelty: no PS3 GameOS port found. Sources: warfork-qfusion master in src/qfusion.

OpenMoHAA (Debian contrib) and ET: Legacy

OpenMoHAA: in Debian contrib (source in sid-contrib-Sources), contrib packages have no ppc64 binary (arch:all only on ports, per the brief), so we would build it ourselves. Its renderer is the ioquake3 renderer family (ioq3 GL1 renderer_opengl1 plus the GL2 one); not GL3-blocked (UNVERIFIED by source reading: renderer code not opened here). Data (MOHAA pak files) is non-free: the user must supply it. Popularity 2, novelty 4 (a Medal of Honor engine reimplementation, no PS3 port known), playability 2 (3D shooter with large models and maps), effort M, ppc64 builds-ourselves (the ioquake3 base is BE-clean: our ioquake3 package runs on the PS3). SCORES: popularity=2 novelty=4 playability_256MB=2 effort=M ppc64=not-in-debian-binary data=non-free size_MB=UNVERIFIED.

ET: Legacy: no Debian package (not in sid or sid-contrib sources). Renderers: renderer_opengl1 (fixed function, GL1.x, the default for old hardware), plus renderer_opengl2 and renderer_vulkan (it has a GL3 renderer rewrite in progress as well, UNVERIFIED). The GL1 renderer would run on nv30 as our ioquake3 opengl1 does. Engine GPLv3, game data from the free Wolfenstein: ET release (ET:Legacy ships its own free assets; the original ET pak files are the proprietary part). BE: ioq3 lineage (LittleLong), UNVERIFIED. Scores: popularity=4 novelty=4 playability_256MB=3 effort=S-M ppc64=not-in-debian data=mixed size_MB=UNVERIFIED. Neither was opened in source; verdicts rest on the engine lineage.

Three most important findings

  1. Xonotic 0.8.6 (the release) still has the GL20 renderpath and ran on a forced Mesa 2.1 / GLSL 120 context (“Using GL2.0 rendering path”); only engine master and Debian’s darkplaces are GL 3.2/GLES2. Build the 0.8.6 engine (source is in the zip) as a ppc64 package; the problem is memory (200 MB textures) and ~450 draws/frame, not GL.
  2. The GLES2 renderpath in DarkPlaces master is not a way out: it does not compile natively (19 errors), has no S3TC (fatal on any DXT texture), no 3D lightgrid, no depth textures/shadows; it is only built for wasm.
  3. Unvanquished/Daemon officially supports OpenGL 2.1 + EXT_fbo + ARB_vao and has a GLSL 120 path with realtime lights switching off automatically: the most promising novel game here (effort L), limited by RAM, CPU and native-only game VM on ppc64.