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

re: fix wait_title.sh's stale oracle; the JP title still is not reached

Browse Source 
Last iteration's "never reached the title in 787 s" was a broken tool
reporting on the world. wait_title.sh was still sampling the single pixel
(625,618) that is_title.py had already been written to replace -- its
docstring says why: a 1280x720 coordinate sampled against the 1279x675
game surface, so it always reads the copyright line. The replacement sat
in the same directory. wait_title.sh now delegates to it.

is_title.py passes its own controls before being trusted here: 753
green-glyph pixels on the committed English title capture, 327 on the
main menu, threshold 400.

Re-ran with the working oracle and the profile flag the English captures
use. The game STILL did not present the interactive title -- but that is
now a measurement rather than an artefact: not one frame showed a single
green-(A) glyph pixel, and content correlation against either build-7
render never exceeded 0.22. Canary was alive and polling
XamInputGetKeystrokeEx (601 calls), sitting in the attract movie.

So the open question narrowed again, and is written into MISSION.md:
whether the attract loop returns to the INTERACTIVE title without a pad
press. title_states_capture.sh claims it does on the English boot with no
pad input; if that holds, the difference is the locale.

Nothing decided about the keyframe-time association or the rest() rule.
Emulator stopped, lock cleared, locale restored to English.
This commit is contained in:
Sylpheed RE agent
2026-08-29 00:21:44 +00:00
parent 948273883f
commit 23f12a3710
4 changed files with 49 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/port/MISSION.md
View File

@@ -114,12 +114,26 @@ 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.
**🟡 Still not settled, for a smaller reason.** A run with the locale set to
Japanese booted fine, but **never reached the title in 787 s** — `wait_title.sh`'s
green-Ⓐ oracle never fired, and burst-sampling 8 frames found none correlating
above 0.18 with either build-7 render. The run sat in the attract loop. So this
needs a *longer or pad-driven* run, not a rebuilt emulator. The locale was
restored to English afterwards.
**🟡 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
tool, not the game.** `wait_title.sh` still carried the single-pixel oracle that
`is_title.py` was written to replace — a 1280×720 coordinate sampled against the
1279×675 game surface, so it always reads the copyright line. Fixed; it now
delegates to `is_title.py`.
*Run 2 (2026-08-29)*, with the working oracle and the profile flag the English
captures use, **still did not reach the interactive title.** Not one frame in the
run showed a single green-Ⓐ glyph pixel, and content correlation against either
build-7 render never exceeded **0.22**. The game sat in the attract movie
throughout, polling `XamInputGetKeystrokeEx` (601 calls) — i.e. alive and waiting
for input, not hung.
🟡 **So what is untested is whether the attract loop returns to the *interactive*
title without a pad press.** `title_states_capture.sh` claims it does, with no
pad input, on the English boot — that is the next thing to check, and if it holds
then the difference is the locale and worth its own note. The locale is restored
to English; `set_console_language.py ja` flips it back in one command.
⚠️ Neither question blocks the five menu screens. Q1's *interpolation law* is
settled and only multi-keyframe absolute timing is open; `rest()` differs from