re: a submenu is REACHED -- and correlation cannot identify it

Third attempt at the .tbm question. All three fixes from the previous page were
applied and all three were needed: hold A for 0.5 s, confirm delivery from
[RE-INPUT] rather than from the pad, and detect the screen change instead of
timing it. Title at 288.6 s, both presses delivered on attempt 1, submenu at
303.4 s with 87.1 % of pixels changed.

The capture is 99.7 % inked and uniform top to bottom -- a full-screen
background. Our renderer gives 1.9-3.0 % for all 19 GP_SAVE_LOAD builds,
6.0-6.4 % for GP_TUTORIAL, 78.4 % for GP_SYSTEM 0/1. So two of the three
archives render essentially nothing where the game draws a full screen.

But WHICH screen was captured is not established, and the reason is worth more
than the run: correlation cannot discriminate when the candidate renders are
near-blank. All 19 GP_SAVE_LOAD builds score -0.004..-0.010 -- a ranking with no
information. A matching statistic is useless against a hypothesis that predicts
an empty image, which is exactly the hypothesis under test.

Focus could not be read either: the two labelled menu captures fit at 2.52 and
2.48 mean absolute difference, 1.6 % apart. That is a SECOND statistic failing on
the focus problem after the per-row brightness one, so it is an open item rather
than an oversight.

Kept regardless: the game surface sits at y=45 in the 1280x720 display frame,
fitting the committed 1279x675 captures to 2.5 mean absolute difference. That is
the alignment the earlier cross-geometry comparison got wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 10:49:48 +00:00
parent ac1b76ee39
commit 77e54e95a5
3 changed files with 200 additions and 1 deletions

View File

@@ -1,4 +1,4 @@
# 🟡 Does a `.tbm` draw pixels? Still open — two runs, and the third timing bug in a row
# 🟡 Does a `.tbm` draw pixels? Still open — but a submenu is now REACHED
**Classification: not an answer.** Recorded per *"do not improvise around a
blocker"*, and because the *reason* both runs failed is the same mistake three
@@ -55,6 +55,52 @@ thing".** The title detector, the menu detector and the delivery check are all t
substitution, and each was written only after the timed version had already produced
a confident wrong answer.
## ✅ Run 3 — all three fixes applied, all three needed, submenu reached
```
[ 288.6s] TITLE (glyph 1520)
[ 289.7s] A delivered (attempt 1) ← confirmed from [RE-INPUT], not from the pad
[ 295.4s] MENU (glyph 327) ← detected, not timed
[ 299.3s] A delivered (attempt 1)
[ 303.4s] SUBMENU: 87.1 % of pixels differ from the menu, glyph 314
```
**The capture is 99.7 % inked**, uniformly top to bottom — a full-screen background
([capture](../captures/title-builds/live-submenu-unidentified.png),
[numbers](../data/tbm-submenu-reached.txt)).
**Our renderer, on the archives carrying a `.tbm` decider:**
| archive | builds | inked |
|---|---|---|
| `GP_SAVE_LOAD` | 19 | **1.9 – 3.0 %** |
| `GP_TUTORIAL` | 3 | **6.0 – 6.4 %** |
| `GP_SYSTEM` | 0, 1 | 78.4 % |
So two of the three render essentially nothing where the game draws a full screen.
## 🔴 But which screen this is, is NOT established — and the reason is a method point
**Correlation cannot discriminate when the candidate renders are near-blank.** An
almost-empty image has no structure to correlate against, so all 19 `GP_SAVE_LOAD`
builds score **−0.004 … −0.010** — a ranking with no information in it. ⚠️ **A
matching statistic is useless against a hypothesis that predicts an empty image**,
and that is precisely the hypothesis under test. The instrument is disabled by the
thing it was brought in to detect.
🔴 **And the focus could not be read either.** Against the two labelled menu
captures the whole-frame mean absolute difference is **2.52** (NEW GAME) and
**2.48** (OPTIONS) — 1.6 % apart, far too weak to call.
[`s00a-drive-blocked-by-focus.md`](../s00a-drive-blocked-by-focus.md) already
records a per-row brightness statistic failing its control; this is a **second**
statistic failing on the same problem, which makes focus identification a real
open item rather than an oversight.
✅ **One thing worth keeping regardless:** the game surface sits at **y = 45** in the
1280×720 display frame — `m[45:45+675, 0:1279]` fits the committed 1279×675 captures
to a mean absolute difference of **2.5**. That is the alignment the earlier
cross-geometry floor comparison got wrong.
## What is now validated, and what the next run needs
✅ Working: the plate-pulse title detector (three runs); the **menu detector**, glyph