All games

Trigger Rally

Rust · 84 0.1 h played, 0 crashes

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

Genre
racing
Players
single player
Input
made for keyboard and mouse
View
3D

Played sessions

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

Builds: Walnut 0.1, trigger-rally 0.6.6.1-4+b1

The platform builds under it (3)
Linux kernel6.12.111+ps3.874 Walnut's build
Mesa26.2.4-1+ps3.1139~dev20261029214356 Walnut's build
ps3rsx0.924+k6.12.111+ps3.874 Walnut's build
DateLauncherRulesPlayEndedPicture
2026-10-29 Trigger Rally 2.35 minquit wrong 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 rateSmoothnessSoundPictureStabilityControlsDisplayFeaturesLoad Play
Walnut 0.1
trigger-rally 0.6.6.1-4+b1
2026-10-29 Rust · 84 2.3 7074100759010010010097 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: Trigger Rally 0.6.6.1: smoke test, not benchmarked. Menu only: the game has no command-line options, so the player starts a race by hand.

The recipe's full description

Trigger Rally 0.6.6.1 (Debian ports ppc64: trigger-rally, trigger-rally-data 116 MB download): smoke test, not benchmarked. Menu only: the game has no command-line options, so the player starts a race by hand (Enter on Single Race / the arrow keys, pick an event and a stage, Enter; drive with the arrow keys, Space is the handbrake, R recovers, C changes the camera). Fullscreen at the desktop resolution comes from setup(): a copy of /etc/trigger-rally.config.defs written to the user's config file with 1920x1080 fullscreen and the cheaper options (no foliage, no weather, no dirt effect, no anisotropic filtering, point snowflakes), restored after the run. What it exercises: GL 2.0 compatibility with fixed function and GLEW (terrain, sky, cars), SDL2_image JPEG/PNG textures (the stage textures are big: RAM is the risk, the data is 121 MB installed), OpenAL + ALUT for the engine and the co-driver's voice. Risks: terrain drawn from many large draws per frame on the PPE, GLEW picking extensions nv30 lacks (it only prints), RAM during the stage load. Variant full: the game's own defaults (foliage, weather, anisotropy 4) to see what the cheap settings buy.

5 variants of the recipe
basethe recipe as it is, without a variant
full-
menu-
fresh-
freshrace-

Conditions: what a variant adds to the recipe (its environment switches) and what ran alongside (the stall recorder, a profiler). Rows marked invalid or not comparable say why. The other numbers, the build and the run length are under "All numbers" in each batch.

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.

Mesa ps3.924 + kernel .874, profiled smoke runs (STALLS=1 PERF=1): which threads hold the CPU in the stall frames

2026-10-29 · batch 2026-10-29-worker-threads · 2 runs in the batch (all games)

VariantConditions Steady fps
in the window
1% low
fps
Stalls
frames over 100 ms
freshrace stall recorder at 10 ms
perf recording
5932.03
All numbers and setup of this batch
VariantNumbersSetup
freshrace fps whole run 59 cpu 94.2 seconds underruns 0 underruns ram_free 52.6 MiB vram 194.6 MiB longest_ms 13875.0 ms stall_disk_s 0.5 seconds stall_swap_s 0.0 seconds stall_reclaim_s 0.4 seconds stall_gpu_s 0.4 seconds stall_cpu_s 15.2 seconds stall_play_s 17.1 seconds longest_play_ms 13875.0 ms no build recorded
the game's resolution, warm-up + 120 s

Observations: One profiled smoke run per game whose engine has more threads than main and audio (scorched3d fresh, trigger-rally freshrace, endless-sky base), VRAM swap on, to see whether the stall frames are the main thread waiting for the CPU while the game's own worker threads run (gamedb:luanti 2026-10-29). They are not: in the stall frames the main thread ran 62% (Scorched 3D) and 74% (Trigger Rally) of the time and the game's other threads 9% and 8% (stalls.py's new stall_main_pct/stall_rest_pct; Luanti before its fix: 22 and 83). Scorched 3D: 20 fps, 13.5 s of stalls in 90 s; kswapd0 23% of the stall time, the main thread itself decoding the Ogg music (18% of its stall samples), the picture right (bots firing, island, HUD). Trigger Rally: 59 fps, 3 stall frames, one of them the 13.9 s stage load inside the smoke window (glTexImage2D, PhysFS reads); the race drawn (the car stands at the start). Endless Sky's run was disturbed by an SSH command at 331 s (left out); its profile covers the data load, where the two loader threads have 74% of the CPU and the main thread 16% (waiting for them, as designed). Every run fullscreen 1920x1080, procs=ok.