diff --git a/docs/port/MISSION.md b/docs/port/MISSION.md index 39737658..416ccbf5 100644 --- a/docs/port/MISSION.md +++ b/docs/port/MISSION.md @@ -114,6 +114,15 @@ independent landmarks rather than guessed: `XLanguage::kJapanese = 2` (`xbox.h:307`). Writing 2 there and restoring afterwards is using canary's own persistence, not patching its code. +**🔴 DIAGNOSED 2026-08-29 — the harness, not the game.** `screenshot` costs +**10.8 s while xenia is running** and **0.117 s once it is killed** (92×, at a +1-minute load average of 1.80, so it is contention with the emulator). A +two-grab polling loop therefore samples every **~41 s**, against a title screen +this corpus documents as lasting *a few seconds*. Four runs — two locales, two +launch paths, two gamma settings — were all blinking slower than the event. +Everything below is the trail that led there; the conclusions it draws about the +*game* are withdrawn. See [capture-harness-status](../re/capture-harness-status.md). + **🟡 Still not settled — two runs, and the reason moved again.** *Run 1 (2026-08-28)* reported "title not seen" in 787 s. **That was a broken diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index b9d714ee..7c537e5a 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -496,3 +496,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the whose flat regions are pure black — every model scored ≈ 0.00 error there. That is not corroboration; it is a test with no power, and reporting the 0.00 as agreement would have dressed an untested claim as a verified one. +* **Time your probe against the thing you are probing for.** Four runs concluded + "the game never reaches the title". `screenshot` costs **10.8 s while xenia is + running** and **0.117 s once it is killed** — 92× — so a two-grab polling loop + samples every ~41 s, against a title screen this corpus documents as lasting a + few seconds. The harness was blinking slower than the event. Before believing a + negative from a polling loop, measure its interval and compare it to the + duration of what you are waiting for; and measure the probe's cost *under the + same load as the run*, because idle timing here was off by two orders of + magnitude. +* **Do not change a display setting and a capture behaviour in the same run.** + `kernel_display_gamma_type = 0` brightens the frame, and `skip_intro.sh` + classifies movie-vs-static on an *absolute* rmse threshold — so the gamma + change biased the very classifier the run depended on. Harness thresholds tuned + on one output configuration are not portable to another. diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index 2baa6125..5edf2ae7 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -430,3 +430,9 @@ neighbourhood, not just the line. 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. +* "neither locale reaches the interactive title without a pad press" / + "the game sat in the attract loop for 604 s" → **withdrawn as causes.** Both + rest on runs whose polling loop sampled every ~41 s, because `screenshot` + costs 10.8 s while the emulator runs (0.117 s idle, 92×). A title lasting a few + seconds would be missed. The observations stand; the conclusions drawn from + them do not. [`capture-harness-status.md`](capture-harness-status.md) diff --git a/docs/re/capture-harness-status.md b/docs/re/capture-harness-status.md new file mode 100644 index 00000000..6caa5a9a --- /dev/null +++ b/docs/re/capture-harness-status.md @@ -0,0 +1,66 @@ +# 🔴 Why the boot harness stopped reaching the title — `screenshot` costs 10.8 s + +**Status:** ✅ **diagnosed, with a control.** Four consecutive runs on +2026-08-28/29 failed to reach the interactive title, across two locales, two +launch paths and two display-gamma settings. The cause is none of those. + +## The measurement + +| condition | one `screenshot` call | +|---|---| +| while Xenia Canary is running | **10.8 s** | +| immediately after killing it | **0.117 s** | + +**92×.** The 1-minute load average at the slow measurement was 1.80, so this is +contention with the emulator (both go through the same X server), not general +system load. + +## Why that breaks the harness + +`skip_intro.sh` takes **two** grabs 0.6 s apart per iteration, plus an +`is_title.py` numpy load. Its actual sample timestamps in the last run: + +``` +57, 95, 177, 218, 238, 298, 333, 380, 426, 471, 515 → intervals +38, 82, 41, 20, 30, 30, 35, 47, 46, 45, 44, 43, 21, 19 median 41 s +``` + +A **41-second** sampling interval against a title screen that the corpus already +documents as lasting *"a few seconds"* before auto-returning to the attract loop +(`wait_title.sh`'s own header). The harness is not seeing a stuck game; it is +blinking slower than the thing it is looking for. + +That is also why runs at 16:43–18:05 the same day succeeded and later ones did +not — nothing about the game changed. + +## 🔴 What this retracts + +Three earlier conclusions were built on these runs and are **withdrawn as +causes**, though the observations stand: + +* *"the Japanese-locale run never reaches the interactive title"* — it may well + have appeared, unsampled. +* *"neither locale reaches the interactive title without a pad press"* — the + English control shared the same defect, so it controlled for locale but not for + the sampling rate. +* *"the game sat in the attract loop for 604 s"* — what was observed is that + **every one of ~15 samples** landed on movie content, which at a 41 s interval + is a much weaker statement than it reads as. + +## ⚠️ A confound I introduced + +Setting `kernel_display_gamma_type = 0` makes the frame substantially brighter +(a mid-attract frame measured mean **122.8** against **52.5** and **82.8** on +comparable phases at type 2). `skip_intro.sh` classifies movie-vs-static on an +**absolute** rmse threshold of 1500 between two grabs, so a brighter output +inflates that difference and biases every frame toward "movie". **The capture +harness's tuning is coupled to the display settings** — changing gamma and +capture behaviour in one run confounds both. + +## The fix, not applied here + +Make the probe cheap enough to sample faster than the title window: grab a small +region rather than the full surface, drop the ImageMagick `convert` round trip, +or keep the glyph test in one long-lived process instead of re-importing numpy +per sample. None of that is done — this page is the diagnosis, and it is what +every remaining emulator-side question is waiting on.