fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs/re: the paint-order item now has a landed fix, not just a finding

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-19 02:32:31 +00:00
parent c3c79ad028
commit f66e9de430
1 changed files with 15 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/re/BACKLOG.md
View File

@@ -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.