Commit Graph

2 Commits

Author SHA1 Message Date
Sylpheed RE agent
102cc344b3 docs/re: the title paint order is build 4's, carries no depth, and is not in the file
Three findings and two corrections, all against the same capture.

Corrections first, because one of them invalidates numbers already written down:

* **the running screen is build 4, not build 7.** `screen info` defaults to the
  largest build; the game runs a different one, and the two disagree on sprite
  sizes (ptlogo1 822x100 vs 919x113 — the capture says 915x115). Every
  declaration index in the previous entry was against the wrong table. The
  conclusions survive unchanged; the indices are restated.
* **the ship capture does NOT skip these UI draws.** This entry justified a new
  hook partly on "it requires an f32x3 position stream, which a 2D quad does not
  have". These quads have one: armed on the title, xenia_ship_capture_01.log
  holds 1150 records of which 965 are the UI sprite shader. The new hook is
  still the right tool — frame brackets, submission order, texture identity —
  but it was justified with a wrong reason.

Findings:

* **no depth in the geometry.** Attribute 0 is k_32_32_32_FLOAT, so every quad
  carries a Z, and every Z is 0.00000. Submission order is the whole ordering.
* **no ordering field in the bundle.** Every word of build 4's declaration table
  dumped (committed as evidence): the unknowns are constant. The placement
  region's per-group lead word — never read before — is 0 for all 24 groups, and
  the region is followed straight by the RATC child stream, so no table hides
  behind it.
* **the batching rule**, which is what makes the order readable: a draw holds
  one or two quads, and a two-quad draw always holds two elements adjacent in
  paint order that share a texture page. The engine flushes when the page
  changes; it does not sort by page (pages alternate).

Reproduced in an independent run — same order, same rects — which is the second
observation the CONFIRMED bar asks for.
2026-08-18 20:16:05 +00:00
Sylpheed RE agent
9da79b92d6 docs/re: the title screen's paint order, measured from the draw stream
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.
2026-08-18 18:57:43 +00:00