Soft-drop: replace OS key-repeat with game-loop tick (W / down-arrow held) #31

New issue

Closed

opened 2026-06-21 13:56:36 +02:00 by bosun · 0 comments

bosun commented

2026-06-21 13:56:36 +02:00

Owner

Symptom (operator playtest, 2026-06-21 ~13:10)

Holding W or the Down arrow during a solo run drops the piece once, then nothing happens for ~500ms (OS auto-repeat delay), then drops resume at the OS auto-repeat rate. Not the smooth accelerated descent expected of soft-drop in a Tetris-family game.

Operator wording: "the W/Down arrow key lowers the block only once. Then the long key press delay blocks any additional inputs, and only after some delay the block starts to drop in increased speed."

Root cause

Soft-drop is currently driven by OS-level key-repeat events (one initial keydown + a hardware-controlled delay + hardware-controlled repeat rate). This makes the soft-drop feel laggy and inconsistent — it depends on the player's OS settings rather than the game's tick.

Fix direction

Replace OS-auto-repeat-driven soft-drop with game-loop-tick-driven soft-drop:

Track softDropHeld: boolean state from keydown → keyup on W / Down-Arrow (independent of OS auto-repeat).
In the game tick, while softDropHeld === true, advance the piece downward at the soft-drop rate (e.g. 1 row per ~30ms, or dropInterval / softDropMultiplier).
Ignore subsequent keydown events for the same key while it's held (no re-trigger from OS auto-repeat — event.repeat filter, or simply key-state tracking).

Reference behavior: classic Tetris guidelines (TGM, NES, modern guideline) all use game-tick soft-drop, not OS auto-repeat.

Acceptance criteria

Holding W or Down-Arrow drops the piece smoothly at the game's soft-drop rate — no initial-delay before the second drop.
Soft-drop rate is consistent regardless of the player's OS key-repeat settings.
Releasing the key stops the soft-drop immediately on the next tick.
Hard-drop (space) behavior unchanged.
Versus mode soft-drop also fixed (same shared handler).

Lane

Shipwright — render-side / game-loop / input-handling.

Effort

Size/S — a focused input-handler refactor with one new piece of per-frame state. Mostly localized to wherever the existing soft-drop handler lives.

## Symptom (operator playtest, 2026-06-21 ~13:10) Holding W or the Down arrow during a solo run drops the piece once, then nothing happens for ~500ms (OS auto-repeat delay), then drops resume at the OS auto-repeat rate. Not the smooth accelerated descent expected of soft-drop in a Tetris-family game. Operator wording: *"the W/Down arrow key lowers the block only once. Then the long key press delay blocks any additional inputs, and only after some delay the block starts to drop in increased speed."* ## Root cause Soft-drop is currently driven by OS-level key-repeat events (one initial keydown + a hardware-controlled delay + hardware-controlled repeat rate). This makes the soft-drop feel laggy and inconsistent — it depends on the player's OS settings rather than the game's tick. ## Fix direction Replace OS-auto-repeat-driven soft-drop with game-loop-tick-driven soft-drop: 1. Track `softDropHeld: boolean` state from `keydown` → `keyup` on W / Down-Arrow (independent of OS auto-repeat). 2. In the game tick, while `softDropHeld === true`, advance the piece downward at the soft-drop rate (e.g. 1 row per ~30ms, or `dropInterval / softDropMultiplier`). 3. Ignore subsequent `keydown` events for the same key while it's held (no re-trigger from OS auto-repeat — `event.repeat` filter, or simply key-state tracking). Reference behavior: classic Tetris guidelines (TGM, NES, modern guideline) all use game-tick soft-drop, not OS auto-repeat. ## Acceptance criteria 1. Holding W or Down-Arrow drops the piece smoothly at the game's soft-drop rate — no initial-delay before the second drop. 2. Soft-drop rate is consistent regardless of the player's OS key-repeat settings. 3. Releasing the key stops the soft-drop immediately on the next tick. 4. Hard-drop (space) behavior unchanged. 5. Versus mode soft-drop also fixed (same shared handler). ## Lane Shipwright — render-side / game-loop / input-handling. ## Effort Size/S — a focused input-handler refactor with one new piece of per-frame state. Mostly localized to wherever the existing soft-drop handler lives.