Technical notes on 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.

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: 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: 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: 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: 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.

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.

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.

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.

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.

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.

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.

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: 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

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, …).

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: 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.

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: 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.

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

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).

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.

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.

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:

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): 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.

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.

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.

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).

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: 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: 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: 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).

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.

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: 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.

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: 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.

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.

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: 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.

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: 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: 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: "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: 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: 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.

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”.

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.

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.

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.

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: 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: 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: 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 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.

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):

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.

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: 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:

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: 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'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: 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: 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.