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.