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) <noreply@anthropic.com>
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user