From 89381d70c1cda1f7aa0a81af884fa17b93ba201e Mon Sep 17 00:00:00 2001 From: MechaCat02 Date: Mon, 17 Aug 2026 20:33:45 +0200 Subject: [PATCH] docs/re: the declaration table is not a paint order on every screen Building the Explorer's UI Screens browser turned up a limit on a claim the format doc states flatly. `ui-rat-layout.md` says the element declaration table is the screen's back-to-front draw list, verified 11/11 on the tutorial pause bundle -- and that reproduces exactly here. `GP_TITLE.pak` build 7 does not: painting in declaration order puts the full-screen background art (element 13) over the wordmarks (elements 0-5). Ruled out rather than guessed at: there is no depth key in the 60-byte entry. Across the title build's 30 entries every unknown word is constant, and `+36` -- the one that varies -- is an instance index on the `kind = 0x4` repeated entries, not a layer. Recorded as an open item with the cheapest next step (composite two more screens that have both a background and overlapping foreground, and check whether their background sits adjacent to a `kind = 0x10` PRMD entry as the title's does). The viewer paints in declaration order and does not paper over it, so a screen whose background lands on top is showing this bug rather than a decode failure. Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/BACKLOG.md | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 19585aa1..c4c96792 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -6,6 +6,51 @@ unknown, what evidence exists, and what the first step would be. Move an item in --- +## The declaration table is not a paint order on every screen + +**Found 2026-08-17**, building the Explorer's UI Screens browser on +[`ui_layout`](structures/ui-rat-layout.md). **Status: 🔎 open — the pause menu is +right, the title screen is not.** + +`ui-rat-layout.md` says the bundle's element declaration table lists elements +"in back-to-front order", verified 11/11 on the tutorial pause bundle. That +holds — the tutorial and in-mission PAUSE builds both composite correctly, and +`pgpeff02a` → parent 3 / `pgp_ttrl_btn10` at (546,288) / the 70 px button pitch +all reproduce exactly. + +**`GP_TITLE.pak` build 7 does not.** Painting in declaration order puts +`ptbase2.t32` (the full-screen background art, element **13**) *on top of* the +`ptlogo1`/`ptlogo2` wordmarks (elements **0–5**), which the real title screen +obviously does not do. The pause bundles never caught this because their +elements barely overlap. + +**What has been ruled out:** there is no depth/layer key in the 60-byte +declaration entry. Dumping every word across the title build's 30 entries, the +unknown fields are constant — `+28` is 0 everywhere, `+44` is `0xffffffff` +everywhere, `+56` is 0 everywhere — and `+36`, which the doc lists as +`0xffffffff`, is not a depth either: it is `0`/`1` **only** on the `kind = 0x4` +repeated-instance entries (`ptlogo1`/`ptlogo2` copies), i.e. an instance index. +So the order is not recoverable by sorting the table on any field it carries. + +**What that leaves.** The background group is contiguous — elements 12, 13, 14 +are `pteff00.prm`, `ptbase2.t32`, `pteff04.t32`, and 12 carries `kind = 0x10`, +a flag no pause element has (theirs are `0x0` / `0x1` / `0x3002`). `pteff02.prm` +at 17 has it too. So `0x10` marking a `PRMD` primitive, and primitives opening a +layer that draws beneath what precedes them, is the cheapest hypothesis — but it +is a **hypothesis**, and "draw the `.prm` group first" would fit this one screen +without being evidence of anything. + +**First step:** composite `GP_MISSION_SELECT` / `GP_READY_ROOM` / `GP_OPTIONS`, +which have both a background and overlapping foreground elements, and see +whether their background sits at a `0x10`-adjacent index too. Two more screens +agreeing turns the hypothesis into a rule; one disagreeing kills it. The +Explorer's `screen render`/`screen info` commands make that a minute's work per +screen, and the per-element visibility toggles isolate a suspect element. + +**Meanwhile** the viewer paints in declaration order and does not pretend +otherwise — a screen whose background lands on top is showing you this bug, not +a decode failure. + ## Capital ships assemble wrong in the viewer **Reported:** 2026-07-30, by the user. **Status:** ✅ **format-side cause found and