re: the ten states are ONE PHASE of five -- and phase 0 is the splash

Chasing where the event code comes from turned up the level above and
corrected my own framing three sections running.

sub_821C6458 has exactly one caller, sub_821C7850, and that caller is
itself a dispatcher -- on a SECOND, outer state field at this+132, five
phases, gated on this+16 == 3. Phase 4 is the title/menu machine I have
been decoding. Phase 0 is sub_821C5690, which the iterate3E notes had
already fingered as the splash mechanics from a completely different
direction. That agreement is the useful check here.

So GamePart_Title has two nested state fields: a phase at this+132
choosing which sub-machine runs, and the state at this+136 inside phase
4. Everything I decoded over the last three iterations -- ten states,
eighteen edges, the event dispatch -- is phase 4 ONLY. Phases 1, 2 and 3
are untouched. I have called that out in REFUTED against my own earlier
wording rather than quietly restating it.

And the event code is forwarded, not created: all five phase handlers are
called with the same (this, r29, r28), where r28 is sub_821C7850's own
third argument passed through untouched. So the event vocabulary is
defined at least one level further up, and finding what 3, 5, 8, 10 and
25 mean means going up again. Not done.
This commit is contained in:
Sylpheed RE agent
2026-08-28 20:05:27 +00:00
parent 52275ddd53
commit a98e96b0f0
4 changed files with 77 additions and 3 deletions

View File

@@ -1,4 +1,26 @@
GamePart_Title's screen state machine -- sub_821C6458, decoded statically.
GamePart_Title has TWO nested state fields.
OUTER -- sub_821C7850, the part's dispatcher
821c786c lwz r11, 16(r30) ; only runs when this+16 == 3
821c7870 cmpwi cr6, r11, 3
821c7874 bne cr6, <exit>
821c787c lwz r11, 132(r30) ; phase = this+0x84
821c7880 cmplwi cr6, r11, 0x4 ; five phases, 0..4
821c7888 lis/addi r12, 0x821C78A0 ; jump table
821c789c bctr
phase 0 -> sub_821C5690 (the splash -- independently identified as the
splash mechanics in the iterate3E notes)
phase 1 -> inline block at 0x821c790c
phase 2 -> sub_821C5818
phase 3 -> sub_821C5EC0
phase 4 -> sub_821C6458 (the title/menu machine, below)
All four call sites forward the SAME three arguments: (this, r29, r28),
where r28 is this function's own third argument -- an EVENT CODE passed
through unchanged from ITS caller.
INNER -- sub_821C6458, the title/menu machine (phase 4 only)
DISPATCH
821c6474 lwz r11, 136(r30) ; state = this+0x88
@@ -67,7 +89,8 @@ THE CONDITION ON STATE 4's EDGES -- decoded
event 25 -> block 0x821c6ed8 -> state 8 (LOADING)
WHAT IS NOT DECODED
* what the event NUMBERS mean -- button id, menu-item id or message id;
* what the event NUMBERS mean -- they are forwarded unchanged from
sub_821C7850's caller, so the vocabulary is defined at least one level up -- button id, menu-item id or message id;
* the conditions on edges out of states other than 4;
* what states 1, 3, 5, 6, 7 and 9 do (they install no named screen);
* state 3 is never a destination here, so something outside this function