All games

Armagetron Advanced

Platinum · 95 0.1 h played, 0 crashes

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

Genre
action arcade
Theme
sci-fi
Players
single player local multiplayer online multiplayer bots
Input
supports gamepad
View
3D
Origin
remake or clone
Keywords
tron

Played sessions

Testing is done with Walnut's rating tool (walnut-rate, on the console): how ratings are made and submitted.

Builds: Walnut 0.1, armagetronad 0.2.9.3.0-1+ps3.816

The platform builds under it (3)
Linux kernel6.12.111+ps3.747 Walnut's build
Mesa26.2.4-1+ps3.721 Walnut's build
ps3rsx0.735+k6.12.111+ps3.747 Walnut's build
DateLauncherRulesPlayEndedPicture
2026-10-25 Armagetron Advanced 1.09 minquit ok Details

Download all sessions as CSV (one row per session, the aspects as columns)

Rating history

The rating on each version it was tested on, newest first: each row is rated from that version's sessions alone, under the newest rules those sessions have the data for.

VersionTestedMedalRules Frame rateSmoothnessSoundPictureStabilityDisplayLoad Play
Walnut 0.1
armagetronad 0.2.9.3.0-1
2026-10-25 Platinum · 95 1.0 100849710090-100 0.1 h
1 test

Scripted benchmarks

Not rated: tests of driver and game changes. A script plays the same scene on the PS3 again and again (the desktop stopped, vsync off) to compare two builds of the game or of the graphics driver. The numbers say which build is faster; they never feed the medal.

How the script plays it: Armagetron Advanced 0.2.9.3: a local game of 4 AI players with the player spectating, which plays itself round after round. fps from the Gallium HUD.

The recipe's full description

Armagetron Advanced 0.2.9.3: a local game of 4 AI players with the player spectating, which plays itself round after round (SPECTATOR_MODE_1 and the SP_* settings make it AI only; setup writes them for every run). fps from the Gallium HUD. Menus (0.2.9: FIRST_USE is true on a first start, so FIRST_USE 1 in the config means the first start's language menu, player setup and welcome screen, which wait for a key: the run of 2026-10-18 sat at the language menu for its whole window). The live variants write FIRST_USE 0 and the language (LANGUAGE_FIRST/_SECOND), and `during` types Return, Down, Return into a virtual keyboard (as etr's recipe does): main menu "Play Game", then "Local Game", which starts the game at once. Playback and record keep FIRST_USE 1: their recording holds the first start's keys. Steady state: the HUD window (WINDOW_STOP=1: 60 s from the first frame, then 120 s, then the game is stopped). The rounds are alike but not identical from run to run (the AIs decide live). The match limits are raised (10 rounds or 30 minutes by default: the champion screen and a new match every few minutes otherwise). Until 2026-10-18 base played back assets/armagetronad-bench.aarec (--playback --benchmark), a 90 s recording cut by the record run's stop, not ended with a quit: after its end the game draws nothing more (a black screen with the cursor, no frames, no CPU: the HUD stopped 66-77 s after its first frame in every run), so the 60 + 120 s window held ~6 s of frames and perf had samples only at its start (the suite run 20261018T004040Z). The recording is variant playback now, with a window that fits in it; a longer one (variant record, ended with Quit from the menu before DURATION) would make a playback window of the full length.

6 variants of the recipe
base stands for the gamethe recipe as it is, without a variant
playback-
recordmake a recording (quit from the menu before DURATION, so its playback ends there), then copy /var/tmp/armagetronad-bench.aarec into assets/ (the asset of 2026-10-17 is a 90 s one, cut)
livethe live game for 45 s, no window (the old smoke test)
texinvMesa 0020 off (texture caches invalidated on every draw, as before ps3.262): bisects its cost
relocsMesa ps3.282 switches (docs/archive/GAME-PLAN.md): relocations back on (0019 off). The kick150, kick100 and kick50 variants went on 2026-10-31 with NV30_PS3_KICK_DRAWS (0026, folded into 0027)

One table, a header row per batch (what it tested and what came out). Conditions: what a variant adds to the recipe (its environment switches) and what ran alongside (the stall recorder, a profiler); a column appears only when this game has a value in it. Rows marked invalid or not comparable say why.

What the run length means

"warm-up + 120 s" is a steady-state run, which leaves out a 60 s warm-up and measures 120 s or more; "whole run" counted everything from the start, the way runs before 2026-10-17 did.

Variant Conditions Steady fps
in the window
1% low
fps
Stalls
frames over 100 ms
fps
whole run
Build Run length ram free
MiB
vram
MiB
stall play s
seconds
longest play ms
ms
sound faults per min
faults a minute
cpu
seconds
underruns
underruns
longest ms
ms
Note
Suite summary 2026-10-20 · suite-summary-2026-10
Tested: Not a test run: the suite's 13 benchmarked games (15 rows, with OpenArena's two renderers and OpenTTD's two blitters) gathered with their known numbers as of October 2026, each value naming the batch or document it came from.
Result: It is the calibration of the rating formula (rules 1): the scale was tried on these numbers before any game was rated, and the GameDB calibration table is generated from it. Benchmarks never give a medal; medals come from played sessions only.
Armagetron the recipe as it is 83.0 24.1 - - - warm-up + 120 s 58 28 0.1 127 0 - - - right, right
Armagetron live AI rounds (recipe e5a556d), Mesa ps3.408; kick 2026-10-18 · 2026-10-18-armagetron-live-ai
Tested: A new Armagetron benchmark: live rounds of AI players spectated, instead of a recorded playback that kept tripping on first-start menus.
Result: The new benchmark runs at 83 fps steady with one stall of 127 ms. It becomes the base, not comparable with the old playback numbers.
What we saw

One run. Live AI rounds spectated (first-start screens skipped, virtual keys): steady 83 fps, 1 stall (127 ms). The webcam showed the arena with the AI light cycles. Not comparable with the old playback numbers.

base waker kick at 10 ms 83 24.1 1 83 Mesa ps3.408 warm-up + 120 s 58.0 27.5 0.1 127.1 - 144.1 289 127.1
Mesa ps3.299 + ps3rsx 0.249 2026-10-17 · 2026-10-17-mesa-299
Tested: Mesa ps3.299, the third round of driver changes: adaptive submission (0027), a fenced index buffer (0028), state reset (0029), index upload (0030) and fragment-program constants read from system memory (0031).
Result: Armagetron gets its frame rate back (50 to 61.5 fps), OpenArena and ClassiCube are unchanged, and X-Moto loses a real 5% that none of the switches fully restores. The picture was right and the driver tests passed.
What we saw
  • Clean runs only, two per game, watched by a webcam script with a single SSH connection.
  • Armagetron: 61.5 fps (50 on ps3.282).
  • OpenArena (compressed textures): 52.4 (51.3).
  • ClassiCube: 46.3, against 46.9 on ps3.282 on the same boot: noise.
  • X-Moto: 44.5, against 47.0 on ps3.282 on the same boot: a real -5%. Turning off adaptive submission (45.5) or the index change (45.0) does not restore it. Fragment constants from VRAM (46) and the late index upload (46) each win back about a frame: 0031 and 0028 cost about one frame each.
  • 0031 checked on the webcam with OpenArena's OpenGL 2 renderer: right picture, no GPU hang. The driver tests pass.
  • Earlier runs that day, made with an old webcam watcher that logged in over SSH every 5 s, were slowed and are left out.
base the recipe as it is - - - 61.5 Mesa ps3.299, ps3rsx 0.249 whole run 53.1 28.8 - - - 63.2 41.5 -
Mesa ps3.282 + ps3rsx 0.249: Armagetron switches (relocs and kick N) 2026-10-17 · 2026-10-17-mesa-282-armagetron
Tested: Which Mesa ps3.262 patch costs Armagetron its frame rate, using Mesa ps3.282's run-time switches: relocations back on, and a submission to the GPU every 150, 100 or 50 draws.
Result: The loss points to patch 0019 (no relocations): without them a whole frame reaches the GPU in one piece at the buffer swap, so the CPU and GPU no longer overlap. Turning relocations back on or submitting every 100 draws restores about 60 fps; the kick100 batch then checked the other games.
What we saw
  • Mesa ps3.282 with a run-time switch per patch. Two interleaved rounds of Armagetron, 90 s each, HUD frame rate.
  • As built: 50 fps.
  • Relocations back on (patch 0019 off): 60.5 fps.
  • A submission every 150 draws (patch 0026): 58.5. Every 100 draws: 60.5. Every 50 draws: 60.5.
  • CPU time is the same in all variants (57-64 s).
  • The runs show the effect, not the mechanism. Two runs per variant.
base the recipe as it is - - - 50.0 Mesa ps3.282, ps3rsx 0.249 whole run 62.5 28.6 - - - 59.5 26.5 -
kick100 the recipe as it is - - - 60.5 Mesa ps3.282, ps3rsx 0.249 whole run 52.4 28.8 - - - 62.8 31.0 -
kick150 the recipe as it is - - - 58.5 Mesa ps3.282, ps3rsx 0.249 whole run 59.0 28.6 - - - 56.5 17.5 -
kick50 the recipe as it is - - - 60.5 Mesa ps3.282, ps3rsx 0.249 whole run 59.9 28.8 - - - 63.5 25.0 -
relocs NV30_PS3_RELOCS=1 - - - 60.5 Mesa ps3.282, ps3rsx 0.249 whole run 64.3 28.8 - - - 62.1 23.0 -
Mesa ps3.246 control for Armagetron (same boot as ps3.262) 2026-10-17 · 2026-10-17-mesa-246-control
Tested: Whether Armagetron's drop on Mesa ps3.262 is real: the older Mesa ps3.246 reinstalled and measured on the same boot.
Result: Yes: ps3.246 gave 59-61 fps against 51-53 on ps3.262 the same day, so the loss comes from ps3.262's patches. Run-time switches for each patch followed in Mesa ps3.282 to find which one.
What we saw
  • Mesa ps3.246 reinstalled on the same boot as the ps3.262 runs.
  • Armagetron: 61 and 59 fps (HUD median), against 51-53 on ps3.262 in the previous batch.
  • The second run also printed the game's own playback average, 71.2 fps. That is a different measure and is not used.
  • This confirms the loss comes from Mesa ps3.262's patches, not from the boot or the day.
base the recipe as it is - - - 60.0 Mesa ps3.246 whole run 61.6 28.6 - - - 63.2 21.5 -
Mesa ps3.262 repeats and Armagetron without 0020 (texinv) 2026-10-17 · 2026-10-17-mesa-262-repeats
Tested: Whether the frame rates of the Mesa ps3.262 suite round hold up when repeated, and whether Armagetron's drop on ps3.262 comes from Mesa patch 0020 (the texture cache flushed only after texture changes).
Result: Single QuakeSpasm runs spread from 66 to 84 fps on the same Mesa, so one-run differences of that size are noise. Armagetron runs at 52-53 fps with or without 0020, so 0020 is not the cause of its loss.
What we saw
  • Same boot as the Mesa ps3.262 suite round.
  • QuakeSpasm again: 73.0 and 84.1 fps (66.3 in the suite round). Single QuakeSpasm runs spread widely on the same Mesa.
  • Neverball again: 77.7 and 74.2 fps (71.5 in the suite round).
  • Armagetron with ps3.262 as built: 53 and 53 fps. With patch 0020 undone (the texture cache flushed before every draw again): 52 and 52. So the drop from 60 to 52 is not patch 0020.
  • All Armagetron numbers here are the Gallium HUD's median. Two runs per variant.
base the recipe as it is - - - 53.0 Mesa ps3.262 whole run 67.8 28.3 - - - 60.8 29.0 -
texinv NV30_TEX_INVALIDATE_ALWAYS=1 - - - 52.0 Mesa ps3.262 whole run 62.7 28.8 - - - 61.1 23.5 -
Mesa ps3.262 + ps3rsx 0.249 2026-10-17 · 2026-10-17-mesa-262
Tested: Mesa ps3.262 (patches 0019 to 0025: fewer words sent to the GPU per draw) across the suite, against ps3.246.
Result: Big gains in several games: OpenArena +23%, Yamagi +24%, X-Moto +21%, Extreme Tux Racer and dsda-doom +15%. Armagetron fell from 60 to 51 fps, which the next batches traced. Single runs; BananaBread's drop is a memory stall, not a driver number.
What we saw
  • The patches: no relocations, the texture cache invalidated only after texture changes, no duplicate vertex-format writes, batched vertex program constants. One run per game.
  • Against ps3.246: OpenArena with compressed textures 44.2 to 54.4 fps (+23%), Yamagi 51.4 to 63.9 (+24%), X-Moto 39 to 47 (+21%), Extreme Tux Racer 46 to 53 (+15%), dsda-doom software 33 to 38 with the demo now finishing (+15%), ClassiCube 47.6 to 50.1 (+5%).
  • Neverball 78.2 to 71.5 (noise), QuakeSpasm 70.5 to 66.3 (repeated in the next batch), Luanti 53 to 53.
  • Armagetron dropped from 60 to 51 (driver frame counter).
  • BananaBread reads 28 to 8 on the counter, but it was memory-stalled (13 MB free, killed at the cap): not a driver number, and the cause is uncertain.
  • The kernel's command validator rejected nothing.
  • Single runs.
base the recipe as it is - - - 51 Mesa ps3.262, ps3rsx 0.249 whole run 71.7 28.8 - - - 59.3 23 -
Mesa ps3.246 + ps3rsx 0.249 2026-10-17 · 2026-10-17-mesa-246-ps3rsx-249
Tested: The first full suite round after the reboot into ps3rsx 0.249, one run per game, as a baseline.
Result: Every game ran with the right picture. The sound was right except in dsda-doom (MIDI music), BananaBread and OpenTTD. Single runs, so differences of a few fps are noise.
What we saw
  • One run per game. Frame rates by the game's own counter, or the driver's frame counter where marked:
  • Armagetron 60 (counter), ClassiCube 47.6, dsda-doom software 33 (counter, demo unfinished), Extreme Tux Racer 46 (counter), Luanti 53 (counter), Neverball 78.2.
  • OpenArena with compressed textures 44.2 (longest frame 2.1 s), QuakeSpasm 70.5, BananaBread with CPU skinning 28 (counter), X-Moto 39 (counter), Yamagi Quake II 51.4.
  • Pictures right. Sound right except dsda-doom (1161 underruns, MIDI music), BananaBread (176) and OpenTTD (1429, choppy).
  • OpenTTD used 55.5 s of CPU and has no frame rate (plain X11 path).
  • Single runs: differences of a few fps are within the run-to-run spread.
base the recipe as it is - - - 60 Mesa ps3.246, ps3rsx 0.249 whole run 72.4 28.3 - - - 65.0 52 -
Group 1 on Mesa ps3.225: ClassiCube demo and Armagetron playback 2026-10-16 · 2026-10-16-group1-mesa-225
Tested: ClassiCube's fly-through demo and Armagetron's playback of the recorded round, as benchmarks on Mesa ps3.225.
Result: Both benchmarks work: ClassiCube 43.24 fps, Armagetron 63.96 fps by its own average. Armagetron's own average is a different number from the driver counter used in its later batches (50 to 61). Single runs.
What we saw
  • ClassiCube fly-through (3000 fixed frames): 43.24 fps by its own counter, longest frame 278 ms, load 12.65 s, 78 s of CPU.
  • Armagetron playback of the 4-AI round completed for the first time: 63.96 fps by the game's own average, ended normally at 94 s.
  • The game's own average differs from the driver frame counter median used in later Armagetron batches (50 to 61).
  • Single runs.
base the recipe as it is - - - 64.0 Mesa ps3.225 whole run 78.2 28.8 - - - 66.0 6 -
Armagetron benchmark recording (Mesa ps3.223) 2026-10-16 · 2026-10-16-armagetron-recording
Tested: Recording an Armagetron round of 4 AI players, to replay as a benchmark.
Result: The recording worked (a 90 s round), but the first playback was killed without a result. Playback first completed on Mesa ps3.225.
What we saw
  • The recording run spectated a 90 s round of 4 AI players: 50 fps on the driver's frame counter, 78 underruns.
  • A first playback launch was killed without a result (48 fps on the counter).
  • Playback first completed on ps3.225 (the following batches).
base the recipe as it is - - - 48 Mesa ps3.223 whole run 71.9 28.8 - - - - 101 -
record the recipe as it is - - - 50 Mesa ps3.223 whole run 64.9 28.3 - - - 72.1 78 -
Mesa ps3.223 + ps3rsx 0.219 2026-10-16 · 2026-10-16-mesa-223
Tested: Where the CPU time goes in five games on Mesa ps3.223, each profiled for 15 s.
Result: The driver stack, not the games, takes most of the CPU: Mesa 28 to 56%, ps3rsx 6 to 16%. That started the per-draw work in Mesa ps3.246 and ps3.262 and ps3rsx 0.249. The profiler slowed the runs, so the fps are not for comparison.
What we saw
  • Each game was profiled for 15 s, so the fps are lower than in plain runs (the run records don't show the profiling). One run per game.
  • X-Moto 34.6 fps (own counter), 208 underruns.
  • OpenArena with compressed textures 37.2 fps, longest frame 3.1 s.
  • ClassiCube 54, Extreme Tux Racer 40 (in its menu), Armagetron 102 (a live first-run game); all three on the driver's frame counter.
  • Result: Mesa took 28 to 56% of the CPU and ps3rsx 6 to 16%.

not comparable every game was profiled with perf during the run, which slows it.
base
not comparable
the recipe as it is - - - 102 Mesa ps3.223, ps3rsx 0.219 whole run 33.2 26.5 - - - 21.8 22 -
Group 1 smokes ETR and Armagetron on Mesa ps3.223 2026-10-16 · 2026-10-16-etr-armagetron-smokes
Tested: First runs of Extreme Tux Racer and Armagetron on Mesa ps3.223.
Result: Both start and draw. Extreme Tux Racer ran with the right picture and no kernel errors; Armagetron's first launch failed on a wrong option in our recipe, and the rerun only showed its first-run screen. No benchmark numbers.
What we saw
  • Extreme Tux Racer ran to the 45 s cap: 42 fps on the driver's frame counter, picture right, no kernel errors.
  • Armagetron's first launch quit after 5 s on "Unknown command line option --fullscreen", an error in our recipe.
  • The second launch ran to the 45 s cap at 89 fps on the first-run screen, which is not a benchmark.
  • Single runs; the numbers are driver counter medians.
base the recipe as it is - - - 89 Mesa ps3.223 whole run 83.6 27.7 - - - 13.8 35 -