Orkuncakilkaya
bccd26fb29
Fixes the papercut: the generated frame loop called rt_poll() (feeding only Input.key) but never input_poll(), so Input.active/key_down/mouse/pad read empty unless the game called Input.poll() by hand. The loop now calls input_poll() when the game uses any Input runtime method — committing the held-key/mouse/gamepad state, and record/replay — and stores its return as the frame key so Input.key still works. A game using no Input runtime keeps the plain rt_poll path, byte-identical. Adds the Input-Manager API: Input.action(name,key) ships a default binding (kept if already bound, so a rebind/loaded map isn't clobbered), Input.bind_pad(name,button) makes an action device-agnostic (keyboard OR pad), and Input.active/just_pressed/just_released read the multi-key device layer with clean on-press/on-release edges (deterministic, dispatch-free — a handler polls the edge; a replay fires identically). Examples input_manager + input_auto, 5 docs pages. Full suite 107/0, goldens byte-identical, fixpoint holds. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
841 B
841 B
id: input-bind_pad name: Input.bind_pad category: input kind: namespace-method tokens: Input.bind_pad sig: Input.bind_pad(action: str, button: int) -> void tip: Also fire a named action from a gamepad button (device-agnostic). order: 32 ns: Input member: bind_pad
Maps a gamepad button (on pad 0) to a named action, so the action fires from the keyboard or the pad. The same action can carry both keyboard keys (Input.bind / Input.action) and pad buttons; Input.active and its edges fire on either device — one action, any input.
program Pad {
entry {
Input.action("fire", 'j')
Input.bind_pad("fire", 0)
if Input.active("fire") { print(1) }
}
}