Skip to content
← All work

2024 – 2025

Rust Beat

Keeping time, a few microseconds at a time.

Role
Personal project
Hardest problem
Reacting to four lanes at once within a few microseconds, without threads waiting on each other.
Result
A median of about 300 µs from a note reaching the hit row to its key press.

The question

Rhythm games are a good test of performance with little room for error. Notes fall, and you’re immediately on the clock to respond. Could a program watch the screen and keep time with four tracks at once, without ever falling behind the music?

The approach

Rust Beat reads screen pixels directly and interprets them as notes. Each of the four tracks runs on its own thread, so a busy passage in one lane never delays another, and input is simulated concurrently.

Capture thread · 4 pixels per frameDFJKnotes fallhit rowatomic flag1 thread each
One capture thread samples a single pixel per lane at the hit row and raises an atomic flag; each lane’s own thread presses its key. No locks sit on the path from pixel to key.

Shared state is kept to a minimum and coordinated with atomics instead of locks, so threads never wait on each other in the hot path. Most of the effort went into doing less: reading only the pixels that matter, and making each decision as late as possible.

Median, note on the hit row to key press
~300 µs
99th percentile over a three-minute track
~600 µs
Measured by timestamping each pixel change and the matching simulated key press inside the program, over a full track.

What I took from it

It started as a bit of fun, but it sharpened habits I rely on every day. The most important optimisations came from sampling single pixels, parallelising across lanes, and using atomic flags.