CydandClaude Fable 5
8dc6605a07
Button banks The exploded diagnostic view was still display-only - it predates the button work - so it now builds the same banks as the cockpit, with the pod arrangement laid out from the panes measured sizes rather than a hardcoded 640/480 grid (the banks make each window bigger than its glass, and the bottom row hung off the work area otherwise). The map side columns were spread height/6 from the top, but the maps own legend grid is not sixths: measured off the bitmap it starts 13 rows down with six 102-tall cells on a 105 pitch. Every button sat high of its label, worst at the bottom. Each buttons top and bottom now come off that grid separately and are subtracted - scaling a height directly would let rounding drift them back out of step on a resized cockpit. Depth 100 to 240: against the 480 glass the two banks meet in the middle bar the strips, so practically the whole display is a press target. This mattered most in the cockpit, where the panes are small enough that the halfway clamp governs - at 100 the MFDs had a 110px dead band straight through the middle of the glass. -fit (also spelled -windowed-fullscreen) Borderless over the whole monitor, with the render size chosen to match. The cockpit presents the 3D into a viewscreen that fills its canvas, so the right -res is that canvas at the scale the cockpit will settle on; computing it with identical arithmetic makes the stretch a copy. On the 3440x1440 panel that is 133% and -res 2553 1436, against 125% for the windowed path that pays for the taskbar. The pick runs after the whole command line, so an explicit -res wins from either side of -fit. Capped at 3840x2160. Cockpit mode only - mode 0 has to stay playable on real pod hardware and mode 2 is a dev view - so those get the resolution and keep their windows. Display layout, in environ.ini L4MFDSCALE sizes all five MFDs, L4MFDSCALE_UL and friends override any one of them, L4RADARSCALE the radar, and L4RADARPOS puts the radar bottom centre, in either bottom corner, or halfway up either side. Scaling is applied in canvas units before the canvas is fitted to the window, so a number means the same thing on every monitor. Sizing each display separately let the clamps become exact rather than one conservative rule for all five: what limits a display is its actual neighbour. Which neighbour that is depends on the radar, so the clamps follow it - on the bottom edge it clears the one MFD above its column, but centred on a side it has one above AND below and grows from the middle both ways, so it must clear the taller twice over. Clamping shrinks uniformly; these are photographs of real instruments and a one-axis clamp would squash them. Verified on the ultrawide: all five radar positions, per-display and group scaling with the clamps biting, -fit with and without an explicit -res, and the button geometry measured back off the screen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Red Planet 4.12 — the Steamification
Red Planet is VWE's pod-racing game: eight-player VTV contests on Mars — Martian Death Race and Martian Football — originally played from inside VWE Tesla cockpit pods. This repo is the third life of that code:
| Generation | What it was |
|---|---|
| Red Planet 4.10 | The original game, running on the Tesla 1 pod platform (DOS-era MUNGA engine, serial RIO cockpit hardware, operator console, batch-file relaunch between missions) |
| Red Planet 4.11 | The Win32 port of 4.10 (RP411) — DirectX 9, WinSock TCP, TeslaConsole/TeslaLauncher session control; still runs in pods, still a LAN |
| Red Planet 4.12 | This repo: the Steamification of 4.11 — the same engine, the same wire protocol, the same missions, made distributable on Steam and playable over the internet with no cockpit hardware |
The architecture is deliberately conservative: the VWE's design survives intact, with each pod-era dependency replaced by a consumer equivalent behind the engine's existing seams.
| Arcade (4.10/4.11) | 4.12 replacement |
|---|---|
| RIO cockpit board (serial) | PadRIO — virtual RIO from XInput pad + keyboard, fully rebindable (bindings.txt, vRIO profile format) |
| Seven physical displays | Single-window cockpit — all displays composed on a locked 1920×1080 canvas around the viewscreen, with the real button banks lamp-lit and clickable |
| Pod button lamps | On-screen lamps, plus an RGB keyboard mirror (Windows Dynamic Lighting) |
| TeslaConsole operator | In-game front end — race setup menu builds the mission egg locally; an in-process console marshals every race (missions still only end on a console stop, exactly as designed in 1994) |
| TeslaLauncher relaunch-per-mission | Single binary — menu → race → results → menu in one process |
| WinSock TCP LAN mesh | NetTransport seam — the deterministic pod mesh unchanged, running over plain TCP (LAN/dev) or Steam Networking Sockets (FakeIP + Steam Datagram Relay) |
| Site network / fixed IPs | Steam lobbies — lobby owner is the console; members exchange FakeIPs and loadouts as lobby data |
Status: it works. Release v4.12.2 carries the first verified end-to-end internet build: three machines, three Steam accounts, lobby → mesh → marshaled five-minute race → deaths and respawns → timed stop → results on every machine → rematch from the same lobby.
Playing
Grab the release zip (or run pack-dist.ps1 on a build). Single player:
run start-windowed.bat — the game boots into the setup menu, where the
SCENARIO group picks Death Race or Football (Football swaps in the
team/position columns and its own track list). Steam multiplayer: see
docs/STEAM-3-MACHINE-TEST.md (until RP412
has its own AppID it runs under Spacewar, 480).
The two config files beside the exe are self-documenting: environ.ini (every engine option, commented) and bindings.txt (every key, pad button, and axis; written with the full default layout on first run). Default controls: numpad flies (8/2/4/6 stick, 7/9 pedals, 0 trigger), Shift/Ctrl throttle, Alt reverse, arrows look, Space fires, letter rows are the MFD button banks as printed on the panel. Alt+Q aborts a mission. Full map with pad and keyboard diagrams: docs/CONTROLS.md.
Building
VS 2022 (v143) + DirectX SDK June 2010 + the vendored Steamworks SDK
(extern/steamworks_sdk_164) — see BUILD.md. Solution
WinTesla.sln, configuration Release|Win32, output
Release\rpl4opt.exe.
Documentation
| Doc | Contents |
|---|---|
| docs/CONTROLS.md | Controls map — pad and keyboard diagrams, the panel button banks, rebinding |
| docs/RP412-ROADMAP.md | The original plan and workstreams |
| docs/RP412-FRONTEND-DESIGN.md | TeslaConsole analysis, the egg format, the console protocol, and the Steam mapping — with status notes as each layer landed |
| docs/STEAM-3-MACHINE-TEST.md | Multiplayer test procedure, Steam Input notes, the abort key |
| BUILD.md | Toolchain and build steps |
Dev tooling: tools/two-pod-test.ps1 races two pods on loopback,
marshaled by a console feeder speaking the arcade Munga protocol.
Related repositories
| Repo | Role |
|---|---|
| RP411 | Upstream: the Win32 arcade port this repo Steamifies (full history preserved; remote rp411 for cross-pulling fixes) |
| VRIO | Virtual RIO panel + vPLASMA — source of the bindings format, the cockpit layout, and the keyboard lamp mirror |
| TeslaSuite | TeslaConsole / Launcher / vPOD — the arcade session-control stack 4.12 absorbed (and the reference implementation of the Munga control protocol, TCP 1501) |