102cc344b3
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.
880 B
880 B