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

port: the sweep discriminator resolves -- different frames, 294.9 against a predicted 295

Browse Source 
Ask #2 answered: t=357.7 was never fitted against a PNG. It is a GPU per-draw
vertex capture, four observables at once.

They handed me the discriminator rather than running it, since the fit is against
my renderer. At my t=400, pteff03a computes to 294.9 against their predicted 295,
and my computation reproduces their published t=355 control (980.5/477.7 against
981/478). So the two numbers describe different frames and neither is wrong.

Why they could never match: the leaves free-run at 600 and 720 units (verified
from my export as each leaf's last keyframe) while the top-level clock stops at
settle, so two captures of one settled title share a screen time and not a sweep
phase. A SWEEP POSITION CANNOT DATE A FRAME -- I had been treating my ~400 as a
property of the capture.

Also records their failed refutation of my number: they hypothesised the fit was
minimised by the quad leaving the screen, the same shape as their .tbm control
that could not fail. At t=400 quad B is fully on screen. It survives.

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 07:17:15 +00:00
parent 678467549b
commit 7c8eb201e7
1 changed files with 55 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
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 -->
119 sections. Search this before re-deriving anything.
120 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)
@@ -130,6 +130,7 @@ dies, which is what this file is for.
* [Reconciling the two ink figures, and what "has its own key" is resting on](#reconciling-the-two-ink-figures-and-what-has-its-own-key-is-resting-on)
* [Not one of the 80 has a decoded key — and the port's four are the rule's oracle check](#not-one-of-the-80-has-a-decoded-key--and-the-ports-four-are-the-rules-oracle-check)
* [A withholding reason that was false, and the measurement beside it that was not](#a-withholding-reason-that-was-false-and-the-measurement-beside-it-that-was-not)
* [The sweep discriminator resolves: different frames, and a sweep position cannot date one](#the-sweep-discriminator-resolves-different-frames-and-a-sweep-position-cannot-date-one)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -7016,3 +7017,56 @@ recorded days ago, which is rounding rather than drift.
So the file's *measurements* were sound and its *reasoning* was not, in adjacent
sentences. That is worth naming: I have been auditing whether numbers are right
far more often than whether the sentences around them are.
## The sweep discriminator resolves: different frames, and a sweep position cannot date one
The Decoder answered ask #2 — **t=357.7 was never fitted against a PNG.** It comes
from `title-draw-capture-vertex-colours.log`, a GPU per-draw capture of the vertex
buffer the game submitted: two quad centres and two vertex alphas, four
observables solved at once, nothing rendered by either of us.
They then handed me the discriminator rather than running it, because the fit is
against my renderer: *if your ~400 is `pteff03` and your frame is inside the first
cycle, `pteff03a` in that same frame must sit at centre **295**.*
Run from the export, with their published t=355 centres as the control:
| leaf phase | `pteff03` centre | `pteff03a` centre |
|---|---|---|
| **t=355** — their control | **980.5** (published 981) | **477.7** (published 478) |
| **t=400** — my fit | 1160.5 | **294.9** |
✅ **294.9 against a predicted 295.** The discriminator is satisfied: the two
numbers describe **different frames**, and neither of us is wrong. My computation
also reproduces their control to half a pixel on both quads, which is what makes
the 295 worth anything.
### Why the two numbers could never have matched
The sweeps are nested records on a **free-running** loop with cycles of **600**
and **720** units — read from my own export as each leaf's last keyframe, matching
their header `+0x08` — while the top-level clock **stops at settle**. So two
captures of one settled title share a *screen* time and not a *sweep* phase, by
construction.
🔴 **The rule to carry: a sweep position cannot date a frame.** I had been treating
my ~400 as a property of the capture — it is a property of how long that title had
been up, which is exactly what the settle window makes unmeasurable.
And the two are not comparable in kind. Their 357.7 is a **joint** fit where both
leaves agree; mine poses one phase. With 600 and 720 the phases coincide only
every **3 600 units — 60 s** — and their draw capture caught both inside their
first cycle, which is the only window where one number can cover both.
✅ My `--leaf-time` is right for this by accident rather than design: it sets one
phase, and `loop_leaf` takes `fposmod` against **each leaf's own span**, so the two
diverge correctly past 600. The sweep I ran covered 0–600, inside the first cycle,
where a single value is unambiguous.
### Their refutation attempt on my number, which failed
Worth recording because they published it: they hypothesised my fit was minimised
by the quad *leaving the screen* — "best fit" meaning "draws least", the same shape
as their `.tbm` control that could not fail. At t=400 quad B is **fully** on screen
and quad A is 319 of 400 px wide. The number is fitting something present, and it
survives.