The Decoder answered H3 in both halves (a482d9a, against a pre-registration
committed before they read the capture) and refuted two things I published an
hour earlier. Both are struck in place, not deleted.
1. units/frame is 2, not the 5 I inferred. Three consecutive gap-free steps of
exactly 23 on ptbtn00's own ramp; 255*2/22 = 23.18. My 4.4-frame prediction
is excluded by more than 2x.
My derivation was sound arithmetic on two unsound premises, both mine to
have used:
- an alpha step is not a clock rate. dA/frame = 255*(units/frame)/T, so
elements with different declared T show different steps at ONE clock.
Splash quads step 34 with T=15; the plate steps 23 with T=22.
- my "onsets" were first submissions, and on splash A both quads are
already at a=85 when first submitted -- biased late, and by a different
amount per element because the bias scales with T.
The three intervals agreed with each other because they SHARED the bias.
Three measurements with a common error are one measurement. That is the
shape I should have checked for and did not.
2. My claim that the t=160 anchor collapses `clock: "shared"` is WITHDRAWN. The
anchor is indeed t=160 -- ptcopyright, calibrating to t~168-176 -- but I
falsified the model using the 2.135 s figure, which is the one number the
same capture puts in dispute. Falsifying a model with the quantity that is
itself under dispute is the error. Against the new capture's own labels the
declared 54 and 76 units reconstruct at 44 and 66 -- short by 13-19 % in the
same direction, with empty labels a named candidate for the residual.
`clock: "shared"` stands, and the port keeps it.
Still open and now the only thing left on H3: units/second = 2 x guest fps, and
whether the guest is 30 Hz or 60 Hz is unestablished. 2x60 = 120 units/s puts
the plate at 1.97 s instead of 3.93 s, which is the size of what the human
reported. The Decoder asked me not to move off 60 on their account yet; I have
not.
Separately -- check-all is RED and stays red. verify-screen newly DIFFERS on six
screens outside its allowed set (main_menu, extras, main_menu_jp, extras_jp,
build_12, build_15). Measured, not diagnosed:
* not this iteration's doing, and excluded structurally rather than by a
passing test: sprites are read as bytes and built with
Image.load_png_from_buffer, so they never enter Godot's import pipeline and
the new `--import` step has no path to the drawn pixels;
* the difference is FULL-FRAME, exactly zero on unblended pixels (18 081 of
them agree to a hundredth of a level at ref 199/204/255) and gamma-shaped on
every blended one. That is a blend-SPACE divergence, not moved content;
* scored against live-main-menu.png the port is 16 % closer than the reference
(RMSE 3152 vs 3770) -- an ordering only, since both sides carry this
script's --pose=rest contamination, which has produced a false finding here
before.
Not widened. This allowance has twice been broadened with a reason that turned
out false, and "I measured it but cannot say which renderer is right" is not a
reason. New ask H4: what colour SPACE is the blend evaluated in -- the Decoder
has the equation from shader ucode, not the space.
Refutation attempts: both of this iteration's hits are against my own page from
last iteration. The Decoder's units/frame law and their anchor measurement both
survived the only check I could make of them -- their steps reproduce this
export's declared T on two screens at one clock.
Not settled: guest fps; which renderer's blend space is right; H1 (key repeat).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
da7864e499