RP412PHYSICSHZ names a rate and the simulation advances in whole steps
of exactly that size on every machine, whatever the display does. 0 -
the default, and the shipped behaviour until the play testers have
spoken - is the game as it has always run: the step is however long the
last frame took, which makes the frame rate part of the physics.
Measured over two seconds of free fall, a 30 fps machine's pod fell
three times further than a 144 fps machine's. Two players on the same
track were not in the same gravity.
With a rate set, the same race is bit-identical across frame rates:
30, 60 and 144 fps produce the same trajectory to the last printed
digit, and identical runs reproduce exactly - which was never true of
this engine before, at any frame rate.
It took three pieces, and every one was found by measuring, not by
reading:
- Simulation::PerformTo turns lastPerformance into the accumulator it
always secretly was: whole steps while time remains, the remainder
carried to the next frame. Watchers and update records stay once per
frame - stepping is physics, watching is I/O.
- Entity::PerformAndWatch interleaves subsystems and entity per STEP.
The frame loop ran all subsystems to the frame boundary and then the
entity, indistinguishable from correct at one step per frame - which
is why thirty years of code never noticed - and wrong at two: the
thrusters raycast twice from a vehicle that had not moved, and the
hover spring fired twice on one stale height sample. The subsystems
are also snapped onto their entity's step grid; each Simulation
anchors its grid at its own creation time, a per-run phase no seed
could pin.
- Mover::BeginStep clears the force accumulator per step. It was
cleared once per frame while the thrusters ADD per step, so step two
of a frame integrated step one's thrust again - and how many steps a
frame holds rides on wall-clock jitter, which is why identical
configs measured a quarter-metre apart. The quaternion renormalise
counts steps now too, for the same reason.
The catch-up clamp is a quarter second of simulation whatever the rate,
so a machine that cannot keep up slows down rather than seizing, and
does so identically everywhere. The engine's clock counts milliseconds,
so rates that do not divide 1000 - 60 among them - quietly run at the
neighbouring millisecond step; the log now says so and names the exact
ones. 25, 50 and 100 are exact, and all three are verified bit-identical
across frame rates and across runs.
Verified for a single vehicle settling under gravity and hover. Driving,
collisions and the network are the next frontiers, in that order: the
collision path writes the victim's state with wall-clock stamps and a
hard-coded 0.1 s bounce, which single-player survives and lockstep will
not.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Imports the current Win32 source for the pod-racing game 'Red Planet',
built on the MUNGA engine and its L4 (Win32/DirectX) platform layer:
- MUNGA / MUNGA_L4: cross-platform engine core and Win32 backend
- RP / RP_L4: Red Planet game logic and Win32 application
- DivLoader, Setup1: asset loader and installer project
- lib, MUNGA_L4/openal, MUNGA_L4/sos: third-party audio dependencies
Removed stale Subversion metadata and added .gitignore/.gitattributes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CydandClaude Fable 5