Root cause of both issues: terminals don't send Release events by
default. When pressing W while holding A, terminal stops repeating A
(but doesn't send Release), so A times out and strafing breaks.
On key release, 400ms timeout means 400ms of extra movement.
Fix: PushKeyboardEnhancementFlags(REPORT_EVENT_TYPES) in terminal init.
This asks the terminal to send proper Press/Release/Repeat events for
ALL keys, not just special ones.
With Release events:
- Key release is instant (no 400ms timeout delay)
- Pressing W doesn't cancel A's held state (terminal sends Release
only when A is actually released)
- A/D strafing works while W is held
Fallback: if terminal doesn't support enhancement flags (old xterm),
got_release flag stays false and 150ms timeout is used. Once any
Release event is received, all keys switch to Release-based mode
(infinite timeout, rely on actual Release events).
109 tests, 0 warnings, 0 failures
Root cause: terminals wait 300-500ms after initial Press before
sending the first Repeat event. With 60ms timeout, the key was
released during this gap, causing step-pause-accelerate pattern.
Fix: two timeout phases:
- After Press (no Repeat seen yet): 400ms timeout
Covers terminal's initial repeat delay, key stays held
- After first Repeat: 80ms timeout
Repeats arrive every ~30ms, 80ms is safe margin
Quick release detection once repeating starts
Result: smooth continuous movement from first keypress, no gap
Problem: event::poll(0ms) once per frame missed events between frames,
causing laggy/missed input. Terminal key repeat timing was unpredictable.
Fix: dedicated input thread that blocks on event::read() and pushes
all events to an mpsc channel. Game loop drains channel with try_iter()
each frame — gets every event without blocking, zero missed inputs.
- InputHandler::start() spawns background thread
- InputHandler::stop() cleans up on game exit
- try_iter() collects all accumulated events per frame
- Removed 16ms sleep (no longer needed, input doesn't block)
- Hold timeout reduced to 60ms (events arrive more reliably now)
- 109 tests, 0 warnings, 0 failures
Terminals don't send Release events for most keys, so held keys
stayed active forever. Two problems:
1. W = infinite jump: Jump was in held_actions, fired every tick
while held. check_on_ground returned true immediately after
landing, causing auto-bounce.
Fix: Jump fires only on initial Press event (jump_pressed flag),
not on Repeat or held state.
2. A ignores D: When both A and D were held, both applied velocity
and cancelled out. But terminal never sends Release for A, so
D couldn't take over.
Fix: Left/Right are mutually exclusive — most recently pressed
key wins (compares last_seen timestamps).
3. Held key timeout: Keys expire after 80ms without a Repeat event,
simulating Release for terminals that don't send it.
109 tests, 0 warnings, 0 failures
Problem: terminal key repeat sends one event, then pauses ~500ms,
then floods repeats. This caused stop-then-accelerate movement.
Fix: track held keys (Press/Release events), apply movement every
tick based on held state, not per-event. Jump still fires once per
press. Paint and quit are one-shot actions.
- InputHandler: held: Vec<HeldKey> tracks Left/Right/Jump/Camera
- update(): drains all pending events, updates held state
- held_actions(): returns active movement actions per tick
- handle_input: applies held actions every frame
- Camera pan reduced to 2/tick (was 5) for smoothness
- 109 tests, 0 warnings, 0 failures
Emil