Walnut Games

32 MB in a random number generator (2026-10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/MEMORY.md (“Findings in the games’ code”, “Cuts, ranked” row 1 and the packages table), where the cross-game memory picture stays.

Symptom

The MEM=1 batch of 2026-10-18 (00:40-01:40 UTC, Mesa ps3.299, one run per game) had Yamagi Quake II at 77 MB of Rss + 3.4 MB swapped, with 42.1 MB of anonymous memory (the most of the ten games) and a 23 MB .bss in the client, 18 MB of it resident.

About the ratings

Mon, 01 Jan 0001 00:00:00 +0000

How Walnut Games tests a game on the PS3 and turns the measurements into a medal.

An 8 MB staging buffer every frame (2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/HOTPATHS.md (“OpenTTD: an 8 MB staging buffer every frame” and the OpenTTD rows of the SSD-root profiles). The driver side, what a soft-masked sample is and the three switches built against it (Mesa 0040 NV30_STAGING_POOL_MB, kernel local/0046 ps3_htab.insert_readback, ps3rsx clear_dcbz), stays in docs/HOTPATHS.md.

Symptom

The gameplay profile of batch ssdroot2 P1b (2026-10-19, kernel .472, Mesa ps3.476, OpenTTD’s OpenGL driver, 18 fps; the webcam showed the title screen with its menu open, so it is the title screen’s redraw and music, not play) spent 49.5% of OpenTTD’s samples in the kernel, 37.6% of them booked as __replay_soft_interrupts (time with interrupts soft-masked), against 1.7-5.7% in the six other games profiled. Mesa’s own share was 1.1%, but its GL API entry hot path was 33.2% (_mesa_memcpy_texture, the CPU copy of its PBO upload) and buffer allocation and free 17.0%.

Armagetron Advanced

Mon, 01 Jan 0001 00:00:00 +0000

A 3D Tron light cycle game: leave a wall behind you and make the others crash into it.

Armagetron Advanced: guides

Mon, 01 Jan 0001 00:00:00 +0000

Armagetron Advanced: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

Armagetron Advanced: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Armagetron Advanced 0.2.9.3 is Debian’s package with two patches of ours (fullscreen at the desktop’s resolution by default, a fixed game-controller scheme) and runs with the right picture and sound. Live AI rounds play at 83 steady fps in the benchmark; its played session (2026-10-25) had a 104 fps median, quit cleanly and was fully playable with the pad.

Packages and patches

armagetronad, armagetronad-common (Debian’s 0.2.9.3.0-1 with our patches, packages/armagetronad). Its textures are RGBA8, and the big-endian risk (GL_RGBA or GL_BGRA picked from the SDL surface’s red mask) didn’t bite.

Armagetron Advanced: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Armagetron: Mesa ps3.262's -13%, the lost CPU/GPU overlap (2026-10-17)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. Mesa ps3.262 (0019-0025, fewer words per draw) sped up every game of the suite by 11-24%, except Armagetron: its playback went from 60 fps HUD median on ps3.246 (59 and 61 in the same boot, batch 2026-10-17-mesa-246-control) to 52.5 (-13%, batch 2026-10-17-mesa-262), and 50 on ps3.282.

Evidence. Not 0020’s texture invalidation: texinv gave 52 (batch 2026-10-17-mesa-262-repeats). On ps3.282 (batch 2026-10-17-mesa-282-armagetron) the switches told: with relocations back on, or a fixed kick every 50 or 100 draws (kick50, kick100), it was 60.5 again. In the first profile (Mesa ps3.223) “other kernel” was 21% of its CPU.

BananaBread

Mon, 01 Jan 0001 00:00:00 +0000

A first person shooter on the Cube 2 engine, with bots and an in-game map editor: the BananaBread content in Debian’s cube2-data.

BananaBread: guides

Mon, 01 Jan 0001 00:00:00 +0000

BananaBread: OOM-killed, then the first memory patches (2026-10-16 to 10-17)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The research of 2026-10-16 found that the Cube 2 engine (and Red Eclipse) turns texture compression off on Mesa: a one-line patch would make it a third S3TC game. On 2026-10-17 the game was OOM-killed while loading cave without the VRAM swap (smoke’s default). With the swap it ran, holding 138 MB of VRAM and filling the swap. The first run with CPU skinning gave a 15 fps HUD median, including a load of over 60 s. GPU skinning ran without a wedge, but at 11 fps and badly stuttering.

BananaBread: session of 2026-10-24

Mon, 01 Jan 0001 00:00:00 +0000

BananaBread: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

BananaBread is Debian’s cube2, which is Sauerbraten’s engine, playing Debian’s cube2-data (the BananaBread content, 20 maps) completed by our licensed sauerbraten-nonfree-data. It runs on our Cube 2 build with all its patches. The user’s recorded demo plays at 39.1 steady fps on the SSD root with 0.05 s of gameplay stalls, and at 45.1 with the world normals sent as shorts (cube2 0011, +17%, not the default yet). It is the suite’s heaviest GLSL game: 117 MB of VRAM and about 20-25 MB of RAM free at the lowest. Its played session (the “Cube2:Demo” launcher, 2026-10-24) had a 20 fps median and 22 s of stutter a minute.

BananaBread: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Beneath a Steel Sky

Mon, 01 Jan 0001 00:00:00 +0000

Revolution Software’s 1994 cyberpunk adventure: Robert Foster and his robot Joey find out who runs the city that kidnapped him. The CD version with speech, free to download.

Beneath a Steel Sky: guides

Mon, 01 Jan 0001 00:00:00 +0000

Beneath a Steel Sky: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

First run 2026-10-19 (batch 2026-10-19-ssdroot3-smoke-new, ScummVM 2026.1.0): the intro, the sound running (20 underruns; the mic heard it 12 dB over the room), 85 MB peak RSS. Escape never reached the window then (the recipe’s keys missed SDL’s window names until 2026-10-28), so the run stayed in the intro. Not run since: its package wasn’t installed in the 2026-10-29 runs. The package is the CD version with speech, all its languages in sky.dsk; the launcher plays the English one.

Beneath a Steel Sky: test runs

Mon, 01 Jan 0001 00:00:00 +0000

BomberClone

Mon, 01 Jan 0001 00:00:00 +0000

A Bomberman clone: blow up walls and the other players with bombs, alone against bots or with friends.

BomberClone: guides

Mon, 01 Jan 0001 00:00:00 +0000

BomberClone: session of 2026-10-26

Mon, 01 Jan 0001 00:00:00 +0000

BomberClone: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

BomberClone 0.11.9, an Atomic Bomberman clone (SDL 1.2 on sdl12-compat, up to 8 local or network players), is Debian’s 0.11.9-9 with two patches of ours. Its played session (2026-10-26, about 5 minutes against bots) had a 50 fps median, no crash, the picture right (4:3 with bars at the sides) and the sound effects and music heard; the gamepad works in matches but not in the menus.

Packages and patches

bomberclone, bomberclone-data (0.11.9-9+ps3.N, packages/bomberclone), replacing Debian’s; in no suite.

BomberClone: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Bring your own games

Mon, 01 Jan 0001 00:00:00 +0000

How Walnut Games turns your own CD, disc image, GOG installer or Steam folder into an installed game on the PS3, and which copies work.

BZFlag

Mon, 01 Jan 0001 00:00:00 +0000

A 3D tank battle game: drive and shoot across online servers or against computer tanks.

BZFlag: guides

Mon, 01 Jan 0001 00:00:00 +0000

BZFlag: session of 2026-10-29

Mon, 01 Jan 0001 00:00:00 +0000

BZFlag: session of 2026-10-29

Mon, 01 Jan 0001 00:00:00 +0000

BZFlag: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Debian’s bzflag-client, bzflag-data and bzflag-server 2.4.30-4 from debian-ports, unchanged (about 20 MB installed). It runs: smoke run on 2026-10-28 (kernel .874, Mesa ps3.924; runs ps3-bench-20261028T194448Z and T194805Z): the client joins a bzfs on the console with three robot tanks, fullscreen at 1920x1080 (geom=1920x1080+0+0 fs=1), the robots fight each other, our tank spawns on i and drives. The Gallium HUD over the 90 s window: 59 fps steady, 1% low 30, one frame over 100 ms (243 ms, the screenshot’s capture), 136% CPU (client, robots and server together), 65 MB RSS, 48 MB of VRAM, 23 MB of GART. Sound ran (RUNNING, 18 dropouts logged, 1 audible). Not checked yet: the sound by ear, the pad, a long match.

BZFlag: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Chromium B.S.U.

Mon, 01 Jan 0001 00:00:00 +0000

A fast vertical arcade shooter: fly a lone ship against waves of enemies and keep the supply ships alive.

Chromium B.S.U.: guides

Mon, 01 Jan 0001 00:00:00 +0000

Chromium B.S.U.: session of 2026-10-29

Mon, 01 Jan 0001 00:00:00 +0000

Chromium B.S.U.: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Debian’s Chromium B.S.U. 0.9.16.1 (chromium-bsu, -data, 1 MB) runs. Smoke runs on 2026-10-28 (kernel .874, Mesa ps3.924; the last one ps3-bench-20261028T201110Z): Return on “new game” and a few shots and moves through XTEST (the recipe’s during(); the first runs never got their keys: xkeys.py looked windows up with XFetchName, which misses sdl2-compat’s UTF-8 window names, fixed the same night), then the level plays: 55 fps steady on the Gallium HUD (the game’s own counter says 53), 1% low 42, one frame over 100 ms (the capture), 37% CPU, 48 MB RSS, 31 MB of VRAM; sound running, no dropouts logged. The webcam shows the same picture as the capture.

Chromium B.S.U.: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Content: campaign

Mon, 01 Jan 0001 00:00:00 +0000

Content: map editor

Mon, 01 Jan 0001 00:00:00 +0000

Content: mods

Mon, 01 Jan 0001 00:00:00 +0000

Content: skirmish

Mon, 01 Jan 0001 00:00:00 +0000

Cube 2

Mon, 01 Jan 0001 00:00:00 +0000

Debian’s cube2 source with our patches: its package.

Technical notes

Debian’s cube2 (0.0.20201229+dfsg-1+ps3.N, packages/cube2) is Sauerbraten’s own engine source (svn at the 2020-12-29 release, minus the bundled enet and the IDE files; the release archive’s src/ differs from it in two files, sound.cpp and stream.cpp, where Debian’s has later upstream fixes). Only Debian’s data, cube2-data, is BananaBread’s. So one engine build with one set of patches runs both BananaBread and Sauerbraten, and Red Eclipse is the same engine family without our patches. The package replaces Debian’s; the release candidate is ps3.354, ps3.442~dev added 0011.

DarkPlaces

Mon, 01 Jan 0001 00:00:00 +0000

Debian buster’s DarkPlaces 0~~20180412~~beta1 (the last with the GL 1.x/2.0 renderpaths) as darkplaces-gl2: its package.

Technical notes

Debian’s DarkPlaces (020180908 and the 2026 git snapshot) has only GL 3.2 core and GLES2 renderpaths, so it can’t run on the RSX. The last snapshot with the GL 1.1/1.3/2.0 renderpaths (RENDERPATH_GL11/GL13/GL20, an SDL2 window, vid_gl20 0 for the combiner path) is 020180412~beta1, Debian buster’s orig tarball (snapshot.debian.org, upstream.mk). Our darkplaces-gl2 (its package, TYPE=upstream, make darkplaces-gl2-deb, 2 MB) builds it with Debian’s 13 patches (link options, no SSE rasterizer off x86, GPU skinning off) and -std=gnu17 (the code uses false/true as enum names; gcc 15 defaults to C23). It installs /usr/games/darkplaces-gl2 beside Debian’s engine and /usr/games/nexuiz-gl2. The one game on it is Nexuiz Classic; built, not yet installed on the PS3.

Day of the Tentacle

Mon, 01 Jan 0001 00:00:00 +0000

LucasArts’ 1993 time-travel comedy: Bernard, Hoagie and Laverne pass things to each other across three centuries to stop Purple Tentacle. Played with ScummVM from your own copy.

Day of the Tentacle: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Day of the Tentacle: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: published so that Walnut Games can set up its data; nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-28 (ps3-bench-20261028T224303Z-smoke-scummvm-dott, ScummVM 2026.4.0, recipe scummvm variant dott, from ~/Games/scummvm/DOTT): Escape twice skipped the intro, then Bernard in the hotel lobby with the verbs and the inventory, colours right, fullscreen with the 4:3 picture between bars; 90 MB peak RSS, the sound running with no audible dropouts.

Day of the Tentacle: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Diablo (DevilutionX)

Mon, 01 Jan 0001 00:00:00 +0000

A dark fantasy action RPG: descend through the dungeon beneath Tristram, kill monsters and collect loot (needs your own game files).

Diablo (DevilutionX): guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Diablo (DevilutionX): session of 2026-10-29

Mon, 01 Jan 0001 00:00:00 +0000

Diablo (DevilutionX): technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Also known as: DevilutionX (the engine); Hellfire (the expansion, also played by DevilutionX).

Status

DevilutionX 1.5.5 built by us (devilutionx 1.5.5-1+ps3.N, built from gamedb/games/diablo/packages/devilutionx/: DevilutionX is under the Sustainable Use License 1.0, non-commercial and not DFSG-free; the user accepted that on 2026-10-29 (“I’m not using it commercially”), so it is public in the testing suite, marked non-free in its description, README.Debian and the GameDB page, Section still games). Two patches: 0001 opens the audio device in the host byte order (AUDIO_S16SYS; AUDIO_S16 is little-endian, so the PPE swapped every sample twice); 0002 fixes the see-through mouse cursor (below). Upstream’s defaults are already console-like: fullscreen at the screen’s mode (SDL_WINDOW_FULLSCREEN_DESKTOP, the picture widened to 16:9 and scaled up), SDL game controllers on. The package links game-data-packager’s diablo-data files (/usr/share/games/diablo/DIABDAT.MPQ, Hellfire’s hellfire.mpq, hfmonk.mpq, hfmusic.mpq, hfvoice.mpq) into /usr/share/diasurgical/devilutionx/, a folder DevilutionX searches (it never looks in /usr/share/games). The player’s 1.09 DIABDAT.MPQ (517,501,242 bytes) is not the GOG file GDP knew (517,501,282); gdp patch 0019 accepts both for diablo-data (tags ?gog and ?1.09). Proven on the PC (2026-10-30): game-data-packager diablo -p diablo-data on a folder with the file builds the deb, and the helper’s manifest check takes its data stream (release 1.09); the import itself on the PS3 is in TESTS.

Diablo (DevilutionX): test runs

Mon, 01 Jan 0001 00:00:00 +0000

Doom

Mon, 01 Jan 0001 00:00:00 +0000

id Software’s 1993 first person shooter, The Ultimate Doom’s four episodes, played with DSDA-Doom from your own copy.

Doom II: Hell on Earth

Mon, 01 Jan 0001 00:00:00 +0000

id Software’s 1994 sequel to Doom, its 32 levels played with DSDA-Doom from your own copy.

Doom II: Hell on Earth: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Doom II: Hell on Earth: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested on the PS3: published so that Walnut Games can set up its data; nobody has played it on Walnut yet. Its launchers start DSDA-Doom 0.30.0 (Debian’s package with Walnut’s patches, dsda-doom), which plays Freedoom 2 at about 56 fps on its OpenGL renderer.

Data: game-data-packager’s doom2-wad (build.toml [data_setup]), made from the player’s own copy; the WADs go to /usr/share/games/doom/, where Freedoom’s are.
Launchers (desktop/launchers), one per IWAD, NoDisplay=true with X-Walnut-Requires= the WAD (shown once the menu rule for it exists, PLAN 5.10):
- dsda-doom -iwad /usr/share/games/doom/doom2.wad -vidmode gl -width 1920 -height 1080 -fullscreen

Doom II: Hell on Earth: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Doom: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Doom: session of 2026-11-02

Mon, 01 Jan 0001 00:00:00 +0000

Doom: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Played once on the PS3 (2026-11-02, 936 s of play from The Ultimate Doom’s DOOM.WAD: median 59 fps, 1% low 40, no crash, no audible dropouts, nothing wrong in the picture; Platinum 95, provisional under an hour of play). Its launchers start DSDA-Doom 0.30.0 (Debian’s package with Walnut’s patches, dsda-doom), which also plays Freedoom 2 at about 56 fps on its OpenGL renderer.

Data: game-data-packager’s doom-wad (build.toml [data_setup]), made from the player’s own copy; the WADs go to /usr/share/games/doom/, where Freedoom’s are.
Launchers (desktop/launchers), one per IWAD, NoDisplay=true with X-Walnut-Requires= the WAD (shown once the menu rule for it exists, PLAN 5.10):
- dsda-doom -iwad /usr/share/games/doom/doom.wad -vidmode gl -width 1920 -height 1080 -fullscreen

Doom: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Drascula: The Vampire Strikes Back

Mon, 01 Jan 0001 00:00:00 +0000

Alcachofa Soft’s 1996 comedy adventure: John Hacker goes into Transylvania after Count Drascula, who has kidnapped B.J. Free to download, with the CD’s music.

Drascula: The Vampire Strikes Back: guides

Mon, 01 Jan 0001 00:00:00 +0000

Drascula: The Vampire Strikes Back: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-20 (ps3-bench-20261020T093104Z-smoke-scummvm-drascula, ScummVM 2026.1.0, the data package of then): “Couldn’t identify game ‘drascula’ for the engine ‘drascula’”, so the game didn’t start. On the PC (2026-10-30, a Debian container, ScummVM 2026.1.0 with drascula 1.0+ds4-4) the menu entry’s command says “Running Drascula: The Vampire Strikes Back (DOS/English)”: to be seen again on the PS3. The music is drascula-music’s Ogg Vorbis tracks in /usr/share/scummvm/drascula/audio/. The other languages are packages of their own (drascula-spanish, …).

Drascula: The Vampire Strikes Back: test runs

Mon, 01 Jan 0001 00:00:00 +0000

dsda-doom

Mon, 01 Jan 0001 00:00:00 +0000

A Doom source port with an OpenGL renderer, accurate demo playback and many mod features.

dsda-doom: guides

Mon, 01 Jan 0001 00:00:00 +0000

dsda-doom: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

dsda-doom: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

dsda-doom: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

dsda-doom 0.30.0 (the PrBoom+ successor, with the same GL renderer) plays Freedoom’s DEMO1 on its GL renderer at 55.9 steady fps with no stalls, after big-endian and GL fixes of ours. Its OpenGL played session (2026-10-25) had a 58 fps median and was smooth; the software launcher 44. What is left is the MIDI music, which still chops: FluidSynth’s voice DSP on the SPEs halved the underruns, but hundreds a minute remain.

dsda-doom: test runs

Mon, 01 Jan 0001 00:00:00 +0000

dsda-doom: the MIDI music chops, and FluidSynth's voices on the SPEs (2026-10-17 onward)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. With the music on, dsda-doom’s sound chopped: 1095-1335 ALSA underruns in a 60 s play run, the music audibly breaking up.

Evidence. FluidSynth took 48% of dsda-doom’s CPU, about 40% of a PPE thread, interpolation alone 31% (SPU-AUDIO.md, “Results on the PS3”). Earlier sound-settings tries (batch 2026-10-17-dsda-doom-sound, Mesa ps3.225): tuned 340 underruns and 46 s of CPU in one run, OPL 1312 in its first.

Run (`play`, 60 s, GL)	CPU a minute	Underruns	Batch
no music	about 29 s	18	batch 2026-10-17-fluidsynth-309
stock FluidSynth on the PPE	44.5-53 s	1095-1335	batch 2026-10-17-fluidsynth-spu-dsp, batch 2026-10-17-speq-367-deadline-pool
version 1 on the SPEs (libspeq 0.288)	31.7 s	1097	batch 2026-10-17-fluidsynth-spu-dsp
version 2 (libfluidsynth3 +ps3.309, libspeq 0.318)	31.8 s	588 and 709 (stock 1231 and 1331 the same session)	batch 2026-10-17-fluidsynth-309
version 2 on the shared deadline pool (libspeq 0.367)	26.5 s	465 (PPE 1095)	batch 2026-10-17-speq-367-deadline-pool

The user listened to version 2: “night and day, spu makes a huge difference”; the glitches that remain line up with the game’s own frame stalls. The gameplay profile of 2026-10-19 still puts the synthesis at about 30% of the samples. In the played sessions of 2026-10-25 the OpenGL launcher counted 7.5 audible dropouts a minute (from 10322 underruns), the software launcher 35.9.

dsda-doom: wrong colours, silent sound lumps, black GL textures (2026-10-16/17)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The first smoke at 1920x1080 in software ran at about 5 fps; at 960x540 the frame came out in wrong colours, green-tinted through SDL’s GL renderer (batch 2026-10-16-dsda-doom-software). The engine’s own sound lumps didn’t play right, screenshots had the wrong byte order, and the GL renderer drew walls, sprites and menus missing or black.

Cause. Three big-endian assumptions and one missing GL feature:

dsda-doom.wad’s DMX sound lumps are little-endian and were read in host order;
the software renderer’s SDL buffer wasn’t in the texture’s own format, so the pixel words were read with their bytes the wrong way round; screenshots likewise;
the GL renderer uploads every indexed texture as GL_RG, and nv30 has no ARB_texture_rg.

Fix. 0001 reads the DMX lumps little-endian; 0003 puts the software renderer’s SDL buffer in the texture’s own format (+ps3.231, batch 2026-10-16-dsda-doom-colours); 0004 writes screenshots as RGB24; 0002 uploads the indexed textures as GL_LUMINANCE_ALPHA (+ps3.247: the GL renderer runs, 48.8 fps on the GL timedemo, batch 2026-10-17-dsda-doom-gl-music). The software renderer then gave 33 fps with the demo unfinished on Mesa ps3.246 and 38 finished on ps3.262.

Engine: Cube 2

Mon, 01 Jan 0001 00:00:00 +0000

Engine: DSDA-Doom id Tech 1

Mon, 01 Jan 0001 00:00:00 +0000

Engine: id Tech 1

Mon, 01 Jan 0001 00:00:00 +0000

Engine: id Tech 2

Mon, 01 Jan 0001 00:00:00 +0000

Engine: id Tech 3

Mon, 01 Jan 0001 00:00:00 +0000

Engine: ioquake3 id Tech 3

Mon, 01 Jan 0001 00:00:00 +0000

Engine: QuakeSpasm id Tech 2

Mon, 01 Jan 0001 00:00:00 +0000

Engine: ScummVM

Mon, 01 Jan 0001 00:00:00 +0000

Engine: Yamagi Quake II id Tech 2

Mon, 01 Jan 0001 00:00:00 +0000

Excluded games re-evaluated (research, 2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

The second pass over games first ruled out for reasons other than GL 3: RAM measured on the PC (amd64, Xvfb + llvmpipe, which adds about 100-200 MB), build and big-endian costs estimated. The first pass is build/tmp/newgames/RESEARCH.md, summarised in the games’ technical notes (gamedb/games//technical.md). Builds of DDNet, OpenTyrian, UQM and Hedgewars started the same night.

Where this lives now (2026-10-26). This survey moved from docs/research to gamedb/research. Every game it names has a bundle in gamedb/games/ (a draft when it is only a candidate, status and status_note saying where it stands) whose technical.md cites this file by section. Part B (OpenRCT2’s big-endian port estimate) moved into the game’s investigations/. The per-game tables and blocks here are kept by hand for now; they become generated blocks (tools/gamedb/blocks.py) in a later step, and until then a game’s current state is its bundle’s, not this file’s.

Extreme Tux Racer

Mon, 01 Jan 0001 00:00:00 +0000

A 3D downhill racing game in which Tux the penguin slides down snowy courses collecting herrings.

Extreme Tux Racer: a 4 ms sound buffer (2026-10-24)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The played session of 2026-10-24 logged 608 xruns, 7.5 audible-dropout marks a minute, which the player did not hear.

Cause. ETR plays through SFML 3.1 (miniaudio), which opens the ALSA device with a 64-frame period and 3 periods: a 4 ms buffer, which the PPE misses whenever a frame runs long. ETR cannot change it: SFML does not expose the setting.

Fix. Our libsfml (packages/patched/audio/libsfml/, 0001) opens it with a 1024-frame period: about 64 ms of buffer at 48 kHz, 24 KB, a sound effect or the music starting at most 23 ms late in the mix. SFML_AUDIO_PERIOD_FRAMES=<32..16384> overrides it (64 is upstream’s). It serves every SFML game. Not yet tried on the PS3: the next played session should show the xrun count.

Extreme Tux Racer: game-side batching (2026-10-17)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. After its first runs (batch 2026-10-16-etr-armagetron-smokes), ETR went from 46 fps HUD on Mesa ps3.246 to 53 on ps3.262 (+15%) and 52 on ps3.299: just short of the 60 fps target, held back by the PPE.

Evidence. A frame made 19,400 GL calls and 697 draws: texture binds repeated, the terrain walked and drawn in immediate mode, Tux’s spheres rebuilt, every tree and item drawn on its own, each snow particle its own draw.

Extreme Tux Racer: guides

Mon, 01 Jan 0001 00:00:00 +0000

Extreme Tux Racer: session of 2026-10-24

Mon, 01 Jan 0001 00:00:00 +0000

Extreme Tux Racer: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Extreme Tux Racer 0.8.4 runs with the right picture and sound at about 59 fps in the benchmark, not a vsync cap (59 uncapped too), after our patches cut a frame from 19,400 GL calls to 850. Its played session (2026-10-24, with the controller patch) had a 58 fps median, the controller fully usable, and 608 sound xruns the player didn’t hear, which the new SFML audio period is meant to remove.

Extreme Tux Racer: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Final Doom

Mon, 01 Jan 0001 00:00:00 +0000

Two 32-level Doom II episodes from 1996, TNT: Evilution and The Plutonia Experiment, played with DSDA-Doom from your own copy.

Final Doom: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Final Doom: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Data: game-data-packager’s plutonia-wad, tnt-wad (build.toml [data_setup]), made from the player’s own copy; the WADs go to /usr/share/games/doom/, where Freedoom’s are.
Launchers (desktop/launchers), one per IWAD, NoDisplay=true with X-Walnut-Requires= the WAD (shown once the menu rule for it exists, PLAN 5.10):
- dsda-doom -iwad /usr/share/games/doom/tnt.wad -file /usr/share/games/doom/tnt31.wad -vidmode gl -width 1920 -height 1080 -fullscreen
- dsda-doom -iwad /usr/share/games/doom/plutonia.wad -vidmode gl -width 1920 -height 1080 -fullscreen

Final Doom: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Flight of the Amazon Queen

Mon, 01 Jan 0001 00:00:00 +0000

Pilot Joe King crash-lands in the Amazon with a film star on board and stumbles on a mad scientist’s plan; the 1995 adventure’s CD version with speech, free to download.

Flight of the Amazon Queen: guides

Mon, 01 Jan 0001 00:00:00 +0000

Flight of the Amazon Queen: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-20 (ps3-bench-20261020T092844Z-smoke-scummvm-queen, ScummVM 2026.1.0): “Running Flight of the Amazon Queen (CD/DOS/English)”, the sound running; no screenshots in that run. The package is the CD version with speech (queen.1c).

How it is set up

Data: Debian’s flight-of-the-amazon-queen, installed with ScummVM by Walnut Games, in /usr/share/scummvm/flight-of-the-amazon-queen.
Launcher (desktop/launchers): scummvm -c ~/.config/scummvm/walnut/queen.ini -i /usr/share/ps3-games/scummvm/queen.ini -p /usr/share/scummvm/flight-of-the-amazon-queen queen through ps3-game, shown once the data is installed (X-Walnut-Requires=); the package’s own menu entry is diverted (the engine’s notes).
Settings: the initial config queen.ini; the player’s settings then live in ~/.config/scummvm/walnut/queen.ini, the saves in ~/.local/share/scummvm/saves/queen.s* (set aside by a played session: rating/test.toml).

Flight of the Amazon Queen: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Freed map blocks kept in malloc's arenas (2026-10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/MEMORY.md (“Growth over the window”, “Malloc arenas”, “Findings in the games’ code” and the Luanti rows of “Cuts, ranked”). The malloc presets and ps3-malloctrim.so, which any game can use, stay in docs/MEMORY.md.

Symptom

In the MEM=1 batch of 2026-10-18 (00:40-01:40 UTC, Mesa ps3.299, one flight of three minutes) Luanti was the biggest game: Rss 102 MB + 47.1 MB swapped, heap 74.5 MB resident (28.5 swapped), and 22.9 MB free inside malloc’s arenas at the middle snapshot, in 14 arenas. Of the swap, 28.5 MB were heap, 11.0 anonymous, 3.6 libraries, 2.7 stacks (16 threads: 1.2 MB + 2.7 swapped), 1.2 Mesa.

Game candidates for the suite (research, 2026-10-16)

Mon, 01 Jan 0001 00:00:00 +0000

This is the survey that picked the benchmark suite, done on 2026-10-16 before any of these games ran on the PS3. Step 0 had rested on OpenArena alone, which misled us about VRAM and sound, and the SPU offload and memory decisions needed 5-10 titles. Every pick has run since, and so have most reserves: Yamagi Quake II, Extreme Tux Racer and Armagetron joined the suite, Teeworlds, SuperTux and Red Eclipse were smoke-tested, TORCS waits for the user, and Nexuiz runs on our own older DarkPlaces build. Current results are in games/README.md; where this survey and the measurements differ, the measurements win.

Garbage textures and a crash in Mesa after GART ran out (2026-10-26)

Mon, 01 Jan 0001 00:00:00 +0000

The driver mechanism of the fix, Mesa 0049, is in docs/DRIVER.md. It follows the out-of-GART paths Mesa 0047 and 0048 closed for Sauerbraten (online-crashes).

Symptom

The first played session (2026-10-25, Scrap) ran at 7 fps on the old default graphics, and every texture was garbage after a restart. The first rules-2.0 session (2026-10-26, package ps3.833, Mesa ps3.827) ended in a crash on Ravenbridge Mansion, with a 21.7 s freeze in play before it, and objects popping in and out on that track (the player, side by side with the PC); the last shot is black. The segfault came while loading the track’s sky, after 414 “out of GART” lines in dmesg.

Genre: action

Mon, 01 Jan 0001 00:00:00 +0000

Genre: adventure

Mon, 01 Jan 0001 00:00:00 +0000

Genre: arcade

Mon, 01 Jan 0001 00:00:00 +0000

Genre: arena shooter

Mon, 01 Jan 0001 00:00:00 +0000

Genre: first-person shooter

Mon, 01 Jan 0001 00:00:00 +0000

Genre: management strategy

Mon, 01 Jan 0001 00:00:00 +0000

Genre: platformer

Mon, 01 Jan 0001 00:00:00 +0000

Genre: point-and-click adventure

Mon, 01 Jan 0001 00:00:00 +0000

Genre: puzzle

Mon, 01 Jan 0001 00:00:00 +0000

Genre: racing

Mon, 01 Jan 0001 00:00:00 +0000

Genre: real-time strategy

Mon, 01 Jan 0001 00:00:00 +0000

Genre: sandbox

Mon, 01 Jan 0001 00:00:00 +0000

Genre: shooter

Mon, 01 Jan 0001 00:00:00 +0000

Genre: simulation

Mon, 01 Jan 0001 00:00:00 +0000

Genre: sports

Mon, 01 Jan 0001 00:00:00 +0000

Genre: strategy

Mon, 01 Jan 0001 00:00:00 +0000

GL 3 census: open-source games that need GL 3+, and what it takes to run them on the PS3 (2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

The question: which open-source games need GL 3+ (or GLES 3), and what would it cost to get each one working on our RSX (Mesa nv30: GL 2.1, GLSL 1.20, GLES 2.0) with everything else that comes with it: memory, CPU, big-endian ppc64, data. Less bling is fine; not working is not. Games new on the PS3 come first. Vulkan-only engines are out.

The per-game detail is in the six parts next to this file, one section per game in a fixed template, with file:line citations: A, space, B, 2D and Java, C, RTS, D, FPS, E, id Tech, Doom, FreeSpace and F, engines and runtimes; the driver-level analysis is G-driver.md (it stays in docs/research: it is about the driver, not a game). The brief the agents worked from was not kept. This file is the cross-game view. Labels as in the parts: measured, read in source, estimate, UNVERIFIED.

Heretic

Mon, 01 Jan 0001 00:00:00 +0000

Raven Software’s 1994 dark fantasy shooter on the Doom engine, Shadow of the Serpent Riders’ five episodes, played with DSDA-Doom from your own copy.

Heretic: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Heretic: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested on the PS3: published so that Walnut Games can set up its data; nobody has played it on Walnut yet. Its launcher starts DSDA-Doom 0.30.0 (Debian’s package with Walnut’s patches, dsda-doom), which plays Heretic and Hexen too (started as dsda-heretic, Debian’s link to it); it plays Freedoom 2 at about 56 fps on its OpenGL renderer.

Data: game-data-packager’s heretic-wad (build.toml [data_setup]), made from the player’s own copy, in /usr/share/games/doom/heretic.wad.
Launcher (desktop/launchers), NoDisplay=true with X-Walnut-Requires= the WAD (shown once the menu rule for it exists, PLAN 5.10): dsda-heretic -iwad /usr/share/games/doom/heretic.wad -vidmode gl -width 1920 -height 1080 -fullscreen.

Engine options

DSDA-Doom is the one Walnut ships and patches; the research’s pick for vanilla exactness is Chocolate Doom (a draft here). The options:

Heretic: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Heroes II: the mid-game "hang" was a message box waiting for OKAY (2026-11-02)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom

On the PS3 (fheroes2 1.1.17+dfsg-1+ps3.1082, SDL2 through our sdl2-compat on SDL3 ps3.1090, Mesa ps3.1219), the game stopped responding in the middle of a turn. The picture stayed the same for 3 s and longer: the adventure map, the hero selected, a grey strip on the left of the map view. The process used 11-27% CPU and the GPU logged no error. A gdb backtrace was taken, then the game was killed with SIGABRT for a core dump. The player said it had played fine until then.

Heroes of Might and Magic II (fheroes2)

Mon, 01 Jan 0001 00:00:00 +0000

The 1996 turn-based fantasy strategy game: lead heroes across the map, build castles and fight tactical battles, played with fheroes2 from your own copy.

Heroes of Might and Magic II (fheroes2): guides

Mon, 01 Jan 0001 00:00:00 +0000

Heroes of Might and Magic II (fheroes2): session of 2026-11-02

Mon, 01 Jan 0001 00:00:00 +0000

Heroes of Might and Magic II (fheroes2): technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Our fheroes2 1.1.17+dfsg-1+ps3.N (packages/fheroes2): Debian’s contrib source built for ppc64 unchanged (debian-ports builds nothing from contrib). Built on 2026-10-29. The engine reads the player’s Heroes II data from ~/.local/share/fheroes2 or /usr/share/games/fheroes2 (its DATA/ and MAPS/ folders: HEROES2.AGG and the maps from the original game, GOG’s install or the demo).

Smoke runs on 2026-10-29 (kernel .874, Mesa ps3.924, the VRAM swap on; the dev build installed by dpkg -i) with the player’s own Heroes of Might and Magic II Gold: DATA/ and MAPS/ (76 MB; HEROES2.AGG sha256 7a11c86d...04315d, HEROES2X.AGG 1f3edad1...f4d41) in ~/.local/share/fheroes2. The recipe (benchmark/recipe.sh) writes a configuration with fullscreen 1920x1080, the first-run dialogs and the intro off, then clicks by XTEST: New Game, Standard Game, Okay on the first map (“4 Dimensions”). The main menu (the 4:3 picture in the middle, the sides in the game’s own brown), the scenario dialog and the adventure map at the full 1920x1080 (the map, the radar, the heroes and castles panel, the day, the scenario’s story) are drawn right, colours included (ps3-bench-20261029T022739Z-smoke-heroes-of-might-and-magic-2-base, xwd; webcam). 88 MB peak RSS, sound running with 9 audible dropouts. The Gallium HUD’s few fps mean little: the game presents only when something changes. Not checked: a turn, a battle, the pad.

Heroes of Might and Magic II (fheroes2): test runs

Mon, 01 Jan 0001 00:00:00 +0000

Hexen: Beyond Heretic

Mon, 01 Jan 0001 00:00:00 +0000

Raven Software’s 1995 sequel to Heretic, with three classes and hub levels, played with DSDA-Doom from your own copy.

Hexen: Beyond Heretic: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Which copies work

Hexen: Beyond Heretic 1.1: a CD, an installed copy (Steam: common/Hexen) or GOG’s installer (setup_hexen_beyond_heretic_1.1_(42801).exe, which has no Deathkings). Version 1.0 (the floppies and the first CD) does not run and is refused; Raven’s update to 1.1 isn’t applied for you yet.
The Macintosh CD’s Hexen.WAD is taken as a 1.1 copy (tagged mac): it is the same game with Macintosh fonts and menu art, but it has no GENMIDI instrument bank, so DSDA-Doom’s OPL music player is unavailable with it; our default player (fluidsynth) plays the same music lumps.
Deathkings of the Dark Citadel, the expansion, is optional: HEXDD.WAD from its CD or an installed copy (Steam: common/Hexen Deathkings of the Dark Citadel). It gets its own entry in Play.

Hexen: Beyond Heretic: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Data import tested, play not: GOG’s installer imported on the PS3 (2026-10-27, 85 s) and DSDA-Doom reached the title and played demo1 with the launcher’s arguments; nobody has played it on Walnut yet. Its launcher starts DSDA-Doom 0.30.0 (Debian’s package with Walnut’s patches, dsda-doom), which plays Heretic and Hexen too (started as dsda-hexen, Debian’s link to it); it plays Freedoom 2 at about 56 fps on its OpenGL renderer.

Data: game-data-packager’s hexen-wad (build.toml [data_setup]), made from the player’s own copy, in /usr/share/games/doom/hexen.wad.
Launcher (desktop/launchers), NoDisplay=true with X-Walnut-Requires= the WAD (shown once the menu rule for it exists, PLAN 5.10): dsda-hexen -iwad /usr/share/games/doom/hexen.wad -vidmode gl -width 1920 -height 1080 -fullscreen.
Deathkings of the Dark Citadel: gdp’s hexen-deathkings-wad (HEXDD.WAD 1.0 or 1.1, in /usr/share/games/doom/hexdd.wad) is optional data (edition expansion); its own launcher adds -file /usr/share/games/doom/hexdd.wad and needs that file. Not tried: none of the user’s copies has HEXDD.WAD.

Which copies work

game-data-packager wants HEXEN.WAD 1.1 (20083672 bytes, md5 abb033ca…453f); DSDA-Doom 0.30 plays nothing else.

Hexen: Beyond Heretic: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Indiana Jones and the Fate of Atlantis

Mon, 01 Jan 0001 00:00:00 +0000

LucasArts’ 1992 Indiana Jones adventure: Indy and Sophia race the Nazis to Atlantis, with three different paths through the middle of the game. Played with ScummVM from your own copy.

Indiana Jones and the Fate of Atlantis: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Indiana Jones and the Fate of Atlantis: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: published so that Walnut Games can set up its data; nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-29 (ps3-bench-20261029T051807Z-smoke-scummvm-atlantis, variant atlantis): Indy in the college’s store room with his first line, colours right. The run before it stopped at once with “Unrecognized game ‘atlantis’”: the bare id matches another engine’s game too, so the recipe used --auto-detect; the menu entries name the target in their own config instead.

Indiana Jones and the Fate of Atlantis: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Input: made for keyboard and mouse

Mon, 01 Jan 0001 00:00:00 +0000

Input: supports gamepad

Mon, 01 Jan 0001 00:00:00 +0000

ioquake3

Mon, 01 Jan 0001 00:00:00 +0000

Debian’s ioquake3 source with our patches: its package.

Technical notes

Our build of Debian’s ioquake3 (1.36+u20260719.58839361+dfsg-1+ps3.N, packages/ioquake3) replaces Debian’s and carries 30 patches (there is no 0017). OpenArena runs on it (its notes), and Quake III Arena with the player’s own data (its notes). Every change sits behind a cvar, so a recipe variant can turn it back to upstream’s behaviour. The PS3 runs ps3.959~dev (0031) since 2026-10-28; the release candidate is ps3.396 (the archived release plan).

Keywords: ball

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: bike

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: bomberman

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: building

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: courses

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: downhill

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: kart

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: levels

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: penguin

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: physics

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: theme park

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: transport

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: tron

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: tycoon

Mon, 01 Jan 0001 00:00:00 +0000

Keywords: voxel

Mon, 01 Jan 0001 00:00:00 +0000

Loom

Mon, 01 Jan 0001 00:00:00 +0000

Lucasfilm Games’ 1990 fantasy adventure: Bobbin Threadbare weaves spells as four-note drafts on his distaff. Played with ScummVM from your own copy.

Loom: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Loom: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: published so that Walnut Games can set up its data; nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-29 (ps3-bench-20261029T051548Z-smoke-scummvm-loom, variant loom): the difficulty choice (Estándar, Práctica, Experto), drawn right.

The player’s copy is the Spanish EGA release (ScummVM: “loom”, EGA, ES; 00.LFL md5 2a208ffb...a6e1). Debian’s game-data-packager doesn’t know it; ours does (loom-ega-es-data, patch 0017: 74 room files, 28 of them the other EGA releases’ own). The VGA talkie (loom-en-data) can’t be imported yet: game-data-packager rips its music from the CD’s one audio track, which the import’s manifest doesn’t describe (the engine’s todo).

Loom: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Luanti

Mon, 01 Jan 0001 00:00:00 +0000

A voxel sandbox engine for building and exploring, with Minetest Game and thousands of mods.

Luanti: guides

Mon, 01 Jan 0001 00:00:00 +0000

Luanti: LuaJIT's state allocated where it refuses it (2026-10-16/17)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. Debian has no ppc64 Luanti (its control lists only LuaJIT architectures; s390x builds 5.15.2 and passes the unit tests, a 2025 ppc64 attempt at 5.10.0 aborted in TestSAO). Our build started, but luaL_newstate() failed about 40% of the time, and with it the game.

Cause. Debian’s LuaJIT on ppc64 big-endian allocated its state between 2 and 4 GB, which LuaJIT itself then refuses: it checks that the state lies in the low 2 GB.

Luanti: session of 2026-10-24

Mon, 01 Jan 0001 00:00:00 +0000

Luanti: session of 2026-10-29

Mon, 01 Jan 0001 00:00:00 +0000

Luanti: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Luanti 5.15.2 with LuaJIT and Minetest Game runs on our own build, since Debian builds none for ppc64. At the package’s viewing range of 120 it flies the bench path at about 38 steady fps with 1-2 s of stalls in the 135 s window (since luanti 0010 and 0011, 2026-10-29: before them 20 fps and 30-36 s); at the recipe’s 60 at about 46 fps. It keeps only 11-15 MB of RAM free: the suite’s most memory-hungry engine on the CPU side. Its played session (2026-10-24, before 0010 and 0011) had a 35 fps median with 25 s of stutter a minute and frames up to 4.3 s, as new map blocks were generated and meshed.

Luanti: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Luanti: the memory variants, the interfered round and its clean repeat (2026-10-17/18)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The first run (2026-10-17) gave 67 fps HUD median in flight but a p10 of 23 and stalls to 0 while chunks loaded, with 177 MB swapped out and 32 MB free. Twenty memory variants were built, one lever each (saved, nopp, mip, chunk3, srvunload, active2, gen3, io, cliunload, leaves, tradeoff, flatlight, nominimap, view40, view90, nomerge, merge100, meshdelay, meshchunk2, noraycull, malloc, trim16, trim64; the bundles lean and leaner).

Evidence. The round of batch 2026-10-18-luanti-memory looked good: cliunload 6.5 to 0.8 s of stalls, lean rendering less terrain. The interference retro-scan then found digs and clicks during base, lean and tradeoff: somebody had played in those runs, so the cells were invalid (STALLS.md, “Interference”). The clean re-runs (batch 2026-10-18-luanti-clean-reruns, kernel .433, the kicker) and the lean parts alone (batch 2026-10-18-batch16) replaced them:

Luanti: the Settings menu and string.lower on ppc64 (2026-10-28)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The played session of 2026-10-24 noted “Options menu is broken”. Every click on the main menu’s gear, and on Settings in the pause menu, logged to ~/.minetest/debug.txt:

ModError: Runtime error from mod '' in callback open_settings():
/usr/share/luanti/builtin/common/settings/dlg_settings.lua:139:
attempt to index field 'controls_touchscreen' (a nil value)

Narrowing it down. builtin/settingtypes.txt was installed and complete. The parser (settingtypes.lua) and the page builder (load_settingtypes in dlg_settings.lua), run on the PS3 through the system’s libluajit from a small ctypes harness with stubs for core, gave 643 entries and 74 categories, Touchscreen among them, but the page ids came out as Controls_Touchscreencontrols_touchscreen: the original string followed by its lower-case copy. Then by itself:

Luanti: the stalls at viewing range 120 (2026-10-29)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. At the package’s viewing range of 120 (0009; the user’s floor, no lower) the bench flight ran at 20 fps steady with 36 s of frames over 100 ms in its 135 s window, a 1% low of 4 fps and frames up to 3.8 s (batch 2026-10-29-luanti-view120). The stall recorder put two thirds of it on cpu (the main thread in state R) and a quarter on swapping from the VRAM swap.

Lure of the Temptress

Mon, 01 Jan 0001 00:00:00 +0000

Revolution Software’s first adventure (1992): Diermot escapes the dungeon and frees the town of Turnvale from the sorceress Selena, with characters who go about their own business. Free to download.

Lure of the Temptress: guides

Mon, 01 Jan 0001 00:00:00 +0000

Lure of the Temptress: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-20 (ps3-bench-20261020T093324Z-smoke-scummvm-lure, ScummVM 2026.1.0): “Running Lure of the Temptress (VGA/DOS/English)”, the sound running; no screenshots in that run. The package holds the English, German, French, Italian and Spanish versions, each in its own folder; the launcher starts the English one (Debian’s lure wrapper picks by locale).

How it is set up

Data: Debian’s lure-of-the-temptress, installed with ScummVM by Walnut Games, in /usr/share/scummvm/lure-of-the-temptress/en.
Launcher (desktop/launchers): scummvm -c ~/.config/scummvm/walnut/lure.ini -i /usr/share/ps3-games/scummvm/lure.ini -p /usr/share/scummvm/lure-of-the-temptress/en lure through ps3-game, shown once the data is installed (X-Walnut-Requires=); the package’s own menu entry is diverted (the engine’s notes).
Settings: the initial config lure.ini; the player’s settings then live in ~/.config/scummvm/walnut/lure.ini, the saves in ~/.local/share/scummvm/saves/lure.* (set aside by a played session: rating/test.toml).

Lure of the Temptress: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Monkey Island 2: LeChuck's Revenge

Mon, 01 Jan 0001 00:00:00 +0000

The 1991 sequel: Guybrush hunts for the treasure of Big Whoop while the zombie pirate LeChuck hunts for him. Played with ScummVM from your own copy.

Monkey Island 2: LeChuck's Revenge: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Monkey Island 2: LeChuck's Revenge: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: published so that Walnut Games can set up its data; nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-28 (ps3-bench-20261028T224550Z-smoke-scummvm-monkey2, variant monkey2): the game’s copy-protection screen (the voodoo recipe wheel), drawn right; ScummVM doesn’t skip it for this release (known issue), so the run went no further.

The player’s copy is the Spanish floppy release (MONKEY2.000 sha256 bdca6e56...88ac5, MONKEY2.001 f5cb9fc5...8b3), monkey-island2-es-data in Debian’s game-data-packager 89 already.

Monkey Island 2: LeChuck's Revenge: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Mr.Boom

Mon, 01 Jan 0001 00:00:00 +0000

A Bomberman clone for up to eight players: drop bombs, blow up the walls and your friends, last one standing wins.

Mr.Boom: guides

Mon, 01 Jan 0001 00:00:00 +0000

Mr.Boom: session of 2026-10-26

Mon, 01 Jan 0001 00:00:00 +0000

Mr.Boom: session of 2026-10-26

Mon, 01 Jan 0001 00:00:00 +0000

Mr.Boom: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Mr.Boom 5.5, a Bomberman clone for up to eight players (SDL2, pads first). Debian’s ppc64 binary crashed within 15 s of every start on the PS3: both played sessions of 2026-10-26 ended in a segfault in the game’s own code on the welcome screen (Scrap). The cause is a big-endian bug in the SDL2 build, now fixed in our package; the fix passes every recorded demo under qemu, and the PS3 check is still to come.

Mr.Boom: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Mr.Boom: the emulated 8086 registers in little-endian layout (2026-10-26)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. Debian’s ppc64 mrboom 5.5+ds-1 segfaulted on the PS3 within 15 s of every start: two played sessions, both on the welcome screen, after 13-14 s of play. dmesg: mrboom: segfault (11) at 1835c88a1 ... in mrboom, a load (lbzx) from an address far outside the program.

Evidence. The fault is in program(), at an LODSB in aff_lettre (the font code), with ESI 0x481dd440. Mr.Boom is the original DOS game translated from 8086 assembly to C: program() runs the translated code on emulated registers. ESI held a value no font offset could have.

Needs: free data download

Mon, 01 Jan 0001 00:00:00 +0000

Needs: low memory

Mon, 01 Jan 0001 00:00:00 +0000

Needs: your own game data

Mon, 01 Jan 0001 00:00:00 +0000

Neverball

Mon, 01 Jan 0001 00:00:00 +0000

Tilt the floor to roll a ball through 3D levels, collecting coins before the time runs out.

Neverball: guides

Mon, 01 Jan 0001 00:00:00 +0000

Neverball: L8A8 swapped, 1-pixel mipmap levels, and graph exception 0x105 (2026-10-16)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. Neverball was the first game to show three driver bugs in one day: its fonts and HUD drew with wrong alpha, its non-square textures broke the GPU’s mipmap generation, and on Mesa ps3.223 it wedged the RSX with a graph exception (batch 2026-10-16-mesa-223-neverball-wedge: nouveau: kernel rejected pushbuf, 89 lines and 35 000 dump lines, ps3rsx: graph exception).

Evidence and cause. Each was reduced to a test in ps3-gpu-tools’ mesa-tests:

Neverball: session of 2026-10-24

Mon, 01 Jan 0001 00:00:00 +0000

Neverball: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Neverball (Debian’s 2018 snapshot of 1.6, with Neverputt) runs with the right picture at about 66 fps in the benchmark’s replay, and its played session (2026-10-24) had a 60 fps median (“played flawlessly”, the player). It found three of the driver bugs on its way.

Packages and patches

neverball, neverputt and their data (1.6.0+git20180603-3+ps3.N, packages/neverball), replacing Debian’s.

Patch	What	Switch
0001	bench mode: a replay prints its frames, seconds, fps and longest frame at its end and the game quits	`NEVERBALL_BENCH=1`
0002	the replay played N times, one line per pass	`NEVERBALL_BENCH_LOOPS=N`
0003	fewer GL calls and draws: one vertex and element buffer per solid file and one for the five item files, items drawn in a row, the background billboards transformed on the CPU and drawn per material run (76 to 13 draws), no depth toggles around empty passes, one texture unit where one is used	`NEVERBALL_GL_MESH`, `_ITEMS`, `_BACK`, `_STATE`; `NEVERBALL_GL=0` all off
0004	fullscreen by default for Neverball and Neverputt (a fresh neverballrc started an 800x600 window; fullscreen takes the desktop’s mode); checked on the PS3 with Neverputt on 2026-10-29	the `fullscreen` setting
0004	fullscreen by default (a fresh `neverballrc` started Neverball and Neverputt in an 800x600 window); fullscreen already takes the desktop’s mode (1920x1080 on the PS3); the Options menu and a saved `neverballrc` still decide. Built 2026-10-28, pending its PS3 test	the Options menu

On llvmpipe at GL 2.1 with a fixed 33 ms clock, 0003 took gui/demo1.nbr from 2154 to 844 calls and 137 to 74 draws a frame (demo2 2916 to 1285; the level intros greed 6289 to 1915 and mover 8205 to 2463; Neverputt 565 to 431). Pixels are identical except BACK’s rounding at cloud edges (demo1: 163 pixels over 7 frames, 1 level, one pixel 11); all switches off is the old build’s exact call stream. VBOs and point parameters are required with no fallback.

Neverball: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Neverputt

Mon, 01 Jan 0001 00:00:00 +0000

A 3D mini golf game: putt a ball around imaginative courses in as few strokes as possible.

Neverputt: guides

Mon, 01 Jan 0001 00:00:00 +0000

Neverputt: session of 2026-10-29

Mon, 01 Jan 0001 00:00:00 +0000

Neverputt: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Our neverputt and neverputt-data from the neverball source package (Neverball’s packages, 1.6.0+git20180603-3+ps3.N; dev build ps3.931~dev installed with dpkg -i, Neverball’s packages with it). Smoke run on 2026-10-29 (kernel .874, Mesa ps3.924, the VRAM swap on; ps3-bench-20261028T230058Z): without a ~/.neverball/neverputtrc (the recipe sets the player’s aside and restores it), Return three times by XTEST (Play, the first course, the first hole): hole 1 with the flag, the course, the score and par, fullscreen 1920x1080 from the package’s new default (neverball 0004). 129 fps steady on the Gallium HUD, 1% low 88, sound running with 6 audible dropouts, 47 MB peak RSS. Not checked: a putt, the pad, the sound by ear. The recipe: benchmark/recipe.sh.

Neverputt: test runs

Mon, 01 Jan 0001 00:00:00 +0000

OpenArena

Mon, 01 Jan 0001 00:00:00 +0000

A fast Quake III Arena style deathmatch shooter with bots, free data included.

OpenArena opengl1: batching, and why the lightmap atlas went off (2026-10-17/18)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. Game-side batching had tripled X-Moto, so the same was tried for OpenArena’s fixed-function renderer: ioquake3 0019-0022 (the lightmap atlas r_mergeLightmaps, a GL state cache, no glLockArraysEXT around batches, the sky from vertex arrays). On llvmpipe at GL 2.1 the bench demo went from 3022 GL calls and 198 draws a frame to 377 and 79, with the pixels within 1-4 levels. On the RSX it measured slower: steady 51.8 fps with all four on against 56.4 with all off (batch 2026-10-17-ioquake3-362-batching).

OpenArena opengl2 (gl2min): the 16 s freezes and the memory (2026-10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/MEMORY.md (“OpenArena opengl2 (gl2min): the 16 s freezes and the memory”). The patches are our ioquake3’s (renderer_opengl2); the driver side, nouveau’s system-memory copies of VRAM buffers and Mesa 0037’s switches that limit them, stays in docs/MEMORY.md. Both causes are settled: since batch 17 gl2min runs at 57-60 steady fps with 1-2 s of gameplay stalls.

Symptom

The profiled gl2min run of 2026-10-18 (PERF=1 MEM=1, ioquake3 ps3.396, Mesa ps3.408~dev, build/bench/ps3-bench-20261018T080250Z-openarena-gl2min, in batch 2026-10-18-batch8) had 54.7 s of gameplay stalls, a 16148 ms longest frame, 66.5 MB swapped and 117 MB of VRAM. Two causes, one in our report and one in memory.

OpenArena opengl2: making the GLSL renderer fit in memory (2026-10-15 to 10-17)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. On 2026-10-15 the GLSL renderer was tried once and dropped: it “ran out of RAM compiling its shaders” (commit 82b6b5f), before the VRAM swap and game mode existed. On 2026-10-17 it ran on nv30 (e708512: all 97 programs link), but compiled them twice at about 25 s each, and Debian’s build played the bench demo at 10.7 fps (gl2, Debian’s opengl2 defaults: 15.9).

Evidence. Where the memory went, from the hunk counters and Mesa’s allocations: Mesa kept every shader’s source and IR after its program linked; 27 bone-animation programs indexed a 105-matrix array, which nv30 (no indirect constant addressing) turns into compare trees; 15 shadow and post-processing programs needed framebuffer objects gl2min never uses; a renderer restart at the map load compiled everything again; the VAO cache held 21 MB that were never drawn from; and the renderer kept a CPU copy of every MD3 vertex frame, about 87 MB of hunk for the demo’s models.

OpenArena: guides

Mon, 01 Jan 0001 00:00:00 +0000

OpenArena: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

OpenArena: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

OpenArena: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

OpenArena 0.8.8 (Debian’s data) runs on our ioquake3 with both of its renderers. The fixed-function opengl1 renderer is the suite’s baseline: 70.6 steady fps with no gameplay stalls. The GLSL opengl2 renderer, in its lean gl2min settings, reaches 56-60 fps with 0-2.4 s of gameplay stalls since ioquake3 0027 sends its vertex colours in a format nv30 fetches. In played sessions the GL 2.0 launcher did better than GL 1.2 (54 against 43 fps median), so the game’s medal comes from GL 2.0.

OpenArena: test runs

Mon, 01 Jan 0001 00:00:00 +0000

OpenRCT2

Mon, 01 Jan 0001 00:00:00 +0000

An open source re-implementation of RollerCoaster Tycoon 2: build a theme park, its rides and coasters, and keep the guests happy.

OpenRCT2 on the PS3: big-endian port estimate (2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from game-reeval.md, where it was part B of the re-evaluation of 2026-10-19 (the file reeval-part-B-openrct2.md its ranked table names). It was written before the port: the package and its PS3 runs are in the game’s bundle (technical notes, the port).

2026-10-19. Read-only look at the source plus web research. Nothing was built for ppc64. The RAM figure in section 9 was measured in a throwaway amd64 container.

Sources examined:

OpenRCT2: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

The expansions

The Wacky Worlds and Time Twister expansions are optional. They come with the Triple Thrill Pack (its CD, a Steam or GOG folder, or either GOG installer, setup_rollercoaster_tycoon2_2.0.0.6.exe or setup_rollercoaster_tycoon_2_triple_thrill_pack_2.01.043_(17987).exe), and the same import installs them as roller-coaster-tycoon2-wacky-worlds-time-twister-data. Their scenarios then get their own tabs in OpenRCT2’s scenario list. The original 2002 CD has only the base game.

OpenRCT2: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Published, Untested: OpenRCT2 0.5.6 ported to big-endian ppc64, packaged, installed on the PS3 and baselined, not played yet. Under qemu-ppc64 the build matches amd64 bit for bit on every check (gtest 275/275, 35 parks after 10000 ticks, 210 screenshots, 169 track designs: the port). Software renderer only (the GL engine needs GL 3.3 core). It needs RollerCoaster Tycoon 2’s data from the player’s own copy: game-data-packager’s roller-coaster-tycoon2-data (build.toml [data_setup], in /usr/share/games/roller-coaster-tycoon2, a path upstream searches: a fresh home finds it there, gdp-step1 on the PS3), which the licensed suite now builds too, or our older licensed rct2-data (from the CD, /usr/share/games/rct2, the path our patch 0005 adds). On the PS3 it runs at 21-24 fps in Electric Fields (10 fps in Six Flags Magic Mountain) with the console’s RAM nearly gone.

OpenRCT2: test runs

Mon, 01 Jan 0001 00:00:00 +0000

OpenRCT2: the big-endian port, milestone 1 (2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

The port followed the estimate of the same day. Upstream refuses big-endian on purpose (a static_assert in Platform.h), so this is our own out-of-tree series.

Starting point. The closed PR #27114, “AmigaOS 3.x (m68k, big-endian) port [RFC]” (Thomas Luebker, 43 commits, 2026-09-10/12, head a5dbca57c5be, closed unmerged as too invasive and AI-generated), contributed to OpenRCT2 and so GPL-3.0-or-later like the rest of the tree. Its endian core was applied on v0.5.6 (82b30979) with 2 conflicts resolved (DataSerialiserTraits.h, SawyerCoding.cpp) and cleaned of the Amiga parts. The work was done in a cross build (g++-16 for powerpc64 against a ppc64 sysroot) with the ppc64 binaries run under qemu-ppc64-static, next to a native amd64 build of the same tree.

OpenRCT2: the blue screenshots and the console defaults (2026-10-27)

Mon, 01 Jan 0001 00:00:00 +0000

Report. In the data-pilot run (docs/TESTS.md, 10-27 17:43) OpenRCT2 0.5.6+ds-1+ps3.889 with roller-coaster-tycoon2-data 89 (game-data-packager’s import of the user’s CD) showed the title, the windows and Electric Fields in blue and purple in every xwd screenshot, while the 10-19 smoke test (the old rct2-data, build ps3.574) had looked right. It also started in a 1280x720 window with the changelog open.

The colours: the game draws right, the screenshot is wrong

Nothing was wrong with the game, the data or the renderer. Same build, same data, same config (drawing_engine = SOFTWARE_HWD, the default a fresh config gets), started windowed:

OpenTTD

Mon, 01 Jan 0001 00:00:00 +0000

A transport simulation: build railways, roads, ships and airports and run a profitable company.

OpenTTD: "no memory to back the GART" with the staging pool (2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. One of 13 OpenTTD runs since Mesa ps3.544 (20261019T102932Z-openttd-base, with NV30_STAGING_POOL_MB=24) logged five ps3rsx: no memory to back the GART (56 of 63 MiB in use) within a second, at 37683 s of uptime; bench/analysis/logscan.py flagged it as NEW. The run still finished (ended=window), nothing showed in the picture, and the other twelve runs are clean.

Cause. OpenTTD uploads an 8 MB staging buffer per frame; the 24 MB pool (Mesa 0040) and the rest of the process’s buffers reach the 63 MiB GART when something else arrives at the same moment (a second 4 MB buffer, the title screen’s textures). This is a different path from the GART-full crashes of other games: the kernel cannot get pages (CMA chunks) to back the GART, not a full aperture. The draw that asked for the buffer may have been dropped.

OpenTTD: guides

Mon, 01 Jan 0001 00:00:00 +0000

Original graphics and sound

OpenTTD plays with its free OpenGFX, OpenSFX and OpenMSX. If you own Transport Tycoon Deluxe for Windows, its original graphics, sounds and music can replace them. It needs the trg*.grf files and sample.cat of the Windows version, and takes its music in either arrangement: the General MIDI gm_tt*.gm files or the FM synthesizer ones, fm/9_tt*.fm, which some copies have instead. The data is installed as transport-tycoon-deluxe-data, with -music (General MIDI, OpenTTD’s original_windows music set) or -music-fm (the FM files and their own set, original_windows_fm, which our game-data-packager writes); both are Standard MIDI files that OpenTTD plays through FluidSynth. Once trg1r.grf exists the game offers a launcher with the original sets (-I/-S original_windows, and -M the General MIDI music when it is there, else the FM music); it picks them at every start, so a music choice made in its options lasts until the next start.

OpenTTD: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

OpenTTD: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

OpenTTD: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

OpenTTD 15.1 runs with the right picture through both of its video drivers: SDL’s software path and the OpenGL driver, which our patches made start on nv30. With the 8bpp-optimized blitter (our package’s default since patch 0003) and Mesa 0040’s staging pool, the 1962 benchmark savegame plays at about 52 steady fps; its OpenGL played session (2026-10-25) had a 60 fps median with clean music. The software driver plays too, but gives the frame timer nothing to measure.

OpenTTD: test runs

Mon, 01 Jan 0001 00:00:00 +0000

OpenTTD: the 1962 savegame, and why the 8bpp-optimized blitter became the default (2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. On the new savegame benchmark (820 vehicles, 30 towns, the camera on a city of 5000, sound and music on, the GL driver) Debian’s default 32bpp-anim blitter ran at 10-14 fps, mostly 11, with 22-54 s of gameplay stalls in the 120 s window, 3500-4700 underruns, 13-22 MB free.

Evidence (batch ssdroot3: SSD root, kernel .472, Mesa ps3.476, openttd ps3.297, three rounds per group):

Variant	Steady fps	1% low	Gameplay stalls	Underruns	Free RAM
`base` (32bpp-anim), 9 runs	10-14, mostly 11	5.5-7.5	22-54 s	700-4700	13-22 MB
`blit8` (8bpp-optimized)	34, 35, 43	13-15	0.3-0.5 s	2600-4000	41 MB
`blit32` (32bpp-optimized)	13-14	6-6.5	26-35 s	3400-4400	18-26 MB
`nosound` / `nomusic` / `quiet`	14 / 13 / 14	7-8	19-21 / 24-28 / 19-21 s	0 / 63-107 / 0
`hz22`, `buf2048`, `buf4096`	11-14, as `base`	5.7-7.5	21-46 s	80-3500
`zoomout`	7	4.0-4.3	115-120 s	3200-4400	9-18 MB
`scroll`	7-8	3.9-4.4	100-116 s	2700-4600
`simplay` (the save’s simulation only)	6000 ticks in 82.7 s				51 MB

32bpp-anim draws every sprite into a 32-bit buffer and keeps an 8-bit animation buffer next to it; the 8bpp-optimized blitter writes one byte a pixel and the GL driver applies the palette on the GPU. So the frame rate triples and a frame no longer takes 100 ms or more. 32bpp-optimized (no palette animation) gains only 2 fps. The picture is the same: webcam pairs of base and blit8 at 60 s and 150 s show the same sprites, town labels, bridges, water and date bar (the speckled water is the webcam catching the palette animation mid-cycle, in both). OpenGFX is an 8bpp base set, so nothing the 8bpp blitter loses shows; 32bpp-only NewGRFs would. Zooming out and scrolling were the worst case: the sprite count per frame. The music costs about 3 fps (-20%) and 25-30 s of stalls.

OpenTTD: the OpenGL driver on GL 2.1, and SDL3's blue cast (2026-10-16 to 10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The research expected the GL mode to fail at init with no GPU risk, and it did: stock -v sdl-opengl refused to start on nv30 with “Single element texture formats not supported” (batch 2026-10-16-openttd-smokes). The software path started, but with a strong blue cast.

Cause.

The OpenGL driver needs GL 3.0 or ARB_texture_rg for its single-channel textures; its VAO check wants ARB and APPLE vertex array objects below GL 3.0 (an upstream bug: Mesa has no APPLE one); and its sprite shaders use texture2DLod in the fragment stage, which needs ARB_shader_texture_lod (nv30 has no TXL).
SDL3’s accelerated window framebuffer was BGRA8888 on big-endian, so OpenTTD’s 0xAARRGGBB words came out with red and blue swapped.

Fix.

Origin: remake or clone

Mon, 01 Jan 0001 00:00:00 +0000

Part A: space games (Endless Sky, Naev)

Mon, 01 Jan 0001 00:00:00 +0000

Endless Sky (own C++ engine, SDL2 + GLEW, upstream master 2026-10-18; Debian sid/ports 0.11.2-1)

Verdict: the only game of the pair worth porting, and upstream already ships an “experimental OpenGL 2” path (3D textures instead of texture arrays, no VAO, EXT FBO) that needs GLSL 1.20 shader files supplied as a plugin, so effort is M. The blocker is memory: 1.3 GB RSS on the PC with the lowest texture settings, 477 MB of it GPU textures; it fits 256 MB only after DXT compression plus more cuts, and that is unproven. ppc64 binary exists in debian-ports, novelty is 5 (no PS3 port found).

Part B: 2D games and Java (Taisei, OpenClonk, Hypersomnia, DDNet, Mindustry)

Mon, 01 Jan 0001 00:00:00 +0000

All measurements: Debian sid amd64 in a podman box, Xvfb + llvmpipe (Mesa 26.2.5, GL 4.6 core), no audio device. Taisei at 960x540, OpenClonk and Hypersomnia at 1280x720, Mindustry at 1280x720 (llvmpipe at 1080p ran at 7 fps for Taisei and starved the game logic, so the smaller windows were used; texture MB do not depend on window size, framebuffer MB do). llvmpipe baseline ~100 MB is subtracted for PS3 estimates. Reports (small) are under /mnt/data_linux/Temp/ps3/gl3census/traces/{taisei,clonk,hyper,mindustry}/c*/report.md; big traces and downloads were deleted.

Part C: RTS games (Warzone 2100, OpenRA, Beyond All Reason / Recoil, 0 A.D.)

Mon, 01 Jan 0001 00:00:00 +0000

Measured 2026-10-19 on the PC (Debian sid box wz, Xvfb 1920x1080, llvmpipe, Debian package 4.7.0-3). Census report kept at /mnt/data_linux/Temp/ps3/gl3census/traces/wz/c47/report.md, mem files in work/wz/.

Warzone 2100 (own engine, SDL2 + GLAD, QuickJS; master of 2026-10-17 = 4.7.x, Debian sid 4.7.0-3)

Verdict: the current line (4.4 to 4.7) needs GL 3.0/3.1+ and is not worth porting, but release 4.3.5 (2023-04-16) is the last one that runs on plain GL 2.1 or GLES 2.0 with GLSL 1.20 shaders, no instancing, no UBOs, no texture arrays. So the route is “build 4.3.x, change nothing in the renderer, maybe cut textures”. Effort S to M, RAM is the open question (estimate 300-450 MB, so it needs cuts to fit; not 256 MB friendly), novelty 5. ppc64: Debian ports ships 4.5.5deb-1+b1 on ppc64 (so the game compiles and links big-endian); 4.5.5 itself needs GL 3.0 though.

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

Mon, 01 Jan 0001 00:00:00 +0000

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)

Part E: id Tech 4, the Doom source ports, FreeSpace 2 Open

Mon, 01 Jan 0001 00:00:00 +0000

The agent for this part stopped at the usage limit after its measurements; the coordinator wrote the part from its saved runs ($B/traces/dhewm3, $B/traces/gzdoom) and from the clones it left ($B/src/{dhewm3,gzdoom,tdm,fs2open.github.com,doomsday}). Clone dates: dhewm3 455b88e 2026-06-08, GZDoom c26ce2e 2026-08-10, fs2open 2026-10-18.

dhewm3 (Doom 3 GPL engine, 1.5.5 / git 455b88e)

Verdict: not GL3-blocked. It renders with GL 1.x fixed function plus ARB_vertex_program / ARB_fragment_program, which nv30 exposes; big-endian is a first-class build option. The blocker is memory: the free Doom 3 demo’s first map peaked at 1161 MB on the PC. Effort M (our ppc64 build, texture downsizing and compression, memory cuts), playable only if those cuts land. FEATURES: glsl_min=none (ARB assembly) core_only=n fallback=gl1 int_ops=no bitwise=no texelFetch=no textureSize=no ubo=no instancing=no tex_arrays=no float_tex=no float_rt=no rg_tex=no mrt=1 vao=no sync=no geom=no tf=no compute=no derivatives=no textureLod_fs=no vertexid=no flat=no arb_fbo=no srgb_fb=no vtf=no dyn_loops=no big_shaders=no (ARB programs written for NV30/R300-class cards) SCORES: popularity=4 novelty=3 playability_256MB=2 effort=M ppc64=not-in-debian (contrib, arch any: our build) data=non-free (free demo, 462 MB) size_MB=462 (demo) / ~1500 (retail)

Part F: engines and runtimes (OpenMW, Barotrauma, Godot 3 games, SDL3 GPU / raylib, skips, scan)

Mon, 01 Jan 0001 00:00:00 +0000

Measured on the PC in podman boxes (Xvfb 1920x1080, llvmpipe, apitrace). Everything not marked “measured” or “read in source (file:line)” is UNVERIFIED or an estimate.

OpenMW (OpenSceneGraph, 0.51.0, git 2026-10-18 master)

Verdict: Already GL 2.1 / GLSL 1.20 in its default configuration, so it is not GL3-blocked. Real work is big-endian (ESM and BSA readers do no byte swapping, so Morrowind.esm cannot be read on ppc64 today; M), then CPU and memory tuning for a 3.2 GHz in-order PPE with ~160 MB. Debian-ports ppc64 builds 0.51.0-1+b4. Data is non-free (Morrowind) unless one plays the CC0 Template and Example Suite. Novel on the PS3: yes.

Particles of one size at every distance: nv30 never took the vertex program's point size (2026-10-27)

Mon, 01 Jan 0001 00:00:00 +0000

Found right after the round particles of the point-smooth fix showed up on the PS3; the driver mechanism of this fix, Mesa 0051 and ps3rsx’s PS3_ABI 2, is in docs/DRIVER.md.

Symptom

With Mesa ps3.874 the particles (blood, sparks, bullet trails) were round, but every one was a disc of about 40 pixels at 1080p, whether it was next to the player or across the room. Blood sprays turned into big overlapping blobs. The user remembered them as “gradients on PC, or much smaller”.

Players: bots

Mon, 01 Jan 0001 00:00:00 +0000

Players: local multiplayer

Mon, 01 Jan 0001 00:00:00 +0000

Players: online multiplayer

Mon, 01 Jan 0001 00:00:00 +0000

Players: single player

Mon, 01 Jan 0001 00:00:00 +0000

Quake III Arena

Mon, 01 Jan 0001 00:00:00 +0000

id Software’s 1999 arena shooter against bots, played with Walnut’s ioquake3 from your own copy, with Team Arena if you have it.

Quake III Arena: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Which editions work

A Quake III Arena CD (or its ISO, or an MDF/MDS image of it): baseq3/pak0.pk3. The CD’s release is older than 1.32, so the import downloads id’s 1.32 point release (linuxq3apoint-1.32b-3.x86.run, 30 MB) for pak1 to pak8, the files ioquake3 needs.
GOG’s Quake III Gold (setup_quake3_2.0.0.2.exe, or the folder it installs): Quake III Arena and Team Arena, both at 1.32; nothing is downloaded. The installer is unpacked whole, so it needs more free space than the folder.
Steam’s common/Quake 3 Arena folder: the same files as GOG’s.
The demo (quake3-demo-data) is a package of the same tool; it has not been tried.

What you get

Two menu entries, shown once their data is there: Quake III Arena (fs_basepath /usr/lib/quake3/base) and Quake III: Team Arena (/usr/lib/quake3/ta, fs_game missionpack). Both start fullscreen at the TV’s resolution with the OpenGL 1 renderer and a pad mapping (triggers fire and zoom, shoulders change weapons, A jumps, B crouches, Start opens the menu), from Walnut’s autoexec.cfg in each folder.

Quake III Arena: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested as a played game: published so that Walnut Games can set up its data. On 2026-10-27 the data came from the CD’s ISO on the PS3 and ioquake3 loaded q3dm1 with the right picture (lightmaps, models, HUD; xwd fullscreen, looked at); on 2026-10-28 from GOG’s installer, with Team Arena, whose mpteam1 loaded with its own HUD. Nobody has played a session or measured it yet.

Packages, data and settings

Engine: our ioquake3 (ioquake3, OpenArena’s engine), /usr/lib/ioquake3/ioquake3. Its package already has Debian’s native game code links: /usr/lib/quake3/base/baseq3/{cgame,qagame,ui}.so for Quake III and /usr/lib/quake3/ta/{baseq3,missionpack}/ for Team Arena. The launchers set vm_cgame 0, vm_game 0, vm_ui 0 and sv_pure 0, so ioquake3 loads those native libraries (ioquake3’s build of id’s GPL game code, the same game as 1.32’s bytecode): ioquake3 has no PowerPC compiler for the QVM bytecode any more (only x86, x86-64 and ARM), and the interpreter is slow on the PPE. With sv_pure 1 the client would insist on the paks’ bytecode.
Data: game-data-packager’s quake3-data (/usr/share/games/quake3-data/baseq3/pak0-8.pk3) and quake3-team-arena-data (.../quake3-team-arena-data/missionpack/pak0-3.pk3), each with gdp’s links into /usr/lib/quake3/{base,ta}. Those links are why the data manifest and walnut-games-helper take symlinks now (docs/PACKAGING.md “Links”). Team Arena’s Conflicts/Replaces quake3-data (<< 77~) is about old gdp builds and is left out of the manifest: unversioned it would remove quake3-data.
Launchers (desktop/launchers), both NoDisplay=true with X-Walnut-Requires= the pak0 of their data: “Quake III Arena” (fs_basepath /usr/lib/quake3/base) and “Quake III: Team Arena” (fs_basepath /usr/lib/quake3/ta, fs_game missionpack).
Defaults: autoexec.cfg in /usr/lib/quake3/base/baseq3/ and /usr/lib/quake3/ta/baseq3/ (desktop/files), OpenArena’s: opengl1, r_mode -2 fullscreen at the desktop’s resolution, vsync, com_maxfps 60, DXT1 textures, the pad bindings; and cl_cdkeyCheck 0 (ioquake3 0030): without it both menus open on a CD KEY screen at every start. ui_cdkeychecked can’t skip it: the UIs register it CVAR_ROM, which forces a value set on the command line or in a config back to 0. No key is shipped or needed (it mattered only to id’s authorize servers).
Settings live in ioquake3’s XDG folders: ~/.config/Quake3, ~/.local/state/Quake3 (~/.q3a when it exists).

Data sources tried

CD ISO (QUAKE3.iso, 1.11-era: Quake3/baseq3/pak0.pk3 and pak1): loop-mounted by walnut-data; gdp needs 1.32’s pak1-8 too, from id’s point release linuxq3apoint-1.32b-3.x86.run. gdp downloaded it from ftp.fu-berlin.de (idstuff) in the games builder on the PC. On the PS3 the import ran with --no-download and GOG’s pak1-8 beside the ISO, for lack of room for the download’s 128 MB.
GOG’s Quake III Gold (setup_quake3_2.0.0.2.exe, 921 MB, known to gdp): gdp unpacks baseq3/pak0.pk3 as well when only Team Arena is asked for (the installer unpacks to 981 MB, whichever package is asked for); walnut-data’s space check counts that. On the PS3 (2026-10-28) a plain import made quake3-data in 349 s and named Team Arena as an add-on, -p quake3-team-arena-data took 315 s; about 2.4 GB free for the base and 2 GB for Team Arena, besides the installer itself.
MDF/MDS: the CD’s ISO written as a 2448-byte-sector MDF (2352 + 96 bytes of subchannel) with its .mds and extracted again by walnut-data’s code gave the ISO 9660 volume byte for byte (on the PC).

Known problems

Sound drops out for 80-170 ms about once a minute in a game with bots (OpenAL’s mmap commit error: Broken pipe in the log, one per dropout): OpenAL’s mixer thread starves at normal priority. With a real-time limit for the session there were none in 3 runs; that change is system-wide and not made yet (the investigation).

Engine options

ioquake3 (the pick: OpenArena runs on our ioquake3 engine, gamedb/engines/ioquake3)
Quake3e (a performance fork: x86/ARM JIT, Vulkan; no PPC JIT)
spearmint (not fetchable)
id’s Quake-III-Arena (frozen dump, reference)

Research

What the surveys and plans said about it, newest first; each line names its source, the section and the date.

Quake III Arena: test runs

Mon, 01 Jan 0001 00:00:00 +0000

QuakeSpasm

Mon, 01 Jan 0001 00:00:00 +0000

A modern source port of id Software’s Quake, with the original campaign and mods.

QuakeSpasm: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Which editions work

Shareware (free): version 1.06, the first episode, downloaded as quake106.zip by game-data-packager (package quake-shareware); a quake106.zip you already have works as a source too.
The full game: package quake-registered. It needs id1/pak0.pak and id1/pak1.pak of your copy: a CD, The Offering from GOG (the installed folder or setup_quake_the_offering_*.exe), or a Steam common/Quake folder. The 2021 re-release can’t stand in for it: it has no original paks (it is an edition of its own, below). A CD’s 1.01 pak0.pak is brought to 1.06 with the patch files game-data-packager downloads.
The CD’s music: package quake-music, optional. A BIN/CUE image of the CD (give the .cue, or the .bin next to it) brings the data and the music in one import.
The 2021 re-release (Nightdive’s Quake Enhanced): package quake-rerelease, edition Remaster. From GOG’s installer setup_quake_enhanced_1.0_(60828).exe (607 MB) or that build installed; other builds of the re-release (Steam’s, older GOG updates) have not been checked. It takes the re-release’s own id1/pak0.pak (the whole game in one 172 MB pak, with coloured lighting and the re-release’s QuakeC), its English text from QuakeEX.kpf and its CD music, 257 MB installed. The import on the PS3 takes about four minutes.
The re-release’s add-ons, optional, from the same installer: Scourge of Armagon (quake-rerelease-armagon, 103 MB with its music), Dissolution of Eternity (quake-rerelease-dissolution, 70 MB with its music), Dimension of the Past (quake-rerelease-dopa, 39 MB) and Dimension of the Machine (quake-rerelease-dimension-of-the-machine, 474 MB). These are the re-release’s own builds, with QuakeC written for it, so they need quake-rerelease and don’t play with the original game’s paks. An import of the installer makes the re-release and then names each add-on it holds (Walnut Games shows an Also add button for each; walnut-data import -p quake-rerelease-dopa quakespasm <installer> adds one). All four played on the PS3 (2026-10-28), each with its own music where the pack has it. Dimension of the Machine needs about 2.5 GB free while it is made. The installer’s CTF pak (Threewave Capture the Flag) is left out: it is for multiplayer, and QuakeSpasm has no bots.
The mission packs (quake-armagon, quake-dissolution) and their music are packages of the same tool; they have not been tried on the PS3.

What you get

The data ends up in /usr/share/games/quake/id1, the music in /usr/share/games/quake/id1/music (QuakeSpasm plays trackNN.ogg there for the CD track a level asks for). The menu entries QuakeSpasm (GLSL) and QuakeSpasm (no GLSL) read /usr/share/games/quake, so they play whichever edition is installed, and they show only when one is (shareware or full game). quake-registered replaces quake-shareware, so the full game takes over the same folder. The 2021 re-release has a folder of its own, /usr/share/games/quake-rerelease, next to the original game, and its own menu entry, Quake (2021 re-release), which shows once it is installed; each add-on goes into a folder there (hipnotic, rogue, dopa, mg1) and has its own entry, such as Quake (2021): Dimension of the Machine. The original game keeps its saves and settings in ~/.quakespasm/id1, the re-release in ~/.quakespasm/rerelease and each add-on in ~/.quakespasm/<its folder>.

QuakeSpasm: session of 2026-10-26

Mon, 01 Jan 0001 00:00:00 +0000

QuakeSpasm: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Debian’s quakespasm 0.96.3, unpatched, with the Quake shareware data. It plays the shareware’s demo1 timedemo at 91.0 steady fps with almost no stalling (batch 2026-10-18-mesa-407-switches), and its played session of 2026-10-26 (the GLSL launcher) had a 70 fps median with a 1% low of 42 and no audible dropouts: one of the games that meet the 60 fps target with room to spare.

Packages, data and settings

quakespasm from Debian, nothing of ours in the binary. Two menu entries of ours (desktop/launchers) replace Debian’s (diverted): “QuakeSpasm (GLSL)” and a -noglsl one, both -basedir /usr/share/games/quake -nopackedpixels -width 1920 -height 1080 -fullscreen, packed hidden (NoDisplay=true, X-Walnut-Requires=/usr/share/games/quake/id1/pak0.pak, which the shareware and the full game both have), so they show only with the original game’s data; a third, Quake (2021 re-release), for the re-release’s own folder (below). Don’t install the quake launcher package: it pulls GTK 4.
-nopackedpixels: 0.96.3’s packed-pixel lightmaps give wrong colours and dlight wraparound on big-endian (quakespasm issue #114). Upstream master disables the path on big-endian; nv30 has no 10-bit format anyway.
The data (licensed, not in the public suite): quake-shareware (/usr/share/games/quake/id1/pak0.pak, Quake 1.06 shareware, 18 MB, demo1-3), built once on the PC by game-data-packager 89 (make game-data, the Debian games builder with lhasa; the shareware archive downloaded from id’s mirrors and kept in build/downloads/game-data) as quake-shareware_89_all.deb, Section non-free/games, and published once to our licensed suite, since game-data-packager’s output isn’t reproducible: the version 89 files the LAN repository published are in the retirement backup’s ps3-licensed-debs/, and make publish DEBS="<those files>" before the next make game-data keeps them the same. Install it by name or from Walnut Games (ps3-games-licensed, which pulled it in, is retired). A registered Quake needs the player’s own id1/pak0.pak and pak1.pak (the data guide on the game’s page).

How it performs

Bench (batch 2026-10-18-mesa-407-switches, the kicker on, same boot): steady 91.0, 1% low 48.6, 2.5 s of gameplay stalls (10 frames over 100 ms), longest 393 ms, 44 MB free at the lowest, 49 MB of VRAM, 5 underruns. Mesa’s NV30_TRANSLATE_LUT=1 changed nothing in fps (90.9/91.0 against 91.0/90.8) but saved about 3% of the CPU.
Memory: 58 MB Rss, its 256 MB heap mapping 24.8 MB touched. The cache inside the heap never needs flushing at this size, so sounds and models stay loaded; nothing to cut (MEMORY.md).
How it got there: the first runs on 2026-10-17 gave 59.2 fps without GLSL, 64.8 with, 70.3 with the gamma pass, colours right; Mesa ps3.262 took it from 70.5 to 78.6 (+11%, batch 2026-10-17-mesa-262).

The recipe (benchmark/recipe.sh) can’t use +timedemo on the command line: the shareware’s own quake.rc runs startdemos demo1 demo2 demo3 after the command line and the attract loop replaces the timedemo, and the shareware refuses -game directories. So a quake.rc of ours in ~/.quakespasm/id1 loops the timedemo by frame count (bench starts it and waits 1100 host frames; demo1’s timedemo is 969 frames), since QuakeSpasm has no hook at a demo’s end: about 5 warm-up passes of 13 s, then about 9 measured. A line starting with -1 frames means a timedemo started before the last one ended. Base keeps GLSL on with gamma at 1.0, so the full-screen gamma pass doesn’t run; variants noglsl and glslgamma.

QuakeSpasm: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Sauerbraten

Mon, 01 Jan 0001 00:00:00 +0000

Cube 2: Sauerbraten, the 2020 Edition: a fast first person shooter with bots, over 200 maps and an in-game map editor.

Sauerbraten: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Sauerbraten’s maps, textures, models, sounds and music are not part of the package: their licences are mixed and much of it is Creative Commons non-commercial, so Walnut does not distribute them. They are free to download from the game’s own site, and the steps unpack them where the launcher looks.

Which edition works

The official 2020 Edition release for Linux, sauerbraten_2020_12_29_linux.tar.bz2, from sauerbraten.org (the download is hosted on SourceForge; the link in the steps on the Overview is the file’s address there). Its SHA-256 sum is in step 3 of those steps. Debian’s cube2-data is not this game: it holds the data of BananaBread, a different game on the same engine.

Sauerbraten: session of 2026-10-24

Mon, 01 Jan 0001 00:00:00 +0000

Sauerbraten: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

Sauerbraten: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

The real game: Sauerbraten’s 2020 Edition release with its maps, models, sounds and music, on the same Cube 2 engine build that runs BananaBread. Debian’s cube2 is Sauerbraten’s own engine source, so no second engine package was made (building the release’s source again would give the same program without the patches); what was missing was the launcher and the data. It plays right, but its big maps fill the 250 MB of VRAM, and both played sessions ended in a crash in Mesa when that happened. Those two crashes are fixed (Mesa 0046, then 0047 and 0048); a session with all three is still to be played.

Sauerbraten: test runs

Mon, 01 Jan 0001 00:00:00 +0000

ScummVM

Mon, 01 Jan 0001 00:00:00 +0000

Debian’s scummvm, unpatched. It runs each of these games from its original data: the free ones from Debian’s packages, the others from your own copy, which Walnut Games makes into a package. Every game has its own menu entry that starts it directly, fullscreen, with the pad as the mouse; ScummVM’s own launcher stays in the menu for everything else.

Technical notes

Debian’s scummvm, unpatched (2026.4.0+dfsg-1 on the PS3 in the smoke runs of 2026-10-29; 2026.1.0 before). The licence is GPL-3.0-or-later: the sources’ headers since ScummVM 2.7 (Debian’s copyright file still says GPL-2+ for most files). Each game it runs is a GameDB entry of its own (the user, 2026-10-30: “we don’t rate engines, we rate games”); the old scummvm bundle is a draft that keeps ScummVM’s own launcher and the smoke-test recipe.

SIGTERM hangs ioquake3; OpenAL's "mmap commit error" (2026-10-28)

Mon, 01 Jan 0001 00:00:00 +0000

Two problems seen in Quake III’s first runs on the PS3 (2026-10-27): ioquake3 hung for good after a SIGTERM, and OpenAL logged [ALSOFT] (EE) mmap commit error: Broken pipe during play. Tested on the PS3 (kernel .472, Mesa ps3.924, openal-soft ps3.874) with OpenArena (opengl1 and opengl2) and Quake III with its native game libraries, each started through ps3-game on the desktop’s display with a map.

SIGTERM: the shutdown ran inside the signal handler

Symptom. With ioquake3 ps3.931 a SIGTERM after the map had loaded hung the game in 4 of 6 tries (OpenArena 2 of 3, Quake III 2 of 3); the log stopped at RE_Shutdown( 1 ), the last frame stayed on the TV, and only SIGKILL ended it. A second SIGTERM did nothing.

Skeletal models skinned on the SPEs (2026-10-17)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/SPU.md (“BananaBread’s skinning”), where libspeq’s skinning op stays described. Measured in BananaBread; the patches are the Cube 2 engine’s.

Symptom

The engine skins its skeletal models (players, the hud gun, monsters) either on the GPU (gpuskel 1) or on the CPU. GPU skinning runs on nv30 without a wedge but at 11 fps against 28 with CPU skinning: nv30 turns the vertex program’s bone lookups into if/else trees. So cube2 0002 makes CPU skinning the default and drops the GPU skinning shaders, and the skinning becomes PPE time.

Square particles: nv30 ignored GL_POINT_SMOOTH (2026-10-26)

Mon, 01 Jan 0001 00:00:00 +0000

Found in the played session of 2026-10-26; the driver mechanism of the fix, Mesa 0050, is in docs/DRIVER.md.

Symptom

In the session the player saw Quake II’s round particles (blood, sparks, bullet trails) drawn as squares on the PS3, against round ones on the PC (the session’s review: “missing: ps3: round particles … draw as squares”).

Cause

Yamagi Quake II’s GL1 renderer draws its particles as GL_POINTS with GL_POINT_SMOOTH. nv30 ignored point_smooth, and NV3x/NV4x have no known smoothing switch, so every point was a square.

Started from the Games menu, Luanti found no X (2026-10-18)

Mon, 01 Jan 0001 00:00:00 +0000

A start from the desktop’s Games menu on the PS3 that went wrong. The bug was game mode’s, not Luanti’s; its fix (ps3-desktop 0.456, commit ba80992) is described in docs/DESKTOP.md.

Symptom

On the PS3, Luanti started from the Games menu found no video device and quit. About 10 s after the click, X stopped answering other clients; killing jgmenu freed it.

Cause

Game mode freezes the desktop’s programs (ps3-desktop.slice) when a game starts. The freeze had caught jgmenu, which stays running between uses, while it held its keyboard and pointer grab, so X waited on a frozen client and Luanti’s connection to it got no answer.

SuperTuxKart

Mon, 01 Jan 0001 00:00:00 +0000

A 3D kart racer with items, many tracks and a family-friendly cast.

SuperTuxKart: guides

Mon, 01 Jan 0001 00:00:00 +0000

SuperTuxKart: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

SuperTuxKart: session of 2026-10-26

Mon, 01 Jan 0001 00:00:00 +0000

SuperTuxKart: session of 2026-10-26

Mon, 01 Jan 0001 00:00:00 +0000

SuperTuxKart: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

SuperTuxKart 1.5 runs on its legacy GL 2.1 renderer with our big-endian fixes; without them the game quits while loading its track models. It is the heaviest game we play: at the lean settings, now the package’s default for a fresh configuration, it races at 19-22 fps by the Gallium HUD in the benchmark, and its played session on Mesa ps3.850 (2026-10-26) had a 24 fps median over five tracks with no crash and no glitches. Light tracks play well, heavy ones (Ravenbridge Mansion) are slow, and a track’s load takes about 20-30 s.

SuperTuxKart: test runs

Mon, 01 Jan 0001 00:00:00 +0000

SuperTuxKart: the "Average FPS" is a tick rate (2026-10-19)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The recipe read the game’s own Number of frames: N time T, Average FPS: F line as the frame rate: 105-111 fps for lean, while the Gallium HUD said 19-22 and the race looked like 20.

Evidence. The number of frames was 21602 in every run. Patch 0005 counts ProfileWorld::update calls, one per physics tick, and STK steps physics at 120 Hz, so 180 s of race is 21600 ticks whatever the renderer does. The HUD counts frames that reached the screen: 5436-5692 swaps in a 300 s run, 3.8-4.0 physics ticks per frame.

SuperTuxKart: the big-endian port and the VRAM (2026-10-16 to 10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The research of 2026-10-16 had two warnings: the FAQ asks for at least 1 GB of RAM against our 217 MB, and Debian had an old powerpc colour bug (#714519). On 2026-10-17 Debian’s build stopped while loading: its mesh loader refuses big-endian (e708512). Our +ps3.264 loaded, the karts rendered, the track didn’t: VRAM exhausted (210 failed buffer allocations), the minimap FBO incomplete, a SIGSEGV at exit.

Cause and fix.

The dark 3D view, the RSX's fragment TXB, and what came after (2026-10-20)

Mon, 01 Jan 0001 00:00:00 +0000

The hardware fact this found is in docs/RSX.md (the fragment program’s TXB samples wrong whatever the bias), the driver’s answer, Mesa 0045, in docs/DRIVER.md. The earlier smoke runs of the same day (the black textures from the stb_image_resize miscompile, the white-noise music) are in the game’s technical page.

Symptom

The third smoke run (2026-10-20 13:43-13:49, warzone2100 ps3.619 with patches 0004-0008: the stb_image_resize no-vectorize and the Opus byte order, Mesa ps3.545): the sound was right, and the user heard plausible music and effects (white noise before; the card fine, 9 recovered xruns), but the picture was still wrong: the loading bar broken, the 3D view dark (terrain black, structures flat and untextured). The UI was fine. qemu ppc64 rendered the same build correctly, so it was RSX-specific.

The Secret of Monkey Island

Mon, 01 Jan 0001 00:00:00 +0000

Lucasfilm Games’ 1990 pirate comedy: Guybrush Threepwood wants to be a pirate and ends up chasing the ghost LeChuck. Played with ScummVM from your own copy.

The Secret of Monkey Island: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

The Secret of Monkey Island: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Untested: published so that Walnut Games can set up its data; nobody has played a session of it on Walnut yet. Runs on ScummVM (the engine, Debian’s package).

Smoke run 2026-10-29 (ps3-bench-20261029T023324Z-smoke-scummvm-monkey, variant monkey): the “Parte Uno” title, then Guybrush on the dock at night with the verbs, colours right.

The player’s copy is the Spanish VGA floppy release (eight disks; ScummVM: “monkey”, VGA, ES; 000.LFL sha256 4b24ef06...dfd9fc). Debian’s game-data-packager doesn’t know it; ours does (secret-of-monkey-island-floppy-es-data, patch 0016, from the copy’s sizes and checksums; its 901-904.LFL are the German floppy’s).

The Secret of Monkey Island: test runs

Mon, 01 Jan 0001 00:00:00 +0000

The water's occlusion query: the frame waits for the GPU (2026-10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/HOTPATHS.md (Target 5, “BananaBread’s 62.8%”, the third round and “Measured on the PS3”). Found in BananaBread’s benchmark demo (map cave); the code is the Cube 2 engine’s, so cube2 0010 serves Sauerbraten too. The driver side, Mesa 0035 NV30_QUERY_WAIT and 0042 NV30_QUERY_KICK, is described in docs/HOTPATHS.md.

Symptom

The first profiling batch (2026-10-18, Mesa ps3.299) put 10.3% of BananaBread’s CPU in nv30_query_result, Mesa’s busy loop waiting for a query result; no other game of the nine had it. On the SSD root (batch ssdroot2 P1b, Mesa ps3.476, 2026-10-19) it was 17.4% of the game’s CPU, the second biggest hot path after the vertex conversion (byte-normals), and the start-up profiles of batch 17 found the same spin in the warm-up (nv30_query_result 13.1 s).

The world's normals as signed bytes: a vertex conversion at every draw (2026-10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/HOTPATHS.md (Target 1, “BananaBread’s 62.8%”) and docs/MEMORY.md (“BananaBread’s world normals as shorts”). Found in BananaBread’s benchmark demo (map cave); the vertex layout is the Cube 2 engine’s (engine/world.h), so Sauerbraten’s world has it too. The driver side, Mesa 0033’s translate table and 0043’s vertex-program normalisation, is in docs/HOTPATHS.md; the system-memory copies it causes are Mesa 0037’s subject in docs/MEMORY.md.

Symptom

The first profiling batch (2026-10-18 early morning, Mesa ps3.299) had BananaBread at 22 fps with 72% of its CPU in Mesa, 44.9% of it in vertex format translation: util_format_r8g8b8a8_snorm_unpack_rgba_float 18.2%, util_format_r8g8b8_snorm_unpack_rgba_float 16.4%, the translate loop generic_run around them. On the SSD root (batch ssdroot2 P1b, 2026-10-19, Mesa ps3.476 with 0033’s table on) it was 40 fps with Mesa at 62.8% of the game’s CPU: vertex format translation 18.3, the query wait 17.4 (water-query-wait), per-draw state 13.8, submission 6.9, nv30 validation 3.8, buffer allocation 3.4, the rest 13.

Theme: family

Mon, 01 Jan 0001 00:00:00 +0000

Theme: fantasy

Mon, 01 Jan 0001 00:00:00 +0000

Theme: horror

Mon, 01 Jan 0001 00:00:00 +0000

Theme: sci-fi

Mon, 01 Jan 0001 00:00:00 +0000

Trigger Rally

Mon, 01 Jan 0001 00:00:00 +0000

A 3D rally racing game: drive a rally car over dirt tracks against the clock.

Trigger Rally: guides

Mon, 01 Jan 0001 00:00:00 +0000

Trigger Rally: session of 2026-10-29

Mon, 01 Jan 0001 00:00:00 +0000

Trigger Rally: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Status

Debian’s Trigger Rally 0.6.6.1 (trigger-rally, -data, 116 MB). Smoke runs on 2026-10-28 (kernel .874, Mesa ps3.924, the VRAM swap on): the menus are mouse-only (Return and the arrows do nothing there), so the recipe (benchmark/recipe.sh) clicks through them by XTEST (xkeys.py @X,Y): single race, Aegyptian, race, the car (Return), then holds the throttle a few times. The race runs, the picture right (desert, sky, the car, the HUD, the offroad sign; xwd and webcam):

Trigger Rally: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Two crashes in Mesa: a query's report slot taken back, then a NULL upload buffer (2026-10-24)

Mon, 01 Jan 0001 00:00:00 +0000

The real Sauerbraten (our cube2 on the 2020_12_29 release’s data) crashed in both of its first played sessions, each time in Mesa’s nv30 driver. The fixes are Mesa 0046, 0047 and 0048, whose mechanisms are in docs/DRIVER.md; upstream nv30 has the same code.

Symptom

Session of 2026-10-24 (an online insta-CTF match on eternal_valley, then berlin_wall; run ps3-bench-20261024T233328Z-session-sauerbraten-edition-base): 54 fps median, 14.7 s of stutter a minute, a segfault after 202 s of play. Occlusion-culled geometry popped (the player’s “a bit glitchy”).
Session of 2026-10-25 (bots, about 6 minutes, Mesa ps3.819 with 0046, sauerbraten 0.819; run ps3-bench-20261025T013202Z-session-sauerbraten-edition-base): no query crash; a different one at 400 s.

Evidence and cause: the first crash (Mesa 0046)

nip resolves (stable-debug’s mesa-libgallium-dbgsym ps3.721) to nouveau_heap_free (nouveau_heap.c:106, r->in_use = 0), called from nv30_query_object_del (nv30_query.c:76). The heap node it wrote was nouveau_mm_free_work’s function descriptor in libgallium’s read-only .opd: the query object had been freed and its memory reused for a fence work. nv30 has 124 report slots; the engine ends up to 2048 occlusion queries a frame and reads them a frame later, so slots were taken back from queries that still pointed at them: the query’s next result check read freed memory and freed it again. The same bug gave queries each other’s results, which shows as geometry popping.

View: 2D

Mon, 01 Jan 0001 00:00:00 +0000

View: 3D

Mon, 01 Jan 0001 00:00:00 +0000

View: first-person

Mon, 01 Jan 0001 00:00:00 +0000

View: side-on

Mon, 01 Jan 0001 00:00:00 +0000

View: top-down

Mon, 01 Jan 0001 00:00:00 +0000

Warzone 2100

Mon, 01 Jan 0001 00:00:00 +0000

A 3D real-time strategy game: build a base, research technology, command tanks.

Warzone 2100: guides

Mon, 01 Jan 0001 00:00:00 +0000

Warzone 2100: session of 2026-10-25

Mon, 01 Jan 0001 00:00:00 +0000

Warzone 2100: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Warzone 2100 4.3.5, the last release with a GL 2.1 renderer, is our package, and it runs on the PS3 with the right picture and sound after a set of big-endian, AltiVec and driver fixes. Its played session (2026-10-25, a skirmish) had a 38 fps median and 5.4 s of stutter a minute. As a console game it is a poor fit: mouse and keyboard only, a sparse 1999 interface, small at 1080p (Options > Video > Display Scale helps). Stable warzone2100 4.3.5-1+ps3.644; the user played it next to the PC build on 2026-10-20.

Warzone 2100: test runs

Mon, 01 Jan 0001 00:00:00 +0000

Warzone 2100: the black 3D view, etcpak and a GCC miscompile (2026-10-19/20)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The first PS3 smoke run (batch ssdroot6, warzone2100 ps3.566, 2026-10-19) had the HUD and the minimap but a black 3D view, and garbled text.

Evidence. The amd64 build on llvmpipe, cut down to the PS3’s GL 2.1 extension list (MESA_GL_VERSION_OVERRIDE=2.1, MESA_GLSL_VERSION_OVERRIDE=120, MESA_EXTENSION_OVERRIDE minus everything nv47 lacks, ARB_texture_rg, ARB_texture_float and EXT_texture_array among them), rendered the skirmish normally: not a GL 2.1 limit. The ppc64 build under qemu-user with llvmpipe and with softpipe was black, as on the PS3. Shader overrides as an autoload mod showed the lightmap (fog of war) right and the textures black; logging each texture upload against the amd64 run showed level 0 identical and level 1 down from 103538663 to 465002 (the byte sum of a 512x512 level). The game’s compiled stb_image_resize.cpp.o reproduced it on its own; it takes -mcpu=cell (or 970, power6: AltiVec), -O3 and -DNDEBUG together.

Warzone 2100: the music was white noise (2026-10-20)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The second PS3 smoke run (ps3.617, stopped at 110 s) played white noise for the music.

Evidence. Checked under qemu with OpenAL Soft’s wave writer at the main menu: a zero-crossing rate of 0.44 with ps3.617 (noise). The decode itself was right on big-endian: track19.opus through the game’s opusfile, built with its flags, matches amd64 within 8 LSB. The Vorbis effects already asked ov_read for big-endian.

Cause. The Opus decoder (the soundtrack, warzone2100-music) wrote its samples little-endian, but OpenAL’s AL_FORMAT_*16 expects native order.

What stalls in OpenArena: map reloads, bots joining and the lost decrementer (2026-10-17)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/STALLS.md (“OpenArena”) and docs/TESTS.md’s history rows, merged. The stall recorder, report.py’s gameplay-only columns (which OpenArena’s reloads led to) and the kernel’s lost decrementer, a cause outside the game that OpenArena showed first, stay described in docs/STALLS.md.

Symptom

The first stall-recorder runs (ioquake3 ps3.379, the timedemo looped, 20261017T233701Z and T234549Z) had 17.6-17.9 s of stall time in the window, 81% of it on the main thread’s CPU.

Evidence

passsplit.py splits it by where it falls in a pass:

Windows PC classics (1990-2010) with open engines

Mon, 01 Jan 0001 00:00:00 +0000

Popular PC games of 1990-2010 that now have an open-source engine, a decompilation, a reimplementation or an official source release, as candidates for the PS3. Researched 2026-10-20 from the projects' READMEs, osgameclones.com, PCGamingWiki, the awesome-unofficial-pc-ports list, GamingOnLinux and news articles. Nothing here has been built or measured on our console yet. Every alternative project per game, with GitHub stars, last activity and the pick for our port, is in Alternatives and popularity.

X-Moto

Mon, 01 Jan 0001 00:00:00 +0000

A 2D motorbike trials game: ride through physics-based levels without falling off, collecting strawberries.

X-Moto: game-side batching beat the driver rounds (2026-10-17)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. X-Moto, a 2D game, played at 35-47 fps: a GL 1.x game held back by the PPE. The Mesa rounds moved it a little each: ps3.246 35 to 37 (HUD median, underruns 208 to 126), ps3.262 39 to 47 (+21%, batch 2026-10-17-mesa-262), and ps3.299 cost 5% against ps3.282 in the same boot (44.5 against 47.0; neither 0027 nor 0030 off restored it, 0031 off and 0028 off gave 46 each, batch 2026-10-17-mesa-282-ab). A fixed kick100 cost 9% (batch 2026-10-17-mesa-282-kick100).

X-Moto: guides

Mon, 01 Jan 0001 00:00:00 +0000

X-Moto: session of 2026-10-23

Mon, 01 Jan 0001 00:00:00 +0000

X-Moto: session of 2026-10-23

Mon, 01 Jan 0001 00:00:00 +0000

X-Moto: session of 2026-10-24

Mon, 01 Jan 0001 00:00:00 +0000

X-Moto: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

X-Moto 0.6.3 runs at 1920x1080 with the right picture and sound. Our package batches the game’s OpenGL drawing (a frame went from 18,500 GL calls to 165), which took the benchmark replay from 44.5 to about 160 fps; its played sessions ran at the 60 fps vsync cap with clean sound (“flawless”, the player). It is one of the games where game-side batching paid most.

Packages and patches

xmoto, xmoto-data (0.6.3+repack-1+ps3.N, packages/xmoto), replacing Debian’s.

X-Moto: test runs

Mon, 01 Jan 0001 00:00:00 +0000

X-Moto's batches copied at every draw (2026-10-18)

Mon, 01 Jan 0001 00:00:00 +0000

Moved on 2026-10-26 from docs/HOTPATHS.md (“X-Moto’s client arrays” and the “Measured on the PS3” rows), where Mesa’s side of client vertex arrays stays.

Symptom

The first profiling batch (2026-10-18, Mesa ps3.299) put 5.5% of X-Moto’s CPU (profile 013240, the credits replay at 154 fps) in u_upload_data, Mesa’s copy of client vertex arrays: memcpy < u_upload_data 5.3%, the biggest single X-Moto item in the graphics stack.

Evidence

All of it is xmoto’s own batches (patch 0001 batches DrawLib’s primitives per state run), drawn from a client array that Mesa copies at every draw. 3.9 of the 5.5% is the minimap: renderMiniMap > drawCircle, a circle of 8 segments per sprite entity in the minimap’s box (933 a frame in the credits replay, ~17000 batch vertices). The copy goes into GART, which ps3rsx maps cacheable (ordinary RAM, IOMMU-coherent).

Yamagi Quake II

Mon, 01 Jan 0001 00:00:00 +0000

A modernised engine for id Software’s Quake II, with the original single player and multiplayer game.

Yamagi Quake II: guides

Mon, 01 Jan 0001 00:00:00 +0000

Setting up the game data

Which editions work

The demo (free): version 3.14, downloaded by game-data-packager itself (no copy or installer needed). Package quake2-demo-data; the Quake II (demo) menu entry starts it and shows only while the demo is installed.
The full game: package quake2-full-data. It needs baseq2/pak0.pak and the baseq2/video folder of your copy: a CD, a Steam common/Quake 2 folder, or GOG’s Quake II Quad Damage (the installed folder or setup_quake2_quad_damage_*.exe). The import downloads the 3.20 patch (the official patch files) unless the copy already has it.
The CD’s music: package quake2-music, optional, in /usr/share/games/quake2/baseq2/music/02.ogg..11.ogg, which Yamagi Quake II plays in place of the CD; from a BIN/CUE image of the CD or the disc in the drive. The 3.20 patch download is allowed only when every package asked for may download, so the full game and its music are two imports: walnut-data import -p quake2-full-data yquake2 /path/to/Quake2.cue, then walnut-data import -p quake2-music yquake2 /path/to/Quake2.cue.
The expansions (quake2-reckoning-data, quake2-groundzero-data, quake2-zaero-data) are packages of the same tool; they have not been tried on the PS3.

What you get

The demo is installed in /usr/share/games/quake2-demo/baseq2 and the full game in /usr/share/games/quake2/baseq2; the two use different folders. The Quake II (demo) entry passes -datadir /usr/share/games/quake2-demo, and the Quake II entry (shown once baseq2/pak0.pak is there) passes -datadir /usr/share/games/quake2.

Yamagi Quake II: OpenAL played white noise (2026-10-16)

Mon, 01 Jan 0001 00:00:00 +0000

Symptom. The first runs of our ppc64 build (+ps3.229) drew right, but every sound effect was loud white noise (batch 2026-10-16-yquake2-white-noise).

Cause. The game loads its 16-bit WAV samples as they are in the file, little-endian, and hands them to OpenAL as AL_FORMAT_*16, which means native byte order: on a big-endian host every sample had its bytes swapped.

Fix. Patch 0001 swaps the 16-bit samples to host byte order at load (+ps3.240, batch 2026-10-16-yquake2-byteswap). The user confirmed the sound by ear. The SDL audio path (s_openal 0, variant sdlsound) is a second way to the card, kept as a variant.

Yamagi Quake II: session of 2026-10-26

Mon, 01 Jan 0001 00:00:00 +0000

Yamagi Quake II: technical notes

Mon, 01 Jan 0001 00:00:00 +0000

Our build of Debian’s yquake2 8.70 on its gl1 renderer, with the Quake II demo data. It plays the demo pak’s timedemo at 68.7 steady fps with almost no stalls (batch 2026-10-18-mesa-407-lut) since its random-number table shrank from 32 MB to 64 KB, and its played session had a 60 fps median, a 1% low of 33, no dropouts and no crash.

Packages, data and settings

yamagi-quake2, yamagi-quake2-core (/usr/lib/yamagi-quake2/quake2, renderers ref_gl1 and ref_gl3), packages/yquake2, COMPONENT=contrib: debian-ports builds nothing arch-specific in contrib, so Debian has no ppc64 binary. The gl1 renderer (GL 1.4 fixed function) is the one that runs; gl3 and gles3 need GL 3.
0001 swaps the 16-bit WAV samples to host byte order at load: uploaded little-endian, they played as white noise through OpenAL (the investigation).
0002 YQ2_KISS_QSIZE: the KISS PRNG’s lag table, allocated at first use with 4096 entries by default instead of a static 16 MiB array in both quake2 and game.so (the investigation). Its upstream offer is drafted in upstream.md.
0003 the default bindings (yq2.cfg, run after id’s default.cfg and before the player’s config.cfg): W/A/S/D instead of Yamagi’s E/S/D/F (the power shield from W to E), and a game controller’s buttons, which Yamagi left unbound (the sticks moved and looked, nothing fired): R2 fires, L2 walks, Cross jumps, Circle crouches, L1/R1 the previous/next weapon, Square uses the item, Triangle the inventory, the D-pad left/right selects an item, up the help computer, down drops the item, Select the score; Start is the menu already. A saved config.cfg keeps its own bindings (Yamagi writes them all), so a home that has played keeps E/S/D/F until Options, Customize controls, “reset to defaults”. Checked on the PS3 (2026-10-29, a fresh home): the config.cfg the game writes has bind w "+forward", bind e "use power shield", bind BTN_SOUTH "+moveup", bind TRIG_RIGHT "+attack"; the pad by hand is for a played session.
Two menu entries of ours (desktop/launchers), the gl1 renderer fullscreen at the desktop’s resolution (r_mode -2): “Quake II (demo)”, -datadir /usr/share/games/quake2-demo, and “Quake II”, the full game, -datadir /usr/share/games/quake2. Both are packed hidden (NoDisplay=true) with X-Walnut-Requires= their data’s baseq2/pak0.pak (/usr/share/games/quake2-demo/..., /usr/share/games/quake2/...): ps3-game-menu shows each only when that file exists. The full game’s data is game-data-packager’s quake2-full-data (build.toml [data_setup]).
The data (licensed): quake2-demo-data (/usr/share/games/quake2-demo/baseq2/, the demo’s baseq2 with demos/q2demo1.dm2 in its pak), built once with game-data-packager 89 (make game-data, the demo archive downloaded from id’s mirrors and kept in build/downloads/game-data) as quake2-demo-data_89_all.deb, Section local/games, and published once to the licensed suite. Quake II’s demo may not be redistributed at all. game-data-packager’s output isn’t reproducible: the version 89 file the LAN repository published is in the retirement backup’s ps3-licensed-debs/, and make publish DEBS="<that file>" before the next make game-data keeps it the same. The full game needs the player’s own Quake II data (the data guide on the game’s page).
The config lives in ~/.local/share/YamagiQ2/baseq2/config.cfg (~/.yq2 before the XDG build).

How it performs

Bench (batch 2026-10-18-mesa-407-lut, same boot, x2): kiss4k (now the default) against the old table: RSS 125 to 56 MB, swap used 80 to 9 MB, gameplay stalls 22.6 to 0.05 s, longest frame 4.5 s to 91 ms, steady 65.7 to 68.7, 1% low 20.1 to 31.1, 46 MB free at the lowest (12 before), 48 MB of VRAM, no underruns.
How it got there: first runs on 2026-10-17 gave 56.1 fps with OpenAL, 58.4 with SDL audio; Mesa ps3.246 51.4, ps3.262 63.9 (+14-24%, batch 2026-10-17-mesa-262).

The recipe (benchmark/recipe.sh) runs the engine directly (Debian’s quake2 wrapper is contrib, not ours) on the demo pak’s only demo, +timedemo 1 +demomap q2demo1.dm2, vsync off. The timedemo repeats in one session: autoexec.cfg’s bench alias sets nextdemo again, disconnects (which prints the pass’s line; a chained demomap would reconnect and clear the counters) and starts the demo cold. Each pass also prints “ERROR: Disconnected from server”. Variants: sdlsound, kissbig, kiss4k, the OpenAL Soft variants.

Yamagi Quake II: test runs

Mon, 01 Jan 0001 00:00:00 +0000