From cc4e5e04a70e34d80266691fc23f1fe59ddeb1b4 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sat, 29 Aug 2026 01:18:05 +0000 Subject: [PATCH] re: the boot harness was blinking slower than the title -- diagnosed Four consecutive runs failed to reach the interactive title, across two locales, two launch paths and two display-gamma settings. I attributed it in turn to a stale oracle, to the locale, and to the attract loop. It was none of those. one `screenshot` call, emulator running: 10.8 s one `screenshot` call, emulator killed: 0.117 s 92x, measured at a 1-minute load average of 1.80 -- so it is contention with the emulator through the X server, not background load. skip_intro.sh takes two grabs per iteration plus a numpy import, giving a median sampling interval of 41 s in the last run (38/82/41/20/30/30/35/ 47/46/45/44/43/21/19). The title lasts "a few seconds" before the attract loop reclaims it -- wait_title.sh's own header says so. The harness was sampling slower than the event it was waiting for. That also explains why runs at 16:43-18:05 the same day succeeded. Withdrawn as CAUSES, though the observations stand: "the JP run never reaches the interactive title", "neither locale reaches it without a pad press", and "the game sat in the attract loop for 604 s". The English control did control for locale -- it just shared the same defect. Also recorded: I set kernel_display_gamma_type = 0 for the gamma control run, which brightens the frame (mid-attract mean 122.8 vs 52.5/82.8 at type 2) -- and skip_intro classifies movie-vs-static on an ABSOLUTE rmse threshold, so the gamma change biased the very classifier the run depended on. Changing a display setting and a capture behaviour in one run confounds both. Config restored to type 2. The fix is not applied: make the probe cheap enough to outpace the title window (small region, no convert round trip, one long-lived process). Every remaining emulator-side question is waiting on that. --- docs/port/MISSION.md | 9 +++++ docs/re/METHOD.md | 14 +++++++ docs/re/REFUTED.md | 6 +++ docs/re/capture-harness-status.md | 66 +++++++++++++++++++++++++++++++ 4 files changed, 95 insertions(+) create mode 100644 docs/re/capture-harness-status.md diff --git a/docs/port/MISSION.md b/docs/port/MISSION.md index 3973765..416ccbf 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 b9d714e..7c537e5 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 2baa612..5edf2ae 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 0000000..6caa5a9 --- /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.