Todd, I think you forgot reply-all. I add wayland-devel again. On Fri, Apr 26, 2013 at 5:50 PM, Todd Showalter <t...@electronjump.com>wrote:
> 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. > 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. >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel