ddidderr
27d40504cc
Bug: with crazy-mode balls on the table and a ball parked in the special hole, the parked ball stayed there after every other ball had drained. It was reported after a tilt, which drains all balls quickly because the flippers are dead. Cause: the special respawn only fired when the drained ball was the very last ball in Game::balls. In crazy mode a ball is often still waiting in the launcher (crazy mode pressed before launching, or a ball that rolled back onto the shooter stop). That waiting ball kept the list non-empty, so each drain simply removed its ball and the parked ball never came out. Reproduced deterministically: 30/30 seeds ended with only the launcher ball left and the special hole still armed. Fix: - special_respawn_pending(leaving) now asks whether the leaving ball is the last one *in play*: every other ball waits in the launcher, and no effect-seven ball is about to be published. It no longer looks at the score mode; in the original, normal scoring there meant "no second ball", which this expresses directly. - lose_ball: with other balls still in the list, the drained ball is removed and, if it was the last one in play, the parked ball is released onto the table (same position, velocity, contact clearing, and gate suppression as the original respawn). With no other ball it respawns in place as before, keeping the original's continuation of the drained ball's response. - A ball that leaves because it came to rest on the shooter stop while the launcher was occupied also releases the parked ball if it was the last one in play. Tilt is untouched: it still ends only with the player's ball, and the released ball plays under it like the original respawned ball. Test Plan: - cargo test parked_ball_is_released_when_only_a_waiting_ball_remains: a tilted game with a launcher ball and one ball in play; draining it releases the parked ball without costing a ball. A second case with another ball still in play keeps the parked ball. - The temporary reproduction (30 tilted crazy-mode games) now releases the parked ball in 30/30; a 40-game crazy-mode stress run still finishes every game.
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.