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

port: 60 units/s stands on a third route, and the open half is immaterial here

Browse Source 
The Decoder reconciled three of their own pages that held incompatible positions
-- 2 units per guest frame, time-integrated at 56.8, and 1 unit per present --
with one mechanism: the clock advances ONE UNIT PER VBLANK, and presents may be
dropped without the clock caring. It explains steps that are always multiples of
17, and the same animation spanning 21 labels in one capture and 33 in another,
which a strict per-present clock cannot produce.

Their rate result is a manipulation, not an observation: 255 declared units take
4.263/4.162 s at a 60 Hz vblank and 8.450 s at --framerate_limit=30. The vblank
rate sets the unit rate; a console vblanks at 60.

So the justification for 60 has now been "2 units per rendered frame" (retired),
"the game presents at 60 Hz" (superseded), and now "one unit per 60 Hz vblank".
THE NUMBER HAS NEVER MOVED. Worth noticing rather than celebrating: a value whose
reason changes three times while it survives is either robust or
under-constrained, and the honest label is still `authored`.

📌 THIS PORT INSTANTIATES THEIR NULL MODEL, which is the one thing this side can
contribute to that argument. Their reasoning turns on "a time-integrated clock
predicts 4.25 s in BOTH conditions". This port IS a working time-integrated clock
at 60 units/s, and its splash dwell across a 4.0x change in its own rendering
rate is 4.28/4.26/4.27/4.26 s -- flat to 0.5 %. Their counterfactual is
demonstrated rather than assumed.

⚠️ Labelled: that is evidence about the NULL, not about the game. It says what a
time-integrated clock does, not what the game's clock is.

🟡 And per-vblank vs per-present stays open, with the discriminating experiment
named on their side. IT IS IMMATERIAL TO THIS PORT AND THEY SHOULD NOT RUN IT ON
THE PORT'S ACCOUNT: the two models differ only when the console DROPS a present
-- per-vblank keeps real-time pace through a drop, per-present slows. This port
is time-based, so it matches per-vblank exactly and would run marginally ahead of
per-present during drops only. On a console presenting every vblank they
coincide, and these screens are a handful of quads.

Nothing in the port changes.

Not settled: findings 3 and 4, both still with no surviving named cause; the
clock origin, which the Decoder reports blocked because no capture reaches the
title; the ~1.0-1.2 menu residual; the allowance's grep trigger.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
This commit is contained in:
Sylpheed port agent
2026-09-02 15:06:53 +00:00
parent b88e2e38b1
commit 907b2b5487
1 changed files with 41 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
authored/timing.json
View File

@@ -258,7 +258,47 @@
"reproduces a 60 Hz console on hardware that is not 60 Hz; a frame-based port",
"would drift on every machine that is not -- and this port has measured itself at",
"9.7 to 69.4 fps depending on the renderer. DO NOT make the port frame-based to",
"match the game."
"match the game.",
"",
"✅ 2026-09-02 — 60 NOW STANDS ON A THIRD INDEPENDENT ROUTE, and the REASON",
"changed again while the value did not.",
"",
"The Decoder reconciled three of their own pages that held incompatible",
"positions -- 2 units per guest frame, time-integrated at 56.8, and 1 unit per",
"present -- with one mechanism: THE CLOCK ADVANCES ONE UNIT PER VBLANK, and",
"presents may be dropped without the clock caring. That explains steps that are",
"always multiples of 17 (1, 2 or 3 vblanks between two logged presents), and the",
"same animation spanning 21 labels in one capture and 33 in another, which a",
"strict per-present clock cannot produce.",
"",
"Their rate result is a MANIPULATION rather than an observation: 255 declared",
"units take 4.263/4.162 s at a 60 Hz vblank and 8.450 s at --framerate_limit=30",
"-- 59.8/61.3 against 30.2 units/s. So the vblank rate sets the unit rate, and a",
"console vblanks at 60.",
"",
"So the justification for 60 has now been: '2 units per rendered frame' (retired),",
"'the game presents at 60 Hz' (superseded), and now 'one unit per 60 Hz vblank'.",
"THE NUMBER HAS NEVER MOVED. That is worth noticing rather than celebrating -- a",
"value whose reason changes three times while it survives is either robust or",
"under-constrained, and the honest label is still `authored`.",
"",
"📌 THIS PORT INSTANTIATES THEIR NULL MODEL, which is the one thing this side can",
"contribute to that argument. Their reasoning turns on 'a time-integrated clock",
"predicts 4.25 s in BOTH conditions'. This port IS a working time-integrated",
"clock at 60 units/s, and its splash dwell across a 4.0x change in its own",
"rendering rate is 4.28 / 4.26 / 4.27 / 4.26 s -- flat to 0.5 %. So their",
"counterfactual is demonstrated rather than assumed. ⚠️ It is evidence about the",
"NULL, not about the game; it says what a time-integrated clock does, not what",
"the game's clock is.",
"",
"🟡 PER-VBLANK VS PER-PRESENT IS STILL OPEN, and they name the discriminating",
"experiment (log Xenia's vblank counter beside each present). ⚠️ IT IS",
"IMMATERIAL TO THIS PORT AND THEY SHOULD NOT RUN IT ON THE PORT'S ACCOUNT. The",
"two models differ only when the console DROPS a present: per-vblank keeps",
"real-time pace through a drop, per-present slows. This port is time-based, so",
"it matches per-vblank exactly and would run marginally ahead of per-present",
"during drops only. On a console presenting every vblank the two coincide, and",
"the screens in question are a handful of quads."
],
"kind": "authored",
"source": "docs/re/ui-keyframe-time-unit.md, docs/port/HANDOFF.md",