From 7927f6c3b7689716c2c0a28627a0ee7f19c2cb1a Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 09:56:32 +0000 Subject: [PATCH] docs: a fourth paint order attempted; the title is intermittent, not input-bound The tie-break needs a fourth measured screen with a tied group, and OPTIONS is three d-pad steps from the main menu, avoiding the NEW GAME hang. It was not reached. Advancing past the title is intermittent: 1 success in 3 attempts today with the same binary, profile and procedure. Attempt 1 stalled before the title existed. The guest was alive - RSS steady at 598MB and the keystroke poll counter climbing past 15000 - but the screen was black and screen_children.py found ONLY the splash object resident. So that failure is not a presentation problem: the game never constructed the title. Being able to separate "stalled before building the screen" from "built but not presenting" is new, and it is what the reader is for. Attempt 2 reached the title at 265s and refused four presses - (A) at 0.25s, 0.25s and 0.5s, START at 0.3s - every one of them logged as DELIVERED to the guest. Third independent confirmation that input delivery is fine and the game simply does not act on the press. Waiting longer does not help either: presses were spread from 10s to about 4 minutes after the title appeared, while the earlier successful run's press landed within seconds. Records the log as evidence and states the next probe: it has to be guest-side now, on whatever consumes the keystroke, since the input path is excluded. --- docs/re/BACKLOG.md | 7 ++- .../title-input-delivered-not-acted-on.log | 33 ++++++++++++++ docs/re/ui-paint-order-third-permutation.md | 45 +++++++++++++++++++ 3 files changed, 84 insertions(+), 1 deletion(-) create mode 100644 docs/re/captures/title-input-delivered-not-acted-on.log diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 6d037032..273ce8e4 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -141,7 +141,12 @@ See [`structures/ui-composable-bundles.md`](structures/ui-composable-bundles.md) the alpha says otherwise. **Next:** it is one element on one screen, so the cheap move is a fourth measured screen with a tied group — not more static guessing at fields that - have all now been checked. + have all now been checked. 🔴 **Attempted 2026-08-19 and blocked:** advancing + past the title is intermittent — **1 success in 3 attempts**, same binary, + same profile, same procedure. Input is excluded for the third time (every + press logged as delivered, `vk=5800`/`vk=5814`); one failure stalled *before + the title was built at all*, with the guest alive and polling and only the + splash object resident. Next probe must be guest-side, not input-side. * ❔ **Blend mode.** Everything is straight alpha-over. The near-white flash quads (`0xf0ffffff`) and coloured ones (`0x60ff0000`) may be additive. The title capture cannot separate the two — its resting elements are all diff --git a/docs/re/captures/title-input-delivered-not-acted-on.log b/docs/re/captures/title-input-delivered-not-acted-on.log new file mode 100644 index 00000000..eecb3c03 --- /dev/null +++ b/docs/re/captures/title-input-delivered-not-acted-on.log @@ -0,0 +1,33 @@ + XEX_MODULE_TITLE +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (1 so far) +F> F8000008 DiscImageDevice::ResolvePath(\dat\movie) +F> F8000008 DiscImageDevice::ResolvePath(\dat\movie) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (601 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (1201 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (1801 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (2401 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (3001 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (3601 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (4201 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (4801 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0001 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0002 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (5401 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (6001 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (6601 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5811 flags=0001 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5811 flags=0002 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (7201 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0001 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0002 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (7801 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (8401 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (9001 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (9601 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0001 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0002 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (10201 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5814 flags=0001 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5814 flags=0002 (call flags 00000003) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (10801 so far) +i> F8000008 [RE-INPUT] XamInputGetKeystrokeEx reached the driver (11401 so far) diff --git a/docs/re/ui-paint-order-third-permutation.md b/docs/re/ui-paint-order-third-permutation.md index b11106a6..cc26fe96 100644 --- a/docs/re/ui-paint-order-third-permutation.md +++ b/docs/re/ui-paint-order-third-permutation.md @@ -171,3 +171,48 @@ of itself can only ever report symptoms. It now keeps a log and prints its path. unread. * ❔ `ptframe1`/`ptframe2` rest at alpha 0 and so are not composited, but the capture shows the menu frame plainly. + + +## A fourth permutation: attempted, blocked on an intermittent boot (2026-08-19) + +The tie-break needs a fourth measured screen with a tied group +([`structures/ui-paint-order-key.md`](structures/ui-paint-order-key.md)), and +OPTIONS is reachable from the main menu with three d-pad steps — avoiding the +NEW GAME path that hangs. It was not reached. + +**Advancing past the title is intermittent: 1 success in 3 attempts today**, with +the same binary, the same profile and the same procedure. + +* **Attempt 1** stalled before the title existed at all. The guest was *alive* — + RSS steady at 598 MB, `[RE-INPUT] … reached the driver (15001 so far)`, i.e. + the game polling input normally — but the screen was black and + `screen_children.py` found **only the splash object** resident. So that failure + is not a presentation problem: the game never constructed the title screen. + Being able to tell those two apart is new, and it is what the reader is for. +* **Attempt 2** reached the title at 265 s and then refused four presses — Ⓐ at + 0.25 s, 0.25 s and 0.5 s, and START at 0.3 s. Every one was **delivered**: + +``` +[RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0001 +[RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5800 flags=0002 +[RE-INPUT] XamInputGetKeystrokeEx -> user=0 vk=5814 flags=0001 +``` + +([log](captures/title-input-delivered-not-acted-on.log)). That is the third +independent confirmation that input delivery is fine and the game simply does not +act on the press. + +Waiting longer does not help: the presses were spread from 10 s to ~4 minutes +after the title appeared, and the earlier successful run's press landed within +seconds of it. No predictor has been found — which is the same conclusion the +corpus reached before, now with the input path excluded rather than suspected. + +## What is not settled + +* 🔴 **Why the title accepts Ⓐ only sometimes.** Input delivery is excluded three + ways over. The next probe has to be on the guest side: the title's handler is + reachable from the emulator-era notes (`sub_821C5690` and the item vtable + `0x820b30b4`), so a watchpoint or a log on whatever consumes the keystroke + would say whether the game reads it and discards it, or never reads it. +* 🔴 A fourth measured paint order, and with it the tie-break. +* ❔ Why a boot sometimes stalls at the splash with the guest still running.