Input and games.

[Pekka Paalanen]

On Mon, 22 Apr 2013 15:32:50 -0400
Todd Showalter <todd at electronjump.com> wrote:

> On Mon, Apr 22, 2013 at 1:40 PM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> 
> >>     Gamepads, by contrast, are all mostly the same these days, much
> >> like mice.  You can find oddball ones like that PC gamepad that
> >> was up on Kickstarter recently which had a trackball in place of
> >> the right thumb stick, but the core gamepad is now every bit as
> >> standardized as the core mouse.
> >
> > Alright, do you really mean that the controls are as standard as
> > mouse buttons and wheels, and we would not need a per-device-model
> > database? If so, then sure, a mouse-like Wayland protocol would
> > indeed be possible.
> 
>     What I mean is that in practice, the difference between game
> controllers is almost entirely two things; which particular bit in the
> button mask gets set/cleared by any particular button, and which axis
> maps to which control.  Right now (unless things have changed), for
> example, if you plug in an xbox 360 controller:
> 
> - left stick is axis (0, 1)
> - left trigger is axis 2
> - right stick is axis (3, 4)
> - right trigger is axis 5
> - dpad is axis (6, 7)
> 
>     I had to determine that by logging values and playing with the
> controls to see what made what numbers move.  The xbox controller (ie:
> not 360) may be the same order, it may not be.  The Dual Shock
> controller may be the same order, it likely isn't.  So unless we're
> really lucky something has to convert the axis ordering to a canonical
> form.
> 
>     Likewise, the buttons are just indexed, since as far as I can tell
> without cracking open the code, JSGetButtonState() is just:
> 
> return (buttons & (1 << index));
> 
>     I'd vastly prefer keysyms here; I don't want to have to go look up
> which button is START on this controller, or have to figure out which
> index is the bottom right face button.
> 
>     So, some layer needs to translate buttons to keysyms, and adjust
> the axis ordering (and possibly scaling) to fit the canonical
> controller model, which I would suggest essentially be two analog
> sticks, two analog triggers, plus keys (where the four dpad directions
> are keys).  The translation layer needn't be very complex; as long as
> there's some way to query evdev or the underlying system to find out
> exactly what kind of device this is, it's a simple matter of per-axis
> scale, offset and index translation (ie: scale this axis by -0.5f, add
> 1.0f, map to left trigger) and a list of bit to keysym lookups.
> 
>     So, in terms of hardware capabilities, there is very much a
> standard.  In terms of how that hardware is presented to the system
> over USB, the same data is all there, but your guess is as good as
> mine with regards to ordering.  Which is the problem I'd really like
> to see solved.

Hi Todd,

what you describe here is very much a keymap-like database for game
controllers: translating from button and axis indices to labels or
symbols. However, having a brief chat with Daniel Stone, it seems we
should not need these.

Take a look at /usr/include/linux/input.h

There you find definitions for BTN_A, BTN_X, BTN_START, ABS_X, ABS_Y,
ABS_RX, ABS_RY, ABS_HATnn, and many more. The kernel evdev interface
should alreay be giving out events with the correct label, so we would
not need any mapping.

Are you saying that the kernel gives out the labels wrong? If so, this
should be fixed in the kernel drivers. One thing less to care about in
Wayland. We "just" need to write the protocol for these devices, the
labels should be already there.

The current behaviour can be checked with evtest:
http://cgit.freedesktop.org/evtest/
Was that what you used to check the controller events?

> >> >>     If the events are just coming in as a pile in 60Hz ticks,
> >> >> it's all good and we can do everything we need to.  If they're
> >> >> coming in as a pile at 10Hz ticks, it's going to be difficult
> >> >> to make anything more active than Solitaire.
> >> >
> >> > Yes as far as I understand, currently input events are sent to
> >> > Wayland clients as a burst at every compositor repaint cycle,
> >> > which happens at the monitor refresh rate, so for a 60 Hz
> >> > monitor, you would be getting them in bursts at 60 Hz.
> >>
> >>     That's as good as we get from consoles, and besides, there
> >> isn't much point in most games in running your simulator at a
> >> higher frequency than the refresh rate.
> >
> > What about these hardcore fps-gamers who want at least 200+ frames
> > per second, or they can't win? :-)
> 
>     If you're sending me vsync at 200Hz, I'll gladly update my
> simulation at 200Hz and chew input at 200Hz.  :)
> 
>     Most players are playing on 60Hz refresh monitors, and those LCD
> monitors have enough lag on them that it really doesn't matter if the
> simulation ticks are happening (and eating input) faster than that.
> Even if you react at the speed of light (literally), you're
> interacting with data where he simulation probably started at least
> 50ms ago, got fed to the GPU 33ms ago, streamed out to the monitor
> 17ms ago, and spent at least a frame (at least, possibly many more if
> we're talking about an LCD TV) cooking in the monitor's circuitry.
> 
>     We're not making games twitchy enough to appeal to the vsync-off
> crowd, but I think especially now with the way that LCD monitors
> actually work the vsync-off crowd is basically asking for better
> racing tyres for their fighter jet.

Phew, that's what I thought. Thank you for telling me that my common
sense about these things is not wrong. :-)

> > That is something I have never understood, apart from game engine
> > bugs where frame rate affected the physics simulation outcome like
> > allowing to jump higher.
> 
>     I think it's partly that, though these days physics engines are a
> lot more robust than they used to be (to be fair, the slight increase
> in CPU horsepower and memory over the past couple of decades might
> have had a minor hand there, not to mention ubiquitous availability of
> accelerated floating point hardware).  I think it's also partly the
> "moar fastur" thing, which doesn't really make sense any more because
> the system is so much more buffered and mediated now than it was ten
> years ago.

Oh yeah, that makes perfect sense to me.

> >>     That's still probably good enough.  If you've got input data
> >> sets coming in at the frame rate of the display, and you know that
> >> the data is internally ordered, I think there's enough to work
> >> with.  We're essentially talking about an ordered set of deltas or
> >> positions covering a 16.67ms snapshot of time.  The timeframe
> >> isn't long enough that the intersample time provides any useful
> >> nuance, at least not with input from humans.
> >
> > Are you sure about that? Sorry for insisting, but this is the first
> > time I can ask a game professional about that. :-)
> 
>     Well, bear in mind I'm as much from a console background as a PC
> game background, and the consoles all run 60Hz (some of them used to
> run 50Hz in some regions, but I *think* that's no longer true?  I've
> been dealing with handheld and mobile a lot lately where it's all 60Hz
> refresh).
> 
>     The only machines that really have the option to run faster than
> 60Hz are PCs.  There are some games that will presumably take input
> just as fast as you can feed it to them, so I'd still consider
> supporting the extension; someone might find a use for it, or someone
> might be able to incorporate input into their simulation with the
> timestamps properly respected.  Most of the game world runs just fine
> on 60Hz ticks.

Yeah, we can still keep it in mind, in case anyone finds real use for
it.


Thanks,
pq