I failed to reply-all before, so I'm forwarding this back to the list.
On Fri, Apr 26, 2013 at 5:46 PM, Jason Ekstrand <ja...@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.
[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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
