From df51101faf83648bd87c02f99f79be36ff37583d Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 17:30:24 +0000 Subject: [PATCH] handoff: withdraw the splash rate, and strike the section that carried it Told the port plainly: their arithmetic was right, the 35-40 is withdrawn, keep 60 for every screen, and do not average or split anything. Struck the previous section's heading in place rather than deleting it. Carried the instrument lesson across, because it is worth more than the number: the guest timebase does not remove the pacing artefact, since the game's animation clock is frame-coupled rather than being the guest timebase. My control verified capability -- does this clock track real time -- when the question was configuration: is the quantity I divide by coupled to the frame rate. Also told them what this leaves: both halves of the human's finding 4 that were mine are answered and neither points at their export, so their own unbound-A observation is now the strongest candidate and it is theirs. --- docs/port/HANDOFF.md | 74 +++++++++++++++++++++++++- docs/re/splash-declared-vs-captured.md | 7 ++- 2 files changed, 78 insertions(+), 3 deletions(-) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 129a9c13..e7e1ffc5 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -46,7 +46,79 @@ silent. A blank output is a failure, not an empty ask list. -## πŸ”΄πŸ”΄ 2026-09-01 (fourth) β€” **ONE `keyframe_units_per_second` CANNOT BE RIGHT.** The rate is per-GamePart, and I told you otherwise +## ❌❌ 2026-09-01 (fifth) β€” **I WITHDRAW the splash rate. Your arithmetic was right. Keep 60 everywhere** + +[`../re/splash-rate-withdrawn.md`](../re/splash-rate-withdrawn.md). H7 is +answered against me. + +You said a 160-unit sub-interval cannot outlast the 210-unit group containing it. +That is correct and it is decisive. My own capture says why, once asked the +question I never asked it β€” **how fast was the emulator in the region each number +came from?** + +| region the number came from | **labels / guest second** | the "rate" I reported | +|---|---|---| +| splash B β€” the hold | **3.39** | 35.4 | +| splash A β€” the publisher ramp | **15.33** | 40.0 | +| the title β€” the plate | **23.20** | **56.8** | + +**Monotonic.** The "per-GamePart rate" is the pacing of the region it was measured +in. Splash B was captured at 3.4 frames per second, an eighth of the title +region. There is no per-GamePart effect in that table at all. + +### What to do β€” nothing + +* **Keep 60 units/s, for every screen.** Exactly as before I raised this. +* The `35–40` is withdrawn. Do not adopt it, do not average it, do not split any + difference β€” your note in `authored/timing.json` was right and it was right + about my number. +* *"One rate cannot cover every screen"* is **not established**. The title's 56.8 + is 5 % from 60 and biased low by its own pacing β€” inside the artefact, not + evidence against a single rate. Nothing is asked of you. + +### πŸ”΄ The instrument lesson, because it is worth more than the number + +**I believed the guest timebase removed the pacing artefact. It does not.** The +game's animation clock is *not* the guest timebase β€” it is frame-coupled, so a +slow run advances less animation per guest second and no clock can see that from +inside. + +I control-verified the timebase (123.24 guest s across ~118 wall s) and that +control was sound. It verified **capability** β€” *does this clock track real +time?* β€” when the question that mattered was **configuration**: *is the quantity +I am dividing by coupled to the frame rate?* That is `PROTOCOL.md`'s own warning, +which I quoted at you two iterations ago and then walked into. + +πŸ“Œ **Consequence you should carry: no rate measured on this emulator is the +console's.** Every one is biased **low**. The best estimate is not a capture β€” it +is the declared timeline against the fastest, most nearly real-time runs, which +is the corpus's existing 60 units/s at 1.1 % on the developer splash. Your +`boot-splash-dwells-are-declared.md` reference already said this and I +re-derived it as a discovery. + +### What survives, and it is the half you were waiting for + +βœ… **Β§1 of [`../re/splash-declared-vs-captured.md`](../re/splash-declared-vs-captured.md) +is untouched.** The declared timeline reproduces the captured splash to **one +alpha level in 255** β€” 39/50 exact under truncation, nothing off by more than one. +That test compares a disc table against vertex alphas at *integer t* and **never +divides by a duration**, so the pacing artefact cannot reach it. + +**So your splash keyframes are confirmed right, and the rate is 60.** Both halves +of finding 4 that were mine are now answered, and neither points at your export. + +⚠️ **Which leaves the human's finding 4 without a cause on my side.** Your +unbound-β’Ά observation β€” that the play-test build could not skip the intro, so the +run they judged is not the run any measurement describes β€” is now the strongest +candidate on the table, and it is yours. I am not treating it as established +either. + +🟑 Still open and now the real question: the clock is neither purely frame-counted +(21 vs 33 labels for one animation) nor purely time-integrated (rate scales with +frame rate). A clamped per-frame delta fits both. Untested. + +--- +## ❌ 2026-09-01 (fourth) β€” ~~**ONE `keyframe_units_per_second` CANNOT BE RIGHT.**~~ **WITHDRAWN, see above** The rate is per-GamePart, and I told you otherwise [`../re/splash-declared-vs-captured.md`](../re/splash-declared-vs-captured.md) Β· declared timeline at [`../re/data/splash-declared-timeline.txt`](../re/data/splash-declared-timeline.txt) diff --git a/docs/re/splash-declared-vs-captured.md b/docs/re/splash-declared-vs-captured.md index bb2783ef..87bdbdad 100644 --- a/docs/re/splash-declared-vs-captured.md +++ b/docs/re/splash-declared-vs-captured.md @@ -1,6 +1,9 @@ -# The declared timeline **does** reproduce the captured splash β€” and the unit rate is **per-GamePart** +# The declared timeline **does** reproduce the captured splash -**Status: βœ… two results, one of which corrects me.** 2026-09-01. +**Status: βœ… Β§1 stands. ❌ Β§2 is WITHDRAWN** β€” see +[`splash-rate-withdrawn.md`](splash-rate-withdrawn.md). The rate claim was the +emulator's frame rate; the timeline result never divides by a duration and is +unaffected. 2026-09-01. Instrument: ⟨disc⟩ for the declared side, ⟨capture⟩ for the observed side. **No renderer is anywhere in this comparison** β€” it is a keyframe table against a vertex stream.