Delivered: T8aD +0x04 bit 0x02 selects additive, so the port derives the blend
instead of transcribing my table -- including for screens neither of us has
captured. With why I got it wrong first: the bit was already in REFUTED.md,
killed by a comparison of two renders made while our renderer had a stale
keyframe association, no leaf geometry and no rotation.
Their asks: pteff10 IS additive on the main menu, three sessions, every frame,
and my coverage table listing it uncovered there is corrected. The sweep ramp is
four leaf keyframes on the disc, with the oracle agreeing on sign and magnitude
and a second identification from the sub-128 alpha. And kind & 0x2 is not mine
to grant -- stated what the decode supports (0 violations in 15493 entries, and
it means the declaration marks the element focusable, not that the cursor can
reach it) and left the adoption to them.
ui-blend-mode-measured.md is superseded in its classification and keeps its
measurements, which are what the decode is fitted to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The four elements the port measured as the worst on EXTRAS, and which appeared
in no draw, were in a draw all along: the 24-index additive batch holds six
quads and Canary printed the first two. Cap raised to 64, screen re-captured,
all six named. Same draw as ptframe3, whose state was already measured -- the
one-way implication doing real work.
pteff10 is identified too, and it needed the resting SCALE: it ships as 409x144
and is drawn at 200 % x 500 % = 816x720. The matcher's 'try 1x and 2x' rule
could not name it at any scale and reported a near miss against something else,
which is a failure wearing the clothes of an answer. Candidates are now the
declaration's pivot*2 scaled by the resting keyframe as well as the texture at
1x and 2x, and the tolerance is the log's own NDC print quantisation rather than
a chosen number.
Flagged rather than buried: pteff10 measuring additive is in tension with the
port measuring it nearly exact under alpha-over. Both can be true for a dim
semi-transparent glow over a dark background, and it is the one row a rendering
check does not corroborate.
Also stated: the three full-screen alpha-over draws are NOT individually
identified -- four elements declare 1280x720 -- so the label on those rows is a
candidate, not an identification.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port checked the coverage claim element by element and it was wrong.
The page said everything on the two screens was covered but for pteff10; on
EXTRAS, ptframe4, pteff21, pteff22 and pteff23 were also in neither the per-draw
log nor a prose row -- and they are exactly the four the port measures as the
worst elements on that screen.
The result rows were never wrong. The claim about what they covered was, and it
is the kind that reads as reassurance.
Also flagged, and fair: 'every button' is a class generalisation in the page
whose own instruction is to read it as per-element facts. It came from one
element on the main menu. Now stated as such.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Two more emulator runs close two of the three reach limits on the blend page.
THE TITLE (entries 4 + 2 composited). Everything alpha-over except the two
rotated sweep strips and -- the finding -- ptbtn00f, the PRESS (A) plate's
focused variant, which is ADDITIVE while its own base ptbtn00 is not. That is
what the documented plate pulse is made of, and a port drawing both alpha-over
cannot reach the pulse's peak by any pacing.
And ptlogo_back2 / ptlogo_back2eff are ALPHA-OVER. They are frame-shaped, large,
dark and 94 %/87 % transparent -- every surface property the menu's ptframe* have
-- so 'frame-shaped and mostly transparent implies additive' is refuted on the
one screen that could test it.
THE MENU replicates draw for draw in two further sessions; the one-session
caveat is retired.
THE VERTEX CAP was 8 = two quads, so a batched draw reported its first two
elements and dropped the rest. Raised to 64. This is why ptframe4, pteff21,
pteff22 and pteff23 looked like elements the game never draws: EXTRAS' 24-index
additive draw holds six quads and the log printed two.
THE SWEEPS are on screen on the main menu in every captured frame, stepping
~0.03 NDC per frame in opposite directions with their vertex alpha ramping, at
different phases in two sessions. The leaf group runs on the menu. What that
does not say is how much they contribute.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
I wrote that yesterday in HANDOFF, the finding page and INDEX. It is false: in
one main-menu frame, draws 5, 6 and 7 are three separate additive draws --
consecutive, identical blend state, not merged.
Only the one-way implication holds: elements inside one draw share a blend
state; sharing a state does not put elements in one draw. The wrong version
would have licensed the port inferring a mode for an element nobody observed,
which is the one thing that page must not do. The ptframe4 conclusion is
unaffected -- it is in the same DRAW as ptframe3, not merely the same mode.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Closes the one route t32-blend-mode-not-on-disc.md left open: the executable's
draw path. Canary's UI draw capture now logs RB_BLENDCONTROL0 per draw, and the
game was driven to the main menu and to EXTRAS with F10 at each.
The title-side UI uses two blend states and ONE pixel shader:
0x07010701 src=ONE dst=1-SRC_ALPHA alpha-over (premultiplied)
ptbase, pteff05, the fade quad, ptmsg, ptmsg2, pttitle, buttons
0x01010101 src=ONE dst=ONE ADDITIVE
ptframe1, ptframe2, ptframe3, pteff20, both rotated sweep strips
Two controls, both run before the result was read:
* the NDC->pixel conversion that identifies a draw by its quad size reproduces
1134 and 1303 px for the two rotated sweep strips -- numbers measured by a
different tool in a different session -- on BOTH screens. The tool prints
PASS/FAIL and disclaims its own output on FAIL.
* pixel shader 0xE59B2B3DA4AA9008 is used with BOTH states, 12 draws additive
and 18 alpha-over. ptframe1 and ptbase run the same shader; only the blend
register differs. So this is a blend result, not a shader result.
This confirms the port's independent measurement -- it solved the composite per
pixel from two backgrounds and found additive halves alpha-over's error on both
frames -- by a route with nothing in common with it.
So the blend is no longer authored: 'any blend you choose is authored' was true
of the disc and is not true of the game. What is still unknown is which field
selects it; elements sharing a mode are batched into one draw call, so the
selection happens before the draw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
