04a3ae1389
Last iteration I claimed the splash's measured_paint_order [0,2,4,6,1,3,5]
records, between its glow and logo halves, the temporal order they were
seen in rather than depth -- because the halves never share a frame.
The no-overlap measurement is right (glows f94-115, logos f116-211). The
inference is wrong, on two independent grounds:
* Wrong source. That vector is not a read of the draw capture. It is a
read of the live screen object's CHILD ARRAY -- ui-screen-runtime.md
records it literally as "paint order (child slots)". A child list has
a definite order whether or not its children are ever drawn together,
so co-occurrence does not bear on it. The capture was the CHECK.
* The order is in the file anyway. paint_order_audit on GP_TITLE entry
11: derived == measured, 0 inverted pairs, 0 same-layer-key ties. The
glows and logos carry distinct T8aD keys (0xa100 < 0xa110), so the
file orders the halves statically, no capture involved.
I asked the question that started this iteration -- do the title and menu
orders have the same problem -- and the answer is that none of the three
does, for the same reason.
What survives is narrower and now recorded with numbers: how much of each
order its capture actually cross-checks. The title capture is stable (8
draws / 12 quads / 5 textures, identical in all five captured frames
across two logs) and confirms 7 of 24 positions; the menu capture is not
(texture 0x11C30000 present in frame 0, gone by frame 3); the splash
capture cannot cross-check its middle at all.
A counting trap worth the tool: count QUADS, not draws. The menu's draw 9
is indices=24 -- six quads batched from one texture. Counting draws reads
9 where 16 are on screen, and an earlier pass of this analysis briefly
"found" three quads for six declarations that way and concluded elements
were missing. They were batched.
METHOD: check what a "measured" value was measured FROM before reasoning
about its limits. The co-occurrence rule is real, and it is specific to
orders read from draw captures.
24 lines
1.1 KiB
Plaintext
24 lines
1.1 KiB
Plaintext
# How much of each recorded paint order its draw capture actually cross-checked.
|
|
# 2026-08-29, tools/re-capture/order_crosscheck_reach.py
|
|
#
|
|
# The three measured_paint_order vectors are reads of the runtime CHILD ARRAY
|
|
# (ui-screen-runtime.md: "paint order (child slots)"). These captures are the
|
|
# cross-check, not the source. Quads = indices/4: a single draw can carry
|
|
# several (the menu's draw 9 has indices=24 = 6 quads), so counting draws
|
|
# under-reads what is on screen.
|
|
|
|
== docs/re/captures/title-screen-draw-order.log
|
|
frame 1: 8 draws, 12 quads, 5 textures
|
|
frame 2: 8 draws, 12 quads, 5 textures
|
|
frame 3: 8 draws, 12 quads, 5 textures
|
|
textures in EVERY captured frame: 5 of 5
|
|
== docs/re/captures/title-draw-order-with-alpha.log
|
|
frame 1: 8 draws, 12 quads, 5 textures
|
|
frame 2: 8 draws, 12 quads, 5 textures
|
|
textures in EVERY captured frame: 5 of 5
|
|
== docs/re/captures/main-menu-draw-order.log
|
|
frame 0: 9 draws, 16 quads, 5 textures
|
|
frame 3: 7 draws, 9 quads, 4 textures
|
|
textures in EVERY captured frame: 4 of 5
|
|
absent from some frame: ['11C30000']
|