feat(port): adopt the measured held-direction repeat rate (F1) #27

Merged

fabi merged 2 commits from feat/f1-held-repeat into main 2026-09-15 19:47:28 +00:00

Conversation 2 Commits 2 Files Changed 4 +404 -54

fabi commented 2026-09-13 11:34:37 +00:00

Owner

Copy Link

Adopts the rate the Decoder measured in #1, and adds the coverage that was missing.

REPEAT_DELAY = 0.402, REPEAT_INTERVAL = 0.134 — 12 and 4 frames at the run's achieved 29.87 fps, converted to seconds because this port does not run at the guest's rate and it is the cadence that was measured. Cited at the constants: docs/re/f1-repeat-measured-via-driver-patch.md.

The two numbers are not equally well evidenced, and the code says so

No physical controller exists in the Decoder's container, so the measurement patched Canary's --hid=file driver to emit Keystroke REPEAT at the SDL driver's own 400/100 ms constants.

• the delay came back as 402 ms — to within the frame quantum, the constant that was fed in. It confirms the instrument, not the game.
• the interval came back as 133 ms against a fed-in 100 ms. That is the new fact: the game paces repeats to its own frame consumption, not to the event stream.

One run. The corpus's two-run minimum is not met and the finding says so itself.

📌 The instruction this was waiting on is vindicated awkwardly: the draft this port refused to ship had 0.40 / 0.20 — the guessed delay nearly right, the guessed interval off by 50 %. The half that was wrong would have been protected by the half that was right.

🔴 The predicted regression did not happen, and that was worse

Both gamepad.gd and held-direction-repeat.md said adopting a rate would turn verify-input's "a held stick is ONE step, not six" red, and warned it would read as the jitter bug returning.

Run on adoption day: it stayed green. steps() feeds axis values through the latch and never advances a clock, so it had never called repeat_due() at all. The prediction was reasoned, not run — and what it hid is that the rate was about to ship into a harness with no coverage of this feature, where that green row would have been read as coverage of it.

So verify-input gains a repeat subject — five rows, each asserting these numbers rather than the shape, because a shape-only check would have passed on 0.40 / 0.20:

nothing repeats before the measured delay    ok  first repeat 0.417s after the press step, delay is 0.402
first repeat lands on the measured delay     ok  0.417s vs 0.402 (±one frame)
steady interval is the measured 0.134s       ok  mean 0.133s over 11 gap(s) vs 0.134
the cadence does not drift with frame rate   ok  12 steps at 30fps, 12 at 240fps
a direction change restarts the delay        ok  0.433s after the reversal

--control inverts every controllable row (it removes the premise — a held direction — since the rate is a const). check-citations: 129/129 resolve.

⚠️ The first-repeat row measures from the arming tick, not t = 0. repeat_due()'s first call only latches the direction; in the port that call is the frame the press is handled, which is the origin the finding measures its 12 frames from. From zero it read 0.433 vs 0.402 — and the tolerance would have had to be widened to hide a units mismatch.

What only you can settle

0.134 s is ~7.5 steps a second. The play-test that opened this asked for "slow enough to see which item is selected". If it reads as too fast, the 100 ms constant is Xenia's and not the game's — and no capture in that container would have revealed it.

godot --path port -- --menu=main_menu     # export/ is built, 149 MB

Closes #2

Adopts the rate the Decoder measured in #1, and adds the coverage that was missing. **`REPEAT_DELAY = 0.402`, `REPEAT_INTERVAL = 0.134`** — 12 and 4 frames at the run's achieved 29.87 fps, converted to seconds because this port does not run at the guest's rate and it is the *cadence* that was measured. Cited at the constants: `docs/re/f1-repeat-measured-via-driver-patch.md`. ### The two numbers are not equally well evidenced, and the code says so No physical controller exists in the Decoder's container, so the measurement patched Canary's `--hid=file` driver to emit Keystroke `REPEAT` at **the SDL driver's own** 400/100 ms constants. * the **delay** came back as 402 ms — to within the frame quantum, *the constant that was fed in*. It confirms the instrument, not the game. * the **interval** came back as 133 ms against a fed-in 100 ms. That is the new fact: the game paces repeats to its own frame consumption, not to the event stream. One run. The corpus's two-run minimum is not met and the finding says so itself. 📌 The instruction this was waiting on is vindicated awkwardly: the draft this port refused to ship had **0.40 / 0.20** — the guessed delay nearly right, the guessed interval off by 50 %. The half that was wrong would have been protected by the half that was right. ### 🔴 The predicted regression did not happen, and that was worse Both `gamepad.gd` and `held-direction-repeat.md` said adopting a rate would turn `verify-input`'s *"a held stick is ONE step, not six"* red, and warned it would read as the jitter bug returning. **Run on adoption day: it stayed green.** `steps()` feeds axis values through the latch and never advances a clock, so it had never called `repeat_due()` at all. The prediction was reasoned, not run — and what it hid is that the rate was about to ship into a harness with **no coverage of this feature**, where that green row would have been read as coverage of it. So `verify-input` gains a `repeat` subject — five rows, each asserting **these numbers** rather than the shape, because a shape-only check would have passed on 0.40 / 0.20: ``` nothing repeats before the measured delay ok first repeat 0.417s after the press step, delay is 0.402 first repeat lands on the measured delay ok 0.417s vs 0.402 (±one frame) steady interval is the measured 0.134s ok mean 0.133s over 11 gap(s) vs 0.134 the cadence does not drift with frame rate ok 12 steps at 30fps, 12 at 240fps a direction change restarts the delay ok 0.433s after the reversal ``` `--control` inverts every controllable row (it removes the premise — a held direction — since the rate is a `const`). `check-citations`: 129/129 resolve. ⚠️ The first-repeat row measures from the **arming tick**, not `t = 0`. `repeat_due()`'s first call only latches the direction; in the port that call is the frame the press is handled, which is the origin the finding measures its 12 frames from. From zero it read 0.433 vs 0.402 — and the tolerance would have had to be widened to hide a units mismatch. ### What only you can settle 0.134 s is **~7.5 steps a second**. The play-test that opened this asked for *"slow enough to see which item is selected"*. If it reads as too fast, the 100 ms constant is Xenia's and not the game's — and no capture in that container would have revealed it. ```bash godot --path port -- --menu=main_menu # export/ is built, 149 MB ``` Closes #2

fabi added 1 commit 2026-09-13 11:34:38 +00:00

feat(port): adopt the measured held-direction repeat rate (F1) ... c0c649c5dd

REPEAT_DELAY = 0.402, REPEAT_INTERVAL = 0.134, from
docs/re/f1-repeat-measured-via-driver-patch.md -- 12 and 4 frames at the
run's achieved 29.87 fps guest rate, converted to seconds because this port
does not run at the guest's rate and it is the cadence that was measured.

The mechanism has been here since 2026-09-02 and inert on purpose. The
instruction it was waiting on is now vindicated in the most awkward way: the
draft it refused to ship had 0.40 / 0.20, so the guessed delay was nearly
right and the guessed interval was off by 50 %. The half that was wrong
would have been protected by the half that was right.

The delay and the interval are NOT equally well evidenced, and the code says
so at the constants. No physical controller exists in the Decoder's
container, so the measurement fed Canary's file driver the SDL driver's own
400/100 ms constants: the 402 ms that came back is the constant that went
in, and confirms the instrument. The 133 ms interval against a fed-in 100 ms
is the new fact -- the game paces repeats to its own frame consumption. One
run; the two-run minimum is not met and the finding says so itself.

Also: the prediction that this would turn verify-input's "a held stick is
ONE step, not six" red was wrong. It stayed green, because steps() never
advances a clock and so had never called repeat_due() at all -- the rate was
about to ship into a harness with no coverage of the feature, with a green
line that would have been read as coverage.

So verify-input gains a `repeat` subject: nothing before the delay, the
first repeat on the delay, the steady interval, cadence independent of frame
rate (the code claims this in a comment, so it is now asserted), and a
direction change restarting the delay. Each asserts THESE numbers, not the
shape -- a shape-only check would have passed on 0.40 / 0.20. The control
removes the premise, a held direction, and every controllable row inverts.

The first-repeat row measures from the arming tick, not from t=0: that tick
is the frame the press is handled, which is the origin the finding measures
its 12 frames from. Measured from zero it read 0.433 vs 0.402 and the
tolerance would have had to be widened to hide a units mismatch.

Closes #2

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

fabi commented 2026-09-13 12:27:43 +00:00

Author

Owner

Copy Link

Found it, and it was not the rate. 07d83c42.

held_direction()'s own comment says "Polled at the DEVICE, never through Input.is_action_pressed". It was not. The d-pad and keyboard branches polled; the stick branch read _latched — a reconstruction of the stick's position from the event history.

That reconstruction is only as good as the last event that arrived. A stick held perfectly still sends nothing, so any single event reading below RELEASE — a spring settling, a deadzone-shaped value, a driver emitting a zero on focus change — clears it with nothing afterwards to set it back. From then on the port believes the stick is centred while the player is holding it.

That is exactly "it moves one item and stops".

Now polls Input.get_joy_axis() against the game's own 0.61, which is what that paragraph always meant. The latch stays as a fallback for injected events so the harness keeps testing something.

🔴 Why nothing here caught it

Every instrument in this repo supplies the input it then measures:

instrument	what it feeds
verify-input's new repeat rows	calls repeat_due() directly, latch set through accepts()
--script=up,down,accept	InputEventAction — bypasses the input map entirely
--script=hold:down:2.0	injects one InputEventJoypadMotion

All three agreed with each other; none of them read a device. This is the same shape as the 2026-09-01 report that opened gamepad.gd — a synthetic-input test asserts the code after the input map, never the input map itself — one level deeper, with the lesson already written at the top of the file it broke.

I claimed this branch was verified on the strength of those instruments. It was not, and the report is the correction.

The two instruments that would have caught it, added

godot --path port -- --menu=main_menu --script=hold:down:2.0   # one real axis event, then silence
godot --path port -- --menu=main_menu --input-probe            # what the devices report, on change

⚠️ The fix is not verified. It is a defect that matches the symptom exactly, found by reading. Only a hand on a stick can confirm it — so please run it again, and if it still does not repeat, --input-probe prints the answer:

probe: [0] Generic X-Box pad Y=+1.000 X=+0.000 dpad=--  latched=1  held_direction=1  (ENTER=0.61 RELEASE=0.40)

If Y reads below 0.61 while you hold it, the threshold is wrong for your pad rather than the poll.

Found it, and it was not the rate. `07d83c42`. `held_direction()`'s own comment says *"Polled at the DEVICE, never through `Input.is_action_pressed`"*. **It was not.** The d-pad and keyboard branches polled; the **stick** branch read `_latched` — a reconstruction of the stick's position from the *event history*. That reconstruction is only as good as the last event that arrived. A stick held perfectly still sends nothing, so any single event reading below `RELEASE` — a spring settling, a deadzone-shaped value, a driver emitting a zero on focus change — clears it with **nothing afterwards to set it back**. From then on the port believes the stick is centred while the player is holding it. That is exactly "it moves one item and stops". Now polls `Input.get_joy_axis()` against the game's own 0.61, which is what that paragraph always meant. The latch stays as a fallback for *injected* events so the harness keeps testing something. ### 🔴 Why nothing here caught it Every instrument in this repo **supplies the input it then measures**: | instrument | what it feeds | |---|---| | `verify-input`'s new `repeat` rows | calls `repeat_due()` directly, latch set through `accepts()` | | `--script=up,down,accept` | `InputEventAction` — bypasses the input map entirely | | `--script=hold:down:2.0` | injects one `InputEventJoypadMotion` | All three agreed with each other; none of them read a device. This is the same shape as the 2026-09-01 report that opened `gamepad.gd` — *a synthetic-input test asserts the code after the input map, never the input map itself* — one level deeper, with the lesson already written at the top of the file it broke. I claimed this branch was verified on the strength of those instruments. It was not, and the report is the correction. ### The two instruments that would have caught it, added ```bash godot --path port -- --menu=main_menu --script=hold:down:2.0 # one real axis event, then silence godot --path port -- --menu=main_menu --input-probe # what the devices report, on change ``` ⚠️ **The fix is not verified.** It is a defect that matches the symptom exactly, found by reading. Only a hand on a stick can confirm it — so please run it again, and if it still does not repeat, `--input-probe` prints the answer: ``` probe: [0] Generic X-Box pad Y=+1.000 X=+0.000 dpad=-- latched=1 held_direction=1 (ENTER=0.61 RELEASE=0.40) ``` If `Y` reads below 0.61 while you hold it, the threshold is wrong for your pad rather than the poll.

fabi added 1 commit 2026-09-13 12:27:43 +00:00

fix(port): held_direction() polls the stick instead of reconstructing it ... 07d83c4229

Reported by a human on a real controller: hold the left stick down, the
cursor moves one item and stops. The repeat never runs.

`held_direction()`'s own comment says "Polled at the DEVICE, never through
Input.is_action_pressed". It was not. The d-pad and keyboard branches polled;
the STICK branch read `_latched`, which is a reconstruction of the stick's
position from the event history.

That reconstruction is only as good as the last event seen. A stick held
still sends nothing, and one event reading below RELEASE -- a spring
settling, a deadzone-shaped value, a driver emitting a zero on focus change
-- clears it with no event afterwards to set it back. The port then believes
the stick is centred while the player is holding it, which is precisely the
symptom reported.

Now polls `Input.get_joy_axis()` against the game's own 0.61, which is what
the comment always meant. The latch stays as a fallback for INJECTED events,
so the script harness and verify-input keep testing something.

🔴 Every instrument here missed this because every instrument SUPPLIES the
input it measures: verify-input ticks repeat_due() directly, --script sends
InputEventAction which bypasses the input map, and the new --script=hold:
injects its own axis event. All three agreed with each other and none read a
device. Same shape as the 2026-09-01 report that opened gamepad.gd, one
level deeper, with the lesson already written at the top of that file.

So this adds the two things that would have caught it:

  --script=hold:down:2.0   hold one real axis deflection and log every move
  --input-probe            print what the devices report, on change

⚠️ The fix itself is NOT verified. It matches the symptom exactly and was
found by reading, but only a human holding a stick can confirm it, and the
probe exists so the answer is measured either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

fabi referenced this pull request 2026-09-13 12:45:24 +00:00

F1 — measure the held-direction repeat: initial delay and interval, in frames #1

fabi commented 2026-09-13 12:45:24 +00:00

Author

Owner

Copy Link

✅ Verified by hand: "Works now and speed is good."

That is the only instrument that could settle either half, and it settles both — the stick now repeats, and 0.134 s reads as the "medium pace" of the play-test that opened F1.

⚠️ Worth keeping straight: it is the interval that a human can judge. The delay is still Canary's SDL constant fed back to us, and no hand can tell 0.402 from 0.38. Both caveats are at the constants and in docs/port/held-direction-repeat.md.

CI is queued; the branch is mergeable. Closes #2, and #1 is closed with the confirmation recorded.

✅ **Verified by hand:** *"Works now and speed is good."* That is the only instrument that could settle either half, and it settles both — the stick now repeats, and 0.134 s reads as the "medium pace" of the play-test that opened F1. ⚠️ Worth keeping straight: it is the **interval** that a human can judge. The **delay** is still Canary's SDL constant fed back to us, and no hand can tell 0.402 from 0.38. Both caveats are at the constants and in `docs/port/held-direction-repeat.md`. CI is queued; the branch is mergeable. `Closes #2`, and #1 is closed with the confirmation recorded.

fabi referenced this pull request 2026-09-13 17:02:50 +00:00

docs(agents): the plan to consolidate six repositories into two #29

fabi merged commit 81fc54e072 into main 2026-09-15 19:47:28 +00:00

fabi referenced this issue from a commit 2026-09-15 19:47:29 +00:00

Merge pull request 'feat(port): adopt the measured held-direction repeat rate (F1)' (#27) from feat/f1-held-repeat into main

fabi referenced this issue from a commit 2026-09-19 20:29:49 +00:00

Merge pull request 'feat(port): adopt the measured held-direction repeat rate (F1)' (#27) from feat/f1-held-repeat into main

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

agent/decoder

Owned by the Decoder (disc to meaning; runs the emulator)

agent/port

Owned by the Port (disc to playable; no RE)

kind/ask

One agent asking the other for something it cannot answer in role

kind/bundle

A bundle the human defined; agents decompose it into items

kind/defect

Found by a play-test or a check

kind/item

One unit of work, small enough to finish in a single session

state/approved

Human approved the shape; an agent may start

state/blocked

Waiting on another item; use the Depends-On field, not prose

state/in-progress

An agent is working it now

state/needs-human

Done as far as an agent can tell -- a person must look. The body says what to look at

state/proposed

Agent proposed this item; awaiting the human's approval to start

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

sylph-decoder sylph-pi sylph-port fabi

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fabi/Sylpheed#27