QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: SMcNeill on February 20, 2019, 12:20:30 pm
-
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?
-
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:
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?
-
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:
-
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.
-
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:
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
Method 2: Clear the buffer after processing mouse information
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:
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.
-
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?