From f66e9de4304fb687942e7b1721a47e3122ce738d Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 02:32:31 +0000 Subject: [PATCH] docs/re: the paint-order item now has a landed fix, not just a finding BACKLOG said the viewer paints in declaration order and the title composites wrongly. That is no longer true for the two builds with measured orders, so the entry says what landed, what it exposed (the kind=0x4 ghosts), and what is still open: deriving the order for screens nobody has captured. The order is deterministic, so a rule exists; it is not in any decoded structure, and the loader is what is left to read. --- docs/re/BACKLOG.md | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 4f7201e..0e68c1b 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -15,12 +15,21 @@ and checked against the draw capture: the seven nameable elements sit at child slots 0, 6, 7, 13, 16, 17, 22, strictly ascending, in exactly the captured order. See [`structures/ui-screen-runtime.md`](structures/ui-screen-runtime.md). -**Still open, and it is what the port actually needs:** deriving that order from -the bundle without running the game. The order is structured (elements sharing a -sprite are adjacent; full-screen effects lead), so it looks derivable, but no -rule has been found. Until then the viewer paints in declaration order and the -title screen composites wrongly — a known, documented defect rather than a -mystery. +**Landed rather than left open** (2026-08-19): the compositor now paints in the +**measured** order for the two builds that have been read off the running game +(the title build and the GAME ARTS/SETA/anima splash) and falls back to +declaration order elsewhere. Rendering that exposed a second defect the same +capture settles — `kind = 0x4` elements are motion-trail ghosts, absent at rest — +and the title now composites correctly +([`captures/title-composited-measured-order.png`](captures/title-composited-measured-order.png)). +Disc-gated test, checked both ways. + +**Still open:** deriving the order from the bundle for screens nobody has +captured. It is not in the declaration entry, the placement region or the runtime +element record (all measured); what remains is the loader that builds the child +list. The order is deterministic across boots, so a rule exists — it just has not +been found, and every screen without a measured order still paints in declaration +order. The investigation that got here follows, kept in full because most of it is refutations that were worth the cost.