Bug: filling the fifth wheel hole with several balls in play awarded the transfer, multiplier, and extra ball, but did not run the wheel replacement. The original deferred the 281-frame panel until a later launcher reset, which with crazy-mode balls could be a long time, while the full wheel kept every hole closed. Requirement: a full wheel must be replaced with the same animation and scoring as in single-ball play. Balls still in play keep moving, with the wheel's outer border as a solid boundary and no hole captures until the replacement is done. Changes: - complete_lock_hole starts the panel for a multiball fill too (if one is not already running). The single-ball path is unchanged and still restarts it unconditionally, as in the original. Scoring was already identical and is untouched. - timer_tick only freezes physics during the panel while every ball waits in the launcher. That is always the case for the single-ball replacement (the locking ball was reset), so it is frozen exactly as before; during multiball the balls in play keep integrating. - While the panel runs, check_lock_holes captures nothing and retain_wheel_rim adds a circle around the wheel hub (record 134's center, 48 px ball-center radius, enclosing the five hole posts) with the hub's material. It only repels balls moving towards it, so a ball already inside rolls out instead of being caged. - Stress runs then showed balls trapped for good at the bottom of a hole pocket, cradled between the hub and a post, after another ball filled that hole or the panel closed it. The pocket bottom lies outside the hole's capture zone, so nothing ever moved them. A filled or closed hole now kicks such a ball (more than 4 px inside its rim) out of its center, radially away from the hub at 3 px/step, a path that clears both neighbouring posts. Balls arriving from outside are reflected by the rim before getting that deep. - A lock or special-hole capture that removes the last remaining ball of a multiball callback now resets it to the launcher (or finishes it when tilted), exactly like the single-ball capture, instead of ending the player's ball. Test Plan: - cargo test (164 tests), including full_wheel_during_multiball_replaces_it_while_balls_play_on (rim bounce, no captures, balls move, wheel cleared after the panel), filled_or_closed_lock_hole_kicks_out_a_ball_resting_in_its_pocket (the exact trapped position seen in stress runs), and the updated fifth_multiball_lock_starts_the_panel_and_caps_survivor_reaward. - A temporary release-mode stress run (not committed): 40 seeded two-player games with crazy mode, autoplay flippers, and nudges all finished; 62 wheel replacements happened during multiball; no invariant violations. - Manual: in crazy mode fill the fifth wheel hole; the replacement animation plays while the other balls keep moving and bounce off the wheel instead of dropping into its holes.
TDK Pinball Machine for modern PCs
This is a native Rust reconstruction of the 1995 Windows game TDK Pinball Machine. It uses the extracted original artwork and sound, recreates the playfield as a fixed-step simulation, and runs from the same source on Linux, macOS, and Windows.
The game opens at the original 640x460 canvas size and presents every artwork pixel one-for-one. The fixed, non-high-DPI client prevents desktop scaling from distorting or vertically offsetting the pixel-art presentation.
The original program is not required at runtime. All required game assets are embedded in the executable at build time.
Run
Install a current stable Rust toolchain, then run:
cargo run
For a distributable optimized binary:
cargo build --profile production
The binary is written below target/production/. On Linux, Macroquad's native
development packages are also required (X11, OpenGL, and ALSA). Windows needs
no extra runtime installation; macOS builds with the normal Apple developer
command-line tools.
Browser version
Build and serve the WASM website locally with:
just web-serve
Then open http://127.0.0.1:8000/. The browser build keeps the original
640x460 presentation centered on a black page and stores settings and a local
fallback table in browser storage unless the optional same-origin
/api/highscores service is deployed. See web/README.md and
highscore-server/README.md for deployment details.
Deterministic mechanics validation
Named scenarios can be advanced without waiting in real time. The simulator uses exact 120 Hz steps, prints its final state as JSON, and can write both the complete step trace and the original-size 640x460 framebuffer:
cargo run -- --simulate claw-6 --at 0.15 \
--trace /tmp/claw-6.json \
--screenshot /tmp/claw-6.png
Use --step N instead of --at SECONDS to reproduce one exact update. The
available scenarios are loading, attract, highscores, name-entry,
effect-7, autoplay, launcher, flippers, panel, targets, claw-1, claw-6,
claw-7, claw-18, and crazy; --seed N fixes random choices.
autoplay charges each ball and operates the flippers from live ball position
for long end-to-end validation runs.
Original and modern controls
| Action | Original key | Additional modern key |
|---|---|---|
| Start game / add up to 4 players | Keypad + or the main +/] position |
= is also accepted |
| Charge launcher | Hold Down arrow, release to launch | - |
| Left flipper | Ctrl (left or right) | A or Left arrow |
| Right flipper | Enter (main or keypad) | D or Right arrow |
| Nudge | Space, Left Shift, keypad 3 |
Right Shift aliases keypad 3 |
| Help | F1 | Enter/Escape returns |
| Settings | TDKPIN.INI before launch |
F10 opens the portable settings screen |
| High scores | Automatic when a player finishes | F9 opens the portable table viewer |
| Sound | F12 | - |
| Crazy mode: drop 10 more balls | - | 0 (main row) |
Crazy mode is a modern addition. Each press drops ten balls at fixed points on
the playfield, up to 64 balls in play. They are ordinary balls: every ball runs
the same physics, sensors, holes, claw, and scoring, and the player's ball ends
only when the last one drains. A player who used crazy mode still enters the
high-score table, with their entry labelled CRAZY.
The five original speed choices remain available in settings. Physics now uses the original invariant 100 Hz millipixel substep, batched as 5/4/3/2/1 steps on the recovered 50/40/30/20/10 ms callbacks. Claw animation, flipper edges, and visible state publication follow the same selected callback cadence.
The help screen is the original artwork in English, German, French, Italian, or Spanish. As instructed on that screen, double-clicking its upper-left exit box closes the program.
Saved data
Native settings and the ten-entry high-score table are stored as save.json in
the platform's normal per-user application-data directory. Browser settings
and the fallback table use localStorage; a deployed browser build uses the
same-origin high-score service as its shared table when available. On first
run, native settings are imported from an adjacent original INI (or the
embedded distributed TDKPIN.INI), and the table is imported from the original
HISCORES.DAT.
Reconstruction status
This repository distinguishes exact recovered material from behavioral reimplementation. See RECONSTRUCTION.md for the evidence ledger, known inference boundaries, and validation performed.