Three facts, none of them the thing being looked for:
* the drawing API is enumerable — the renderer accessor the quad emitter uses has
exactly 6 callers, four of them sibling quad emitters;
* sub_823C2990 is a FACTORY, not the singleton accessor its use in the top-level
render function suggested: it allocates 4 bytes plus a 244-byte object from the
heap at [0x828E2B14] and runs the chain that ends at the constructor installing
vtable 0x820b30b4. So a UI item is 244 bytes;
* the 0x823C region holds both the item class and four of the RATC-fourcc
loaders, so bundle parsing and item construction live together.
And the part worth writing down more than any of them: three iterations have
added map without answering the question, and each step has been a plausible next
query rather than a decisive test — the shape of a search that can run forever.
The decisive alternative is costed instead of started: a Canary memory watch on
the UI vertex buffers would report the guest PC that writes them, naming the
emitter and its caller outright. That is real emulator work, and it is now a
choice to weigh against leaving the paint order unresolved, which costs the port
one screen's fidelity and nothing else.
5d5680a0d5