Fwd: Input and games.

[Todd Showalter]

On Mon, Apr 29, 2013 at 9:57 AM, Bengt Richter <bokr at oz.net> wrote:
> On 04/27/2013 03:05 AM Todd Showalter wrote:

>> stick.x = ((float)raw_x) / (raw_x>= 0) ? 127.0f : 128.0f;
>> stick.y = ((float)raw_y) / (raw_y>= 0) ? 127.0f : 128.0f;
>>
> I'm not an electronics or game equipment insider, but I wonder
> why isn't the above
>
>    stick.x = (((float)(raw_x+128)) / 127.5f) - 1.0f;
>    stick.y = (((float)(raw_y+128)) / 127.5f) - 1.0f;
>
> thus mapping [0,255] to [-1.0 to +1.0] symmetrically?

    You could do that too.  There are lots of ways to calculate the
range, and in practice you may well wind up feeding the output through
an easing function as well.  There's no advantage in being too
precise, however; while your function is symmetrical, it assumes
symmetrical input, which isn't a safe assumption.  My experience has
been that most of these things center at $80, at least in theory (Sega
hardware actually did settle precisely to $80, $80 in my experience),
but most hardware has some jitter around the center position.
Sometimes that gets hidden from you by the electronics, sometimes it
doesn't.

    Many sticks also don't go to the full range even along the
encoding axis, and even those that do invariably don't encode the full
range along the diagonal; you wind up with a range of (very roughly)
-0.5(root 2) to 0.5(root 2).  They also usually have a lot of noise,
though that sometimes gets hidden from you by hysteresis built into
the electronics.  Practically speaking, a lot of gamepad joysticks
only really have about 5 bits of useful position data, and everything
below that is valid-looking noise.

    So, if you could assume that the byte value you were getting
linearly and symmetrically encoded the analog range of the device,
then yes, your algorithm would be more correct.  I don't think you can
make that assumption, but that doesn't make your algorithm wrong, just
no more correct than the alternatives.

> I think you might want to map a shaft encoder differently
> though, since while a linear fence with 256 pickets make
> a span of 255 spaces end to end, a circular fence of 256
> pickets makes 256 spaces along the full circle.

    I don't think we're mapping rotational controls anywhere, though;
the sticks are 2d vectors, and the triggers are 1d vectors.  The only
place you could get a circular input from that is from the angle of
stick deflection, and if the game wants that it can feed the stick
vector into atan2f().

> BTW, does input come in well behaved chunks, so that you get
> a well aligned struct without having to assemble it yourself from a
> stream of bytes as done somehow in showkey to group what comes
> in a burst together from a function key press? Is it one record
> at a time, or as many as are available and will fit in the
> buffer you supply?
>
> I.e., how hard would it be to write a showkey utility
> for game inputs, with similar cooked and raw options ?
>
> BTW2, does showkey itself work with wayland in all modes?

    Are you asking about how the hardware behaves, or how the proposed
protocol will behave?

                                           Todd.

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