_DEVICES and joystick glitched?

[FellippeHeitor]

No glitch on my end with the updated snipped you provided. I've only changed the _LIMIT line so it updates more often.

[SpriggsySpriggs]

I don't have any glitches either. If any axes are off by a bit it is because my controller has a messed up deadzone. Same results with XInput WinAPI. It's probably just the controller.

[SMcNeill]

So it's either a Windows thing, a specific model joystick/driver thing, or just a Steve's old hardware thing...

I've ordered me a new joystick which should be here on the 2nd from Amazon.  Here's hoping that once it's hooked up, the glitch will disappear for good for me.  :)

[SpriggsySpriggs]

Waiting for your update with great anticipation. I love the idea of using gamepads with QB64

[TempodiBasic]

Hi guys and gals
I love so much passion versus QB64 and its features...
Also this argument is very interesting for all those like to use Joystick in their applications.
I can apport my experience with the codes posted into this thread.

Using the beginning code posted by Steve  I find some issue.
In a second moment using the code posted by Fellippe I got it works fine!.
Running the second code of Steve that matches the features of that posted by Fellippe I got some strange results.
Seeing closer to it I found that we can get some erroneous input from Joystick if we go too slow to catch the events.

however the same last code of Steve gives good detection of event... the issue that I found  was about the output of these events. I try to be clearer : _AXIS gives as output a single precision number that  is -1/1 if the knob of joystick reaches the extreme inferior / superior point  of its range of movement, while when it stands on the middle he gives back a value very long in single precision digit.

The joystick that I have used is a generic joystick USB  similar to that of PS3

Adapting the output of the last code of Steve I can say that  it gives back tha same results of that of Fellippe.

Code: QB64: [Select]

1. Dev = _DEVICES
2. DO
3.     WHILE _DEVICEINPUT(3): WEND
4.     FOR i = 1 TO _LASTBUTTON(3)
5.         but = _BUTTON(i)
6.         LOCATE i + 2, 5
7.         IF but <> 0 THEN PRINT "Button"; i; but ELSE PRINT "Button "; i; SPACE$(20)
8.     NEXT
9.     FOR i = 1 TO _LASTAXIS(3)
10.         LOCATE i + 2, 30
11.         ax = _AXIS(i)
12.         IF ax <> 0 THEN PRINT "AXIS "; i; ax ELSE PRINT "AXIS "; i; SPACE$(20)
13.     NEXT
14.     _LIMIT 10
15.     CLS
16. LOOP
17.  

Thanks to read

PS: about the issue that moving the right knob I got button pressed sorry that is a my mistake because when is activate the switch on the joystick it works in that way Right knob and right side button are the same, so the left cursor buttons and left knob are the same. It is a feature of this kind of joystick, No issue for QB64!

[SMcNeill]

I try to be clearer : _AXIS gives as output a single precision number that  is -1/1 if the knob of joystick reaches the extreme inferior / superior point  of its range of movement, while when it stands on the middle he gives back a value very long in single precision digit.

The joystick that I have used is a generic joystick USB  similar to that of PS3

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.)

Test the code here and see if that glitch doesn’t go away: https://www.qb64.org/forum/index.php?topic=3303.0

The level of off-centerness is less than 1 in 126 points of change allowed with the command. (1-126) is left/down, (127) is center, (128-254) is right/up.

STICK only reads 1/126th levels of precision.  The false reading is 1/127th of a click. It’s juuuuuuust enough of a difference that STICK ignores it and calls it 0, preventing the false positive.  (On my machine, at least.)  Test it out, and let me know if/how it works for you.  ;)

[TempodiBasic]

Hi Steve,
so I'm understanding that what you are calling glitch is a too much sensitivity of the _DEVICE that report a fixed result ( a single precision digit too long that is expressed in output as  digit elevated to power) near to 0 but not 0.
Wow  this appears to be like the  Limit towards 0 of a function!
So the user (coder) must manage manually this too precision of _DEVICE  to avoid false reading of events...
it needs just to tare the 0 state to that value that is always the same for the same state of my generic USB joystick (the fix long value is different for the two state of joystick:  Analogic ON / OFF   -1.5XXXXXXX ^-5 = -0,000015XXXXXX / -7,82XXXXXX^-3 = -0,00782XXXXXX ).

well my solution is taring the 0 position with tolerance as you suggest at the beginning of this thread
so adding this line of code into last test

Code: QB64: [Select]

1.  IF ax < 0.01 AND ax > -0.01 THEN ax = 0  

we got a standard working of joystick

Code: QB64: [Select]

1. Dev = _DEVICES
2. DO
3.     WHILE _DEVICEINPUT(3): WEND
4.     FOR i = 1 TO _LASTBUTTON(3)
5.         but = _BUTTON(i)
6.         LOCATE i + 2, 5
7.         IF but <> 0 THEN PRINT "Button"; i; but ELSE PRINT "Button "; i; SPACE$(20)
8.     NEXT
9.     FOR i = 1 TO _LASTAXIS(3)
10.         LOCATE i + 2, 30
11.         ax = _AXIS(i)
12.         IF ax < 0.01 AND ax > -0.01 THEN ax = 0
13.         IF ax <> 0 THEN PRINT "AXIS "; i; ax ELSE PRINT "AXIS "; i; SPACE$(20)
14.     NEXT
15.     _LIMIT 10
16.     CLS
17. LOOP
18.  
19.  

another option is to use the scale of input for managing the input too precise
as Fellippe showed with his code....
as you can see he uses the function MAP to calculate the position of the cursor of the joystick along the axis.

[SMcNeill]

That’s the solution I came up with as well to eliminate that false positive:

IF ABS(ax) > 0.01 THEN ‘Axis changed

For whatever reason, _DEVICES doesn’t reset all the way to 0 on my joystick, once I press a button.  The axis state stays around -0.0078.... (the same as your Analogic OFF)

With STICK, our scale of input is slightly larger than this minute amount off, so it reads 127 (dead center), as it should, rather than 126, which would be the next point off center.

My only concern with the tolerance limitation was when you posted the screenshot of moving the axis and getting false positives on the buttons.  Our buttons are only 0 or -1, so we can’t adjust a tolerance level for those!  Luckily, that’s a controller setting/option on your joystick, and not something we have to worry about.

I think a tolerance level on the axis, as above, can eliminate those false positives for us and have everything reading properly.  (Though I’d probably end up setting my stress test at around 0.1, instead of 0.001, just to rule out any problems with someone who might have a controller that glitches even a little more than ours do.)

[Cobalt]

Analog Joysticks are just that Analog, so there is some "noise", this shows up even in my Windows Game Controllers properties panel. the little center cross hairs "vibrate" just a tiny bit when the stick is just siting on the desk, and tends to get a little "jiggle" if buttons are pressed. That of course would have nothing to do with QB64.
Thats where the programmer would have to deal with the noise from the device, I'm pretty sure if you could hack a console game for anything that uses one of those controllers, you would probably find some code in game to cancel that out or a special instruction set to cancel out controller noise before the game even sees it.

So, lets say, if you were to use a _BYTE to monitor joystick motion, you would want to ignore anything that returned, say, a value of +\- 3.

[STxAxTIC]

I'm glad this is becoming resolved so publicly. Cobalt, you are on FIRE right now!

[SMcNeill]

Analog Joysticks are just that Analog, so there is some "noise", this shows up even in my Windows Game Controllers properties panel. the little center cross hairs "vibrate" just a tiny bit when the stick is just siting on the desk, and tends to get a little "jiggle" if buttons are pressed. That of course would have nothing to do with QB64.
Thats where the programmer would have to deal with the noise from the device, I'm pretty sure if you could hack a console game for anything that uses one of those controllers, you would probably find some code in game to cancel that out or a special instruction set to cancel out controller noise before the game even sees it.

So, lets say, if you were to use a _BYTE to monitor joystick motion, you would want to ignore anything that returned, say, a value of +\- 3.

Aye.  That's what I mentioned up in Reply #3:  IF ABS(_AXIS(i)) > 0.1 THEN...

The only concern after that was when Tempodi was posting false positives with button readings when pressing an axis, but that was later determined to be a controller toggle setting.

_DEVICES needs to account for that minute variance, whereas STICK and STRIG, as I posted as alternatives, don't.  They were made for analog devices back in the day, and their level of tolerance isn't as great as _DEVICES is.  _DEVICE will read a joystick as being -0.0000005 points off center, whereas STICK will happily call that centered for you.  ;)

[NOVARSEG]

OK a signed byte is from -128 to + 127 decimal

If the axis has 256 increments per rotation, then the center = 128(unsigned)  -128(signed)

Say the axis detection hardware uses a signed byte to store position data.

Position data could be calculated as follows:

A signed byte value of -128 would be center position with a return value =
1/128 * (-128 +128) = 1/128 * 0

A signed byte value of -127 would be one increment past center position with a return value =   1/128 * (-128 +127) = 1/128 * -1 = -0.0078125

****
For the positive byte values:

A signed byte value of -128 would be center position with a return value =
1/128 * -(-128 +128) = 1/128 * 0 = 0

A signed byte value of 127 would be one increment past center position with a return value = 1/128 * -(-128 +127) = 1/128 * 1 = 0.0078125

A signed byte value of 1 would be 127 increment past center position with a return value = 1/128 * -(-128 +1) = 1/128 * 127 = .9921875
 
A signed byte value of  0 would be 128 increment past center position with a return value = 1/128 * -(-128 +0) = 1/128 * 128 = 1


****
OK was looking at the AXIS function and it returns -1, 1 with 0 at center.  In the code above you can see the calculation for 1 , 0 but  in order to get -1 there must be a weird value of -0 which does not really exist as there are only 256 states in a byte and to store the interpretation of -0 would require 257 states.

In the usual counting system 0 is not viewed as being the center but it seems that the AXIS outputs suggest the existence of -0.

For instance  the signed byte values usually count like -3, -2, -1,  0

If zero is at the center then
-0 would mean a count from -1 to 0 
 0 would mean a count from  1 to 0
 
OK lets try -0
A signed byte value of  -0 would be 128 increment past center position with a return value = 1/128 * (-128 +0) = 1/128 * -128 = -1

. Sorry for all the edits.

[johnno56]

A slightly related question:

With all this talk about joysticks and getting them to work properly, can I assume that somebody is planning on writing a flight-sim? Please say yes....I have a Logitech Extreme 3D Pro stick that has been sitting on my desk for years... The only time I pick it up is to remove dust... My trigger finger is rusting solid... lol

J

[NOVARSEG]

SPOK
what do you think about -0?

I'm trying to send joystick data to a computer. The data is a byte value where each value corresponds to a particular position.

The computer derives the position from the byte values as:

Position values:
      center = 0 
   max left = 1   
max right = -1   
 
A full 128 increments on either side of joystick center would require the byte plus another indicating bit of data that gives a total of  257 states. 

I wanted to send a single byte of data.

[SMcNeill]

SPOK
what do you think about -0?

I'm trying to send joystick data to a computer. The data is a byte value where each value corresponds to a particular position.

The computer derives the position from the byte values as:


      center = 0 
   max left = 1   
max right = -1   
 
A full 128 increments on either side of joystick center would require the byte plus another indicating bit of data that gives a total of  257 states. 

I wanted to send a single byte of data.

Which is why you use 127 increments on either side...

(-127 TO -1)  0    (1 TO 127)

Signed bytes go from -128 to + 127, so just use 127 step scale for amount off-center.