7c8e4a863a
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
10 KiB
Executable File
10 KiB
Executable File