Investigating the V4c connected blank-world failure needed two things the tree
did not have: a way to tell whether a blank run is caused by the binary under
test, and a way to see GL state at the end of the world phase rather than only
at the frame clear. Both are apparatus only - no production behaviour changes,
and the new probe emits nothing unless ACDREAM_PROBE_GLSTATE=1.
run-blank-world-ab-probe.ps1 interleaves two client builds over the repeat
gate's exact connected route and reports the blank rate per arm. This exists
because the blank rate is not stable across blocks: the same V4c binary
measured 3/10 in one block and 7/10 in another an hour later, so a block of A
followed by a block of B confounds the change with whatever else moved on the
machine in between. Strict alternation shares that drift between both arms.
Run against V4c and its parent it reported 4/5 versus 0/5 (Fisher exact
p~0.024), which is what established the defect follows the binary.
run-blank-world-surface-probe.ps1 grabs the composited window off the desktop
with CopyFromScreen at the same moment the client writes its own screenshot.
No instrument inside the GL context can separate "the renderer drew nothing"
from "the read did not return what the renderer drew", because both live on
the same side of the readback; an independent witness can. It is what showed
the two disagree - see below.
EmitPostWorldGlStateIfChanged is a second sample of the existing [gl-state]
snapshot, taken at the end of the normal-world phase. The existing tripwire
samples just after the clear phase's RestoreFrameDefaults, so it can only
observe state that survives from one frame into the next, and the draw
framebuffer is restored by no frame-global path. A binding established during
the world phase and put back before the next clear was therefore invisible to
it. Sampling at both ends brackets the phase.
What the apparatus established, recorded here rather than in the campaign doc
because no fix landed and the doc's re-land conditions are unchanged:
* The world draw path is not what is missing from the frame. On a blank run
the desktop grab shows the atmosphere clear over the whole viewport and the
complete retained UI - chat, radar, toolbar, vitals - in their normal
places, with every 3-D surface absent. Terrain and sky are still raw GL and
V4c does not touch them, so whatever V4c disturbs is shared, not per-
renderer.
* The CPU issues the same work either way. With ACDREAM_PROBE_FLAP=1 the
render signature is identical between blank and rendered runs: same
RetailPViewInside branch, same resolved root, terrain drawn, 3,331 outdoor
statics and 6 live dynamics dispatched.
* Both GL-state samples read fbo=0, full 1280x720 viewport, scissor off and
err=0x0, byte-identical between blank and rendered runs.
* The client's own capture disagrees with the screen. glReadPixels returns
uniformly RGBA(0,0,0,0) on a frame the desktop grab shows as fog plus UI.
The default framebuffer is 4x multisampled (SampleBuffers=1, Samples=4 in
the capability report) and glReadPixels against a multisampled read
framebuffer is undefined per the GL spec, so the gate's blank-versus-
rendered verdict rests on undefined behaviour in both directions.
Baseline App tests 3,864 passed / 3 skipped, unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Erik