diff --git a/authored/flow.json b/authored/flow.json index c07e6147..02f08615 100644 --- a/authored/flow.json +++ b/authored/flow.json @@ -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": { diff --git a/authored/timing.json b/authored/timing.json index 70609246..b03c649b 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -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": { "_": [ diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index e9a33379..45295c10 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -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**. diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index e887f3d4..0186b287 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -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. diff --git a/port/scripts/boot.gd b/port/scripts/boot.gd index 8208ea9e..fbf6ffe8 100644 --- a/port/scripts/boot.gd +++ b/port/scripts/boot.gd @@ -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