From 3f2dd46487b3297f054d71e4a27871fe68ecaa75 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 16:36:29 +0000 Subject: [PATCH] port: nested leaves may advance at half rate -- the title sweeps ship 1.87x too fast Their corrected least-squares fit gives 4.287 and -4.348 px/frame against my declared 4.000 and 4.063 px/unit: 1.072 and 1.070 units/frame, where Q1 establishes 2 for top-level elements. My port drives everything from one clock -- boot.gd:375, time_units += delta * units_per_second at 60 units/s -- and the leaf path reads that same clock. So the title's sweeps cross in 10.0 s where the game takes 18.7, a visible 1.87x defect in what the boot ships. Not changed, and not only out of caution: keyframe_units_per_second is authored from a measurement and governs build-in, transitions and the plate. Changing it globally breaks the top-level timing Q1 measured; a leaf-only clock is a claim about how the game works rather than about my renderer. That is a Q1 sub-question and theirs. Refutation attempt on their strongest argument: two strips agreeing to three significant figures constrains the strips to EACH OTHER, not the absolute rate. Both ratios come from one capture under one fps assumption, so a systematic error scales both identically and the agreement survives. Their own untested candidate -- 1 unit per 1/30 s at 28.5 fps gives 1.053 -- sits within that uncertainty of 1.070. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/BLOCKED.md | 19 ++++++++++++++++ docs/port/DECISIONS.md | 49 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 67 insertions(+), 1 deletion(-) diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index cc8d2b88..fe03990c 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -843,3 +843,22 @@ two of their own wrong readings. black interval? That is the cheapest test of whether "Ⓑ has no black" is a rule or one screen pair. (2) Is the Ⓐ ~10 units a designed hold or a load? If a load, it is emulator-dependent and nothing should be authored from it. + +### Do nested leaf records advance at half the top-level rate? + +**Derived from Decoder `auto/build-ordinal-audit`, draw-stream fit over 132/112 +frames.** + +Measured 1.072 and 1.070 units/frame for the two title sweeps, against Q1's 2 +units/frame for top-level elements. My port drives both from one clock at 60 +units/s, so if that holds **the title's sweeps ship 1.87x too fast** -- a 10.0 s +cycle where the game takes 18.7 s. + +**Not changed.** `keyframe_units_per_second` is authored from a measurement and +governs build-in, transitions and the plate; a leaf-only clock is a claim about +the game, not about my renderer. + +**The ask:** is the factor a property of nested records, or does Q1's 2 +units/frame simply not apply to them? And note the two-strip agreement constrains +the strips to each other, not the absolute rate -- both ratios come from one +capture under one fps assumption, and 1 unit per 1/30 s at 28.5 fps gives 1.053. diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index b89bf6cd..0406baa3 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -183 sections. Search this before re-deriving anything. +184 sections. Search this before re-deriving anything. * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28) * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28) @@ -194,6 +194,7 @@ dies, which is what this file is for. * [Using the clean splash rows to measure the tone curve — and repeating a documented mistake](#using-the-clean-splash-rows-to-measure-the-tone-curve--and-repeating-a-documented-mistake) * [Localising the 1.92 splash floor: it is glyph edges, and off them the port is ~1 RMSE from the game](#localising-the-192-splash-floor-it-is-glyph-edges-and-off-them-the-port-is-1-rmse-from-the-game) * [Their draw-stream result checked against my export — three confirmations and one correction](#their-draw-stream-result-checked-against-my-export--three-confirmations-and-one-correction) +* [Nested leaves may advance at half rate — a quantified defect in shipped output](#nested-leaves-may-advance-at-half-rate--a-quantified-defect-in-shipped-output) ## P0 — the exporter, 2026-08-28 @@ -10433,3 +10434,49 @@ the file declares; whether the game advances the leaf at 4.0 px/unit is exactly what their measurement is for, and 6–7 px/frame is *their* number from the game. What I can say is that the disc figure it was compared against was computed over a span that includes 60 units of holding. + +## Nested leaves may advance at half rate — a quantified defect in shipped output + +Their corrected fit (least squares over 132/112 points, replacing an eyeballed +figure that was 50 % high) gives **4.287** and **−4.348** px/frame against my +declared **4.000** and **4.063** px/unit — i.e. **1.072** and **1.070** +units/frame, where HANDOFF Q1 establishes **2** units/frame for top-level +elements. + +🔴 **My port drives everything from one clock.** `boot.gd:375` is +`view.time_units += delta * view.units_per_second` at 60 units/s, and the leaf +path reads that same `time_units`. So: + +| | port cycle | game cycle (at 1.07) | | +|---|---|---|---| +| `pteff03` | 10.0 s | **18.7 s** | port **1.87×** too fast | +| `pteff03a` | 12.0 s | **22.4 s** | port **1.87×** too fast | + +That is a visible defect in what the boot sequence ships — the title's sweeps +cross in half the time the game takes. + +⚠️ **Not changed, and not only out of caution.** `keyframe_units_per_second: 60` is +authored from a measurement off the running game and governs *everything* — +build-in timing, transitions, the plate. Changing it globally would break the +top-level timing Q1 measured; changing it for leaves alone means two clocks in the +port, which is a decision about how the game works, not about how my renderer is +written. **That is a Q1 sub-question and it is theirs.** + +### Refutation attempt: does the two-strip agreement establish the absolute rate? + +Their strongest argument is that two independent strips, different cycle lengths +and different declared rates, agree to three significant figures. 🟡 **It is +weaker evidence than it looks for the *absolute* value.** + +Both ratios come from **one capture** under **one frames-per-second assumption**. +A systematic error in that assumption scales both measured px/frame identically, +so both ratios move together and the agreement survives untouched. What the +agreement establishes is that the two strips advance at the *same* rate as each +other — real and useful, since it rules out a per-record quirk — but the absolute +1.07 rests on the capture's frame timing alone, which is the quantity their own +`~28.5 fps` note says is not exactly 30. + +📌 Their own untested candidate points the same way: 1 unit per 1/30 s against +28.5 fps gives **1.053**, and the gap between that and 1.070 is about the size of +the frame-rate uncertainty. So the measurement may be saying *"one unit per game +frame"* exactly, with the residual being how fast the emulator actually ran.