67d57452ba0ca784b468d6969e2230130eb4fa95
14
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Fable 5
|
af52476603 |
The pod can drive a scripted lap
RP412INPUTSCRIPT names a timeline file - one row per change, throttle, stick X and Y, pedals, held until the next row's time - and the pod drives it instead of listening to the controls. Times are SIMULATION seconds from the green light, evaluated per step in the one place every mapper funnels through (VTVControlsMapper::InterpretControls), so the same script is the same lap at any frame rate. Rows hold rather than interpolate on purpose: interpolation would sample differently at different physics rates, and nothing on this path is allowed to. The script shares the green-light anchor with RP412PHYSTRACE - its clock starts at the instant the vehicle is stopped dead - because a timeline that starts when the loader happens to finish is a different lap every run. A race is only deterministic if somebody DRIVES it, and a human cannot drive the same lap twice. The first scripted lap - full throttle, a steer, a crash at speed - earned the harness immediately: - The drive, the crash, the death and the respawn teleport were all BIT-EXACT between identical runs, through t=13.5. Collisions with world geometry and the damage path are step-deterministic, which is better news than the code reading suggested. - The first divergence is the step AFTER the respawn: the DropZoneReply that stands a dead pod back up is posted at wall-clock Now()+1.0 (RPPLAYER.cpp), so the reset lands on a different sim step every run and everything after is time-shifted. The crash is deterministic; the RECOVERY is not. That is the next fix, and it is now a measurement, not a theory. Values are clamped at load, once and visibly, so a script asking for throttle 2.0 cannot trip the mapper's own range Verifies. Off unless the environment names a file; it would be a cheat in a real race. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
2a679ab571 |
A race can be replayed exactly, so physics claims can be tested
Three pieces of harness, all env-gated and inert in normal play, that turn "do two frame rates play the same race?" from an argument into a number: - RP412PHYSTRACE=1 samples the player vehicle's position on the SIMULATION's own clock - the vehicle's lastPerformance, which advances in whole fixed steps - so two runs sample at identical step counts and their traces compare exactly. Frame-time sampling compares different instants and calls the difference physics; an earlier version of this trace did exactly that, and its noise was chased as if it were drift. At the green light it stops the vehicle dead, because the pod simulates on its pad while the mission loads and a load is never the same length twice: two runs reached the start 776 and 599 steps in, same position, different velocity. - RP412SPAWNZONE pins which drop zone is tried first. The pick is Random(), and Random() is seeded - but a seed only repeats a run if the same NUMBER of draws precedes the pick, and that count rides on load timing. Same seed, different pad, incomparable traces. Pinned, the zone is tried first and falls back to the random walk if taken, so it cannot wedge and changes nothing unless set. - The trace prints the global step counter, which is what caught the force-accumulator bug: the position columns can look plausible while the step column says the physics ran a different number of times. With these three and RANDOM= (which already existed), a race is repeatable to the bit, and the determinism matrix - rates by frame rates by repeats, run as parallel sandboxed instances - is a regression suite: any mismatch in any cell is a real bug. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
5e47987508 |
The simulation steps at a fixed rate
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> |
||
|
CydandClaude Opus 5
|
b7b2c3b148 |
The GPU transforms the vertices
The cockpit displays were updating every two to three seconds while the 3D view held a perfectly smooth 55 fps. This is why, and it is one line. Every device was created D3DCREATE_SOFTWARE_VERTEXPROCESSING - every vertex on the track transformed and lit on the CPU, on the one core this game uses for everything. That was not a choice when the engine was written; there was no hardware to hand it to. The error message beneath the call still says "Couldn't create HARDWARE_VERTEXPROCESSING device", so the flag was changed at some point and the message left behind. Measured on the biggest track, 1920x1080: software foreground 17.2 ms background 1.2 ms 2.4 gauge passes/s hardware foreground 0.2 ms background 17.9 ms 50.0 gauge passes/s The frame loop runs the foreground and then spends whatever is LEFT on the background gauge work. A foreground costing 17.2 ms of an 18 ms frame leaves nothing, so the gauge loop got the single pass it is guaranteed and no more. A pass needs about twenty steps - eighteen gauges and three display copies - so the cockpit ran at two passes a second, and since the renderer walks a sixteen-step rate wheel, a gauge on one step redrew once per SIXTEEN of those. Three seconds. The map, the clock, the boost gauge and the sim still running after the fade to black were all that one number. Hardware T&L is now the default and sw is the way back. Fixed-function lighting and fog are not bit-identical between the old software path and a driver, so the escape hatch stays - but the picture was checked against both and the difference is not the one worth defending. A cockpit whose instruments update twice a second is. It falls back to software by itself if the adapter has no hardware T&L. The instruments that found it stay in, because nothing about this was visible from outside: - FrameSplit, under RP412GAUGEDIAG, reports foreground against background against whole frame. APPMGR has computed those four timestamps every frame since forever and never reported one of them; it would have pointed here on the first day. - FrameDiag reports frames per second on the same window, so the gauge sweep rate can be read against the frame rate rather than guessed at. - ProfileReport, which already existed and was only reachable through F11 on the RIO controls mapper - not the mapper a desktop player runs, so in practice unreachable - now runs on a timer under RP412GAUGEPROFILE. Its per-gauge line gains the rate mask and tier, which is what names a display as one-in-sixteen rather than merely slow. - The winners' circle logs what its exterior and name-plate rebuilds cost, since nothing else runs while they do. RP412VSYNC is here too, and it is honest about itself: presenting IMMEDIATE was measured and made no difference to the frame budget, because the frame was full of work rather than waiting. It stays as a latency-against-tearing preference, not a fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
6e829f815e |
Doors run on the mission clock instead of being replicated
A door's position was an integrated countdown owned by whichever machine the map-entity round-robin happened to deal it to. That left doors one one-way-latency behind on every other machine, re-acquired at each state change; drifting permanently on any frame hitch over a second, which the old code dropped outright rather than clamping; and frozen mid-cycle, collision volumes included, when their owning peer left, since ownership transfer is not implemented. Doors are clockwork with no inputs, and door/VTV physics is already local pointer access - VTV::ProcessCollision reads door->currentVelocity off the local object and the crush test is local VTV state - so a door does not need an owner at all. Door::SlideDoor is now a phase function of Application::GetMissionElapsed(), anchored so phase zero reproduces the original DefaultState entry: fully open, starting to close. Every host builds its own doorframe out of the map stream as a HermitInstance, the instance kind DynamicEntityCreation does not broadcast, so nothing is sent, nothing is received, and a peer leaving takes no doors with it. Verified against a copy of the old integrator at 25fps with the real 10s travel / 3s dead timings: identical 26s cycle, a constant one-frame offset, and no drift across a 3s stall that leaves the old code permanently 3 seconds out of phase. Also fixes a latent bug found on the way: UpdateManager iterates the dynamic master socket, which holds Independant and Hermit instances as well as masters, and handed all of them to EntityUpdateReplicants, which asserts MasterInstance. Doorframes no longer consume a slot in the map-entity ownership cursor, which shifts who owns every map entity dealt after them, so this cannot share a session with an older build. The lobby publishes a simulation revision and refuses to launch a mixed room. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
ce1b0ab9c3 |
Sounds fade, dull and doppler with distance again
The OpenAL port kept the whole authored audio model and then threw most of
its output away. Every frame the engine computed a distance-attenuation
curve, a high-frequency rolloff, doppler cents, a reverb level and a
front/rear placement, and every one of those consumers had been commented
out when the two AWE32 cards were replaced. What reached the speakers was
OpenAL's own defaults instead: a straight-line fade to silence, no
filtering, doppler at the wrong constants with an inverted velocity, no
reverb, and every cockpit sound dead centre.
Restored, per AUDIO.INI, which is byte-identical to the file that shipped
in August 1995:
- the authored knee/rolloff distance curve, replacing AL_LINEAR_DISTANCE.
This also un-blinds the transient cull, the voice-steal weighting and
the mix ducking, which all key off it and were treating far sources as
full presence
- the CC7 squared volume law; writing the scale linearly ran everything
about 6 dB hot at mid-scale
- brightness and distance muffling, and the wet-exterior/dry-cockpit
reverb split, both through a new OpenAL EFX bridge
- doppler on the moving-source path only, as the original had it
- front/rear placement from the authored position enum
The larger find is that AL_PITCH was never called anywhere in the tree, so
the entire pitch chain was inert - not only doppler but pitch_mix_offset,
which our own sequences author 97 times. Doppler alone would have changed
nothing audible.
Note pitch is applied for parity with the BT engine but is identity here:
our content predates NoteAudioControlID, so every source runs at note 60.
Builds clean on VS2022 Release|Win32. Smoke-tested against vRIO on COM1 -
reaches gameplay and holds a steady frame loop. ALC_EXT_EFX is present on
the build machine with all nine entry points, so the filter and reverb work
is live rather than inert. Not yet listened to on the pod, which is the
real test: the volume law changes the level of everything.
docs/SOUND.md documents the original two-card quadraphonic design, where
the surviving original assets are, and what remains.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
f4fef29428 |
The map keeps drawing when the view gets busy
Two testers reported the map and the countdown clock freezing, one of them only on larger, more complex maps, and one of them until a death. Both details point at the same place. The gauges and the cockpit displays are redrawn in whatever time is left after the 3D view. The background loop is guaranteed a single pass per frame and gets more only while time remains before the frame is due, and one pass drew exactly one gauge. So a full sweep of ninety-odd gauges needed ninety-odd passes - free when there is spare frame, but on a busy map the 3D view eats all of it, the loop drops to its one guaranteed pass, and a sweep takes ninety-odd FRAMES. Seconds. A death makes the renderer skip every static object, the budget frees up, and the backlog drains at once: the display appears to come back to life. Worse, the copy phase that follows ended after a SINGLE display, so the map - one of three - came round only every third sweep. So: draw gauges to a 2ms slice rather than one per pass, which ties the refresh rate to elapsed time instead of to how much spare frame there happened to be; and copy every display before reporting the sweep done. Measured on a deliberately starved frame budget, which reproduces the reported symptom: 0.7 sweeps/s before, 3.1 after. At a normal budget 20/s, against 18-19 before - no cost to the healthy case. RP412GAUGESLICE tunes the slice and 0 restores the old behaviour, which reproduces the 0.7 exactly. RP412GAUGEDIAG=1 logs the rate; watching the screen cannot tell a display that has stopped refreshing from one whose picture simply is not changing, which is what made this hard to see. Also fixes the constructor calling Update() three lines before it initialised mDisplayToUpdate, so the first pass indexed the D3D device and surface arrays with whatever was on the stack. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
82e733c1a6 |
Replicants reckon from when an update was sent
Simulation::ReadUpdateRecord threw away the sender's timestamp and
stamped lastUpdate with its own arrival time. The line carried the
original authors' own note: "HACK - should be based upon
message->timeStamp".
The dead reckoner extrapolates a replicant over
(lastPerformance - lastUpdate), so starting that clock at ARRIVAL rather
than at SEND leaves every remote vehicle exactly one network latency
behind where it should be. On the 1 ms LAN inside an arcade that is
nothing. Over Steam Datagram Relay it is 50-150 ms of positional lag on
every other player - a constant bias, not jitter, and the information
needed to remove it was already in the packet.
The timestamp cannot be used as it stands: both machines run
QueryPerformanceCounter since their own boot, so the two clocks share no
epoch. The offset is estimated per peer instead. Each record gives
sample = ourNow - theirStamp = trueOffset + oneWayLatency
and latency is never negative, so the smallest sample seen is the
closest to the truth. A rolling minimum over 128 samples follows crystal
drift and re-adapts when a route gets slower, rather than being pinned
forever by one lucky packet; a shorter path is believed immediately.
Applied with two clamps: never ahead of our own clock, and never further
back than 500 ms. Past that the packet is stale or the estimate is
wrong, and throwing a vehicle half a second forward does more damage
than the lag being corrected.
Entity::UpdateMessageHandler is the only point on the receive path that
knows whose update this is - records carry a timestamp but not an owner -
so it publishes the sender around the loop, and only for entities
somebody else owns. Offsets are forgotten in CreateMission: the hosts in
the next race are not the hosts in the last one and a HostID gets reused.
RP412NETCLOCK=0 restores the arrival-time behaviour, documented in
environ.ini, so a test machine can compare the two without a rebuild.
The estimate is logged per host when it first settles and whenever it
moves more than 50 ms, which is what a three-machine session should be
read against.
WHAT IS AND IS NOT VERIFIED. A full single-player race runs unchanged -
the path is never entered without replicants, which is the regression
risk that reaches everybody. The behaviour this exists for needs real
latency between real machines and is therefore untested: a two-instance
loopback race would only have exercised the zero-latency case, where the
correction is a no-op by construction. Expect remote vehicles to sit
further forward than before, and watch for overshoot when somebody
changes direction sharply - that is the tradeoff this makes, and the
clamp above is what bounds it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
68f5780efa |
The cockpit clock counts the console's clock
A race ends when the console says so, but the countdown on the map display was computed from the engine clock and its own idea of when the race started - QueryPerformanceCounter from Application::gameStarted, against the console's GetTickCount from gRunStartTick. Two clocks, two epochs, two threads. They agreed to within a frame in the ordinary case, which is why nobody noticed. They do not agree at all when RP412MISSIONSECONDS is set: the override shortens the CONSOLE's length and leaves the egg's alone, so a 25-second test race displayed a clock counting down from 5:00 and was stopped with 4:35 still showing. gMissionClockHook (APPMGR.h, alongside the gPerFrameHook it mirrors) lets the console answer for the countdown when it is marshalling. NULL, or a console that has no answer yet, falls back to exactly the old computation - which is what the arcade -net pods, lobby members and mission review all take, none of them running a console locally. A member's clock is anchored by the console's RunMission arriving over the wire anyway, so it starts within one latency of correct and only drifts at the rate the two crystals differ. Two things come out of it beyond the clock itself. The camera directors switch behaviour at "30 seconds left" (DIRECTOR.cpp, RPDIRECT.cpp) and were reading the same free-running number, so the dramatic end-of-race camera and the actual buzzer were on different clocks too; they now share one. And the countdown holds at 00:00 instead of going negative - the console polls at 250 ms, so zero always arrives slightly before the stop is dispatched. The hook is guarded on gWatchedApp == application. Nothing ever uninstalls it, so a player who hosts a race and then joins somebody else's lobby still has it wired up, and in that race the console is a bystander holding the previous mission's gLengthMs and gRunStartTick. Verified by running a 25-second race with the menu still set to 5:00 and photographing the map display: 00:17, 00:01, then 00:00 held while "time expired - stopping mission" went to the log. Captures use PrintWindow rather than CopyFromScreen - the first attempt grabbed the desktop sitting in front of the Map window, which is somebody's screen contents written to disk, and those files were deleted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
3f691cacb3 |
Departed-pod resilience: collision guard + console loss ends the race
Round six raced all three machines (staging fix confirmed) and then exposed what happens when a pod leaves mid-mission - which arcade pods never did. The B crash dump named it exactly: VTV::TakeDamageMessageHandler resolved message->inflictingEntity to NULL (the entity belonged to the departed owner) and dereferenced it - Verify is compiled out in release. Collision damage from an entity that no longer exists is now ignored. And the race B and C were left in was a zombie: the owner (console) had aborted, so the mission clock would count up forever and the death/respawn flow hung with nobody to arbitrate. Lobby-member races now set gConsoleLossEndsMission: losing the console mid-mission posts StopMission locally, the pod tears down, and lands back in the lobby room. Arcade -net pods keep the re-listen-and-wait behavior. Loopback hosted race still green. For the drivers: the ampersand key is the arcade mission-abort - that was every crash-on-keypress so far; and a sleeping Bluetooth pad wakes on the Xbox button and hot-connects within 3 seconds (PadRIO re-probes). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
2d5057c528 |
Hosted races stage properly: the owner no longer launches itself
Round five reached the race - full mesh on all three machines, eggs, ACKs, mission running - but the owner raced ALONE. Cause: the engine self-runs a pod at WaitingForLaunch when its console host is not online (the arcade no-console fallback), and the owner''s in-process console never connects to its own pod. On fast-loading owners the self-run beat the console''s staging gate, so RunMission was never sent and the members sat staged at black screens until someone hit the & emergency-abort key. gConsoleMarshalsLaunch (APPMGR) now tells the engine an in-process console owns the launch: the network-race install sets it and the owner holds at WaitingForLaunch with everyone else; plain single player leaves it False and auto-runs as always. Verified on loopback: all pods staged - RUN is back in the hosted-race log and both the hosted race and the single-player cycle pass. Also: unhandled-exception minidumps (rpl4crash.dmp beside the exe, dbghelp loaded lazily) so test-machine crashes hand back stacks. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
9f79508257 |
LocalConsole: the in-process marshal that ends missions
Domain correction from playtest: hand-fed eggs are a developer shortcut - a mission only ends on a console command, so the clock hits 00:00 and counts up forever. Even single-player games need a console marshal. RPL4CONSOLE is that console. Like the real one it lives on its own thread: it owns the mission clock and raises the stop request at the selected length; the app-manager per-frame hook (new gPerFrameHook seam in APPMGR, called while the application global is live - the loop condition NULLs it on exit, which ate the first attempt) executes the engine-safe part, dispatching the same StopMissionMessage TeslaConsole sent. Final scores flow in through a new RP-layer sink (gConsoleScoreSink in RPCNSL): RPPlayer feeds it the same score it sends a real console at mission end. It also inherits the launcher role: the application tears down after a stop (arcade pods were relaunched per mission by TeslaLauncher), so WinMain respawns the process when the console ended the mission, landing back on the race-setup screen. L4NetworkManager grows FeedLocalEgg (the single-user egg-inject path, callable mid-session) for the future in-process loop. Verified end to end: menu -> 3:00 race -> stop dispatched exactly on time -> final score collected (host 1 = 4113) -> process respawned with the front end up. -egg runs stay unmarshaled (the dev shortcut). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
12b31187f9 |
Move the build to VS2022 (v143) with runtime parity against VC9
Hand-converted the four .vcproj projects to .vcxproj (Win32, v143, Windows 11 SDK + DXSDK June 2010 for d3dx9/dxerr only). WinTesla.sln now builds the v143 projects; the legacy solution is kept as WinTesla_vc9.sln. Kept: /Zp1 in Munga_L4+RP_L4, Unicode, x86, /DYNAMICBASE:NO, /FORCE:MULTIPLE (header-defined globals still duplicated across TUs). Changed: CRT unified to /MD(d); import libs linked by the exes instead of merged into Munga_L4.lib; WINDOWS_IGNORE_PACKING_MISMATCH and _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS defined; legacy_stdio_definitions.lib for the June-2010 dxerr.lib. Source fixes, all behavior-preserving: Time gains standard (non-volatile) copy-ctor/assignment overloads (rvalues cannot bind to volatile& in standard C++); operator==(SOCKADDR_IN&,...) made inline; L4DINPUT's Enum*Callback pair renamed DIEnum* (collided with L4CTRL's under LTCG); std::ios.in -> std::ios::in in CAMMGR.cpp. Verified: VC9 baseline rebuilt from this tree first, then the v143 build compared against it in a sandboxed game working copy - identical logs and behavior through RIO init (against vRIO) and mission load, including the same pre-existing AV in d3d_OBJECT::LoadTexture (L4D3D.cpp:262) that both toolchains hit; documented in BUILD.md 4 as the next debugging target. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Opus 4.8
|
4abbf8879f |
Initial import of Red Planet v4.10 Win32 source
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> |