From 1bcee1f9eba80835edf7545e81ef6c21df673610 Mon Sep 17 00:00:00 2001 From: Joe DiPrima Date: Sun, 2 Aug 2026 10:20:52 -0500 Subject: [PATCH] #96: the effective-rate theory is corroborated -- upgrade the calibration provenance T3 -> T2 Frame-rate testimony from the morning follow-up, now on record beside the bytes: * Oracle, asked if the pod frame rate was rock solid: "I think I could do as well with a flipbook"; heavy fights "would turn to a slide show". * Lynx (original era): "RP had a target frame rate of 30FPS. It wasn't hard coded or locked. BT never had a locked frame rate in 1st release testing... coming from 3.0, where 20FPS was a miracle." * The engine pacer's own design agrees: fixed budget + background fill + NO overrun catch-up (APPMGR.cpp, T0) = "target 28 but allowed to slip", with the 18.2065 BIOS fallback anticipating degraded timing. Also settles epilectrik's open confirmation ("frame rate is advancing at least some of the subsystems -- i have to fully confirm that"): ALL of them -- UpdateManager::Execute runs every interesting master every frame, Entity::PerformAndWatch runs every executable subsystem per entity tick, no throttle at any layer. The crisp rule: CADENCE is frame-linked for everything; only terms missing a dt multiply are rate-SENSITIVE. Corollary worth keeping: a choking 486 generated LESS heat/s exactly during the biggest fights -- the slideshow was mercy. Veteran memory of seek-4 endurance encodes the LOADED rate, which is why bracketing by their consensus is the correct instrument rather than a concession. Follow-up filed in the KB: sweep the reconstruction for OTHER dt-less per-tick accumulators (known: particle trail density, rendering.md; the 15-sample heatFilter window is rate-dependent smoothing, benign). Each found one should normalize against the same 28-nominal/bracketed-effective pair. Co-Authored-By: Claude Opus 5 (1M context) --- context/decomp-reference.md | 9 ++++++++- game/reconstructed/myomers.cpp | 25 +++++++++++++++++-------- 2 files changed, 25 insertions(+), 9 deletions(-) diff --git a/context/decomp-reference.md b/context/decomp-reference.md index d8119ea..4d268f5 100644 --- a/context/decomp-reference.md +++ b/context/decomp-reference.md @@ -561,7 +561,14 @@ whenever the decomp shows an unexplained multiply/divide by `_DAT_0052140c`, it is per-second <-> per-frame conversion at the pod's 28 Hz. **So the pod's nominal simulation cadence was 28 fps, not the i860 board's -30 Hz.** Every "per tick with no dt" accumulation in the binary (the myomer +30 Hz — and it was UNLOCKED.** Corroborated testimony (2026-08-02): Oracle — +the pod rate was "flipbook" territory, heavy fights "a slide show"; Lynx +(original era) — "BT never had a locked frame rate in 1st release testing", +RP targeted 30, Tesla 3.0 managed ~20 on a good day. The engine pacer design +agrees: fixed budget, background fill, NO overrun catch-up (APPMGR.cpp T0) — +target 28, allowed to slip. Consequence: any per-tick dt-LESS accumulator ran +SLOWER during heavy combat on real pods; per-tick behaviors must be calibrated +against the loaded effective rate (veteran bracketing), not the constant. Every "per tick with no dt" accumulation in the binary (the myomer kinetic heat term; candidate: particle trail density) was calibrated against 28 nominal — and less under load (the 18.2 fallback existing at all says slow paths were expected; the EFFECTIVE in-pod rate is an open question, see diff --git a/game/reconstructed/myomers.cpp b/game/reconstructed/myomers.cpp index 0e42dc9..6fbccf4 100644 --- a/game/reconstructed/myomers.cpp +++ b/game/reconstructed/myomers.cpp @@ -772,14 +772,23 @@ void Myomers::MyomersDriveHeat(Scalar time_slice) // the ApplicationManager ctor (0x401189: push [0x52140c]). So the pod's // nominal Performance cadence was 28 Hz, byte-proven. [T1] // - // CALIBRATION FACTOR 0.5, testimony (Oracle, 2026-08-02): at the byte rate - // the veterans still report ~2x too much myomer heat -- "If you could - // please halve the myomer heat rate again. We will bracket to something - // reasonable." The plausible physical story is the pod's EFFECTIVE rate - // under load (a 486 host missing beats; the 18.2 fallback existing at all - // says slow paths were expected), which statics cannot settle. Effective - // default therefore 28 * 0.5 = 14 Hz, explicitly marked testimony- - // calibrated [T3]; BT_MYO_HZ= overrides absolutely for bracketing. + // CALIBRATION FACTOR 0.5 -- the pod's EFFECTIVE rate under load, now + // corroborated from three directions (2026-08-02): + // * Oracle (pod veteran), asked if the frame rate was rock solid: + // "I think I could do as well with a flipbook"; heavy fights "would + // turn to a slide show". + // * Lynx (original-era): "RP had a target frame rate of 30FPS. It + // wasn't hard coded or locked. BT never had a locked frame rate in + // 1st release testing... coming from 3.0, where 20FPS was a miracle." + // * The engine's own pacer DESIGN: end_of_frame = Now() + frameDuration + // with background fill and NO overrun catch-up (APPMGR.cpp, T0) -- + // "target 28 but allowed to slip" is the construction, and the + // 18.2065 BIOS fallback anticipated degraded timing. + // Corollary: a choking 486 generated LESS heat/s exactly during the + // biggest fights -- veteran memory of seek-4 endurance encodes the LOADED + // rate, so bracketing by their consensus is the correct instrument. + // Effective default 28 * 0.5 = 14 Hz [T2 multi-witness]; BT_MYO_HZ= + // overrides absolutely for bracketing. static const Scalar kPodFrameHz = 28.0f; // byte-proven nominal [T1] static const Scalar kSeekHeatCalib = 0.5f; // Oracle bracket 2026-08-02 [T3] static Scalar s_hz = -1.0f;