# The UI screen object at runtime — found in live guest memory **Status:** ✅ `CONFIRMED` for the object's identity and its element array (five independent field matches against the file, on a running game). 🟡 the remaining arrays are unidentified. ❔ nothing here settles the paint order — see the "what this does not answer" section, which is the reason the search happened. ## How it was found, in one step The item class from the emulator-era splash work has vtable **`0x820b30b4`**, and `sub_823C2990` allocates its objects at **244 bytes** each ([`ui-quad-class-foothold.md`](../ui-quad-class-foothold.md)). A vtable pointer is a fixed 4-byte value at offset 0 of every instance, so the objects are findable in the live guest image without a debugger: ```bash tools/re-capture/gmem.py find hex:820b30b4 # while the title screen is up ``` Seven live objects, at `0xBCD24D88`, `0xBCD25188`, `0xBCD25388`, `0xBCD25488`, `0xBCD25588`, `0xBCD25688`, `0xBCD26488` — spaced 0x100 apart, consistent with a 244-byte object plus allocator overhead. ## What they are Each object begins with **two** vtable pointers (`0x820b30b4`, `0x820b31a4` — multiple inheritance) and then a run of `{pointer, count, capacity}` triplets. The counts identify the objects immediately: | object | first triplet's count | which `GP_TITLE` build | |---|---|---| | `0xBCD25188` | **7** | builds 0/1 — the loading overlay (7 elements) | | `0xBCD25388` | **24** | **build 4 — the title (24 elements)** | | `0xBCD24D88` | **1** | builds 2/3 — the `PRESS Ⓐ BUTTON` bundle (1 element) | So the three bundles this project decoded statically are all resident, with the element counts the files declare — including the two-bundle composition of the title screen that the draw capture inferred. ## The element array `+0x08` of the screen object is `{ptr, count, capacity}` pointing at an array of **48-byte entries, one per element, in declaration order**. Verified field-by-file at five positions on the title build, with no misses: | index | file says (build 4) | live memory at `+0x10`/`+0x14` | |---|---|---| | 0 | `ptlogo1.t32` pivot (451,50) | 451.0, 50.0 | | 1 | `ptlogo2.t32` pivot (449,46) | 449.0, 46.0 | | 6 | `pteff01.t32` pivot (320,160) | 320.0, 160.0 | | 9 | `ptbase2.t32` pivot (320,180) | 320.0, 180.0 | | 21 | `ptcopyright.t32` pivot (309,10) | 309.0, 10.0 | Entry layout as far as it is read: ``` +0x00 u32 pointer (per-element data) +0x04 u32 0 +0x08 u32 flags (0x10081021 on element 0) +0x0C u32 ? +0x10 f32 pivot X ← the declaration entry's pivot, as a FLOAT +0x14 f32 pivot Y +0x18 u32 0 +0x1C u32 ? +0x20 u32 pointer } +0x24 u32 count } the element's KEYFRAMES — 8/8 on elements 0 and 1, +0x28 u32 capacity } which is exactly their keyframe count in the file +0x2C u32 ? ``` So the pivot and the keyframe group, which this project reads out of the bundle, are present at runtime in the same order and with the same values. ## What this does not answer **The paint order.** The array is in *declaration* order, and the capture proves the screen is not painted in that order, so the renderer either walks something else or sorts. Three more `{ptr,count,capacity}` triplets are present in the screen object and unidentified — `+0x14` (24 entries of 12 bytes, each `{ptr,1,1}`, pointing into a densely packed region), `+0x24` (2 entries) and `+0x30` (24). The `+0x14` one is *not* an index list (its entries are pointers, not small integers), so the obvious "draw order table" reading is already out. **What is better than before:** the question is now a *data* question on a live structure that can be dumped in seconds, rather than a code-reading exercise. The next probe is to dump `+0x24` and `+0x30` on the title build and see whether either is 24 entries in a non-declaration order. ## ✅ The paint order is the screen object's CHILD array at `+0x30` **Status: `CONFIRMED`.** The question this project has carried since the first capture — *what orders the elements, given that the declaration table does not* — is answered: the screen object holds a **second list**, a reordering of the elements built at load time, and that list is the paint order. `+0x30` is `{ptr, count, capacity}` → an array of **24 pointers** (not 12-byte records like `+0x14`). Each pointer is the `+0x00` field of one of the 48-byte element records, so the two arrays hold the same objects in different orders. The permutation, read live off the title screen: | child slot | element | | child slot | element | |---|---|---|---|---| | 0 | 9 `ptbase2` | | 12 | 17 `back2eff4` | | 1 | 11 `ptloop01` | | 13 | **0 `ptlogo1`** | | 2 | 12 `ptloop02` | | 14 | 2 `ptlogo1` (copy) | | 3 | 10 `pteff04` | | 15 | 4 `ptlogo1` (copy) | | 4 | 13 `pteff02.prm` | | 16 | **7 `ptlogo_tm`** | | 5 | 6 `pteff01` | | 17 | **1 `ptlogo2`** | | 6 | **20 `ptlogo_back2eff`** | | 18 | 3 `ptlogo2` (copy) | | 7 | **19 `ptlogo_back2`** | | 19 | 5 `ptlogo2` (copy) | | 8 | 14 `back2eff1` | | 20 | 22 `ptlogoall_eff` | | 9 | 15 `back2eff2` | | 21 | 23 `ptlogoall_eff2` | | 10 | 18 `back2eff5` | | 22 | **21 `ptcopyright`** | | 11 | 16 `back2eff3` | | 23 | 8 `pteff00.prm` | ### Checked against the capture, not merely plausible The seven elements the draw capture can name occupy child slots ``` ptbase2 0 back2eff 6 back2 7 ptlogo1 13 tm 16 ptlogo2 17 copyright 22 ``` — **strictly ascending, in exactly the captured submission order**. Two details make this more than a coincidence of a short list: * it **resolves the ambiguity** that no static field could: slot 6 is element **20** (`ptlogo_back2eff`), slot 7 is element 19, so the pair paints 20-then-19 — *descending* in declaration terms. Nothing in the file predicts that, and the runtime list states it; * the three `kind = 0x4` repeat instances of each logo sit **immediately after their template** (slots 13,14,15 and 17,18,19), which the declaration table interleaves (0,1,2,3,4,5). They draw at α=0 and so never appeared in the capture, but their placement in the list is consistent with the grouping. ### What this means for the port, stated carefully The reimplementation cannot read a runtime array — it has to *derive* this order from the bundle. **That derivation is not solved.** What the order shows is structure worth attacking: elements sharing a sprite are adjacent (`ptlogo1`×3 together, `ptlogo2`×3 together, the `back2eff*` family together), and the full-screen/effect elements lead. So the load-time build is doing some grouping, not an arbitrary shuffle. Until it is derived, a reimplementation has two honest options: hard-code the captured order for the screens that have been captured, or paint in declaration order and accept that the title screen composites wrongly. The first is what the evidence supports; the second is what the viewer does today. ## Two ground-truth permutations, and what they rule out Deriving the child order from the bundle is what the port needs, so the first step is data. Both live screen objects with more than one element, read off the title screen: **The developer-logo splash** — `GP_TITLE.pak` entries 11/14, identified by matching its pivots against every 7-element build on the disc. It is the GAME ARTS / SETA / studio anima screen, i.e. the one the emulator-era Milestone 1 worked on: ``` 0 palogo_eff0.prm (640,360) 1 palogo_gamearts (250,36) 2 palogo_gamearts_eff (260,46) 3 palogo_seta (120,44) 4 palogo_seta_eff (130,55) 5 palogo_anima (194,68) 6 palogo_anima_eff (204,78) ``` ``` paint order (child slots): 0 2 4 6 1 3 5 ``` — which, with the names, reads as **the full-screen `.prm`, then all three `_eff` glows, then all three base logos**. The glow behind, the logo on top: a semantic grouping, and one that the declaration table interleaves (base, glow, base, glow, …). **This refines the "grouped by sprite" reading.** Here every element has its own sprite, so the grouping cannot be by sprite identity — it is by *role*. In the title build the two readings coincide (the three `ptlogo1` instances share both a sprite and a role), so that build alone could not tell them apart. **The 24-element title build:** ``` paint order: 9 11 12 10 13 6 20 19 14 15 18 16 17 0 2 4 7 1 3 5 22 23 21 8 ``` ### What the pair shows * **The list is grouped, not shuffled.** Elements sharing a sprite are contiguous: `ptlogo1`'s three instances (0,2,4) at slots 13–15, `ptlogo2`'s (1,3,5) at 17–19, the `back2eff*` family at 8–12. The 7-element bundle's even/odd split is the same phenomenon in miniature if its evens and odds are two sprites. * **The five single-keyframe elements lead.** In the title build, exactly elements 9, 10, 11, 12, 13 have one keyframe, and the child list opens with 9, 11, 12, 10, 13 — all five, before anything animated. That is unlikely to be chance (5 of 24 in the first 5 slots), and it is a *file-visible* property. ### Refuted as the ordering key, on this data * **first-keyframe time** — `back2eff1` starts at t=52 and paints *after* `back2` (t=66); * **resting-keyframe time** — same pair, 56 against 80; * **declaration order and its reverse** — neither, obviously; * **the RATC child (sprite) order** — the group order does not ascend in it (`ptbase2` is RATC child 4 and paints first; `ptlogo1` is child 0 and paints fourteenth). ### The order is deterministic Two independent boots, the same screens: **byte-for-byte identical permutations** (and identical object addresses). So the child list is not built in I/O-completion order or anything else run-dependent — it is a pure function of the bundle, and therefore derivable in principle. That was worth testing before hunting for a rule, because a load-order-dependent list would have made the hunt pointless. **Not settled:** the rule itself. What is known is that the list groups elements by role — glows before bases, instances beside their template — which the declaration table interleaves. What is not known is where that role comes from: no decoded field carries it, and the names (`_eff`) are suggestive but a loader sorting on a name suffix would be unusual. The next step is the loader — the code that appends to `+0x30` — which is now worth reading precisely *because* the order is deterministic. ## The runtime record carries no ordering field (measured) The obvious next suspect was a role/depth field in the 48-byte element record, so every undecoded word was dumped for all 24 title elements next to its paint slot. The result is a clean negative and one confirmation: * **`+0x04` is the declaration entry's `kind`**, verified against the file for all 24: `0x10` on the two `.prm` elements (8 and 13), `0x4` on the four repeat instances (2,3,4,5), `0x3000` on the two `ptlogoall_eff*` (22,23), zero elsewhere. So the record mirrors the file here, as the pivot and keyframe count already did. * **Every other undecoded word is zero** — `+0x08`, `+0x0C`, `+0x18`, `+0x1C`, `+0x2C` are `00000000` on 21 of the 24 elements. The three exceptions (elements 0, 1, 2) hold values that change nothing about ordering and look like live animation state rather than static fields. So **nothing in the element record orders the elements**, and `kind` does not either (the paint order interleaves kinds freely). Combined with the earlier result that no field of the 60-byte declaration entry does, and that the region after the placement groups is the RATC child stream, the ordering does not live in the data this project has decoded. **What remains is the loader**: the code that appends to `+0x30`. It is worth reading now — the order is deterministic, so that code is a pure function of the bundle — but it is a code-reading task, and this note is careful not to promise that a static rule exists just because one *could*.