From 891c38e87e0b2842b137af2123543faa34f5b195 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 12 Sep 2026 13:24:27 +0000 Subject: [PATCH] re: fix two stale rows -- NEW GAME's destination, and my own repeat claim No emulator-requiring state/approved item was open this iteration (issues #1, #3, #5 all landed and moved to state/needs-human; #25 still awaits approval). Used the gap for corpus consistency instead of idling, per the same "a correction that never reaches the row someone reads" failure this project keeps naming. 1. menu-navigation-semantics.md's own Q4 table still said NEW GAME was "not tested" and its own prose said it was "deliberately not pressed" and hangs the emulator -- both refuted BY THIS SAME PAGE on 2026-08-28, 34 lines further down ("NEW GAME -- measured ... it is not a hang. It opens DIFFICULTY then SELECT DATA"). The correction never propagated backward into the table or the status line above it, so a reader stopping at either would come away with the wrong (and already-refuted) answer. Fixed in place, struck rather than deleted, with the actual destination and an honest note that DIFFICULTY has no id-table name match (already refuted separately) while SELECT DATA plausibly matches GP_SELECT_STORAGE as a fresh, low-confidence guess. 2. Found the identical failure mode in my own recent work: HANDOFF.md's original Q1-Q10 summary table (near the top of a 6600+ line file) still quoted the 2026-08-30 "no auto-repeat" finding as current, three commits after this same session measured 12 frames delay / 4 frames interval through a repeat-capable driver and explained why the earlier negative was a driver limitation, not a game fact. A reader who only sees the summary table -- which is exactly what a long file trains a reader to rely on -- would get the withdrawn answer. Fixed with an explicit note pointing at the current entries rather than silently editing the number in place, so the correction itself stays visible. Refutation-shaped either way: two claims ("NEW GAME untested", "no auto-repeat") checked against this corpus's own newer evidence and found not to survive, recorded rather than left to be rediscovered. --- docs/port/HANDOFF.md | 13 ++++++++++++- docs/re/menu-navigation-semantics.md | 20 +++++++++++++------- 2 files changed, 25 insertions(+), 8 deletions(-) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index c554fad8..5254ec27 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -3424,7 +3424,18 @@ discovered it after re-exporting. ❔ The sweeps may simply be a small term, and | Q2 | which build is which screen state | ✅ answered | `GP_TITLE` is **8 screens shipped twice, EN/JP**: 4/7 title art, 2/3 the `PRESS Ⓐ` plate, 5/8 main menu, 6/9 `EXTRAS`, and ✅ **pak entries 0/1 and 12/15 are the LOADING screen** — two variants, plain and dressed, decoded from their `pgloading_*` element names (2026-08-29). ⚠️ **Read that in ENTRY space.** This row said "0/1 and 10/11" until 2026-08-29; that is true only of `screen list`'s ordinals, where 10→entry 12 and 11→entry 15. In entry space the splashes are **10/13** (`palogo_sqex`, publisher) and **11/14** (`palogo_gamearts`/`palogo_seta`/`palogo_anima`, developer) — ~~"in entry space 10/11 are the publisher and developer splashes"~~ was **wrong** (2026-08-30): 10 and 11 are one half each of two *different* pairs, not a pair. 🔴 **And this row enumerated only six of the eight screens** — `sylpheed-port` caught that a reader counting it gets twelve entries with no slot for the splashes, in a row already corrected once for an ordinal-versus-entry error. **All eight, verified off the disc** (`examples/gp_title_entry_names.rs`): 0/1 loading plain, 2/3 the plate, 4/7 title art, 5/8 main menu, 6/9 `EXTRAS`, **10/13 publisher splash**, **11/14 developer splash**, 12/15 loading dressed = 8 × 2 = 16. The port caught it; see [METHOD](../re/METHOD.md#mechanics-that-have-bitten). 🟡 which of the two is `LOADING` vs `LOADING2` is undecided; 🟡 the English member of a pair is the one in the first half of the data segment — [`ui-title-build-map.md`](../re/ui-title-build-map.md) | | Q3 | paint order for the six screens | ✅ answered, ❔ tie-break | **decoded**: a `u16` layer key at `+0x0A` of each `T8aD` sprite header, stable-sorted with declaration index; unkeyed elements get an implied key. Confirmed on 5 measured orders + `EXTRAS` vs a capture. One residual: the **tie-break** is unknown and bites on one element of the title — [`structures/ui-paint-order-key.md`](../re/structures/ui-paint-order-key.md). ⚠️ **The key does not fully order a screen**: elements sharing a key are tied, and the tie-break is ❔ **undecodable from the bundle** — declaration table, `T8aD` header (exhaustive: every offset 0x00–0x7f at u8/u16/u32, both directions, **0** fields match the measured order against **64** for the control) and the RATC child order all give the same order the game does *not* use. ✅ **Your exposure is now measured at ZERO PIXELS (2026-08-29).** The 2 overlapping tied pairs on `EXTRAS` are `ptframe3`×`ptframe4` (the other is a `loop*` you never draw), and rendering the screen with that pair swapped changes **0 px** — because the two sprites put ink on ~3 600 pixels each and **share none of them**; the 102×132 "overlap" was a bounding-box artefact. Same on the main menu's `ptframe1`×`ptframe2`. This is blend-independent: layers that never touch the same pixel cannot be ordered wrongly. **Nothing about the tie-break can change a pixel on any of your five screens** — [`structures/ui-paint-order-derived-check.md`](../re/structures/ui-paint-order-derived-check.md) | | Q4 | button → GamePart | ✅ answered | **measured** which screen all **5** buttons open, by pressing each one and reading the screen's own title off the framebuffer. ✅ **In the form you need it: exactly ONE main-menu button opens a `GP_TITLE` entry.** `EXTRAS` → **entry 6** (EN) / **9** (JP). The other four leave the archive: `NEW GAME` → `DIFFICULTY` → `SELECT DATA`; `LOAD GAME` → the save-slot list; `TUTORIAL` → the lesson list; `OPTIONS` → GAME/CONTROL/SOUND/SCREEN SETTINGS. None of those four is a `GP_TITLE` build — so a menu→submenu→back cycle inside this archive is `main menu ↔ EXTRAS` and nothing else. The **GamePart id is still a name match**, not a measurement, and 🔴 the "cheap way to measure it" this page used to point at is a dead route (the guest words are monotonic counters, not a screen id) — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) | -| Q5 | navigation semantics | ✅ answered, ⚠️ **per clause** | 🔴 **This row used to open with a single `**measured**` covering six clauses of different strength, and the port's `authored/flow.json` copied that word into a `MEASURED` provenance stamp for a clause whose evidence cell reads `none`. A bundled label is exactly as strong as its weakest cell.** Split: ✅ **measured** — initial focus varies boot to boot (2× `TUTORIAL`, 2× `NEW GAME`); ⬆⬇ move **one item per press** (indirect: the 4-press wrap count only works if each press moves one) and **wrap both ends**; ⬅➡ do nothing; Ⓑ on a submenu returns to the parent **with focus restored** (4/4); Ⓑ on the main menu → **title**, ≤ 0.4 s, no loading screen (2026-08-30). ✅ **AND BOTH WEAK CLAUSES ARE NOW MEASURED (2026-08-30, later)** — you can stamp them: **no auto-repeat** (a 2.0 s held ⬇ moves the cursor exactly **once**; the counter passes its control, a single tap giving exactly 1 spike) and **Ⓑ on the title → nothing** (20 s after a delivery-confirmed Ⓑ the screen is still the title with `PRESS Ⓐ BUTTON` up — and that run waited for the **plate pulse**, the title's own settled signature, which is what the confounded earlier attempt did not). ✅ The plate **is** re-drawn after Ⓑ from the menu, ~7 s later — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) | +| Q5 | navigation semantics | ✅ answered, ⚠️ **per clause** | 🔴 **This row used to open with a single `**measured**` covering six clauses of different strength, and the port's `authored/flow.json` copied that word into a `MEASURED` provenance stamp for a clause whose evidence cell reads `none`. A bundled label is exactly as strong as its weakest cell.** Split: ✅ **measured** — initial focus varies boot to boot (2× `TUTORIAL`, 2× `NEW GAME`); ⬆⬇ move **one item per press** (indirect: the 4-press wrap count only works if each press moves one) and **wrap both ends**; ⬅➡ do nothing; Ⓑ on a submenu returns to the parent **with focus restored** (4/4); Ⓑ on the main menu → **title**, ≤ 0.4 s, no loading screen (2026-08-30). ✅ **AND BOTH WEAK CLAUSES ARE NOW MEASURED** — you can stamp them, but 🔴 +**one of the two flipped since 2026-08-30, and this row sat stale for +several iterations of the same session before this fix (2026-09-12) — read +issue #1's own entries further down this file, not this sentence, for the +current number.** The 2026-08-30 measurement ("no auto-repeat, a 2.0 s hold +moves the cursor exactly once") went through Canary's scripted `--hid=file` +driver, which is *built* to suppress repeat by design — it could not have +shown one either way. Once that driver was patched to emit the same +`REPEAT` keystroke a real controller's driver does, the identical hold +produced continuous repeat: **12 frames initial delay, 4 frames interval**, +at this run's 29.87 fps guest rate. **Use 12 and 4, not "none."** The other +clause stands as measured: **Ⓑ on the title → nothing** (20 s after a delivery-confirmed Ⓑ the screen is still the title with `PRESS Ⓐ BUTTON` up — and that run waited for the **plate pulse**, the title's own settled signature, which is what the confounded earlier attempt did not). ✅ The plate **is** re-drawn after Ⓑ from the menu, ~7 s later — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) | | Q6 | boot sequence + what drives it | ✅ answered | sequence **measured** end to end; the driver is **code, not data** — four search spaces closed, so the port **authors** the sequence — [`boot-config-and-gamepart-registry.md`](../re/boot-config-and-gamepart-registry.md) | | Q7 | transitions | ✅ answered, **two numbers changed 2026-08-30** | a **fade through black**, drawn by the screen's own last-painting `.prm` quad. 🔴 **Fade-in is 12 units (0.20 s) on the menu/`EXTRAS` and 16 (0.27 s) on the title — this row's source used to say 0.87–4.08 s, which is the quad's CLEAR-hold, not its ramp** (a stale Python reader that shifted every keyframe time by one slot). Fade-out **is** on the disc: 10/10/8 units. ✅ **And the transition is OVERLAP, not ramp-then-hold, measured from the running game**: content elements start fading ~6 frames before the black quad's ramp begins, total blackout 9 frames ≈ 0.30 s, and the gap between screens is **one frame**. The "~14 units of black hold" this page used to carry was arithmetic and is **withdrawn** — [`screen-transitions.md`](../re/screen-transitions.md) | | Q8 | menu audio bindings | ✅ answered | cue vocabulary + bank **decoded**; event binding is a **name match** (the authors' own event names). ✅ **You CAN have the SE audio** — ⚠️ an earlier version of this row said it was "undecodable from the disc"; that was **retracted** and the row was stale. Three cues are located in `Static.slb` and **decode to PCM**: d-pad move `0x1ec0` (4 packets), Ⓑ back `0x0ec0` (2), Ⓐ confirm `0x5d6c0` (6), all mono 48 kHz. The bank is a packed run of XMA waves with no delimiter, so a wave is only (offset, packet count) — and ⚠️ the file order is **not** cue-id order, so the index cannot be counted out — [`menu-audio-cues.md`](../re/menu-audio-cues.md) | diff --git a/docs/re/menu-navigation-semantics.md b/docs/re/menu-navigation-semantics.md index 8af4d767..e385f9c6 100644 --- a/docs/re/menu-navigation-semantics.md +++ b/docs/re/menu-navigation-semantics.md @@ -1,9 +1,10 @@ # The title menu — how it moves, and where each button goes **Status:** ✅ `CONFIRMED` (**measured**, by driving the running game) for the -movement rules and for four of the five main-menu destinations. 🟡 the GamePart -*id* behind each destination is a **name match onto the decoded id table**, not a -measurement. ❔ `NEW GAME` deliberately untested. +movement rules and for all **five** main-menu destinations, `NEW GAME` +included (→ `DIFFICULTY` → `SELECT DATA`, not a hang — corrected 2026-09-12, +see the Q4 table). 🟡 the GamePart *id* behind each destination is a **name +match onto the decoded id table**, not a measurement. Answers [MISSION Q5](../port/MISSION.md) and most of Q4. Nothing here is on the disc in any form found so far — the port is **authoring** these rules from this @@ -244,7 +245,7 @@ Measured by driving: focus the item, press Ⓐ, read the screen's own title. | button | screen it opens | evidence | GamePart id | |---|---|---|---| -| `NEW GAME` | ❔ **not tested** | — | — | +| `NEW GAME` | 🔴 **stale row, corrected 2026-09-12** — measured 2026-08-28: `DIFFICULTY` (`EASY`/`NORMAL`/`HARD`/`BACK`) → `SELECT DATA` → guest crash (unrelated cache-manager bug, not a menu fault). The "`NEW GAME` — measured" section further down this same page had the answer already and this table was never updated to match it | [captures](captures/newgame-path/) | `DIFFICULTY`: **no id-table name match** — already tried and refuted (`boot-config-and-gamepart-registry.md`: neither `DIFFICULTY` nor `EXTRA_MENU` survive as call-site strings). `SELECT DATA`: 🟡 `2 GP_SELECT_STORAGE`, a fresh name-guess, same low confidence as every other row here | | `LOAD GAME` | the save-slot list, `LOAD GAME` / `Current Storage` | [`q4-destinations.png`](captures/menu-nav/q4-destinations.png) left | 🟡 `3 GP_LOAD` | | `TUTORIAL` | the lesson list, `TUTORIAL`, Level 1 / Level 2 | same, middle | 🟡 `25 GP_TUTORIAL` | | `OPTIONS` | `OPTIONS` — GAME / CONTROL / SOUND / SCREEN SETTINGS / BACK | same, right | 🟡 `8 GP_OPTIONS` | @@ -262,10 +263,15 @@ it is a name match I made by eye. The port should treat these ids as authored. Worth noting that the ids and the paks are not one-to-one: `GP_EXTRAS` is id 5 with **no pak of its own** — its artwork is a build inside `GP_TITLE.pak`. -**❔ `NEW GAME` was deliberately not pressed.** Ⓐ on it leads to a standing -black-screen hang that ends the run +~~**❔ `NEW GAME` was deliberately not pressed.**~~ **Withdrawn — stale, fixed +2026-09-12.** This line said Ⓐ on it hangs the emulator ([`ui-paint-order-third-permutation.md`](ui-paint-order-third-permutation.md)), -and this iteration needed the session. It is the one destination still unmeasured. +which the very next section of this same page already refuted on +2026-08-28: it does not hang, it opens `DIFFICULTY` then `SELECT DATA` before +an unrelated crash. Kept struck rather than deleted — this is the exact +failure this corpus keeps naming, a correction that landed lower in the +same document than the claim it corrected and never caught up to the table +above. ### 🔴 The "cheap way to finish this" was a dead route — WITHDRAWN 2026-08-29