fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: check their draw-stream result against my export -- three confirmations, one correction

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 16:33:12 +00:00
parent b492a639d1
commit 93d69e6148
1 changed files with 52 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
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)
<!-- /INDEX -->
## 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.