The two ideas the input revamp leads with, built in Ludic over the single-key poll every target already provides: - Action maps: gameplay reads named actions, not physical keys, so keys are rebindable and a scheme is data. Input.bind(action, key), Input.down/pressed(action), Input.rebind(action, from, to). - Deterministic record/replay: Input.poll() is the one per-frame input read; Input.record() captures the key each frame and Input.replay() feeds the tape back, so a run reproduces exactly — the seed of lockstep netcode. "Read input" and "read a recorded snapshot" are the same call. runtime/native/input.ludic (spliced when the new Input.* methods are used; pulls in core.ludic for rt_poll). emit_ns_call routes the methods to the @fn_input_* runtime; parse.ludic gates the splice. Seven docs/language pages; worked example + regression examples/library/input_actions.ludic (1 0 1 1 0 1 0). Full suite 75 passed, self-host fixpoint intact, no golden drift. The device layer (multi-key held, gamepads, touch, analog) needs a platform key-state backend and is tracked separately. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
24 lines
780 B
Markdown
24 lines
780 B
Markdown
---
|
|
id: input-pressed
|
|
name: Input.pressed
|
|
category: input
|
|
kind: namespace-method
|
|
tokens: Input.pressed
|
|
sig: Input.pressed(action: str) -> bool
|
|
tip: Did a named action go down this frame (a one-shot edge)?
|
|
order: 5
|
|
ns: Input
|
|
member: pressed
|
|
---
|
|
|
|
Returns whether a named action went down <em>this</em> frame — held on the frame last polled, but not on the one before — the edge you want for "press to jump / confirm / fire", where <a href="input-down.html"><code>Input.down</code></a> would retrigger every frame the key is held. Depends on the two most recent <a href="input-poll.html"><code>Input.poll</code></a> calls, so poll once per frame.
|
|
|
|
```ludic
|
|
program Edge {
|
|
entry {
|
|
Input.bind("jump", ' ')
|
|
Input.poll()
|
|
if Input.pressed("jump") { print(1) }
|
|
}
|
|
}
|
|
```
|