fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

docs/re: the title screen's paint order, measured from the draw stream

Browse Source 
BACKLOG's UI-ordering item ended at "the next step is no longer static — it is a
per-draw capture of the title screen showing the order the game submits". That
capture now exists.

The order, in submission order: a full-screen background layer, a rotated effect
pair, a second full-screen layer, ptlogo_back2eff + ptlogo_back2, ptlogo1 +
ptlogo_tm, ptlogo2, ptcopyright, and the PRESS (A) BUTTON plate — declaration
indices 13, 22|24, 23, 0, 11, 1, 28, and then two elements that are not in that
build at all.

Two more candidate orderings die on it (keyframe start time, resting-keyframe
time), and one structural fact reframes the item: the visible screen composites
TWO bundles — build 7 plus the one-element build 2 that is the button — so no
single build's element table can be the paint order whatever its order. The
button's quad lands at (384,551) against a declared rest of (383,550), which is
a one-pixel agreement between the static placement decode and the running game
on a bundle nothing had checked.

INDEX's "the screen's draw list is the bundle's declaration table (back-to-front)"
is demoted in place rather than edited away.

Still open and said so: the rule that produces the order; three of twelve quads
unidentified; one screen only.
This commit is contained in:
Sylpheed RE agent
2026-08-18 18:57:43 +00:00
parent 81b391d8d5
commit 9da79b92d6
5 changed files with 236 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/re/BACKLOG.md
View File

@@ -122,6 +122,27 @@ the other two are — and therefore a `build-canary` run. That is the cost to
state up front rather than discover halfway in; it is not a container
limitation, just a long build plus a title-screen run.
### 2026-08-18 (later) — the hook was built and run; the order is now measured
`log_ui_draws` exists (Canary branch `auto/re-ui-draw-order`), and the title
screen's paint order is **ground truth** rather than a candidate:
[`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md).
Background first, then the `back2` glow pair, then `ptlogo1` + `ptlogo_tm`, then
`ptlogo2`, then `ptcopyright`, then the `PRESS Ⓐ BUTTON` plate — i.e.
declaration indices `13, 22|24, 23, 0, 11, 1, 28` and then two elements that are
**not in build 7 at all**. Two more orderings die on that evidence (keyframe
start time, resting-keyframe time), and one structural fact reframes the whole
item: the screen composites **two bundles** (build 7 plus the one-element build
2 that is the button), so no single build's element table can be the paint order
whatever its order.
**Still open, and now sharper:** the rule. The bundle's 60-byte declaration entry
carries no depth field (dumped, above); the per-element `.rat` record has not
been checked for one against this ground truth, and nothing yet explains how the
two bundles are sequenced. Both are static questions again — the oracle side is
answered.
## Capital ships assemble wrong in the viewer