82b4a9e523
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.