Two things, and both are about a hidden parameter nobody was recording.
1. THE STICK THRESHOLD IS DECODED NOW, and it replaces an authored value.
The Decoder measured that the game digitises the left stick to four direction
bits at 61 % deflection, so it never sees a velocity. Gamepad.ENTER moves
0.5 -> 0.61. The 0.5 was never a chosen value: it was a FLOOR, because Godot's
`ui_*` action deadzone is 0.50 and the latch must not arm below it. Between 0.50
and 0.61 Godot reports a direction the real game does not, and at 0.5 this port
stepped there.
The mechanism also corroborates the human's latch fix rather than merely
agreeing with it: a control that digitises to bits cannot express a rate, so
"one step per deflection" is what the hardware layer CAN produce.
⚠️ The 0.11 hysteresis gap stays AUTHORED -- nothing says the game has
hysteresis at all. And a human chose 0.5, so this changes feel: revert the one
constant if 0.61 reads as needing too much push.
🔴 AND THE CONTROL CAUGHT MY FIRST ATTEMPT AT ASSERTING IT. I added the new
device-level row as subject "latch", and `verify-input --control` failed
immediately with "a check did not invert -- it is not testing what it claims to
test". It was right: removing the latch does not remove the THRESHOLD, the
unlatched path tests `>= Gamepad.ENTER` too, so 0.55 counts 0 either way and the
row could never invert. It is a NEGATIVE, and its positive control is the 0.70
row on the same shape. Reclassified.
That also exposed a smaller thing: ok()'s negative branch HARDCODED "positive
control is the stick row", so a second negative would have borrowed someone
else's green line. It now takes the control's name, defaulting to the original
text so the d-pad row is unchanged.
✅ I never consumed the pad bit table they have just corrected -- checked by grep
over port/, authored/ and tools/port/, not remembered.
2. MY verify-screen NUMBERS WERE llvmpipe-SPECIFIC, and the prediction failed.
Pre-registered: both renderers blend in encoded 8-bit space, so the diffs should
be identical or within 1 level on the GPU. They are not -- every mean rose 3-35 %:
title 0.4431 -> 0.5936, main_menu 3.9363 -> 4.1449, extras 6.7422 -> 6.9757,
title_jp 2.7715 -> 2.9448, main_menu_jp 0.7885 -> 1.0157, extras_jp 0.6592 ->
0.8906, build_12/15 0.0368 -> 0.0454.
But the MAXIMA are unchanged -- 41, 97, 113, 233, 17 identical, 26 -> 27 on one
row. That is a rounding population growing, not content moving: two rasterisers
round the last bit of a blend differently while the elements that genuinely
differ do not move.
Survives: the additive diagnosis, because it rests on an ORDERING and the
ordering holds (9 elements > 5 > 0); the pgloading_loop5 localisation; the
build_00/01 agreement; the derived allowance, same four failing rows.
Does not, and is now labelled: the histogram (53 % within 1 level, 16 844 over
40); every absolute mean; and the RMSE-vs-capture pair 3151.96 / 3769.61 -- that
ORDERING claim is not re-derived on the GPU and is not claimed until it is.
The rule this earns: a renderer comparison carries its RASTERISER as a hidden
parameter. Nothing here recorded which one produced a diff, and for months there
was only one so it never mattered. Same discipline TEMPORAL-VERIFICATION already
demands for capture rate, applied to what rasterises rather than what clocks.
Not settled: H1's repeat half; H6's +0x04 exposure; the four red verify-screen
rows; whether the port is still nearer the capture than the reference on the GPU.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
7c8e4a863a