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

port: apply their linearity gate to my side of the ratio, and find an inversion

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 17:05:07 +00:00
parent 2a8caf03ff
commit 14a129ad75
1 changed files with 63 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
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 -->
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)
<!-- /INDEX -->
## 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.