From a3946e50051c9a125690051ddceda27ac25477b0 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sat, 29 Aug 2026 01:49:42 +0000 Subject: [PATCH] re: the game surface is rendering BLACK -- check that before explaining absences The named experiment was to attach the fast probe at t=0 so the boot title could not be missed. Done, default config, English: 2391 frames in 600.4 s = 3.98 fps; max glyph 0; hits 0 Ten minutes sampled four times a second FROM LAUNCH, no green-(A) glyph. So "the plate only shows in an early boot window I keep missing" is mine and refuted -- the third explanation refuted in three iterations. Then the check that should have come first. Splitting the raw root grab into bands: y 0- 44 (GTK menu bar) 100.00% non-black mean 210.50 y 45-719 (game surface) 0.08% non-black mean 0.07 The game is rendering black, reproducibly across back-to-back samples, while the guest is alive and polling input (XamInputGetKeystrokeEx past 1201 calls) and MEM-WATCH keeps reporting. The crop and every pixel oracle were correct; there was nothing on the surface to detect. What this does NOT do is retroactively explain the earlier failures, and claiming so would be the fourth over-reach in a row. Those runs had content: run 2 sampled mean 33.1, run 3's classifier measured real frame-to-frame rmse, the gamma_type=0 run measured mean 122.8. The failure mode CHANGED over the session; black is the newest and worst. Hypothesis for the regression, untested: canary's shader/pipeline cache is 47 MB and was last written 23:49 on Aug 28, during the failed runs, and this session has kill -9'd the emulator repeatedly. The test is to move cache* aside and boot again -- one line and one run, not done. Two METHOD lines: ask whether the screen is drawing anything before explaining why a feature of it is missing; and a newly found fault does not retroactively explain older failures. --- docs/re/METHOD.md | 14 +++++++++ docs/re/REFUTED.md | 5 +++ docs/re/capture-harness-status.md | 52 +++++++++++++++++++++++++++++++ 3 files changed, 71 insertions(+) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 37f7cdc..ba0c676 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -518,3 +518,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the happened not to be the cause — the most seductive kind, because fixing it feels like confirmation. A plausible mechanism that explains a failure is a hypothesis, and the fix is its experiment, not its proof. +* **Ask whether the screen is drawing anything before explaining why a feature of + it is missing.** Four iterations produced four explanations for "the title is + not detected" — a stale oracle, the locale, the sampling rate, a one-shot boot + window — and three of them were refuted in turn. Splitting a raw root grab into + bands then showed the game surface at **0.08 % non-black, mean 0.07**: it was + rendering black. The check costs one command and belongs at the *front* of that + sequence, not after the fourth hypothesis. A detector reporting absence is + ambiguous between "the feature is not there" and "nothing is there". +* **A newly found fault does not retroactively explain older failures.** The + black surface is real and reproducible *in the run where it was measured*. + Earlier runs in the same session had measurable content (mean 33.1, mean 122.8, + non-zero frame-to-frame rmse), so the failure mode changed over the session. + Reaching back to re-explain earlier results with the newest cause would have + been the fourth over-reach in a row. diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index eec5872..92d67ad 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -446,3 +446,8 @@ neighbourhood, not just the line. withdrawn last iteration for want of evidence, now **reinstated as a measurement**: 1 674 dense samples over 420 s, English, zero glyph frames. ⚠️ Reach: a mid-run window only; it says nothing about the boot title. +* "the PRESS Ⓐ plate appears only in the **boot** title window, which mid-run + sampling could never catch" → **mine, and refuted.** The fast probe was + attached at t=0: **2 391 frames over 600 s at 3.98 fps from launch**, max glyph + 0. The plate did not appear at any point in the first ten minutes. + [`capture-harness-status.md`](capture-harness-status.md) diff --git a/docs/re/capture-harness-status.md b/docs/re/capture-harness-status.md index 31947b9..602c5e6 100644 --- a/docs/re/capture-harness-status.md +++ b/docs/re/capture-harness-status.md @@ -118,3 +118,55 @@ 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. + + +--- + +## 🔴 The boot-window hypothesis is refuted too — and the surface is BLACK + +**2026-08-29, third explanation and third refutation.** The named experiment was +to attach the fast probe at **t = 0** so the boot title could not be missed. +Done, on the default config, English: + +``` +2391 frames in 600.4 s = 3.98 fps; max glyph 0; hits 0 +``` + +Ten minutes, sampled four times a second **from launch**, and the green Ⓐ glyph +never appeared. So "the plate only shows in an early boot window I keep missing" +is **mine, and refuted**. + +Then the thing I should have checked first. Splitting the raw root grab by band: + +| band | non-black | mean | +|---|---|---| +| y 0–44 (the GTK menu bar) | **100 %** | 210.5 | +| **y 45–719 (the game surface)** | **0.08 %** | **0.07** | + +**The game is rendering black**, reproducibly across back-to-back samples, while +the guest is alive and polling input (`XamInputGetKeystrokeEx` past 1 201 calls) +and `MEM-WATCH` keeps reporting. The crop and every pixel oracle were correct; +there was nothing on the surface to detect. + +### ⚠️ What this does and does not explain + +**It does not retroactively explain the earlier failures**, and saying so would +be the fourth over-reach in a row. Those runs had *content*: run 2 sampled frames +at mean 33.1 (warm), run 3's classifier measured real frame-to-frame rmse, and +the `gamma_type = 0` run measured mean 122.8. A black surface is **this run's** +symptom. + +So the honest reading is that the failure mode **changed** over the session, and +the black screen is a new and worse one. + +### 🟡 Hypothesis for the regression, untested + +Canary's shader/pipeline cache at `~/.local/share/Xenia/cache` is **47 MB** and +was last written **23:49 on 2026-08-28** — during the failed runs. This session +has `kill -9`'d the emulator repeatedly, which can leave a partially written +cache. A corrupt pipeline cache is a plausible route to a guest that runs while +nothing reaches the screen. + +**The test is one line and one run:** move `cache*` aside and boot again. Not +done — it needs a fresh 10-minute run, and this iteration had spent its emulator +budget proving the negative above.