From 105ed4d3e26123641e1427427597eea235e12949 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sat, 29 Aug 2026 00:35:49 +0000 Subject: [PATCH] re: the English control removes the locale from the title-capture problem Two iterations framed the JP title capture as possibly locale-specific. It is not. Same flags, same oracle, English locale: 75 samples over 734 s, every one glyph = 0. The English boot does not present the interactive title either. Canary was alive throughout, polling XamInputGetKeystrokeEx (1801 calls); the frame at 734 s has content but correlates 0.15 with build 4's render and 0.05 with the main menu -- an attract-movie frame, not title art. So neither locale reaches the interactive title in ~12 minutes without a pad press. What is actually untested is the pad: pad.py and nav_to_flight.sh exist, and title_states_capture.sh reaches title states with a flag set this probe did not replicate (--log_ui_draws --ui_draw_capture_frames, plus xdotool window focus). It is a capture problem, not a locale one. MISSION.md updated. Also resolved a caveat I had given the port agent without checking it: "rotation is decoded but not rendered" does NOT affect their five screens at rest. Title, main menu, EXTRAS and both splash halves have ZERO top-level elements with a non-zero rotation. The only rotations on any of them are the title's two nested ptloop records (r = 30 and -45), and at rest those sit at x = 1521 and x = -839 -- a 399-wide sprite entirely off both edges of a 1280 screen. The caveat now applies only to animating the title build-in, where the sweeps cross the screen rotated. Two METHOD lines: run the control before theorising about the difference, and log every sample so a failure is a measurement rather than a silence. Emulator stopped, lock cleared, locale English. --- docs/port/HANDOFF.md | 7 +++++++ docs/port/MISSION.md | 22 +++++++++++++++++----- docs/re/METHOD.md | 12 ++++++++++++ docs/re/REFUTED.md | 4 ++++ 4 files changed, 40 insertions(+), 5 deletions(-) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 258560a7..d9f30db4 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -166,6 +166,13 @@ authored version can be deleted. renderer and the port will *both* draw these upright until a rotating blit exists — and per your own rule, the two of them agreeing about it means nothing. + ✅ **Checked 2026-08-29: this does NOT affect your five screens at rest.** + Title, main menu, `EXTRAS` and both splash halves have **zero** top-level + elements with a non-zero rotation. The only rotations on any of them are the + title's two nested `ptloop` records (`r = 30` and `−45`), and at rest those sit + at `x = 1521` and `x = −839` — a 399-wide sprite entirely off both edges of a + 1280 screen. So a static composite is unaffected; the caveat applies only if + you animate the title's build-in, where the sweeps cross the screen rotated. 🟡 The neighbouring words `+4` and `+8` are still unexplained: signed, non-zero in ~4.8 % / 4.6 % of blocks, almost entirely `±180`/`±90`. That distribution looks like a flip flag rather than a free angle, but nothing observed turns on diff --git a/docs/port/MISSION.md b/docs/port/MISSION.md index 2c749d98..495d25c2 100644 --- a/docs/port/MISSION.md +++ b/docs/port/MISSION.md @@ -129,11 +129,23 @@ build-7 render never exceeded **0.22**. The game sat in the attract movie throughout, polling `XamInputGetKeystrokeEx` (601 calls) — i.e. alive and waiting for input, not hung. -🟡 **So what is untested is whether the attract loop returns to the *interactive* -title without a pad press.** `title_states_capture.sh` claims it does, with no -pad input, on the English boot — that is the next thing to check, and if it holds -then the difference is the locale and worth its own note. The locale is restored -to English; `set_console_language.py ja` flips it back in one command. +**✅ The control was run (2026-08-29), and it removes the locale from the +picture.** Same flags, same oracle, English locale: **75 samples over 734 s, every +one glyph = 0.** The English boot does not present the interactive title either. +Canary was alive throughout and polling `XamInputGetKeystrokeEx` (1 801 calls); +the frame at 734 s has content but correlates only **0.15** with build 4's render +and 0.05 with the main menu, i.e. it is an attract-movie frame, not title art. + +So the Japanese run was **not** failing because of the locale — neither locale +reaches the interactive title in ~12 minutes of no pad input. 🟡 What remains +untested is a **pad press**: `pad.py` and `nav_to_flight.sh` exist, and +`title_states_capture.sh` reaches title states with its own flag set +(`--log_ui_draws --ui_draw_capture_frames`, plus xdotool window focus) which this +probe did not replicate. That is the next thing to try, and it is a capture +problem, not a locale one. + +The locale is restored to English; `set_console_language.py ja` flips it back in +one command. ⚠️ Neither question blocks the five menu screens. Q1's *interpolation law* is settled and only multi-keyframe absolute timing is open; `rest()` differs from diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 7e03672d..efd6dd8a 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -451,3 +451,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the check whether something in the toolkit already supersedes it, and run the probe against a known-positive capture first — `is_title.py` scores 753 on a real title frame and 327 on the main menu, which takes one command to confirm. +* **Run the control before theorising about the difference.** A Japanese-locale + run failed to reach the interactive title, and I wrote up the open question as + "if English reaches it, the difference is the locale". English does not reach + it either — 75 samples over 734 s, every one a miss. The locale had nothing to + do with it, and two iterations framed the problem around a variable that was + never implicated. The control cost one run and would have cost the same one + iteration earlier. +* **Log every sample, not just the hit.** The first probe printed nothing until + it succeeded, so a 787 s failure was indistinguishable from a probe that never + ran. Printing the oracle's value each tick turns "no title" into "75 samples, + max glyph 0", which is a measurement — and it is what showed the black-screen + and attract-movie phases were being sampled correctly all along. diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index 1ed74923..2baa6125 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -426,3 +426,7 @@ neighbourhood, not just the line. oracle. Re-run with `is_title.py`: the game still did not present the interactive title, but that is now a measured statement (zero green-glyph pixels, correlation ≤ 0.22 to either build-7 render) rather than an artefact. +* "the Japanese-locale run fails to reach the interactive title *because of the + locale*" → **refuted by the English control.** 75 samples over 734 s with the + same flags and oracle, every one glyph = 0. Neither locale presents the + interactive title without a pad press.