From 3df042f10f856542c05fd0fd8084e32fce1637fd Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Tue, 1 Sep 2026 19:13:57 +0000 Subject: [PATCH] port: the re-opened rest() pair reaches nothing we draw, and 60 units/s is authored now MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two things, and both are about a label being wrong rather than a value. 1. THE rest() PAIR IS MOOT FOR THIS PORT, and that is measured rather than waited on. R1 re-opened both legs, 8 further claims died with the ⟨render-vs-capture⟩ instrument, and ScreenView.settle_time() uses rest.t -- so this port has been sitting on a question with no instrument behind either side. An element reaches the plateau-less fallback exactly when no two consecutive keyframes are identical. Census over all sixteen screens at every nesting depth: FIVE elements, three distinct -- palogo_sqex_eff, palogo_anima_eff, ptlogo_eff3, plus two region twins. And every one of them is transparent where its rest pose is read: publisher_logo t=140 not drawn: palogo_sqex_eff (transparent) developer_logos t=117 not drawn: palogo_anima_eff (transparent) title_jp --pose=rest not drawn: ptlogo_eff3 (transparent) So no rest() rule -- plateau-plus-dwell, `last`, `maxalpha` or `lastall` -- can change any pixel this port draws. That is why the splash rows score 0.01 % against their captures while resting on a heuristic nobody can currently defend: it is not load-bearing there. 🔴 And the brief's "the two splashes are the ONLY screens reaching that fallback" is narrowly refuted -- title_jp reaches it too, via ptlogo_eff3. Stated as a measurement of the CURRENT export: the record-layout fix re-timed keyframes corpus-wide and a plateau is exactly what that could create or destroy, so this does not say the claim was wrong when written. ⚠️ It does NOT rehabilitate rest.t, still wrong for transients like ptlogo_back2eff1 whose rest.t=54 is a two-frame flash's PEAK. That is a plateau case, not a fallback case, and nothing here touches it. 2. keyframe_units_per_second RECLASSIFIED measured -> authored. The value does not move; the label was false. The Decoder withdrew their guest-frame-rate finding the same day they published it, and this file carried `kind: measured` on its strength. Three routes now disagree -- withdrawn movie cadence 60, vblank ~120, title-plate-delay ~56 -- and at most one is right. 60 is kept, and not as a coin toss: the one leg of this file's own reasoning that never touched a frame count still brackets it. The transition quad is declared black for 12 units and the capture measured 0.14-0.30 s, i.e. 40-86 units/s. 60 sits inside; 120 does not; ~56 is 7 % away and inside the same bracket. 🔴 audit-kinds caught my first attempt at this, DANGLING: I cited guest-frame-rate-WITHDRAWN.md, which is on their branch and not in my checkout -- citing a document I cannot read. The check doing exactly its job. The withdrawal is now named in prose and labelled as coming from their message. 📌 Their method note is worth more than the number and is recorded in the file: their pre-registration named three ways the ruler could lie and guarded two; the third occurred, and a PERFECT 1.0000 is precisely what it produces. A clean result on an instrument whose key assumption is unguarded is not confirmation -- the cleanness may be the failure mode's own signature. Same family as this port's non-inverting latch check, which passed for the wrong reason until its control failed. Not settled: finding 3 still has no surviving cause; the ~1.0-1.2 menu residual against the additive-capable reference; pgloading_loop5's own residual; and the allowance still waits on its grep trigger. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX --- authored/timing.json | 48 +++++++++++- docs/port/BLOCKED.md | 1 + docs/port/rest-fallback-reaches-nothing.md | 87 ++++++++++++++++++++++ 3 files changed, 133 insertions(+), 3 deletions(-) create mode 100644 docs/port/rest-fallback-reaches-nothing.md diff --git a/authored/timing.json b/authored/timing.json index cab8b22c..2679c809 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -90,10 +90,52 @@ "screen' is a claim about the format, and the title's 56.8 does sit ~5 % off the", "splashes' 58-61. If a per-screen rate is real this file should carry a MECHANISM", "-- a field or a GamePart constant -- not two authored numbers. The Decoder has", - "'where the per-GamePart rate comes from' as its next item." + "'where the per-GamePart rate comes from' as its next item.", + "", + "🔴 2026-09-01 (later still) — RECLASSIFIED measured -> authored. THE VALUE DOES", + "NOT MOVE; THE LABEL WAS FALSE.", + "", + "The Decoder withdrew their guest-frame-rate finding the same day they published", + "it. ⚠️ THAT DOCUMENT IS NOT IN THIS CHECKOUT -- it is `guest-frame-rate-WITHDRAWN.md`", + "on their branch, named here in prose deliberately rather than in `source`:", + "`audit-kinds` flagged the first version of this entry DANGLING because I cited", + "a file I cannot read, which is exactly the check doing its job. The reading", + "below is from their message and is labelled as such.", + "It read the guest's presentation as 30 fps from a movie-frame ruler and", + "concluded 2 x 30 = 60. This file carried `kind: measured` on that strength.", + "`kind: measured` on the strength of it. It cannot any more.", + "", + "Three routes now disagree and at most one can be right:", + "", + " withdrawn movie cadence 60 units/s", + " vblank cadence (Xenia, 60 Hz) ~120", + " title-plate-delay, 120 units ~56 -- two runs agreeing to 6 ms", + "", + "⚠️ 60 IS KEPT ANYWAY, and it is not a coin toss between the three. The one leg", + "of this file's own reasoning that never touched a frame count still stands and", + "still brackets it: the transition quad is declared black for 12 units and the", + "capture measured the plateau at 0.14-0.30 s, i.e. 40-86 units/s. 60 sits inside", + "that; 120 does not. And ~56 is 7 % from 60, inside the same bracket.", + "", + "So the honest statement is: 60 is AUTHORED, bracketed by one surviving", + "frame-free measurement, and consistent with the nearest of the three live", + "routes. It is no longer 'measured', and anything that cited it as measured is", + "citing a withdrawal.", + "", + "📌 THE METHOD NOTE IS WORTH MORE THAN THE NUMBER, and it is the Decoder's: their", + "pre-registration named three ways the ruler could lie and guarded two. The third", + "occurred, and a PERFECT 1.0000 is exactly what it produces -- a triple buffer", + "rotating once per present gives run-length 1 at any frame rate. Both guards", + "tested how the buffer was READ, neither tested whether a change meant a decode.", + "", + " A clean result on an instrument whose key assumption is unguarded is not", + " confirmation. The cleanness may be the failure mode's own signature.", + "", + "Same family as this port's non-inverting latch check, which passed for the wrong", + "reason until its control failed." ], - "kind": "measured", - "source": "/reborn docs/port/HANDOFF.md Q1, docs/re/ui-keyframe-time-unit.md, docs/re/units-per-second-measured.md", + "kind": "authored", + "source": "docs/re/ui-keyframe-time-unit.md, docs/port/HANDOFF.md", "ramp": "linear", "ramp_why": [ "Also HANDOFF Q1, and part of the same measurement: the fade lands on the", diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index 26dd084d..1dc6289a 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -174,6 +174,7 @@ submitted per frame. | **H5** | ✅ **CLOSED, and now confirmed from the other side too.** `pgloading_loop5` is additive, which is why `build_12`/`build_15` differed and `build_00`/`build_01` did not — the latter never draw it. With the reference taught the additive blend (`formats-pin-2026-09-01b`) **`build_00`/`build_01` go DIFFERS → OK** (`over3` 3422 → 0) and `build_12`/`build_15` fall 0.0772 → 0.0463. | ⚠️ They do **not** return to their pre-change 0.0368, so `pgloading_loop5` carries a small residual of its own beyond the blend — recorded, not chased. 📌 The Decoder nearly reported my H5 claim as a contradiction because `loop5` is not a sprite: it is an **element**, `pgloading_loop5.rat`, resolving to sprite `pgloading_ring.t32`. **The element/sprite name split is a trap for any census keyed by sprite name** — worth knowing before writing one. | | **H6** | ✅ **CLOSED — and my counter-example FAILED, which is the honest outcome.** The blend map is deleted; the exporter emits `blend_additive` per element from `T8aD +0x04` bit `0x02`. | ❌ I reported `pteff10` as a possible counter-example. **It is not** — the oracle measures it additive on `main_menu` in all three menu sessions, every frame, and my premise was a stale coverage table sitting upstream of its own correction. **I treated a summary as the log.** The 10.88 → 13.02 is characterised rather than excused: max difference **32 levels** over 36 % of the frame, zero pixels past 60 — broad and shallow, which is what moves an **area-weighted** RMSE 20 % while being invisible to an eye. Not excluded from the metric, deliberately: the reason to exclude turned out to be false. See [`blend-decoded-adoption.md`](blend-decoded-adoption.md). | | **H7** | ✅ **CLOSED 2026-09-01 — WITHDRAWN BY THE DECODER, same day.** `splash-rate-withdrawn.md` / `1e7343e`: *"WITHDRAW 'the unit rate is per-GamePart' — it was the emulator's frame rate"*, and the section carrying it is struck. §1 of `splash-declared-vs-captured.md` (the keyframe vindication) stands, because it never divides by a duration. | The port never moved, so nothing had to be undone. The refutation is kept in [`splash-rate-contradiction.md`](splash-rate-contradiction.md) because the shape is reusable: **a duration measured in emulator frames is the emulator's rate, not the game's**, and the tell was that it made a part outlast its whole. `keyframe_units_per_second` remains **60**, now unchallenged on the splashes. | +| **H8** | 🟢 **NOT AN ASK — a bound, recorded so nobody spends an iteration on it.** The re-opened `rest()` pair **cannot change a single pixel this port draws.** Only **five elements in the whole export** reach the plateau-less fallback — `palogo_sqex_eff`, `palogo_anima_eff` and `ptlogo_eff3` (plus two region twins) — and **every one is fully transparent** at the instant anything reads its rest pose. | 🔴 **And the brief's claim that the two splashes are the ONLY screens reaching it is narrowly refuted: `title_jp` does too.** Stated as a measurement of the current export — the record-layout fix re-timed keyframes corpus-wide and a plateau is exactly what that could create or destroy, so this does not say the claim was wrong when written. ⚠️ It does **not** rehabilitate `rest.t`, which is still wrong for transients like `ptlogo_back2eff1` — that is a *plateau* case, untouched. See [`rest-fallback-reaches-nothing.md`](rest-fallback-reaches-nothing.md). | ## Still open — these block work diff --git a/docs/port/rest-fallback-reaches-nothing.md b/docs/port/rest-fallback-reaches-nothing.md new file mode 100644 index 00000000..872426b5 --- /dev/null +++ b/docs/port/rest-fallback-reaches-nothing.md @@ -0,0 +1,87 @@ +# The re-opened `rest()` pair cannot change a single pixel this port draws + +**Status:** ✅ **measured, and it bounds a question rather than answering it.** +Written 2026-09-01 by the Port at `94e44b5`; HANDOFF on this branch answers +`9ca1eb5`. + +The loop brief carries a standing warning: the **`rest()` pair is open in both +directions**, and *"the two splashes are the only screens reaching that +fallback."* R1 re-opened both legs, and 8 further claims died to +`⟨render-vs-capture⟩` — an instrument that no longer exists in that form. + +`ScreenView.settle_time()` uses `rest.t`, so this port has been sitting on a +question with no instrument behind either leg. **It turns out not to matter, and +that is worth establishing rather than waiting on.** + +## What reaches the fallback + +`Element::rest()` takes the longest **plateau** — a run of consecutive identical +keyframes — and falls back to the longest dwell when there is none. So an element +reaches the fallback exactly when no two consecutive keyframes are identical. + +Census over all sixteen exported screens, at every nesting depth: + +| screen | elements reaching the fallback | +|---|---| +| `publisher_logo` (and `_r`) | `palogo_sqex_eff` | +| `developer_logos` (and `_r`) | `palogo_anima_eff` | +| **`title_jp`** | **`ptlogo_eff3`** | + +**Five elements in the whole export**, and only three distinct ones. + +## 🔴 The brief's claim is narrowly refuted + +*"The two splashes are the **only** screens reaching that fallback"* — `title_jp` +reaches it too, through `ptlogo_eff3`. + +⚠️ Stated as a measurement of the **current** export and nothing more. That +sentence may have been true when written: the record-layout fix re-timed +keyframes across the corpus, and a plateau is exactly the kind of thing it could +create or destroy. This does not say the claim was wrong when made; it says it is +not true now. + +## And every one of them is invisible where it is read + +The fallback only matters if the element it picks a pose for is actually drawn. +Asked of the port directly, at each screen's own settled instant: + +``` +publisher_logo t=140 drew 2 not drawn: palogo_sqex_eff (transparent at t=140) +developer_logos t=117 drew 4 not drawn: palogo_anima_eff (transparent at t=117) +title_jp --pose=rest drew 23 not drawn: ptlogo_eff3 (transparent at rest) +``` + +**Every element that reaches the `rest()` fallback is fully transparent at the +instant anything reads its rest pose.** + +> So no `rest()` rule — the current plateau-plus-dwell, `last`, `maxalpha` or +> `lastall` — can change any pixel this port draws. The pair is open, and for the +> port it is **moot**. + +That is why the splash rows score 0.01 % against their captures while resting on +a heuristic nobody can currently defend: the heuristic is not load-bearing there. + +## Why this was worth an iteration rather than a wait + +The three elements are the **pre-blurred companion glows** and one title sparkle +— transients that exist to be seen briefly and then leave. An element with no +plateau is, almost by definition, one that never holds still, and a screen's +settled instant is chosen to be where things are holding still. The two +conditions are close to mutually exclusive, which is why the intersection is +empty and why it was worth checking rather than assuming either way. + +⚠️ **This does not rehabilitate `rest.t`.** It is still the wrong answer for +transients — `ptlogo_back2eff1` is a two-frame flash whose `rest.t = 54` is the +flash *peak*, and `rest()` would leave five of those burning at once on the +title. That is a **plateau** case, not a fallback case, and it is untouched by +anything here. + +## What this does not claim + +* That the `rest()` pair is settled. It is open, and this page does not touch it. +* That `rest.t` is right. `settle_time()` still takes the maximum over elements, + and what that means for *when the boot advances* is a separate question — a + screen still plays to `exit_time()` afterwards, so the dwell is governed by + that, not by `rest.t`. **Measured for the drawn picture; argued for the dwell.** +* Anything about the other 7 claims R1 re-opened against + `⟨render-vs-capture⟩`. Not mine to re-derive.