_DEVICES and joystick glitched?

[SpriggsySpriggs]

I'd use this stuff more often if I knew what the heck was going on

[NOVARSEG]

 SMcNeill

127 increments OK!!!!!!!

So with a signed byte the joystick center is still at -128

 127 increments on either side of center will arrive at byte values of 1 or -1, never arriving at zero. So:

byte value of 1 can be interpreted as
1/127 * -(-128 +1) = 1/127 * 127 = 1

byte value of -1 can be interpreted as
1/127 * (-128 +1) = 1/127 * -127 = -1

byte value of -128 can be interpreted as
1/127 * (-128 +128) = 1/127 * 0 = 0

all sent with a single byte!

[SpriggsySpriggs]

So much simpler with XInput for determining position (but isn't cross platform with WinAPI, so....). So glad I have a modern controller:

bLeftTrigger

The current value of the left trigger analog control. The value is between 0 and 255.

bRightTrigger

The current value of the right trigger analog control. The value is between 0 and 255.

sThumbLX

Left thumbstick x-axis value. Each of the thumbstick axis members is a signed value between -32768 and 32767 describing the position of the thumbstick. A value of 0 is centered. Negative values signify down or to the left. Positive values signify up or to the right. The constants XINPUT_GAMEPAD_LEFT_THUMB_DEADZONE or XINPUT_GAMEPAD_RIGHT_THUMB_DEADZONE can be used as a positive and negative value to filter a thumbstick input.

sThumbLY

Left thumbstick y-axis value. The value is between -32768 and 32767.

sThumbRX

Right thumbstick x-axis value. The value is between -32768 and 32767.

sThumbRY

Right thumbstick y-axis value. The value is between -32768 and 32767.

[NOVARSEG]

SpriggsySpriggs

Lots of resolution on the thumb stick !

So thumb stick center is actually zero for the signed (2 byte) value.

That is another way to do it.

[NOVARSEG]

SMcNeill

This is the same type results I’m producing, with the same style joystick.  At startup, everything I have reads zero properly.  All I need do is press a simple button, and then I generate the very long single precision digit.  (Which is, oddly enough, exactly 1/127 — which is the tolerance level STICK and STRIG tolerates without glitching out.)

The 1/127 makes sense if there are 127 increments  either side of joystick center

 byte value of -128 can be interpreted as
1/127 * (-128 +128) = 1/127 * 0 = 0  (center)

One increment either side of joystick center:

byte value of 127 can be interpreted as
1/127 * -(-128 +127) = 1/127 * 1 = 1/127 = 0.0078740157480315

byte value of -127 can be interpreted as
1/127 * (-128 +127) = 1/127 * -1 = -1/127  = -0.0078740157480315

1/127 is the value of a single increment.

[NOVARSEG]

SMcNeill
From :  https://www.qb64.org/forum/index.php?topic=3303.0

Works with my USB gamepad, without any issues, which confuses the heck out of me.  The glitch my controller reports is always around a 0.0078... range of variance off center.  STICK offers a range from 1 to 254, with 127 being center, giving us 127 levels of precision in any direction.  1/127 is 0.0078... The variance _DEVICES reports is *exactly* the same amount as 1 level off on STICK — yet, it’s not going off center

 -128 is the signed byte value for joystick center

STICK offer a range of 1 to 254

I don't know why that is the range, it should be 1 to  255 because 1 is interpreted as 1 and 255 is interpreted as -1

There would be 127 increments on either side of joystick center * 2 = 254 increments with each increment using a state.

One state is zero (illegal)

The other state is used by the center value of -128 for a total of 256 states

Could STICK be thinking that 127 was center?

your controller  says 127 which is one increment past the actual center of -128.  So is STICK thinking that 127 is center and accepts the glitched value?

Whereas _DEVICES shows the error.

[SMcNeill]

https://www.qb64.org/wiki/STICK

STICK uses 127 as center, with values of 1 TO 254.

(1 TO 126)    127    (128 TO 254)

This gives 126 points of negative variance, and 127 points of positive variance off-center.  Now WHY these two scales aren’t the same, I have no clue, but that’s just the way they are.

_DEVICES returns SINGLE precision values from -1 TO +1, with 0 being centered, but it’s so sensitive it generates false positives if you just want to check for values <>0 as being off center.  You’ll need to code a tolerance level into your programs to avoid those false results.

[NOVARSEG]

Found some real STICK readouts on a you tube vid.  OK hope I'm allowed to post a vid here

at 7:36 into the video.  SORRY for posting a vid link but thought this was important.
****
For the right stick:
full up = 0
center  = 127
full down  = 255

full right = 255
center = 128
full left = 0
****
For the left stick:
full up = 0
center  = 127
full down  = 255

full right = 255
center = 128
full left = 0
****

The up - down axis has a center of 127 and the left - right axis has a center of 128

The left - right axis has 128 increments from center to full left and 127 increments from center to full right.   

The up - down axis has 128 increments from center to full down  and 127 increments from center to full up.   

Still not sure why both 127 and 128 are used as center values. Maybe there is no longer a true center because of the unequal increments. If 127 or 128 is used as center the increments are still 127 on one side of center and 128 on the other side.

If 127 is used as center : 
0 to 127 = 127 increments ,   127 to 255 = 128 increments

If 128 is used as center : 
0 to 128 = 128 increments ,   128 to 255 = 127 increments