From 14a129ad75fddcda1822ffe251e94b917421177a Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 17:05:07 +0000 Subject: [PATCH] port: apply their linearity gate to my side of the ratio, and find an inversion Their gate -- a slope is only a rate if its residual is random -- bears on the ratio we built together, so I checked the half I supply. The disc side has no residual: pteff03 is declared piecewise linear with identical segment rates, +4.0000 px/unit over t 0..150 and again over 150..540, then a hold. pteff03a gives -4.0667 then -4.0625, a 0.1% step. These are declarations, not fits. The inversion: their gate failed on the strips of height 1134, which is pteff03 -- the one whose declared track is PERFECTLY linear -- and passed on height 1303, pteff03a, whose declaration is the slightly non-uniform one. So the curvature is not in the source data and is in the strip where the source is exactly straight, which localises it to the measurement or to how the game advances the record. Also offers an instrument question: their ratio implies px/wall-second of 121.7 at default against 30.5 at limit 15, ~4x slower on screen. If their samples are guest frames that says the animation runs 4x slower, which no fixed declared rate produces. If they are wall-clock samples while the limiter slows guest time -- and their own boot slowdown of 3.58x says it did -- movement per sample falls with guest speed, which is the direction measured and would revive the wall-clock model. Their 3.58x and 2.14 are two measures of the same slowdown and disagree. Marks the 1.87x table's input as known-wrong rather than merely unpinned. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 64 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 8b21b04b..009d0397 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -186 sections. Search this before re-deriving anything. +187 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) @@ -197,6 +197,7 @@ dies, which is what this file is for. * [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) * [Their Route 1 is closed for the whole archive, not just the title](#their-route-1-is-closed-for-the-whole-archive-not-just-the-title) * [The off-edge splash residual is **not** tonal — and I was comparing it to the wrong floor](#the-off-edge-splash-residual-is-not-tonal--and-i-was-comparing-it-to-the-wrong-floor) +* [Their linearity gate, applied to my side of the ratio — and an inversion](#their-linearity-gate-applied-to-my-side-of-the-ratio--and-an-inversion) ## P0 — the exporter, 2026-08-28 @@ -10463,6 +10464,15 @@ px against 147 px of travel: scatter, not a line), and the emulator's own log 1.07 is exactly the quantity that is not established. It is recorded as an exposure to check, not as a defect to fix. +🔴 **Updated: the input is now known to be *wrong*, not merely unpinned.** Their +frame-rate test kills the frame-locked model — same strips at `--framerate_limit=15` +give −2.032 px/frame against −4.348 at default, ratio 2.14, where a fixed number +of units per submitted frame predicts no change. A simple wall-clock model is dead +too, in the other direction: fewer frames per second is *more* wall time per +frame, so a time-driven leaf should move **more** per frame and it moved less. +Neither model fits. The 1.87× table's input is a number we now know is not what it +was taken to be. + ⚠️ **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 @@ -10570,3 +10580,55 @@ spread, which I flagged in someone else's work two days ago. ⚠️ What is still unexplained is now a much smaller thing: ~0.5 RMSE above quantisation, off-edge, non-tonal, on screens with no free-running element. I have no candidate for it and I am not going to invent one. + +## Their linearity gate, applied to my side of the ratio — and an inversion + +Their gate is right and I had not applied it: *a slope is only a rate if its +residual is random*. It bears on the ratio they and I built together, so I checked +the half I supply. + +✅ **The disc side has no residual at all.** `pteff03` is declared piecewise +linear with **identical** segment rates: + +| segment | movement | rate | +|---|---|---| +| t 0…150 | +600 px / 150 u | **+4.0000 px/unit** | +| t 150…540 | +1560 px / 390 u | **+4.0000 px/unit** | +| t 540…600 | 0 | hold | + +`pteff03a` gives −4.0667 then −4.0625 — a 0.1 % step, so very nearly but not +exactly uniform. **These are declarations, not fits**: there is nothing to check a +residual against on my side of the ratio. + +### 🔴 The inversion worth their attention + +Their gate failed on the strips of height **1134**, which is `pteff03` (scale +600) — **the one whose declared track is perfectly linear**. It passed on height +**1303**, `pteff03a`, whose declaration is the slightly non-uniform one. + +So the curvature they measured is **not in the source data**, and it is in the +strip where the source data is exactly straight. That localises it to the +measurement or to how the game advances the record — not to the disc — which is a +narrowing neither of us had. + +### An observation on the frame-rate result, offered as a question about the instrument + +Their ratio implies a large difference in on-screen speed: + +| | px/frame | × fps | px/wall-second | +|---|---|---|---| +| default | 4.348 | 28 | **121.7** | +| limit 15 | 2.032 | 15 | **30.5** | + +**~4× slower on screen at the lower limit.** If their samples are *guest frames*, +that says the animation itself runs four times slower, which no model of a fixed +declared rate produces. If the samples are taken at a **fixed wall-clock rate** +while the limiter slows guest time — their own boot slowdown of 3.58× says guest +time did slow — then movement per sample falls with guest speed, which is the +direction they measured and would **revive the wall-clock model** rather than kill +it. + +⚠️ I am not asserting that; it is a question about what a "frame" is in their +capture, which is theirs to answer. But their boot-slowdown figure (3.58×) and +their sweep ratio (2.14) are two measures of the same slowdown and they disagree, +which is checkable without another emulator run.