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

port: withdraw 'the boot is known too fast' -- the splash dwells are declared and the port already played them

Browse Source 
The Decoder measured both splashes over 3 cold boots: publisher t=0..255,
developer t=0..210, the developer agreeing with wall clock to 1.1%. The port
emits each declared value plus the 9-unit black hold, exactly. No code change.

My error was the generalisation, not the arithmetic: build 4 is the title, whose
exit is caused from outside its timeline, so it holds; a splash's exit is caused
by nothing, so it plays out. I used the one boot screen the port is unaffected
by to overturn the two it governs. Declining to scale by 9x while adopting the
conclusion that implied was half a caution.

Also refutes their two splash boundaries as not comparably anchored: 2.237 vs
2.414 units/frame in one boot, and the publisher has a glow symmetric with the
developer's three.

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-29 21:32:08 +00:00
parent 2e29572b02
commit 77292e98fc
5 changed files with 153 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
authored/flow.json
View File

@@ -44,32 +44,37 @@
],
"dwell": {
"_": [
"NOT SET -- and the reason is no longer the one this key used to give.",
"NOT SET -- because the dwell is DECLARED, and the port already plays it.",
"",
"🔴 It used to say \"a screen's dwell is its OWN keyframe group\". That is",
"REFUTED, measured in the draw stream by the Decoder on 2026-08-29",
"(docs/re/structures/ui-clock-freezes-at-settle.md): GP_TITLE build 4 declares",
"t = 0..269, about 120 presented frames at that capture's pacing, and the real",
"dwell lasted ~1100 -- roughly NINE TIMES its own timeline. The top-level clock",
"advances through the build-in, STOPS inside the settle window, and holds. The",
"exit ramp is not on a timer; it plays when something makes the screen leave.",
"This key has now been wrong in two opposite directions, and the second was",
"mine, so both are recorded.",
"",
"So the group is not the dwell, and a port that leaves when the group ends is",
"not reproducing the disc's pacing -- it is leaving at the moment the game",
"starts waiting.",
"It first said 'a screen's dwell is its OWN keyframe group'. Then GP_TITLE",
"build 4 was measured dwelling ~1100 presented frames against a declared ~120,",
"and I generalised that into 'the boot is KNOWN TOO FAST on both splashes'.",
"🔴 THAT WAS AN OVER-CORRECTION and it is withdrawn. Build 4 is the title: its",
"exit is caused by something outside its timeline, so it holds. A splash's exit",
"is caused by nothing, so it plays its declared timeline and leaves. The title",
"is the exception, not the rule, and one screen was never enough to overturn",
"the other two.",
"",
"The DECISION is unchanged and still right: hold zero extra rather than invent",
"a number. What changes is what may be claimed for it. The boot is KNOWN TOO",
"FAST on every screen it plays out, by an amount nobody has measured. It is not",
"'the disc's own pacing'; that phrasing said the port was faithful here, and it",
"is not.",
"MEASURED 2026-08-29 by the Decoder over 3 cold boots",
"(docs/re/structures/boot-splash-dwells-are-declared.md):",
"",
"⚠️ Only build 4 has been measured, and build 4 is the one screen where the port",
"is unaffected -- it is the boot's end state and holds indefinitely anyway. The",
"two screens this actually governs, publisher_logo and developer_logos, are",
"UNMEASURED. Nothing here may be read as a number for them.",
" publisher declared t=0..255 = 4.250 s corpus 4.30 / 4.60 / 4.37",
" developer declared t=0..210 = 3.500 s corpus 3.51 / 3.50 / 3.37",
"",
"If a capture ever times the real boot, this is where that number goes."
"The developer agrees to 1.1 %, two of its three runs to 0.3 %. The port emits",
"4.400 s and 3.650 s -- each declared value plus the 9-unit black hold, exactly.",
"So the pacing was right all along and nothing changes in the code.",
"",
"🔴 AND THE UNIT STAYS UNITS, NOT SECONDS. The same two dwells timed in the",
"Decoder's own container came out 15-20 % LONGER than both the declared values",
"and the corpus -- same disc, same timeline -- and three independent readings",
"of that container's rate disagree with each other. A seconds figure records",
"one emulator's pacing on one run. The units are on the disc. If anything ever",
"goes in `dwell` it is an extra hold in UNITS, and only for a screen that is",
"measured to wait beyond its group."
]
},
"navigation": {

47
authored/timing.json
View File

@@ -26,32 +26,37 @@
],
"dwell_seconds": null,
"dwell_why": [
"NOT SET -- and the reason is no longer the one this key used to give.",
"NOT SET -- because the dwell is DECLARED, and the port already plays it.",
"",
"🔴 It used to say \"a screen's dwell is its OWN keyframe group\". That is",
"REFUTED, measured in the draw stream by the Decoder on 2026-08-29",
"(docs/re/structures/ui-clock-freezes-at-settle.md): GP_TITLE build 4 declares",
"t = 0..269, about 120 presented frames at that capture's pacing, and the real",
"dwell lasted ~1100 -- roughly NINE TIMES its own timeline. The top-level clock",
"advances through the build-in, STOPS inside the settle window, and holds. The",
"exit ramp is not on a timer; it plays when something makes the screen leave.",
"This key has now been wrong in two opposite directions, and the second was",
"mine, so both are recorded.",
"",
"So the group is not the dwell, and a port that leaves when the group ends is",
"not reproducing the disc's pacing -- it is leaving at the moment the game",
"starts waiting.",
"It first said 'a screen's dwell is its OWN keyframe group'. Then GP_TITLE",
"build 4 was measured dwelling ~1100 presented frames against a declared ~120,",
"and I generalised that into 'the boot is KNOWN TOO FAST on both splashes'.",
"🔴 THAT WAS AN OVER-CORRECTION and it is withdrawn. Build 4 is the title: its",
"exit is caused by something outside its timeline, so it holds. A splash's exit",
"is caused by nothing, so it plays its declared timeline and leaves. The title",
"is the exception, not the rule, and one screen was never enough to overturn",
"the other two.",
"",
"The DECISION is unchanged and still right: hold zero extra rather than invent",
"a number. What changes is what may be claimed for it. The boot is KNOWN TOO",
"FAST on every screen it plays out, by an amount nobody has measured. It is not",
"'the disc's own pacing'; that phrasing said the port was faithful here, and it",
"is not.",
"MEASURED 2026-08-29 by the Decoder over 3 cold boots",
"(docs/re/structures/boot-splash-dwells-are-declared.md):",
"",
"⚠️ Only build 4 has been measured, and build 4 is the one screen where the port",
"is unaffected -- it is the boot's end state and holds indefinitely anyway. The",
"two screens this actually governs, publisher_logo and developer_logos, are",
"UNMEASURED. Nothing here may be read as a number for them.",
" publisher declared t=0..255 = 4.250 s corpus 4.30 / 4.60 / 4.37",
" developer declared t=0..210 = 3.500 s corpus 3.51 / 3.50 / 3.37",
"",
"If a capture ever times the real boot, this is where that number goes."
"The developer agrees to 1.1 %, two of its three runs to 0.3 %. The port emits",
"4.400 s and 3.650 s -- each declared value plus the 9-unit black hold, exactly.",
"So the pacing was right all along and nothing changes in the code.",
"",
"🔴 AND THE UNIT STAYS UNITS, NOT SECONDS. The same two dwells timed in the",
"Decoder's own container came out 15-20 % LONGER than both the declared values",
"and the corpus -- same disc, same timeline -- and three independent readings",
"of that container's rate disagree with each other. A seconds figure records",
"one emulator's pacing on one run. The units are on the disc. If anything ever",
"goes in `dwell` it is an extra hold in UNITS, and only for a screen that is",
"measured to wait beyond its group."
],
"looping_focus_records": {
"_": [

38
docs/port/BLOCKED.md
View File

@@ -431,31 +431,21 @@ without it, against a measured order. See `DECISIONS.md`.
---
## The two splash dwells, now known-wrong rather than merely unmeasured
## ~~The two splash dwells~~ — ✅ answered 2026-08-29, and the row was my over-correction
*Derived from HANDOFF `9ca1eb5`. Raised 2026-08-29 by the Decoder's clock-freeze
measurement on build 4.*
*Derived from HANDOFF `9ca1eb5`. Closed by the Decoder over 3 cold boots.*
The port advances from `publisher_logo` and `developer_logos` **the instant each
group settles** — t=235 (3.92 s) and t=190 (3.17 s). That was filed as "the
disc's own pacing". It is not: on the one screen anybody has measured, the game
held for roughly **nine times** the declared timeline, because the top-level
clock stops at the settle window and waits for something to make the screen
leave.
**The dwells are declared on the disc** — publisher t=0…255, developer t=0…210 —
and the port was **already playing them**, each plus the 9-unit black hold, to
4.400 s and 3.650 s. The developer's declared value agrees with wall clock to
**1.1 %**.
⚠️ This does **not** license scaling the splashes by nine. Build 4 is the title,
and there is no reason a title's wait and a logo splash's wait are the same
quantity — the title's is plausibly "until the attract timer fires", which no
splash has. **A ratio measured on one screen is not a unit of pacing.**
🔴 So this row should never have been filed. I generalised build 4's ~9× hold
onto two screens it does not govern: the title's exit is caused from outside its
timeline, a splash's is caused by nothing. See `DECISIONS.md` — the withdrawal is
recorded there rather than only struck here.
What would settle it: **a capture timing the real boot** — wall-clock from the
first frame of the publisher wordmark to the first frame of the developer logos,
and from there to the intro. Two timestamps answer it completely, and it needs no
frame analysis. The numbers go in `authored/flow.json` `dwell`, which has been
sitting empty and correctly shaped for this since P3.
🔴 Bounded by the Decoder's own blocker: a single Ⓐ press on the title faults the
guest in their container, so **menu-side dynamic RE is unavailable there**. The
boot timing above needs no button press and should survive that — three runs in
the same session that pressed nothing all completed — but it is their call
whether it is safe to attempt.
⚠️ And the ask itself was wrong-shaped: I asked for **two wall-clock timestamps**.
The Decoder's own container timed these same dwells 15–20 % long, so a seconds
figure records one emulator's pacing. Anything that ever goes in
`authored/flow.json` `dwell` is in **units**.

75
docs/port/DECISIONS.md
View File

@@ -5167,3 +5167,78 @@ unaffected** — it is the boot's end state and holds indefinitely. The two scre
this actually governs, `publisher_logo` and `developer_logos`, have no measured
dwell at all. The port's boot is **known too fast on both, by an unmeasured
amount**. Nothing here is a number for them.
## 🔴 Withdrawn — "the boot is known too fast". The splash dwells are declared, and the port was already playing them
Last iteration I took the Decoder's build-4 measurement — declared ~120 presented
frames, dwelled ~1 100 — and wrote into three files that the port's boot is
**"known too fast on both splashes, by an unmeasured amount"**. That is
**withdrawn**. It was wrong, and the way it was wrong is the interesting part.
They then measured the splashes directly, over 3 cold boots:
| splash | declared | at 60 units/s | corpus wall clock |
|---|---|---|---|
| publisher (entries 10, 13) | t = 0…**255** | 4.250 s | 4.30 / 4.60 / 4.37 |
| developer (entries 11, 14) | t = 0…**210** | 3.500 s | 3.51 / 3.50 / 3.37 |
The developer agrees to **1.1 %**, two of its three runs to 0.3 %. And the port
emits **4.400 s and 3.650 s** — each declared value plus the 9-unit black hold,
exactly. ✅ **The pacing was right the whole time and no code changes.**
### What I actually did wrong
Not the arithmetic — the generalisation. Build 4 is the **title**, whose exit is
caused by something outside its timeline, so it holds. A splash's exit is caused
by nothing, so it plays its declared timeline and leaves. **The title is the
exception, not the rule.** I had one screen, it was the one screen in the boot the
port is structurally unaffected by, and I used it to overturn the two it governs.
I wrote at the time that a ratio from one screen is not a unit of pacing, and
declined to scale the splashes by nine. That refusal was right and is the only
reason this cost nothing but documentation. But refusing to apply the number
while adopting the *conclusion* it implied was half a caution: I still let one
screen's behaviour rewrite what the port claimed about two others. **The correct
move was to file build 4 as measured and leave the splashes alone**, which is
what the file now says.
### And the unit stays units
🔴 The Decoder's own container timed those same two dwells **15–20 % longer** than
both the declared values and the corpus — same disc, same declared timeline — and
three independent readings of that container's frame rate disagree with each
other. A seconds figure is one emulator's pacing on one run. The declared units
are on the disc. `authored/flow.json` `dwell` therefore takes **units**, and only
for a screen measured to wait beyond its group.
This also retires the "two timestamps would settle it" ask I filed: timestamps
were the wrong thing to author, and the measurement's own result says so.
## Refutation attempt — their two splash boundaries are not anchored the same way
Their draw stream reports *"publisher wordmark frames 6–119"* and *"developer
glows 123, wordmarks 140–209"*. Taking those spans against the declared groups:
| splash | declared units | their frames | units / frame |
|---|---|---|---|
| publisher | 255 | 6…119 = 114 | **2.237** |
| developer | 210 | 123…209 = 87 | **2.414** |
**Within one continuous boot, on one guest, those should be the same number.**
They differ by **7.9 %**, and the discrepancy runs the same direction as the
error split they have open — publisher +4.1 % where the developer is 1.1 %.
The file suggests why, and it is not the guest's clock: **the two boundaries are
anchored on different elements.** The developer span starts at its *glows*; the
publisher span is reported as starting at its *wordmark*. Those are 15 units
apart — every wordmark on both splashes is `alpha > 0` from t=16, every glow from
t=1 — and the publisher **has a glow**, `palogo_sqex_eff`, visible t=1…44,
structurally identical to the developer's three. So either frame 6 is the
publisher's glow and is mislabelled, or the publisher span genuinely starts 15
units later than the developer's and the two are not comparable quantities.
⚠️ I cannot tell which from here — it is their log, and the answer is one grep for
`palogo_sqex_eff` in it. Recording it because a 7.9 % internal inconsistency and
an unexplained 4.1 % error on the same screen are more likely one problem than
two. ⚠️ It also does **not** touch the corpus comparison, which is a separate
instrument (3 cold boots, not this draw log); their 4.1 % may still be real.

25
port/scripts/boot.gd
View File

@@ -350,21 +350,20 @@ func _process(delta: float) -> void:
return
# A screen holds at `rest` until it has arrived, then plays itself out and
# the next one begins. Nothing waits on a timer the disc does not carry.
# the next one begins. Nothing waits on a timer the disc does not carry --
# and for the two splashes that is now MEASURED to be right, not merely
# cautious. Their dwells are declared: publisher t=0..255, developer
# t=0..210, corroborated over 3 cold boots to 1.1 % on the developer. The
# port emits each declared value plus the 9-unit black hold, exactly.
#
# 🔴 That is a choice made for lack of a number, NOT a reproduction of the
# game's pacing, and this comment used to claim otherwise. Measured in the
# draw stream (docs/port/DECISIONS.md, "The clock freezes at settle"): the
# top-level clock advances through the build-in, STOPS inside the settle
# window and holds -- build 4 declares ~120 presented frames and dwelled
# ~1100. The exit ramp is not on a timer; it plays when something makes the
# screen leave. Leaving AT settle, as the line below does, is leaving at the
# instant the real game starts waiting.
# ⚠️ The title is the exception and it is why this loop leaves the LAST screen
# alone: build 4 declares ~120 presented frames and dwells ~1100, because its
# exit is caused by something outside its timeline. A splash's exit is caused
# by nothing, so it plays out. Do not generalise either one to the other --
# a previous revision of this comment did, in both directions.
#
# The structure here is right and the duration is wrong: `_advance` is
# already caused by the next screen rather than scheduled, which is what the
# measurement says the game does. What is missing is the hold, and it goes
# in `authored/flow.json` `dwell` the day a capture times one.
# `_advance` is CAUSED by the next screen arriving, never scheduled off a
# timer, which is what the draw stream says the game does.
if view.holding and view.time_units >= view.settle_time():
# The LAST screen in the sequence keeps holding. A screen plays itself
# out because something is taking its place; nothing is taking the