From c2b940c98b21e20097268197eca98860d69060f3 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 02:20:01 +0000 Subject: [PATCH] docs/re: no ordering field in the runtime element record either MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The next suspect was a role or depth field in the 48-byte element record, so every undecoded word was dumped for all 24 title elements against its paint slot. Clean negative: +0x08, +0x0C, +0x18, +0x1C and +0x2C are zero on 21 of 24 elements, and the three exceptions hold what looks like live animation state. Nothing there orders anything. One confirmation on the way: +0x04 is the declaration entry's `kind`, verified against the file for all 24 — 0x10 on the two .prm elements, 0x4 on the four repeat instances, 0x3000 on the two ptlogoall_eff, zero elsewhere. The record mirrors the file here as the pivot and keyframe count already did. And `kind` does not explain the order either: the paint order interleaves kinds freely. So the ordering is in none of the decoded data — not the declaration entry, not the placement region, not the runtime record. What is left is the loader that appends to +0x30, which is worth reading precisely because the order is deterministic. Stated without promising a static rule exists merely because one could. --- docs/re/structures/ui-screen-runtime.md | 28 +++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/docs/re/structures/ui-screen-runtime.md b/docs/re/structures/ui-screen-runtime.md index f3c17f64..a0de44b9 100644 --- a/docs/re/structures/ui-screen-runtime.md +++ b/docs/re/structures/ui-screen-runtime.md @@ -222,3 +222,31 @@ 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*.