fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: a fourth paint order attempted; the title is intermittent, not input-bound

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-19 09:56:32 +00:00
parent 2efc0b7c59
commit 63011eb9ed
3 changed files with 84 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/re/BACKLOG.md
View File

@@ -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

33
docs/re/captures/title-input-delivered-not-acted-on.log Normal file
View File

@@ -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)

45
docs/re/ui-paint-order-third-permutation.md
View File

@@ -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.