Files
Sylpheed/docs/re/data/tbm-submenu-reached.txt
sylph-decoder 77e54e95a5 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
2026-08-30 10:49:48 +00:00

43 lines
2.2 KiB
Plaintext

# A submenu REACHED and captured -- but not identified.
#
# 2026-08-30, tools/re-capture/tbm_submenu_v2.py. Third attempt; the two
# earlier ones are in tbm-submenu-not-reached.md. All three of that page's
# fixes were applied and all three were needed:
# [ 288.6s] TITLE (glyph 1520)
# [ 289.7s] A delivered (attempt 1) <- confirmed from [RE-INPUT], not 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: 1280x720, mean 52.77, 99.7 % of pixels above 16, coverage
# uniform top (0.993) / middle (1.000) / bottom (0.990). A FULL-SCREEN
# BACKGROUND.
#
# OUR RENDERER, on the archives that carry a .tbm decider:
# GP_SAVE_LOAD 19 builds 1.9 - 3.0 % inked mean 2.2 - 3.1
# GP_TUTORIAL 3 builds 6.0 - 6.4 % inked mean 5.3 - 6.0
# GP_SYSTEM builds 0,1 78.4 % inked mean 38.7 - 39.4
#
# So GP_SAVE_LOAD and GP_TUTORIAL render essentially NOTHING while the game
# draws a full screen -- but which screen was captured is NOT established.
#
# 🔴 WHY IDENTIFICATION FAILED, and it is a method point:
# Correlation cannot discriminate when the candidate renders are near-blank.
# A near-empty image has almost no structure to correlate with, so every
# GP_SAVE_LOAD build scores -0.004..-0.010 against the capture -- a ranking
# with no information in it. A matching statistic is useless against a
# hypothesis that predicts an empty image, which is exactly the hypothesis
# under test here.
#
# 🔴 AND THE FOCUS COULD NOT BE READ from the menu capture. Against the two
# labelled references the whole-frame mean absolute difference is 2.52
# (NEW GAME focused) and 2.48 (OPTIONS focused) -- a 1.6 % separation, far
# too weak to call. 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.
#
# ✅ ONE THING WORTH KEEPING: the game surface sits at y=45 in the 1280x720
# display frame. Cropping m[45:45+675, 0:1279] fits the committed 1279x675
# captures to a mean absolute difference of 2.5. That is the alignment the
# earlier cross-geometry floor comparison got wrong.