8b4965f0a5
Continuing Q6's last residual -- the control flow I left unread. All three state-name sites in sub_821C6458 compile to the same shape: load the name, then bl 0x821CC860 with it in r5 and 0 in r6, then hand the result to sub_82187B78. So a transition is lookup-by-string then install: sub_821CC860(this+88, this+24, "TITLE_SCREEN", 0). Not a numeric id and not a table index. That also explains something that had been sitting unexplained -- GP_ADVERTISE_DEMO having zero xrefs -- because at this level the screen graph is keyed by name rather than by GamePart id. sub_821CC860 has 28 callers, and the upper-case identifiers in that neighbourhood split cleanly into screen names and config keys. Three of the screen names are corroborated by measurements I took before ever opening this function: DIFFICULTY is what NEW GAME opens, EXTRA_MENU is the EXTRAS submenu, TUTORIAL_MENU the lesson list. That is the static side agreeing with the dynamic side on names neither knew about the other. Held at amber deliberately. The 35 strings are what those callers REFERENCE, not proven arguments, and the list plainly mixes screen names with things like TEXT_FONT and GAMMA_RGB. Confirming it means checking per call site which string actually lands in r5, and I did not do that. Still unread: which state leads to which. The three lookups sit in different branches and TITLE_MENU's is guarded by a cmplwi/bne, but I did not trace the branch structure, so the ORDER still comes from measurement rather than from the code.