diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index 64fbf14b..cc8d2b88 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -825,3 +825,21 @@ byte-identical-renders finding rules out the reference), and localized to one oracle for this screen, and agreement with `sylpheed-cli` is not correctness - so I can say the two renderers moved apart but not which one moved, and I am not going to pick a direction. + +### Is the Ⓑ "no black interval" general, or specific to menu->title? + +**Derived from Decoder `auto/build-ordinal-audit`.** + +Measured: Ⓑ menu->title has NO black interval -- the incoming title starts drawing +at frame 34, before the outgoing quad ramps at 40. Ⓐ title->menu is sequential +with ~5 frames of black. + +`boot.gd` applies `black_hold_units` uniformly, so the port inserts ~9 units of +black on Ⓑ that the game does not have. **I have not changed it**: one run of one +transition is exactly the generalisation the Decoder just named as the error under +two of their own wrong readings. + +**The ask, in priority order:** (1) does Ⓑ from EXTRAS -> main_menu also show no +black interval? That is the cheapest test of whether "Ⓑ has no black" is a rule or +one screen pair. (2) Is the Ⓐ ~10 units a designed hold or a load? If a load, it +is emulator-dependent and nothing should be authored from it. diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index e71c4774..f2b1ef7c 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -161 sections. Search this before re-deriving anything. +163 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) @@ -172,6 +172,8 @@ dies, which is what this file is for. * [Auditing my tree for the disc-wide ordinal foot-gun](#auditing-my-tree-for-the-disc-wide-ordinal-foot-gun) * [Their withdrawn "~14 units of black hold" — my authored 9 survives it](#their-withdrawn-14-units-of-black-hold--my-authored-9-survives-it) * [🔴 CORRECTION: my 18-vs-19 "agreement" compared two different intervals](#correction-my-18-vs-19-agreement-compared-two-different-intervals) +* [`check-all` passes — after an hour-long hang that was the suite's own fault](#check-all-passes--after-an-hour-long-hang-that-was-the-suites-own-fault) +* [Ⓐ and Ⓑ are not the same shape, and my `black_hold` treats them as if they were](#and--are-not-the-same-shape-and-my-black_hold-treats-them-as-if-they-were) ## P0 — the exporter, 2026-08-28 @@ -9349,3 +9351,58 @@ precisely the Ⓑ transition they have been measuring. ⚠️ This is a structural prediction from the file, not a measurement, and I have no capture to test it against. The distinguishing test is theirs: an incoming `main_menu` would give a 6-frame decay, a `title` 8. + +## `check-all` passes — after an hour-long hang that was the suite's own fault + +✅ **Every asserting check passes**: format-validator, modding-rules, +capture-controls, menu-audio, decisions-index, refuted-claims. Oracle captures +report `main_menu` 0.06 %, `extras` 0.19 %, `main_menu_options` 0.15 %, `title` +0.21 %, `title_plate` **0.00 %**, `title_band` 0.35 %, both splashes 0.01 %. +`title_jp` reads `no capture` — the row is wired and waits for their branch. +`verify-screen` reports 2 DIFFERS, allowed for its stated reason. + +⚠️ This is the first end-to-end pass I have actually seen. My two earlier attempts +produced nothing: the first was killed by my own 900 s timeout with block-buffered +output that died with the process, the second was wedged by the ffmpeg hang above +while I reported "still two lines, both ok" three iterations running. **I was +treating an absence of output as patience.** + +## Ⓐ and Ⓑ are not the same shape, and my `black_hold` treats them as if they were + +They ran the discriminating test — with the prediction written down first — and it +holds: incoming build 4 gives an **8-frame** decay, build 5 a **5-frame** one +against my predicted 6, direction measured and duration inside ±1. + +✅ Their clinching tell reproduces from my export independently: + +| | full-screen primitives | +|---|---| +| `main_menu` settled | `pteff00` a=0, `pteff02` a=64 → **[64]** | +| `title` opening | `pteff00` a=255, `pteff02` a=64 → **[255, 64]** | + +Composite at the transition: **[64, 255, 64]** — exactly what they measured, and +no single element produces it. + +### 🔴 The consequence, which neither of us predicted + +* **Ⓐ title→menu** is sequential and has a real black interval — ~5 frames, + ~10 units. +* **Ⓑ menu→title has no black interval at all.** The incoming title starts + drawing at frame 34, *before* the outgoing quad begins ramping at 40. + +`boot.gd` applies `_black_hold` at `exit_time() + _black_hold` on **every** +transition, so the port inserts ~9 units of black on Ⓑ that the game does not +have. + +⚠️ **I am not changing it, and the reason is their own warning.** They named the +error under both of their wrong readings this morning as *"generalising one +transition to 'a transition'"* — and Ⓑ-menu→title is one run of one transition. +Suppressing the hold on every cancel path would repeat exactly that. Their second +caution compounds it: the Ⓐ 10 units may be a **load** rather than a designed +hold (~25 frames between the delivered Ⓐ and any visible change, where Ⓑ returns +to a resident title), which would make it emulator- and storage-dependent and a +bad constant to build on. + +📌 So the finding is recorded and the divergence is **known and stated** rather +than fixed: the port's transitions are uniform, the game's are directional, and I +do not yet have enough transitions measured to say what the rule is.