_DEVICEINPUT vs _MOUSEINPUT

[SMcNeill]

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. _SCREENMOVE _MIDDLE
3.  
4. devices = _DEVICES
5. FOR i = 1 TO devices
6.     IF INSTR(_DEVICE$(i), "[KEYBOARD]") THEN Keyboard = i
7.     IF INSTR(_DEVICE$(i), "[MOUSE]") THEN Mouse = i
8.     IF INSTR(_DEVICE$(i), "[CONTROLLER]") THEN JoyStick = i
9. NEXT
10.  
11. DO
12.     _LIMIT 60
13.     WHILE _MOUSEINPUT: WEND
14.     x = _DEVICEINPUT
15.     IF x = Mouse THEN PRINT INT(_AXIS(1) * 320 + 320), INT(_AXIS(2) * 240 + 240), _MOUSEX, _MOUSEY
16.  
17.  
18. LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit

Some very simple code to show 2 different ways to get our Mouse X/Y information. 

_DEVICEINPUT returns values of -1 to +1, with 0 being the center of our screen, so we need to translate that into screen coordinates with the simple math functions: INT(_AXIS(1) * 320 + 320) and INT(_AXIS(2) * 240 + 240).

If you run the little demo and scroll the mouse a few times, you'll quickly see my query:  Why do the numbers sometimes not match?  Is this something off with my math, as simple as it is, or is this just an instance of the 2 routines polling the mouse at various different times as it moves and generating slightly different results?  Whenever I stop moving the mouse, the end results always seem to match (within a single pixel which could be the result of rounding differences), but the steps in the middle seem completely different from each other from time to time.  (Sometimes by a change of dozens of pixels.)

Is this right?  Wrong?  Any ideas?

[SMcNeill]

I'm thinking this is a case of _DEVICEINPUT taking forever to clear the buffer and keep up with current events.  Trr this code for a demo:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. _SCREENMOVE _MIDDLE
3.  
4. devices = _DEVICES
5. FOR i = 1 TO devices
6.     IF INSTR(_DEVICE$(i), "[KEYBOARD]") THEN Keyboard = i
7.     IF INSTR(_DEVICE$(i), "[MOUSE]") THEN Mouse = i
8.     IF INSTR(_DEVICE$(i), "[CONTROLLER]") THEN JoyStick = i
9. NEXT
10.  
11. PRINT _LASTBUTTON(2), _LASTAXIS(2), _LASTWHEEL(2)
12.  
13.  
14.  
15. DO
16.     _LIMIT 60
17.     WHILE _MOUSEINPUT: WEND
18.     x = _DEVICEINPUT
19.     IF x = Mouse THEN
20.         LOCATE 1, 1
21.         PRINT INT(_AXIS(1) * 320 + 320), INT(_AXIS(2) * 240 + 240), _MOUSEX, _MOUSEY
22.         PRINT _WHEEL(1), _WHEEL(2), _WHEEL(3)
23.         PRINT _BUTTON(1), _BUTTON(2), _BUTTON(3)
24.     END IF
25. LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit
26.  
27.  

Scroll the mouse repeatedly across the screen for several seconds and then stop.  Watch how _MOUSEX/_MOUSEY give you the current location instantly, and then notice how it takes several seconds after you stop moving the mouse so the AXIS commands will catch up to your position. 

Unless I'm doing something wrong here, I really don't see how the DEVICE commands could be used reliably to handle mouse input.  Is there something obvious I'm missing to make this work as intended? 

[FellippeHeitor]

Once you've figured the mouse's _DEVICE number, call _DEVICEINPUT with that index, much like you do with _MOUSEINPUT. Look at the critical bit below:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. _SCREENMOVE _MIDDLE
3.  
4. devices = _DEVICES
5. FOR i = 1 TO devices
6.     IF INSTR(_DEVICE$(i), "[KEYBOARD]") THEN Keyboard = i
7.     IF INSTR(_DEVICE$(i), "[MOUSE]") THEN Mouse = i
8.     IF INSTR(_DEVICE$(i), "[CONTROLLER]") THEN JoyStick = i
9. NEXT
10.  
11. DO
12.     WHILE _MOUSEINPUT: WEND
13.     DO WHILE _DEVICEINPUT(Mouse): LOOP 'this is the critical bit
14.     CLS
15.     PRINT INT(_AXIS(1) * 320 + 320), INT(_AXIS(2) * 240 + 240), _MOUSEX, _MOUSEY
16.     _DISPLAY
17.     _LIMIT 60
18. LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit
19.  

[Petr]

Steve, FellippeHeitor,  thank you very much for this program. This is exactly what I was thinking about when using the mouse and the MAPTRIANGLE 3D command, which is based on OpenGL just like _DEVICEINPUT, because in the OpenGL space that generates MAPTRIANGLE 3D with MOUSEINPUT, I have to recalculate it. I needed to get mouse coordinates in the OpenGL coordinate system. I'll try to implant it tomorrow. For information on Dungeon - I already have a program that translates the map from the map image (from PNG) to OpenGL (for MAPTRIANGLE 3D), and the display in the space is correct, but I will still solve the collision scheme. The easiest way will be a 2D field that solves a collision when converting a map from PNG to an OpenGL coordinate system. The big problem I'm addressing today is a way of calculating visibility in a space that limits the number of elements to display in the array. It will take a while. But I'm a lot out of theme of this thread.

[SMcNeill]

Once you've figured the mouse's _DEVICE number, call _DEVICEINPUT with that index, much like you do with _MOUSEINPUT. Look at the critical bit below:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. _SCREENMOVE _MIDDLE
3.  
4. devices = _DEVICES
5. FOR i = 1 TO devices
6.     IF INSTR(_DEVICE$(i), "[KEYBOARD]") THEN Keyboard = i
7.     IF INSTR(_DEVICE$(i), "[MOUSE]") THEN Mouse = i
8.     IF INSTR(_DEVICE$(i), "[CONTROLLER]") THEN JoyStick = i
9. NEXT
10.  
11. DO
12.     WHILE _MOUSEINPUT: WEND
13.     DO WHILE _DEVICEINPUT(Mouse): LOOP 'this is the critical bit
14.     CLS
15.     PRINT INT(_AXIS(1) * 320 + 320), INT(_AXIS(2) * 240 + 240), _MOUSEX, _MOUSEY
16.     _DISPLAY
17.     _LIMIT 60
18. LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit
19.  

One point of interest here:  You have to either put the mousewheel information inside the WHILE:WEND loop, or else clear the buffer afterwards.  So far, I've found 2 different methods which work:

Method 1: Scroll wheel inside the WHILE

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. _SCREENMOVE _MIDDLE
3.  
4. DO
5.     _LIMIT 60
6.     WHILE _DEVICEINPUT(2): Scroll = Scroll + _WHEEL(3): WEND 'clear and update the mouse buffer
7.  
8.     LOCATE 1, 1
9.     PRINT INT(_AXIS(1) * 320 + 320), INT(_AXIS(2) * 240 + 240) 'convert to screen coordinates
10.     PRINT _WHEEL(1), _WHEEL(2), _WHEEL(3), Scroll 'mouse wheel status
11.     PRINT _BUTTON(1), _BUTTON(2), _BUTTON(3) 'mouse button status
12.  
13. LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit

Method 2: Clear the buffer after processing mouse information

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. _SCREENMOVE _MIDDLE
3.  
4. DO
5.     _LIMIT 60
6.     x = _DEVICEINPUT(2) 'update mouse information
7.  
8.     LOCATE 1, 1
9.     PRINT INT(_AXIS(1) * 320 + 320), INT(_AXIS(2) * 240 + 240)
10.     Scroll = Scroll + _WHEEL(3)
11.     PRINT _WHEEL(1), _WHEEL(2), _WHEEL(3), Scroll
12.     PRINT _BUTTON(1), _BUTTON(2), _BUTTON(3)
13.     WHILE _DEVICEINPUT(2): WEND 'clear the mouse buffer
14. LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit
15.  

In many ways, I think I personally prefer method 2 as it allows us a means to completely skip the mouse processing routines if nothing is going on with them, as such:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. _SCREENMOVE _MIDDLE
3.  
4. DO
5.     _LIMIT 60
6.     x = _DEVICEINPUT(2) 'update mouse information
7.  
8.     IF x THEN
9.         LOCATE 1, 1
10.         PRINT INT(_AXIS(1) * 320 + 320), INT(_AXIS(2) * 240 + 240)
11.         Scroll = Scroll + _WHEEL(3)
12.         PRINT _WHEEL(1), _WHEEL(2), _WHEEL(3), Scroll
13.         PRINT _BUTTON(1), _BUTTON(2), _BUTTON(3)
14.     END IF
15.  
16.     WHILE _DEVICEINPUT(2): WEND 'clear the mouse buffer
17. LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit
18.  

With programs which require a lot of CPU power, method 2 might be preferable as it skips the whole mouse handling routines unless the values have changed and require processing.

[bplus]

I wonder if keyboard and maybe even timer could be added such that you have a getEvent like routine st when called, it clears all previous mouse clicks or keypresses... and waits for next event to occur to report. Not sure that it could work with mouse wheel?