From 93d69e614846f1241b60ecb0962fcd47fe62af08 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 16:33:12 +0000 Subject: [PATCH] port: check their draw-stream result against my export -- three confirmations, one correction Their oracle run refutes their own 'may not draw these leaves' hypothesis and confirms my title curve from the game. Checked against my export: Rotation: the export carries rotation_deg +30 on pteff03 and -45 on pteff03a, constant across all four keyframes, matching their ROT flag. spin_period_units returns 0 for four-keyframe elements so the spin override does not fire and the port draws the declared angle. Directions: ptloop01 runs -639 -> 1521, ptloop02 runs 1721 -> -839 -- their strip A and strip B. Height: a 30-unit phase step changes a band 1121x720 and 1137x720, full frame height, which is what a 1134/1303 px strip on a 720 px screen must produce. The correction: their rate check divided 2160 px by a 600-unit cycle to get 3.6 px/unit, but the last segment HOLDS. pteff03 moves over t=0..540 then sits at 1521; pteff03a moves over 0..630 of 720. Corrected: 4.00 and 4.06 px/unit, predicting 8.0 px/frame against their measured 6-7. That widens the gap from 7.2-vs-6.5 to 8.0-vs-6.5, so 'the rate matches the disc' does not survive the corrected span, and a lower emulator frame rate moves the prediction the wrong way. A cycle length is not a motion duration -- same family as a pivot anchor read as a drawn extent. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 53 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 7ba8f45e..b89bf6cd 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -182 sections. Search this before re-deriving anything. +183 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) @@ -193,6 +193,7 @@ dies, which is what this file is for. * [Their "the game may not draw these leaves" hypothesis — my curves say *sometimes*](#their-the-game-may-not-draw-these-leaves-hypothesis--my-curves-say-sometimes) * [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) ## P0 — the exporter, 2026-08-28 @@ -10382,3 +10383,53 @@ exists to preserve. is whether the condition it guards against is present, not how to remove the guard.** `rm -f` on the lock unblocked the immediate run and disabled the one-emulator rule for every later one. + +## Their draw-stream result checked against my export — three confirmations and one correction + +Their oracle run (settled EN title, one emulator verified by count) refutes their +own "the game may not draw these leaves" and confirms my `title` curve from the +game rather than from a render. Checking it against my export: + +✅ **Rotation.** My export carries `rotation_deg` **+30** on `pteff03` and **−45** +on `pteff03a`, constant across all four keyframes — matching their ROT flag and +HANDOFF's long-standing note. `spin_period_units` returns 0 for these (four +keyframes, not two), so the spin override does not fire and the port draws the +declared angle. + +✅ **Opposite directions.** `ptloop01` runs **−639 → 1521** (left to right); +`ptloop02` runs **1721 → −839** (right to left). Their strip A and strip B. + +✅ **Taller than the screen.** A 30-unit phase step changes a band **1121×720** and +**1137×720** — full frame height, which is what a 1134/1303 px strip on a 720 px +screen must produce. + +### 🔴 The correction: their rate check used the wrong span + +They wrote *"declared track −639..1521 = 2160 px over a 600-unit cycle = 3.6 +px/unit"*. **The last segment holds.** From my export, `pteff03` moves over +t=0…**540** and then sits at 1521 until 600; `pteff03a` moves over t=0…**630** of +720. + +| | motion span | px/unit | at 2 units/frame | +|---|---|---|---| +| their figure | 600 | 3.60 | 7.2 px/frame | +| **corrected** | **540** | **4.00** | **8.0 px/frame** | +| `ptloop02` | 630 | 4.06 | 8.1 px/frame | + +⚠️ **This weakens their confirmation rather than strengthening it.** 7.2 against a +measured 6–7 reads as agreement; **8.0 against 6–7 is a 20 % gap.** Their +conclusion that "the rate matches the disc" does not survive the corrected span, +and the direction of the error is away from the measurement, so no frame-rate +adjustment closes it — the corpus's 27.6–28.8 fps would make units/frame *larger* +and the prediction worse. + +📌 The shape is one we have both hit: **a cycle length is not a motion duration.** +Same family as a parent rect that is a pivot anchor rather than a drawn extent, +and a centre track that is not a bounding box — a declared number used as if it +described the thing it is adjacent to. + +⚠️ I am not claiming the port is right and the oracle wrong. The port draws what +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.