F1: the human watched the real game and it repeats on a held direction, on the
stick AND (confirmed separately) the d-pad. gamepad.gd had predicted this exact
refutation in its own words, so one-step-per-deflection stops being the
conservative reading and becomes a known defect.
Mechanism: Gamepad.held_direction() polls the DEVICES -- not
Input.is_action_pressed, because ui_up/ui_down sit on the stick at Godot's 0.50
deadzone while the port steps at the game's measured 0.61, so polling the action
would repeat through the exact band ENTER exists to exclude.
Boot._menu_repeat() re-applies the same guards a real press gets, rather than
sharing them, because a second input path is where this port's defects hide.
The RATE is NOT shipped, on instruction: an invented interval is
indistinguishable from a measured one later. An earlier draft of this change had
0.40/0.20 with a why attached; that was the named failure mode and the numbers
are removed, not commented out. repeat_due() returns 0 until both are set.
Flagged at the adoption site: verify-input's 'a held stick is ONE step, not six'
asserts the ABSENCE of this feature and will go red when a rate lands -- for the
right reason, and looking exactly like the jitter bug returning.
main's P6 row reads 'Looping is blocked on HANDOFF Q10' while main's OWN
HANDOFF.md line 39 marks Q10 answered -- the row was stale, not a decision, so
the resolution keeps the answered status rather than silently un-resolving it.
P5 takes main's line verbatim: that is the human's gate call and not mine.
P6 explicitly does NOT claim the gate -- the same play-test found the SFX mix
wrong, and 'sound on the P5 gate' means the RIGHT sound.
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
Both found by a human playing the port on a real controller. Both were
invisible to every check this port has, for one reason:
`--script` sends InputEventAction, which BYPASSES the input map.
So the harness asserted every line of code AFTER the map and nothing about the
map itself. Measured on this Godot, not remembered -- the remembered answer was
wrong:
ui_accept key:Enter, key:Kp Enter, key:Space <- no joypad at all
ui_cancel key:Escape <- no joypad at all
ui_up key:Up, JOYBTN:11, JOYAXIS:1- <- d-pad AND left stick
ui_down key:Down, JOYBTN:12, JOYAXIS:1+
Four actions worked on the pad and two did not, which presents as a broken
controller: navigation moved, Ⓐ skipped nothing and opened nothing. Godot
4.7.2 binds no joypad button to ui_accept or ui_cancel.
Gamepad.bind_missing() ADDS the two buttons to the built-in actions rather than
redefining them in project.godot, which would replace the built-ins wholesale
and drop the keyboard bindings silently.
Second defect, same blind spot: an InputEventAction is not an analog axis. The
left stick is bound to axis 1, and an axis is not an edge -- held at deflection
it emits an event per jitter, each reporting the action pressed. That was one
cursor step per jitter ("moves the cursor too fast"). The stick is now latched
to one step per deflection, with hysteresis so a stick resting near the
threshold does not chatter.
AUTHORED, and deliberately the conservative half: whether the game REPEATS a
held direction, and how fast, is an oracle question. One deflection one step
cannot run away and invents no rate. Logged as BLOCKED H1.
tools/port/verify-input asserts the map and the latch, with a control that
removes each check's OWN subject -- its first version inverted all nine
assertions when only two depended on the fixup, and reported seven correct
checks as broken. Three rows say plainly they are not controllable (they assert
Godot's own bindings) and one is a negative carrying a positive control (R4),
rather than faking an inversion for either.
Also logged BLOCKED H2, unguessed: the splash blur/fade-in is more pronounced
in the game than in the port. The port applies no blur at all. Noted there that
the two splashes are the only screens reaching the rest() plateau-less
fallback, which the R1 pass just re-opened in both directions.
