Input Systems (HID)

01Where input fits

Two delivery models coexist, and a good engine uses both. The platform layer pushes discrete events (key down, key up, mouse moved, gamepad connected) onto a queue; the game loop also samples current device state once per frame (is W held right now? what's the left-stick vector?)^[1].

The usual shape: at the top of each frame, drain the event queue (this is where the platform layer hands you events), fold the transitions into a per-frame snapshot plus an event list, and let gameplay read the snapshot. Events are authoritative for transitions (a tap shorter than a frame, the exact down/up); polling is convenient for "held right now."

02Scancodes vs keycodes

A scancode identifies the physical key position, independent of layout. A keycode (virtual key) names the symbol the key produces under the current layout. SDL's keyboard guide is explicit: scancodes "are guaranteed to reference the physical location on the keyboard and not what is printed on it," while keycodes "name specific keys and don't care where on the user's keyboard they actually are"^[3]. SDL's scancode values come straight from the USB HID usage tables^[2].

One more keyboard detail: when a key is held, the OS emits auto-repeat key-down events after a delay. That's a typing convenience. For gameplay you ignore it: one-shot actions fire only when the event is not a repeat (SDL's repeat flag, winit's KeyEvent.repeat), and held movement comes from polling state per frame, not from repeat events^[4].

03Raw mouse & pointer lock

There are two mouse signals. The cursor position (for UI) is filtered through OS pointer acceleration and the Control Panel mouse-speed slider. Mouselook wants the opposite: raw, unaccelerated deltas.

On Windows, the Raw Input API delivers WM_INPUT messages whose mouse deltas, unlike WM_MOUSEMOVE, are "not subject to the effects of the mouse speed set in the Control Panel's Mouse Properties sheet." Check the MOUSE_MOVE_ABSOLUTE flag, though: remote-desktop sessions and pen tablets report absolute positions instead of deltas^[5]. winit exposes the raw deltas as DeviceEvent::MouseMotion. For an FPS camera you also lock the cursor: winit's CursorGrabMode::Locked pins it in place (you hide it yourself), versus Confined, which only keeps it inside the window. Neither works everywhere (Locked isn't implemented on X11, Confined isn't on macOS), so engines try one and fall back to the other^[6].

04Gamepads

Think of one standard gamepad (two sticks, two triggers, a d-pad, face and shoulder buttons) and let a library map every real device onto it. The reason the library matters is the backend zoo underneath.

On Windows, XInput is the Xbox-controller API, with the two triggers as independent axes. (Microsoft now recommends its newer GameInput API, a superset of XInput, DirectInput and Raw Input, for new code: GameInput overview.) Legacy DirectInput, for the standard gamepad mapping, often combines both triggers onto one shared axis; Microsoft notes this "does mean it is not possible to see all possible trigger combination values through DirectInput... To test the trigger values separately, you must use XInput"^[7]. SDL hides all of it behind a standard model with separate left and right trigger axes, using a community mapping database^[8]; Rust's gilrs does the same and, helpfully, names face buttons by position (South/East/North/West) to sidestep the Xbox-vs-Nintendo A/B swap^[9].

// SDL3: stick axes are int16, -32768 (up/left) to 32767 (down/right): Y grows DOWNWARD.
// Triggers are 0..32767.
SDL_Event event;
while (SDL_PollEvent(&event)) {
    if (event.type == SDL_EVENT_GAMEPAD_ADDED)
        gamepad = SDL_OpenGamepad(event.gdevice.which);   // standard-mapped handle
}
if (gamepad) {
    float rawX = SDL_GetGamepadAxis(gamepad, SDL_GAMEPAD_AXIS_LEFTX) / 32767.0f;
    float rawY = SDL_GetGamepadAxis(gamepad, SDL_GAMEPAD_AXIS_LEFTY) / 32767.0f;
    bool jump = SDL_GetGamepadButton(gamepad, SDL_GAMEPAD_BUTTON_SOUTH);
}

// gilrs returns already-normalized f32 in [-1, 1].
while let Some(Event { id, event, .. }) = gilrs.next_event() {
    if let EventType::Connected = event { active = Some(id); }
}
if let Some(pad) = active.map(|id| gilrs.gamepad(id)) {
    let raw_x = pad.value(Axis::LeftStickX);   // already -1.0..1.0
    let raw_y = pad.value(Axis::LeftStickY);
    let jump  = pad.is_pressed(Button::South);  // South == A on an Xbox pad
}

05Dead zones

A thumbstick never rests at exactly zero, so you must ignore a small region near center. How you ignore it is a commonly botched piece of gamepad code, and the canonical reference is Josh Sutphin's^[10].

• Axial (per-axis): zero each axis independently. This makes a square dead zone that clips diagonals: a gentle diagonal can fall inside the square on both axes and read as zero, or snap to a cardinal. Correct only for grid or 4-way movement.
• Radial: zero by vector magnitude. A circular dead zone, no cardinal snapping, but the output jumps from 0 to a finite value the instant you cross the boundary.
• Scaled radial (the right default for free aim): after the radial cut, re-scale so output ramps from 0 at the boundary to 1 at full deflection.

Take the raw stick magnitude, subtract the dead-zone radius, then divide by what's left of the range so the output ramps from 0 right at the boundary to 1 at full deflection. Multiplying by the unit direction v̂ keeps the aim direction while the fraction supplies the new length. Without the divide the stick would jump straight to a finite value at the boundary; this is the re-scale that lets you walk slowly. Clamp |v| to 1 first: many sticks report diagonals slightly outside the unit circle, which would otherwise produce outputs above 1. Hover any symbol to see what it stands for.

Drag the stick. Switch dead-zone shapes and watch the diagonal get clipped, then watch the output ramp smoothly once you scale:

Wrong answers, and why: a bigger square dead zone worsens diagonal clipping; a response curve changes sensitivity, not snapping; and both scancodes and keycodes carry up/down, they differ in physical-vs-symbolic meaning.

06Response curves & smoothing

Two more shaping steps run on the post-dead-zone magnitude. A response curve (output = magnitude^k, k > 1) gives finer control near center while keeping the full range at the edge. A low-pass filter smooths jitter.

The one-pole low-pass is a single line, an exponentially weighted moving average^[16]:

Each frame's smoothed value is a blend of the new reading and the last smoothed value, weighted by α. At α = 1 there's no smoothing (output equals input); push α toward 0 and the output leans on its own history, so it's smoother but trails the input. The subscript i−1 just means 'the value from the previous frame'.

The widget feeds a noisy signal through both. Crank the smoothing and watch the filtered line lag the flicks:

07Action maps

Don't let gameplay name keys. Let it ask "is Jump triggered?" and resolve that through a table from physical inputs to semantic actions, scoped by context (menu, on-foot, vehicle). This is what makes rebinding, multi-device support, and accessibility possible.

Steam Input states the principle bluntly: in its native mode the game receives input "in the form of 'actions'" and "has no knowledge of what actual inputs are driving said actions, simply that the actions are happening"^[11]. Unreal's Enhanced Input models it as Input Actions plus Mapping Contexts you push and pop, with per-binding modifiers and triggers^[12]; Unity's Input System uses Action Maps with bindings and processors^[13]. The minimal data shape:

enum class Action { MoveForward, Jump, Fire };

struct PhysicalInput {                // tagged so one action binds keyboard OR pad
    enum class Source { Scancode, GamepadButton } source;
    int code;                          // SDL_Scancode (a position) or a button
    bool operator==(const PhysicalInput&) const = default;
};
// One context; swap the whole map for menu/vehicle.
std::unordered_map<PhysicalInput, Action, Hash> bindings;

#[derive(Clone, Copy, PartialEq, Eq, Hash)]
enum Action { MoveForward, Jump, Fire }

#[derive(Clone, Copy, PartialEq, Eq, Hash)]
enum PhysicalInput {              // one action binds keyboard OR pad
    Key(KeyCode),                    // physical position, survives AZERTY
    Pad(Button),
}
// One context; swap the whole map for menu/vehicle.
let bindings: HashMap<PhysicalInput, Action> = HashMap::new();

08Input buffering

Input buffering widens timing windows so the game registers the input the player meant. It is a feel feature, not added latency: it changes when an input is accepted, not when the result renders.

• Motion windows. A fighting-game quarter-circle counts if its directions land within an N-frame window. Community frame-data analysis puts Street Fighter 6's quarter-circle window at 11 frames, one to three frames stricter than Street Fighter V's windows, and reports that SF6 reads inputs three times per frame where SFV read once^[15].
• Coyote time. A jump still fires for a few frames after you walk off a ledge. Celeste's designer documents this kind of forgiveness (coyote time, jump buffering, corner correction) as deliberate feel^[14].
• Jump buffering. A jump pressed just before landing fires on the landing frame instead of being dropped^[14].

Tap the inputs. The move fires only if the sequence lands inside the buffer window; widen it and the same timing now succeeds:

09Sampling & latency

Polling once per frame can miss a transition shorter than the frame, a tap that goes down and up between two samples. The event stream carries every transition with a timestamp, which is why fast-twitch genres lean on events (and sub-frame sampling) rather than per-frame polling alone.

High-frequency mice deliver many events per frame; accumulate them rather than taking the last. And felt input latency is multi-causal (the sampling phase, the render queue, the display), so per-frame sampling adds up to about half a frame on average (a full frame worst case) on top of the rest. Timestamps let you order inputs and age the buffer from §8, which is a timestamped ring of recent inputs.

10Pitfalls

11What's next

That completes the runtime spine: a loop, a window, and input. The next phase is resources, turning source art into fast-loading data: the Asset Pipeline and Compression, building on the existing File Streaming tutorial. Then the renderer. The full path is on the series hub.

1. Jason Gregory. Game Engine Architecture, "Human Interface Devices (HID)." gameenginebook.com. Reading and processing input in an engine: events vs polling, dead zones.
2. SDL. SDL_Scancode. wiki.libsdl.org. The scancode enum, whose values are based on the USB HID usage tables.
3. SDL. Best Keyboard Practices. wiki.libsdl.org. Bind movement to scancodes (WASD survives AZERTY), symbolic shortcuts to keycodes.
4. winit. KeyEvent and the keyboard module. docs.rs/winit. physical_key vs logical_key, the repeat flag, and logical key being unaffected by Ctrl.
5. Microsoft. "Raw Input Overview" and "RAWMOUSE structure." learn.microsoft.com, learn.microsoft.com. Batched GetRawInputBuffer reads for 1000 Hz mice; relative vs absolute motion flags; raw deltas not subject to the Control Panel mouse speed.
6. winit. CursorGrabMode. docs.rs/winit. Locked (pins the cursor for mouselook) vs Confined (keeps it in the window), and the platforms where each returns NotSupported.
7. Microsoft. "Comparison of XInput and DirectInput Features." learn.microsoft.com. DirectInput combines the triggers onto one axis; XInput keeps them independent; XInput dead-zone constants.
8. SDL. SDL_GamepadAxis / SDL_GetGamepadAxis. wiki.libsdl.org. The standard gamepad model with separate left/right trigger axes over any backend.
9. gilrs. Crate documentation. docs.rs/gilrs. Cross-platform gamepad input in Rust; normalized axes; positional face-button names (South/East/North/West).
10. Josh Sutphin. "Doing Thumbstick Dead Zones Right." joshsutphin.com. Axial vs radial vs scaled-radial dead zones and the re-scaling formula.
11. Valve. Steam Input "General Concepts." partner.steamgames.com. Native mode delivers actions, not the inputs driving them; action sets group actions by context, one active per device.
12. Epic Games. "Enhanced Input in Unreal Engine." dev.epicgames.com. Input Actions, Mapping Contexts, and per-binding Modifiers and Triggers. The plugin's API reference lists the modifier classes, including UInputModifierDeadZone, UInputModifierResponseCurveExponential and UInputModifierSmooth.
13. Unity Technologies. Input System: Action Bindings. docs.unity3d.com. Action Maps, bindings, deadzone/scale Processors, composite bindings.
14. Maddy Thorson. "Celeste & Forgiveness." maddymakesgames.com. Coyote time, jump buffering, and corner correction as deliberate feel features.
15. EventHubs, reporting Loïc "WydD" Petit's input analysis. "Breakdown of why players struggle with SF6 inputs." eventhubs.com. SF6's 11-frame quarter-circle buffer, windows one to three frames stricter than SFV's, and input read three times per frame.
16. "Low-pass filter," Wikipedia (discrete-time / exponential moving average). en.wikipedia.org. The one-pole filter y = αx + (1−α)y_prev and the smoothing-versus-lag trade.