fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs/re: no ordering field in the runtime element record either

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-19 02:20:01 +00:00
parent 72afde7115
commit f35a871baa
1 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/re/structures/ui-screen-runtime.md
View File

@@ -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*.