The Decoder caught the title's build-in on the console and found ptlogo_back2eff3
never drawn -- not a miss, but phase: a flash's peak is 2 keyframe units, 0.85 of
a presented frame at that pacing, so the console shows a SUBSET on any given
play. The warning was that drawing all five would read heavier than the real
thing.
Checked rather than reasoned about. Sweeping the build-in with --no-hold, the
port draws them sequentially -- eff1 at t54-56, eff2 at 58-60, eff3 at 60-62,
eff4 at 62-64, eff5 at 64-68 -- never more than two at once, and those only where
their declared windows abut. That is the stagger the disc declares. The pile-up
was the rest() bug and it is fixed.
SO THE DIFFERENCE FROM THE CONSOLE IS PRESENTATION RATE, NOT CONTENT. At 60 fps
each 2-unit flash gets ~2 frames; at the console's pacing it gets 0.85, so some
are skipped. A frame-by-frame comparison of the build-in against a console
capture will show flashes the console missed -- a fact to know rather than a bug
to fix. The settled comparison verify-capture makes is unaffected: at t=198 none
of the five is drawn.
Also recorded: my top-level restriction on the settle window was verified by them
rather than merely accepted ([160,236] width 76 against [269,540] width 271 with
the leaves in, which is an instant after every top-level element has exited); the
120-unit loop is confirmed from the guest's own vertex colour alpha, observed
range 0..80 against a decoded peak of 80, with the decoded ramp fitting at RMS
13.16 against 38.18 reversed; and a trap for any future draw-stream tooling here
-- a 2D draw's identity is its vertex geometry, not its bound texture, because
these sprites sample large shared pages.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
dee6c495ad