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

re: the UI screen gap is closed -- the bundle also carries every element's placement

Browse Source 
Immediately after the declaration table the RATC bundle holds a placement region,
one group per element: a header of (u32 element index, u32 keyframe count)
followed by that many 40-byte keyframes carrying scale/tint/X/Y. The element
index is stated in the header, so the correspondence is read, not inferred from
order.

Tutorial pause bundle: 11 groups for 11 elements, every header index and count
matching the blocks present. The values are self-evidently right -- three menu
buttons at X=546 exactly 70 px apart (288/358/428), title (540,119), message
(451,545), and the eff* sprites carrying multi-position fly-ins.

Cross-checked: pgp_ttrl_btn10.rat places its own sprite at (546,288), identical
to its inline group, so the inline region is the same placement data and it
covers the eff*/deli*/msg elements that have no record of their own.

So a screen is fully reconstructible from its bundle alone: element list and
order from the declaration table, placement and animation from this region,
plus the sprites, with "opt " supplying focused states. This retires the caveat
added earlier today that only the order was known.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-11 21:58:21 +00:00
parent dd8770826b
commit f65387143e
2 changed files with 27 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/re/structures/ui-rat-layout.md
View File

@@ -196,9 +196,32 @@ recording them because a static-only reading would have shipped them:
`btn00/01/04/05.rat`, `msg`, `deli1…4`, `eff30…33`, `loop1.rat`. Note what it does
**not** list: the focused button variants, which are reached through each base record's
`opt ` link — so the table is the screen's element set, not a resource inventory.
- **What is still missing is only the position** for the elements that have no `.rat`:
the declaration entry carries a pivot but no X/Y. So *what* is drawn and *in what order*
is answered; *where* the `eff*` / `deli*` / `msg` sprites land is not.
- **And the position is there too — the gap is closed.** Immediately after the
declaration table the bundle carries a **placement region, one group per element**:
```
group header: u32 element index (0,1,2… — the correspondence is stated, not inferred)
u32 keyframe count
then `count` keyframes, 40 bytes apart, each holding the familiar block:
u32 scale X = 100 u32 scale Y = 100
u32 tint = 0xffffffff
u32 X u32 Y (+ a trailing time field)
```
For the tutorial pause bundle this yields 11 groups for 11 elements, and every
group's header index and count match the blocks actually present. The values are
self-evidently right: the three menu buttons sit at X=546, **70 px apart**
(288 / 358 / 428), the title at (540,119), the message at (451,545), and the
`eff*` sprites carry multi-position fly-ins.
**Cross-checked against the records themselves:** `pgp_ttrl_btn10.rat` places its
sprite at **(546,288)** — identical to its inline group. So the inline region is
the same placement data, and it covers the `eff*` / `deli*` / `msg` elements that
have no record of their own.
A screen is therefore fully reconstructible from its bundle alone: **element list
and order** (declaration table) + **placement and animation** (this region) +
sprites, with `opt ` supplying focused states.
- The same method should now unroll the other screens directly; `GP_HANGAR_ARSENAL.pak`
(789 T8aD + 510 RATC) is the big one, and the ARSENAL `DATA SHEET` panel documented in
[weapon-datasheet-runtime.md](../weapon-datasheet-runtime.md) is a ready-made oracle for it.