From aaa4ea60b31d4ac910f822dfc8114d64cd13b8f8 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Tue, 28 Jul 2026 19:38:04 +0000 Subject: [PATCH] =?UTF-8?q?re:=20ui=20.rat=20=E2=80=94=20pivot=20field,=20?= =?UTF-8?q?language-independence,=20PRMD,=20and=20a=20tightened=20claim?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow-up decoding on the layout record: - 0x50/0x54 is the sprite PIVOT: exactly half the texture size on 4 of 5 plain sprites. It is a rotation/scale centre, not a draw offset — X/Y remains the top-left, which is what actually reproduces the screenshot. - The records are byte-identical across the English and Japanese bundles: layout is authored once and only the sprites are swapped. That explains pgpbtn01's pivot implying a 226px texture that neither shipped language has. - loop1.rat is NOT the screen composition — it is a looping sprite animation (3-name table + ~30 keyframes at one position). The eff*/deli*/msg draw list is therefore still unfound, and that gap is now stated plainly. - The 380-byte top-level entries are PRMD primitives: a colour plus four explicit corner coordinates for a full-screen quad — the pause dim overlay. The format is tag-driven ('opt ', 'PRMD', 'end '), not a fixed struct. Also demotes one piece of evidence. The screenshot is of the TUTORIAL pause menu, so only pgp_ttrl_* can be checked against it; the in-mission records mapping onto the same screenshot under a constant offset works only because both builds share the 70px pitch and proves nothing. In-mission coordinates are now marked unverified. Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/structures/ui-rat-layout.md | 63 ++++++++++++++++++++++------- 1 file changed, 49 insertions(+), 14 deletions(-) diff --git a/docs/re/structures/ui-rat-layout.md b/docs/re/structures/ui-rat-layout.md index 7bb236f..85e0deb 100644 --- a/docs/re/structures/ui-rat-layout.md +++ b/docs/re/structures/ui-rat-layout.md @@ -38,31 +38,57 @@ menu item, `btnNNf` = that item's **focused** sprite, `eff*` = frame/glow decora ## Record layout -Big-endian u32 throughout (Xbox 360). A minimal record (a static button) is 165 bytes: +Big-endian u32 throughout (Xbox 360), and **tag-driven**: 4-char ASCII tags (`opt `, +`PRMD`, `end `) mark sections, so a record is a stream of blocks rather than a fixed struct. +A minimal record (a static button) is 165 bytes: ``` 0x00 "RATC" magic — a RATC bundle reused as a data record 0x08 u32 payload size +0x14 u32 entry count (loop1.rat: 3, matching its 3 sprite names) 0x18 u32 design width = 1280 0x1c u32 design height = 720 -0x20 char[] the sprite this record places, e.g. "pgpbtn00.t32" +0x20 char[16] the sprite this record places, e.g. "pgpbtn00.t32" +0x50 u32 pivot X = texture width / 2 +0x54 u32 pivot Y = texture height / 2 ... ── placement block ── u32 scale X = 100 (percent) u32 scale Y = 100 u32 tint = 0xffffffff (RGBA, white = untinted) - u32 X ← position + u32 X ← top-left position u32 Y ← u32 time (keyframe records only) ... "opt " u32 len char[len] link to another record, e.g. "pgpbtn00f.rat" ``` +- **X/Y is the sprite's top-left**, not its centre: compositing at these coordinates + reproduces the screenshot, which drawing centred on them would not. +- **The pivot at 0x50/0x54 is half the texture size** — 4 of the 5 plain sprites match + exactly (`pgpbtn00` 86×42 → 43,21; `pgpbtn05` 221×42 → 110,21; `pgptitle` 202×73 → + 101,36; `pgpbtn04` 172×43 → 86,22). It is a rotation/scale centre, not a draw offset. - **Animated elements are a keyframe list.** `pgptitle.rat` (752 B) is the same placement block repeated with a varying trailing `time` field — the PAUSE title's fly-in. - **`opt `** carries a length-prefixed record name. On `pgpbtn00.rat` it points at - `pgpbtn00f.rat`, i.e. *normal state → focused state*. -- Two fields (at 0x50/0x54 in the button records) vary per button and are **not identified**. + `pgpbtn00f.rat`, i.e. *normal state → focused state*. Focused records place their sprite + 42 px left and 8 px up of the base, because the focused art includes the selection ring + that hangs off the left edge; their pivot is a constant (21,25) rather than half-size. +- `loop1.rat` is **not** a screen composition — it is a looping sprite animation: + a 3-name table (`pgpeff34/35/36.t32`) plus ~30 keyframes all at one position. +- The small (380 B) top-level entries are **`PRMD` primitives**, not sprites: a colour and + four explicit corner coordinates `(0,0) (1280,0) (0,720) (1280,720)` — the full-screen + quad that dims the scene behind the pause menu — terminated by `end `. + +### The records are language-independent + +`pgpbtn00.rat` is **byte-identical** in the English and Japanese bundles. The layout is +authored once and only the `.t32` sprites are swapped, which has two consequences: + +- The baked pivot belongs to *whichever build the record was authored from*, not to the + sprite actually shipped beside it. That is why `pgpbtn01`'s pivot (113 → a 226 px wide + texture) matches neither the English sprite (207) nor the Japanese one (148). +- **Do not infer anything about a language from a texture size** — see the traps below. ## Evidence @@ -72,12 +98,18 @@ game, twice, in that order — the records were never fitted to the picture. 1. **Differential.** Across `pgpbtn00/01/04/05.rat`, exactly one field varies and it steps `268 → 338 → 408 → 478` — a constant 70 px pitch — while the field before it is 226 in all four. A vertical menu: constant X, evenly spaced Y. -2. **Against the game.** The three visible items measured at screenshot y-centres - 346.0 / 415.5 / 485.5 — spacing 70.0 and 70.0, and a *single* constant offset maps all - three onto 268 / 338 / 408 to within 0.5 px. -3. **Absolute placement.** The tutorial build's records give 546/288, 546/358, 546/428 and - 540/119, which are framebuffer coordinates directly: compositing the sprites there - reproduces the screenshot (image above). +2. **Absolute placement — the decisive test.** The *tutorial* build's records give + 546/288, 546/358, 546/428 and 540/119. Compositing its sprites at exactly those numbers, + with no offset and no fitting, reproduces the screenshot (image above). +3. **Pivot.** 4 of 5 plain sprites carry exactly half their texture's dimensions at + 0x50/0x54 (above). + +> A caution on step 2, because the first pass here got it subtly wrong: the screenshot is +> of the **tutorial** pause menu, so only the `pgp_ttrl_*` records can be checked against +> it. The in-mission records (X = 226) also map onto the same screenshot under a single +> constant offset — but that only works because both builds share the 70 px pitch, and it +> proves nothing. The in-mission coordinates remain **unverified**: confirming them needs a +> screenshot of a pause during an actual mission. ## Two traps this caught @@ -87,7 +119,8 @@ recording them because a static-only reading would have shipped them: - **Texture width does not identify a language.** English `RESUME` (166 px) and Japanese `再開` (86 px) differ hugely, but Japanese `通信ログ` (148 px) is within a few px of an English label. The first language assignment made here was wrong; rendering the sprites - is the only reliable check. + is the only reliable check. (The records being language-independent makes this worse: + a record's baked pivot implies a texture width that matches *no* shipped sprite.) - **The in-mission and tutorial pause menus are different sprite sets, not one set re-packed.** In-mission is `RESUME / RADIO LOG / OPTIONS / BACK TO TITLE` (4 items, `pgpbtnNN`); the tutorial is `RESUME / OPTIONS / BACK TO MENU` (3 items, @@ -96,8 +129,10 @@ recording them because a static-only reading would have shipped them: ## Next -- `loop1.rat` (1320 B) is the screen-level record — decoding it should give the - draw order and the `eff*`/`deli*` placements that are missing from the rebuild above. +- **The `eff*` / `deli*` / `msg` placements are still missing** — those sprites have no + `.rat` of their own, and `loop1.rat` turned out to be an animation, not a composition. + So the screen's draw list lives somewhere not yet found (the parent RATC's own header + region, or title code). That is the gap between the rebuild above and a complete screen. - 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.