Walnut Games

All games

Extreme Tux Racer

Gold · 80 0.2 h played, 0 crashes

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

Genre
racing sports
Theme
family
Players
single player
Input
supports gamepad
View
3D
Keywords
penguin downhill courses

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, extremetuxracer 0.8.4-2+ps3.803

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-24 Extreme Tux Racer 1.012 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
extremetuxracer 0.8.4-2		 2026-10-24 Gold · 80 1.0 70687710091-96 0.2 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: Extreme Tux Racer 0.8.4: no demo mode, so a race played once by a person is recorded as keyboard events and replayed into a virtual keyboard.

The recipe's full description

Extreme Tux Racer 0.8.4: no demo mode, so a race played once by a person is recorded as keyboard events (evemu-record) and replayed into a virtual keyboard (evemu-device + evemu-play). The same events at the same times from when ETR's window appears: ETR's physics follow the frame time, so at another frame rate Tux's line can drift a little (the game's technical.md). A marker event written into the keyboard when the window appears makes the recording start there. variant record: you play (menus too, then quit from the menu); the events land in the run directory as etr-race.evemu, to copy to assets/etr-race.evemu, cut after the last input that matters (assets/etr-race.evemu: Practice, one course, 69 s) base: the recorded race, replayed; fps from the Gallium HUD Steady state: the HUD window (60 s from the first frame, then 120 s; WINDOW_STOP=1 ends the run). The recording is ~69 s (menus to 24.7 s, the race after), so the race is raced again: after the replay, Enter on the game-over screen (back to the race selection, the course still chosen), then the recording from ETR_LOOP_FROM (24.7 s: the Enter that starts the race) once more, up to ETR_LOOPS times; during.log stamps each. Caveats: ETR's physics take the frame time as their step, and the inputs replay at wall-clock times, so at another frame rate (or a faster second load) Tux's line can drift from the recorded one, more in the later races; the window also holds the game-over and selection screens and the reload between races. A fixed time step in our etr (states.cpp: g_game.time_step from an environment variable) would make the steering repeatable per frame, but then the wall-clock inputs drift whenever the frame rate does.

13 variants of the recipe
base stands for the gamethe recipe as it is, without a variant
record-
gloffOur extremetuxracer (gamedb/games/etr/packages/etr/): fewer, larger GL submissions, each with an environment variable (src/glfast.h in the package). base has them all on, gloff is ETR_GL=0 (the game as Debian draws it), a no* variant is base with one change off.
noterrain-
notux-
noshadow-
notracks-
notrees-
treesorder-
noparticles-
nosnow-
nohud-
nobind-

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.
Extreme Tux Racer the recipe as it is 59.0 27.3 - - - warm-up + 120 s 29 58 2.9 483 0 - - - right, right
Real-time audio as shipped: ps3-desktop 0.1013 (limits.d rtprio 10 + ps3-rt-audio, RTAUDIO=1) against none (RTPRIO=0) on dsda-doom software (owncfg), Extreme Tux Racer, X-Moto and Neverball (kernel .874) 2026-10-28 · 2026-10-28-rt-audio-shipped
Tested: Real-time audio as shipped in ps3-desktop 0.1013 (a priority limit plus ps3-rt-audio, which game mode uses to put the game's audio thread on SCHED_RR), against none, on dsda-doom, Extreme Tux Racer, X-Moto and Neverball.
Result: Shipped. Audible dropouts a run fell from 29 to 2 in dsda-doom, 26 to 2 in Extreme Tux Racer and 3 to 0 in Neverball, with steady fps unchanged within 0.4%. The 1% lows came out a little lower in the light games, with the ranges touching.
What we saw

25 runs in three rounds, games interleaved, arm order alternating. Two Neverball runs with it were interfered by the agent's own SSH checks and left out, so Neverball has 2 runs with it. Every run fullscreen at 1920x1080 and in gameplay at its 40 s screenshot.

  • ps3-rt-audio put the audio thread on SCHED_RR 1 in every run with it: SDL's audio thread in dsda-doom, X-Moto and Neverball, and Extreme Tux Racer's unnamed audio thread.
  • Audible dropouts a run (about 200 s), median, without and with it: dsda-doom 29 to 2 (audible time 0.8-1.2 s to 50-113 ms), Extreme Tux Racer 26 to 2 (0.65-0.92 s to 58-124 ms), Neverball 3 to 0, X-Moto 0 to 0 (logged underruns 78 to 11).
  • Steady fps unchanged within 0.4%: dsda-doom 39.75 and 39.8, X-Moto 161.7 and 161.0, Neverball 82.73 and 82.72.
  • 1% lows a little lower with it in the light games, ranges touching: X-Moto 113.4 to 109.4, Neverball 57.9 to 56.6, dsda-doom 20.6 to 19.0.
  • Extreme Tux Racer's were higher with it: HUD 1% low 19.8 to 29.2, steady 56 to 59. The previous batch had no such gap (29.9 against 28.6).
base rtaudio 59 29.2 1 59 - warm-up + 120 s 53.8 58.0 0.4 339.6 - 128.5 0 339.6
base real-time priority 0 56 19.8 0 59 - warm-up + 120 s 53.3 58.1 0.0 96.2 - 148.9 0 96.2
RT audio thread: SCHED_RR 1 from outside (RTPRIO=10+RTTHREAD) and nice -20 (NICELIM=40) against none on dsda-doom software (owncfg), Extreme Tux Racer and OpenTTD (kernel .874) 2026-10-28 · 2026-10-28-rt-audio-thread
Tested: Whether putting the game's own audio thread on real-time priority (SCHED_RR 1, set from outside) or running the game at nice -20 stops the audible dropouts in dsda-doom (software renderer), Extreme Tux Racer and OpenTTD.
Result: SCHED_RR clearly helps: median dropouts a run fell from 19 to 2 in dsda-doom and from 24 to 3.5 in Extreme Tux Racer, at no frame-rate cost. nice -20 helped less and cost dsda-doom 2%. A per-game opt-in was recommended; not shipped in this form.
What we saw

38 runs in four rounds, order rotated. 14 were interfered by another agent's SSH logins and left out. Every counted run was fullscreen at 1920x1080 and in gameplay at its 40 s screenshot.

  • Audible dropouts a run (about 200 s), median. dsda-doom: 19 with nothing, 10.5 with nice -20, 2 with SCHED_RR.
  • Extreme Tux Racer: 24 with nothing, 3.5 with SCHED_RR.
  • OpenTTD: 2 with nothing (2 clean runs), 1 with nice -20; logged underruns 2019 to 1095.
  • No fps cost from SCHED_RR beyond the noise: dsda-doom 40.1 against 40.3, Extreme Tux Racer 59 against 59. nice -20 cost dsda-doom 2% of its steady fps and two points of 1% low.
  • SDL's own real-time hint does nothing without RTKit: the thread stayed at normal priority.
base real-time priority 0 59 29.9 1 59 - warm-up + 120 s 47.1 58.1 0.1 114.2 - 127.6 0 114.2
base real-time priority 10
switch rtthread		 59.0 28.6 1.5 59.0 - warm-up + 120 s 45.8 58.0 0.2 172.4 - 126.8 0.0 172.4
batch 17: ETR uncapped, start-up profiles x5, shader cache cold/warm, OpenArena gl2 memory variants, Mesa sysmem switches, Sauerbraten shortnormals 2026-10-18 · 2026-10-18-batch17
Tested: A mixed batch: ioquake3 462's new colour path and memory variants for OpenArena's OpenGL 2 renderer, Mesa's system-memory copy switches, BananaBread's short normals, a warm shader cache, Extreme Tux Racer without a frame cap, and start-up profiles.
Result: ioquake3 462 cuts OpenArena's stalls from 9-11 s to 0.7-2.6 s at 57-60 fps, Mesa's system-memory switches fix the old colour path's stalls, and BananaBread's short normals give +17%. The shader cache gives no faster loads and Extreme Tux Racer's 59 fps is not a vsync cap.
What we saw
  • Same boot as batch 16 (kernel .433), ioquake3 462, Mesa 442~dev, cube2 442~dev. One BananaBread run with a key press left out.
  • OpenArena OpenGL 2 on ioquake3 462 (compact colours by default): steady 57-60 fps, stalls 0.7-2.6 s. On the 396 build in batch 16: 51-53 fps and 9-11 s.
  • The old 16-bit colour path: 52-53 fps, 12.9 s of stalls, 20 s of swap stalls.
  • Packed animated model frames: 20 MB less VRAM, same stalls. Gamma-correct mipmaps computed per channel: the lowest stalls (0.7-0.9 s).
  • Mesa's system-memory copy plus buffer invalidation on the old colour path: stalls 9.9 and 12.3 s to 1.5 and 1.4 s, swap stalls 20-26 s to 0.6-1.1 s, steady 53-54 to 59 fps.
  • BananaBread with short normals: 38.7 to 45.4 fps (+17%), stalls equal, VRAM +4 MB.
  • Shader cache cold against warm: no load gain (OpenArena 10.3 s cold, 10.6 s warm; BananaBread 17.4 against 18.4 s).
  • Extreme Tux Racer without a frame cap: still 59 fps, so not a vsync cap.
base the recipe as it is 59 27.3 11 59 - warm-up + 120 s 29.1 58.0 2.9 483.3 - 132.8 0 483.3
xmoto ps3.323 + etr ps3.324 (game-side batching) + Mesa ps3.299 2026-10-17 · 2026-10-17-xmoto-etr-batching
Tested: Our X-Moto and Extreme Tux Racer packages with the game's drawing batched into far fewer OpenGL calls and draws per frame.
Result: A large win: X-Moto went from 44.5 to 166.5 fps with the same picture, and Extreme Tux Racer from 52 to 59 fps.
What we saw
  • X-Moto: GL calls per frame from 18,500 to 165 and draws from 1,960 to 40 (counted on the PC). Credits replay from 44.5 to 166.5 fps (HUD median), against the old drawing on the same boot. The picture was identical on the webcam.
  • Extreme Tux Racer: calls from 19,400 to 850 and draws from 697 to 72. Race replay from 52 to 59 fps, against the old drawing.
base the recipe as it is - - - 59.0 Mesa ps3.299 whole run 53.5 58.0 - - - 53.0 0.0 -
gloff ETR_GL=0 - - - 52.0 Mesa ps3.299 whole run 48.0 52.5 - - - 83.6 0.0 -
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 - - - 53 Mesa ps3.262, ps3rsx 0.249 whole run 52.6 52.5 - - - 84.7 0 -
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 - - - 46 Mesa ps3.246, ps3rsx 0.249 whole run 63.7 52.5 - - - 84.0 0 -
Extreme Tux Racer replay cut at 69 s (Mesa ps3.225) 2026-10-16 · 2026-10-16-etr-replay-cut
Tested: The Extreme Tux Racer replay cut after the last steering input (69 s), so that only the race counts.
Result: 45 fps on the driver's frame counter in a single run. The input replays the same each time, but the game's physics follow the frame time, so Tux's line can drift at another frame rate. No decision recorded.
What we saw
  • The recording was cut at 69 s; the game closed 5 s later and the run ended after 83 s.
  • 45 fps on the driver's frame counter (10th percentile 22).
  • Single run. The input is the same every time, but the physics follow the frame time, so Tux's line can drift at another frame rate.
base the recipe as it is - - - 45 Mesa ps3.225 whole run 61.5 52.5 - - - 85.3 - -
Extreme Tux Racer race recorded and replayed uncut (Mesa ps3.225) 2026-10-16 · 2026-10-16-etr-replay-uncut
Tested: A benchmark for Extreme Tux Racer: the user raced while the keyboard was recorded, then the recording was replayed into a virtual keyboard.
Result: The replay works, but the uncut recording runs past the race into the results and menu screens, which show as stretches of about 20 fps at the end. The next batch cut that tail; these numbers are not comparable with the cut replay.
What we saw
  • Recording run: the user raced while the keyboard was captured; 134 s, 21 fps on the driver's frame counter.
  • Replay of the uncut recording: 22 fps, 134 s.
  • Both runs end in stretches of about 20 fps, where the recording runs on past the race (the results and menu screens).
  • Picture and sound right.
  • Not comparable with the cut replay of the next batch.
base the recipe as it is - - - 22 Mesa ps3.225 whole run 62.7 52.6 - - - 140.8 - -
record the recipe as it is - - - 21 Mesa ps3.225 whole run 68.9 52.6 - - - 139.2 - -
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 - - - 40 Mesa ps3.223, ps3rsx 0.219 whole run 19.1 52.7 - - - 44.6 - -
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 - - - 42 Mesa ps3.223 whole run 67.4 52.5 - - - 46.0 - -