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.