From ba516a3dfab323b3a44668e2678f69b2c2b89d74 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 02:08:50 +0000 Subject: [PATCH] docs/re: the paint order is deterministic, and the 7-element screen is the logo splash MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two things this iteration, both of which change what is worth doing next. The order is DETERMINISTIC: two independent boots give byte-for-byte identical permutations for both live screens. That kills the hypothesis that the child list is built in I/O-completion order — which mattered, because a run-dependent list would have made deriving a rule pointless. It is a pure function of the bundle. And the 7-element bundle is identified by matching its pivots against every 7-element build on the disc: it is the developer-logo splash (GAME ARTS / SETA / studio anima, GP_TITLE entries 11/14). With names attached, its paint order 0 2 4 6 1 3 5 reads as the full-screen .prm, then all three _eff glows, then all three base logos — glow behind, logo on top. That refines the earlier "grouped by sprite" reading and partly withdraws it: here every element has its own sprite, so the grouping is by ROLE, not sprite identity. The title build could not tell the two apart because its repeated logo instances share both. Still not derived: where the role comes from. No decoded field carries it, and sorting on a "_eff" name suffix would be an odd thing for a loader to do. --- docs/re/structures/ui-screen-runtime.md | 42 ++++++++++++++++++++----- 1 file changed, 35 insertions(+), 7 deletions(-) diff --git a/docs/re/structures/ui-screen-runtime.md b/docs/re/structures/ui-screen-runtime.md index 6b288fa0..f3c17f64 100644 --- a/docs/re/structures/ui-screen-runtime.md +++ b/docs/re/structures/ui-screen-runtime.md @@ -153,15 +153,30 @@ 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: -**A 7-element bundle** (pivots `(640,360) (250,36) (260,46) (120,44) (130,55) -(194,68) (204,78)` — three pairs 10 px apart plus a full-screen layer): +**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 ``` -— the **even** declaration indices in order, then the **odd** ones. A stable -partition into two groups, nothing more. +— 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:** @@ -191,6 +206,19 @@ 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 (`ptbase2` is RATC child 4 and paints first; `ptlogo1` is child 0 and paints fourteenth). -**Not settled:** the rule. Two permutations are enough to kill the simple -candidates and not enough to build the real one — the group *contents* are -explained (same sprite), the group *order* is not. +### 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.