Input and games.

[Todd Showalter]

On Thu, Apr 18, 2013 at 5:29 PM, Jonas Kulla <nyocurio at gmail.com> wrote:

> What exactly do you mean by "unique requirements", can you be a little
> bit more specific? In general I think the current consensus (correct me if
> I'm wrong) is that using the default wayland pointer and keyboard events
> plus Joypad support via SDL is sufficient for most purposes.

    In general we can work with anything as long as we can get the
right events and process them; it's perhaps more a matter of
convenience.

    There are a few things of note that are somewhat specific to games:

Permissions

    We're often running things like mods, user-generated scripts, and
in general lots of untrusted content, so the fewer privileges we need
to handle things like input, the better.

Hooking Things Up

    This may be beyond the scope of Wayland, but at least in the past
I've found that in particular joysticks/gamepads are a bit of a
guessing game for the developer.  You can usually assume that the
first stick is the first couple of axis values in the axis array, but
after that, it's a tossup whether an analog axis is part of a stick a
trigger, or a pressure-sensitive button.

    It would be really nice if there was some sort of configuration
that could be read so we'd know how the player wanted these things
mapped, and some sort of way for the player to set that configuration
up outside the game.

Event Driven vs. Polling

    Modern gui applications tend to be event-driven, which makes
sense; most modern desktop applications spend most of their time doing
nothing and waiting for the user to generate input.  Games are
different, in that they tend to be simulation-based, and things are
happening regardless of whether the player is providing input.

    In most games, you have to poll input between simulation ticks.
If you accept and process an input event in the middle of a simulation
tick, your simulation will likely be internally inconsistent.  Input
in games typically moves or changes in-game objects, and if input
affects an object mid-update, part of the simulation tick will have
been calculated based on the old state of the object, and the rest
will be based on the new state.

    To deal with this on event-driven systems, games must either
directly poll the input system, or else accumulate events and process
them between simulation ticks.  Either works, but being able to poll
means the game needs to do less work.

Input Sources & Use

    Sometimes games want desktop-style input (clicking buttons,
entering a name with the keyboard), but often games want to treat all
the available input data as either digital values (mouse buttons,
keyboard keys, gamepad buttons...), constrained-axis "analog" (gamepad
triggers, joysticks) or unconstrained axis "analog" (mouse/trackball).
 Touch input is a bit of a special case, since it's nearly without
context.

    Games usually care about all of:

- the state of buttons/keys -- whether they are currently down or up
-- think WASD here
- edge detection of buttons/keys -- trigger, release and state change
- the value of each input axis -- joystick deflection, screen position
of the cursor, etc
- the delta of each input axis

    From what I've seen, SDL does not give us the button/key state
without building a layer on top of it; we only get edge detection.
Likewise, as far as I understand nothing does deltas.

Input Capture

    It would be very helpful to have an input capture mechanism that
could be turned on and off easily; I'd like to be able to have mouse
input captured when a game is playing, but be able to shut off the
mouse capture if the player brings up the pause menu.  I'd also like
it to deactivate if the game crashes, because at least in development
that can happen a lot.

> Personally, I'd be interested in seeing joypads become first class input
> devices on wayland (as a capability of wl_seat alongside mice/keyboard
> etc.),

    Hear hear!

> seeing that there are already evdev drivers existing for most gamepads.
> But I'm unfortunately lacking experience and knowledge in that field,
> otherwise I'd give it a hacking attempt myself.
>
> So yeah, for now I think SDL should serve you perfectly well =)

    SDL works, but it's not ideal; SDL maintains a lot of the desktop
impedance mismatch with games that desktop environments have without
it.

                                          Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.