af52476603638df228b05ca67d0d7cb823a619f6
13
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
|
c2e2df1dce |
Every knob the code reads is in the documented file
A sweep of every getenv() in the tree against the environ.ini template found five options the code answers to that the file never mentioned: the physics trace, the spawn-zone pin, the gauge profiler, the renderer diagnostic and the joystick-scan log. They were deliberately env-only once - scaffolding, not settings - but scaffolding that cannot be found is scaffolding that gets rebuilt, and RP412RENDERDIAG had already been forgotten thoroughly enough that this sweep is what rediscovered it. They get their own section, between the shipped configuration and the optional extras, with the header saying what they are for: making a claim about the game testable instead of arguable. All five ship commented out, cost nothing when off, and none belongs in a real race. The sweep now closes empty - there is no environment variable the game reads that the file does not document - and the mention-check keeps it honest from here: a build that grows a new option names it in rpl4.log for every carried-over file. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
9643e02198 |
The physics rate is the play testers' question now
RP412PHYSICSHZ documented in environ.ini, under TARGETFPS where it belongs, with the three rates worth testing: 25, the arcade pods' rate and the step the original handling was tuned against; 50, the middle road; 100, the smoothest contact response. All three divide the engine's millisecond clock exactly and all three are verified bit-identical across frame rates. The entry says what to feel for - hover bounce, wall hits, how the pod takes a hill crest - and asks for the rate alongside the verdict, because whichever one the testers pick becomes the canonical physics for PC and pods alike. It ships commented out: the default stays the frame-coupled game everyone knows until that decision is made on purpose. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
1dd40be0a3 |
The map draws on every step of the rate wheel
The renderer walks a sixteen-step rate wheel: one step per full pass over the gauge list, shifted right each pass and reset at the bottom. A gauge redraws only on the step its configured rate names, so the map - on one step - waited a whole turn of the wheel however cheap its redraw was. With the frame budget fixed the wheel turns about fifty times a second and one-in-sixteen would be tolerable. It is still the wrong shape for the map: the thing a pilot reads to navigate should not be the display that updates least often, and RP412MAPRATE says how many of the sixteen steps it draws on. Sixteen by default, one for the old data-driven behaviour. Each extra step costs one gauge's redraw against a pass that runs ninety of them, which measured as nothing. The write has to be QUALIFIED, and that is worth recording because it cost hours. GPS's constructor takes its rate as a parameter also called 'rate', which shadows the inherited Gauge::rate for the whole body - so a bare assignment sets the parameter and leaves the member holding whatever the gauge data asked for. oldRate is not shadowed, so it took the value, and the pair then disagreed: rate=2000, old=ffff. That looked exactly like something writing the member from outside, and there is no such writer - Gauge touches rate in three places, none of which can produce that pair. A hardware write-watch on the member settled it by reporting an address on the STACK. Also here, the terrain-arrival work on the map background. It draws one placement into the cached picture when the static bounds are unchanged, and rebuilds the whole thing only when they move - the bounds set the scale, and the scale is what everything already on the picture was drawn at. It is honest to say this fires rarely: the logs show terrain arriving in one burst at mission load, not streaming in as you drive, so the incremental path is mostly insurance. What it does close is real, though - departures now order a rebuild. Nothing listened for those before, and they had been swept up by the rebuild the next ARRIVAL ordered, which on a track whose terrain all arrives at load is a rebuild that never comes. Co-Authored-By: Claude Opus 5 (1M context) <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
|
827c5b295b |
The controls answer only while the game is the window in front
Testers taking notes in another window were flying the pod while they typed. RP412INPUTFOCUS=1 is the new default; 0 restores the old behaviour. The pod was the only thing running on its cabinet, so the virtual RIO reads the key state directly rather than waiting on the message pump. That is the right call for latency and it is why the pedals feel like pedals - but a direct read is a read of the WHOLE keyboard, whatever has focus. On a cabinet that distinction did not exist. On a desktop it is the difference between writing a bug report and steering into a wall while you write it. One choke point does the whole job: PadRIO::PollInputs is where the keyboard, the XInput pad and the DirectInput stick are all read, so a single flag covers the three of them. The joystick needs no change of its own - unfocused the resolve block is skipped, every device slot stays at -1, and the button, hat and axis loops find no device and read released on their own. It is opened DISCL_BACKGROUND on purpose, or it would stop answering the moment a cockpit pane took focus, so declining to poll it is what makes it go quiet. Each source reads as RELEASED rather than the poll returning early, and that is the part worth keeping: bail out instead and whatever was held at the moment you switched away stays held until you come back, which is the stuck throttle this is meant to prevent rather than cause. Reading released lets the diffs already in there turn it into proper release events. The throttle accumulator is the deliberate exception. It is the pod's one sticky axis and it integrates what the controls ask for, so controls asking for nothing simply stop moving it - you come back to the speed you left rather than to a dead stop. Focus is tested per PROCESS, not against one window handle. The cockpit is a shell full of child panes, the exploded view is six windows of its own and the plasma glass another; matching a single HWND would drop the controls the moment somebody clicked an MFD. Real RIO cockpit hardware is untouched - this is the keyboard, pad and joystick path only. The volume and bass keys in L4CTRL were already gated this way, unconditionally, which is where the idiom comes from. On by default because the alternative is every tester editing a file before the fix reaches them: an environ.ini written by an older build does not carry the line, so the built-in default is what they get. The log says which way it is set, and the option-mention check names it as one they have not heard of. Verified against the built exe both ways: a fresh run writes the documented default and applies 14 settings where it applied 13, and a file with the line removed reports exactly one unknown option and falls back to focus-gated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
25e25260b1 |
Home and End are the bass knob
The volume keys wanted a partner, and the bass trim could not be one as it stood: it scaled the sample data as it loaded, so by the time anyone pressed a key the audio was already sitting in OpenAL buffers and nothing short of a restart would move it. So the trim is now a per-zone gain applied in the mix instead. Each buffer's depth - how much of the low band it occupies - is still worked out once at load from its playback rate, but the trim itself is read every frame, which is what lets Home and End move it while sounds are playing. It is the better form regardless: no rewriting of sample data, and no quantisation on top of audio that has already been through one gain stage. Home raises, End lowers, in steps of 0.05, and the setting is written to bass.cfg beside the exe exactly as the volume writes volume.cfg. Together with PageUp and PageDown that is the amplifier and the crossover the cabinets had in hardware and a desktop does not. Builds clean, runs, and neither knob fires unprompted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
4e8392fcfb |
PageUp and PageDown are the volume knob
The cabinets had no volume control - they ran at unity and left level to an external amplifier - so a player without that hardware had nowhere to turn it down but environ.ini and a restart. PageUp and PageDown now step the master volume by 0.05 while you play, from silent to double, and whatever you leave it on is written to volume.cfg beside the exe and used from then on. The environ.ini figure decides where a machine that has never been touched starts out; the keys are the knob, and a knob stays where it was left. Page keys because they produce no typed character, so they cannot collide with the character-keyed commands the engine already answers to, nothing else in RP binds them, and they are on every keyboard including tenkeyless. They are polled rather than read off the key-message path, which is worth recording because the message path looked like the obvious home for them and was tried first. RP's keyboard pump only takes WM_KEYUP, WM_SYSKEYUP and WM_CHAR off the front of the queue, and the front end runs message loops of its own, so key messages get raced for and lost: six deliberate, well-spaced presses arrived as two. Fine for the abort chord, useless for something you tap repeatedly to find a level. Reading key state directly costs nothing and cannot be dropped. That losses figure is a pre-existing property of the input path, not something this change introduced, and is worth knowing before anything else gets bound there. Builds clean, runs, and does not fire unprompted. The step function itself is proven - it was driven end to end through the message path before the switch, stepping the right way, clamping, and persisting. What I could not test from here is the polling trigger, because Windows would not hand the game foreground and injecting keys without it would have sprayed them across whatever else was open. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
523f713a30 |
Volume and bass knobs, for players without an amplifier
The cabinets ran the game at unity and shaped volume and tone outside it, in an external amplifier and a 3-way crossover. That is why there is no master volume anywhere in the original code and none in AUDIO.INI - an operator turned a knob on an amp. A desktop player has no amp and no crossover, and the recovered soundbanks are a good deal livelier than what 4.12 shipped with, so the game has to offer the two controls the pod got from hardware. RP412AUDIOVOLUME, 0.0 to 4.0, is the amplifier: a listener gain, which the port had never set at all. RP412AUDIOBASS, 0.0 to 1.0, is the crossover's low band. Both default to leaving the mix exactly as the pod played it, so neither changes anything for anyone who does not go looking. The bass trim is not a filter, and the reason is worth writing down: the OpenAL we ship is Creative's, not OpenAL Soft, and it implements only AL_FILTER_LOWPASS. It rejects highpass and bandpass outright. A bandpass would have been the tidy answer, carrying the authored brightness model on GAINHF and the trim on GAINLF across the single direct filter a source gets. It is not on offer. So the trim scales sample data as it loads, which suits how this low end is actually built: the weight lives in discrete deep layer zones whose per-zone tuning bakes out to a very low playback rate - thirteen zones below 8kHz, three to five octaves under their recorded pitch, against four fifths of the set at 22kHz and up. Baked rate is a dependable proxy for band, so pulling down the low-rate zones is a real low-band trim and not a blunt cut. It eases in below 22kHz and reaches full depth at 5.5kHz. Caught while building this, and the reason for the probe: EFX_Initialize checks alGetError after configuring the scratch filter, so asking for a filter type the driver refuses leaves an error pending and takes the entire bridge down - reverb included. The bandpass attempt did precisely that and would have silently killed the reverb and brightness work. Initialize now survives losing the filter and says so. Builds clean, runs with both knobs set and with neither. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
6ce729bab5 |
Lit cockpit buttons keep up with the sim
BT411's f99003c, brought across. Its playtesters reported the cockpit lighting going slow or stopping altogether while the 3D view stayed smooth, and RP412 has the same structure exactly: the on-screen vRIO buttons light themselves from PadRIO::GetLampState, but what FILLS that store is lampManager->Update() in GaugeRenderer::ExecuteForeground - once per full gauge cycle. Which is the cycle the previous commit was about. Measured on a starved frame budget it now completes 3.1 times a second, and completed 0.7 times a second before that; either way far too slow to carry a flashing lamp. So sweep the lamps once per frame from the main render instead, which runs regardless of how little frame is left over. It is cheap, and AssertNewLampValue already drops anything unchanged, so this pushes no extra traffic - it only stops changes arriving late. Only when a PadRIO is active, i.e. cockpit-less play, and only while a mission is actually running. With real serial hardware selected the pod keeps its authentic bandwidth-paced cadence, untouched. RP412LAMPSWEEP=0 restores the once-per-cycle behaviour. BT411's other half, 02ce9f5, does not apply. That one is about Windows throttling WM_TIMER and paint messages for background windows, which made the glass panels' flash crawl whenever they did not have focus. RP412 has no timer-driven repaint anywhere - the MFD windows are D3D devices presented from SVGA16::Update, and the panel strips repaint from there too - so there is no throttled message path to bypass. That path was starved rather than throttled, and the previous commit is the fix. Verified: no regression at either budget, 20.0 display sweeps/s at a normal frame budget and 3.1/s starved, both unchanged by this commit; mission runs clean. The lamp win itself is structural - the sweep is now an unconditional per-frame call - and would want a busy multiplayer mission to see directly. 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
|
4f34684b16 |
environ.ini is written on first run, not shipped
Packing one into every zip meant a tester who unzipped a new build over their folder got their configuration replaced. bindings.txt has never had that problem, because the exe carries the template and writes the file only when it is absent. environ.ini now works the same way, so a new build can land on an existing folder and every setting survives. The 245-line template moves out of pack-dist.ps1 and into RPL4ENVIRON.cpp as the exe's own literal, which also means the exe alone can produce a working install. It was lifted mechanically rather than retyped, and the file it writes is line-for-line identical to the one we have been shipping - only the line endings changed, from a mongrel 243 LF plus one stray CRLF that PowerShell's Set-Content left on the end, to the uniform LF the game already writes bindings.txt with. It cannot simply become optional. Without environ.ini, L4GAUGE is unset - which disables the gauge renderer and takes every MFD with it - and L4MFDSPLIT is unset, which is the packed-window arcade layout rather than the glass cockpit. The shipped values ARE the desktop game; the built-in getenv fallbacks are the 1995 pod. So the game writes the file rather than tolerating its absence. The cost of a file that is never overwritten is that a tester carrying one across many builds stops being offered new options. Nothing breaks - an option added later defaults to "behave as before" - but it goes unnoticed, and "the podium does not work" is a confusing bug report when the real answer is that their environ.ini predates RP412PODIUM. So the load names every template key the player's file has never mentioned, and says they are at built-in defaults and that deleting the file brings the documented one back. A stale seven-line file lists all 40. The file is read, never rewritten. The mention test is deliberately generous - a key counts as known if it appears in any form, commented or not - because the failure it guards against is worse than a missed notice: environ.ini is applied line by line, so a second copy of a key appearing later in the file would silently override the player's own. The version line also moves to the top of WinMain. It used to print after the environment was loaded, so the first thing in rpl4.log was a message about environ.ini rather than which build wrote it. Verified: the written file matches the old shipped one line for line; an edited file with a hand-added comment survives another run untouched; a seven-line file from an older build boots and names all 40 options it has never heard of; and a full mission on a self-written file brings up the glass cockpit at 125% with the virtual RIO active and nothing alarming in the log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |