fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: menu focus does not survive a reboot -- six fresh boots, three following a session that ended elsewhere

Browse Source 
No new boot was spent: six runs had already captured the first menu entry of a
fresh boot, and all six read NEW GAME. Three of them follow a session that ended
with the cursor on EXTRAS or OPTIONS, which is what makes it a test of persistence
rather than a repeated observation.

Reach stated rather than implied: every session ends with the emulator KILLED, so a
game that writes menu state on a clean shutdown would never get the chance. This
measures 'does not survive a killed session'.

Refutation attempt on the port's extras/initial_focus: ptbtn11 -- it SURVIVES.
ptbtn11 is the top button on the EXTRAS build, with the main menu as a control
where ptbtn01 is top and is known to be NEW GAME.

Incidentally corrects ring_row.py's stated calibration. It cited capture_y = 49.5 +
1.060*design_y, fitted against menu_focus.py's row centres, which are NOT the
disc's button rows -- the disc says 162/242/322/401/482, spacing 80, and
menu_focus.py drifts up to 17 px against them. Re-fitted: 64.82 + 0.9919*design_y,
residuals under 0.7 px. No item assignment changes.

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-31 01:51:03 +00:00
parent 924f16c2a1
commit 1bf619460a
4 changed files with 131 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/re/REFUTED.md
View File

@@ -818,3 +818,22 @@ here, against the **19–20 dB** an unrelated movie gave them. A 0.66 dB thresho
an 8× margin against that floor rather than a 30× one, so **the safety of the
threshold depends on how different the chosen known-negative is**, not on the method.
[data](data/impossibility-scope-sweep.txt)
### Refutation attempt on `sylpheed-port`'s `extras/initial_focus: ptbtn11` — ✅ SURVIVES (2026-08-31)
**Target:** their statement that `EXTRAS` keeps `ptbtn11` and is "correct under the
surviving reading" — i.e. that a submenu resets to the item it opens on, and that
`ptbtn11` is that item.
**My attempt:** the oracle shows `EXTRAS` opening on `MISSION SELECT`, the first of
three. So their value is right only if `ptbtn11` is the **top** button on that
screen. Checked against the disc, with the main menu as a control
(`examples/extras_button_order.rs`):
| | buttons top to bottom |
|---|---|
| **control** — main menu (entry 5) | `ptbtn01` y162, `ptbtn02` y242, `ptbtn03` y322, `ptbtn04` y401, `ptbtn05` y482 → top is `ptbtn01` = `NEW GAME` ✅ |
| `EXTRAS` (entry 6) | `ptbtn11` y282, `ptbtn12` y362, `ptbtn13` y442 → **top is `ptbtn11`** |
**The claim survives**, and the control confirms the ordering rule reproduces a
screen whose answer is independently known.

52
docs/re/data/focus-does-not-survive-a-reboot.txt Normal file
View File

@@ -0,0 +1,52 @@
# Does the main menu's cursor survive a REBOOT? ✅ NO -- MEASURED 2026-08-31.
#
# The main menu PERSISTS its cursor across menu -> title -> menu within one boot
# (focus-persists-across-title.txt). Whether it survives a reboot has been listed
# as untested since, and it decides whether "initial focus = NEW GAME" is a fresh
# -start value or merely what the last session happened to leave.
#
# NO NEW BOOT WAS SPENT. Six runs already captured the FIRST menu entry of a fresh
# boot (each `reach/1-F1.png`), read here with the calibrated ring reader:
#
# run ring y first menu entry
# focuspersist 225.5 NEW GAME
# extrasfocus 225.5 NEW GAME
# submenusweep 225.5 NEW GAME
# submenu3 227.0 NEW GAME
# submenu4 225.5 NEW GAME
# difficulty 225.5 NEW GAME
#
# ✅ SIX INDEPENDENT FRESH BOOTS, ALL NEW GAME.
#
# 📌 AND THREE OF THEM FOLLOW A SESSION THAT ENDED ELSEWHERE, which is what makes
# this a test of persistence rather than a repeated observation:
# 22:06 extrasfocus ended INSIDE EXTRAS -> 22:17 submenusweep opened NEW GAME
# 22:17 submenusweep ended on OPTIONS -> 00:42 submenu3 opened NEW GAME
# 01:21 submenu4 ended on OPTIONS -> 01:46 difficulty opened NEW GAME
#
# => Menu focus does NOT carry across a reboot. The port's authored NEW GAME is
# correct for a fresh start, and is not an artefact of session history.
#
# ⚠️ REACH, and it is the important line: EVERY ONE of these sessions ends with the
# emulator being KILLED (ensure_single_emulator terminates the process). A game
# that writes menu state on a CLEAN shutdown would never get the chance, so this
# measures "does not survive a killed session", not "the game never saves focus".
# A clean-exit path is untested and this harness has no way to exercise one.
#
################################################################################
# INCIDENTAL, and it corrects a number of mine.
#
# The disc says the main menu's five buttons sit at design y 162 / 242 / 322 /
# 401 / 482 -- spacing 80 (examples/extras_button_order.rs).
# menu_focus.py's row centres are [166, 241, 315, 390, 465], spacing 75, drifting
# +4, -1, -7, -11, -17 against the real rows: over a QUARTER of a row by the
# bottom item. That drift is why the old reader was fragile.
#
# 🔴 So ring_row.py's stated calibration was wrong. It said
# capture_y = 49.5 + 1.060 * design_y
# fitted against those approximate rows. Re-fitted against the DISC rows:
# capture_y = 64.82 + 0.9919 * design_y residuals all < 0.7 px
# The surface is offset ~65 px in the capture and essentially NOT scaled; the
# 1.060 was an artefact of the wrong reference.
# ⚠️ No item assignment changes -- ROW0 and SPACING are measured off captures
# directly and never used the bad fit.