Input and games.

[Jason Ekstrand]

Todd,
I think you forgot reply-all.  I add wayland-devel again.

On Fri, Apr 26, 2013 at 5:50 PM, Todd Showalter <todd at electronjump.com>wrote:

> On Fri, Apr 26, 2013 at 5:46 PM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
>
> > My first general comment is about floating point.  I'm not 100% sure what
> > all went into the design decision to make wl_fixed have 8 bits of
> fractional
> > precision vs. 12 or 16.  I'm guessing that they wanted the increased
> integer
> > capability, but you'd have to ask Kristian about that.  My understanding
> is
> > that most game controllers work with ranges of [0,1] or [-1,1] which
> would
> > be wasteful to put into wl_fixed.  Looking below, it seems as if you're
> > fairly consistently picking a 16 bit fractional part.  That breaks out of
> > the norm of the wire format a bit, but I think it's justified in this
> case.
> > The big thing is to be consistent which it looks like you're doing
> anyway.
>
>     In my experience, most game controllers actually return byte
> values which you wind up interpreting either as signed or unsigned
> depending on what makes sense.  Certainly that's been the case
> historically.  In games we typically do something like:
>
> stick.x = ((float)raw_x) / (raw_x >= 0) ? 127.0f : 128.0f;
> stick.y = ((float)raw_y) / (raw_y >= 0) ? 127.0f : 128.0f;
>
> > Another concern is how to map [0, 255] onto [0, 2^15 - 1] cleanly.
> > Unfortunately, there is no good way to do this so that 0 -> 0 and 255 ->
> > 2^15 - 1.  Perhaps that doesn't matter much for games since you're
> sensing
> > human movements which will be slightly different for each controller
> anyway.
>
>     There is, actually:
>
> expanded = (base << 7) | (base >> 1);
>
>     ie: repeat the bit pattern down into the lower bits.  Examples:
>
> 11111111 -> (111111110000000) | (1111111) -> 111111111111111
> 0000000 -> (0000000000000000) | (0000000) -> 000000000000000
> 1000000 -> (1000000000000000) | (100000) -> 100000001000000
> 1011001 -> (10110010000000) | (101100) -> 1011001101100
>
>     And so forth.  It's the same scheme you use when doing color
> channel expansion.  I haven't seen a rigorous mathematical proof that
> it's correct, but I'd be surprised if someone more so inclined than I
> hasn't come up with one.
>

Wow, I've never seen that one before.  And yes, it is provably exactly
correct (up to a little integer round-off because of the implicit right
shift by 1).  I guess I learned a new trick today; that's really cool!


> [wl_gamepad::connect and disconnect]
>
> > Do we really need connect and disconnect timestampped?  Are those
> timestamps
> > going to be reliable/useful?  When you plug in a device, it takes a
> second
> > or two just to detect and show up in /dev.  On that time scale, "when
> did I
> > see the event?" is just as accurate as any timestamp.
>
>     It seemed like all events had timestamps as part of the protocol,
> so I didn't know how fundamental that was to the underlying system.
> The only reason connect and disconnect might need to be timestamped is
> if events are going to be batched up, you might possibly have ordering
> issues with delivery.  If that's not a problem and the underlying
> system doesn't require timestamps, they can go.
>
> [wl_gamepad::button]
>
> >>     The trigger_index is 0 for left stick values and 1 for right stick
> >> values.  Hardware with more triggers can potentially supply higher
> >> values; the pressure-sensitive buttons on the ps3 controller would go
> >> here, for instance.
> >
> > Could you be more clear about what other pressure-sensitive buttons on
> the
> > PS3 controller you're referring to here?  I know they went a bit
> overboard
> > on pressure sensitivity in the PS3 controller and seem to recall that
> even
> > buttons like triangle etc. were pressure-sensitive.  That said, those
> > buttons should map as buttons not triggers so that they can be picked up
> in
> > a canonical way.  Are you simply planning to double-report events there?
>
>     I included this as a "this data could work without breaking the
> protocol", but it's not essential.
>
>     In the particular case of the ps3 (and all of the dual shock
> controllers, IIRC), all of the buttons are pressure sensitive with a
> [0..255] range except "start", "select", "home" (on pads that have it)
> and the stick clicks.  The face buttons, the dpad and all four
> shoulder buttons are pressure sensitive.  Whether it's worth exporting
> that is another question entirely; I've heard rumour that the ps4
> controller removes pressure sensing from a lot of the buttons.
>
> [wl_gamepad::extended]
>
> > My feeling on this would be to wait until we have a use-case for it.  We
> can
> > always bump the version and add an event if it comes up.  I think that's
> > better than just assuming we can do something sensible with four generic
> > parameters.
>
>     This is partly in response to things like the razer Wiimote-like
> contraption that apparently spits out piles of quaternions, and also
> things like hardcore flightsticks that have things like fixed-range
> throttles.  I'm not convinced it's needed either, but I figured if I
> was making a proposed protocol it was worth throwing it in for the
> sake of discussion.
>
>                                         Todd.
>
> --
>  Todd Showalter, President,
>  Electron Jump Games, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130426/a530f82d/attachment.html>