Let’s see if I can help explain away the mystery.
A few things to establish first: Your OS is actually what interacts with your hardware. Windows/Mac/Linux all handle the drivers and such, and they read our input devices; QB64 doesn’t do this ourselves. We just read the input buffers that the OS reserves for us, and use them to associate with the device they tell us they belong to.
Now, your OS is going to have a set speed that it polls the hardware at, to check device state at a certain frequency. A keyboard might check changes 10 times a second, whereas a mouse might poll for updates 100 times a second. Some of these settings you can tweak via the OS interface (such as keyboard repeat rate), some of them you can’t. (At least not easily, that I know of.)
Now, how does this affect our programming inside QB64? Let’s look at a few simple programs:
DO
x = _MOUSEINPIT
LOOP
Now with the above, we might process that do loop 1000 times a second, while the hardware is polling the mouse 100 times a second. We’re going to catch every mouse event, keep the buffer clear, and have no issues with anything.
DO
x = _MOUSEINPUT
_LIMIT 10
LOOP
Now, however, we’re just doing the do loop 10 times a second, while the hardware is polling the mouse 100 times a second. We’re never going to clear that mouse buffer, so our program is always going to respond to mouse events that occurred in the past. We set a limit to use less CPU and play nice with other programs, and we’re not looping as fast as the hardware is putting stuff into the buffer.
So what’s the solution??
DO
WHILE _MOUSEINPUT: _WEND
_LIMIT 10
LOOP
Now we’re running our loop 10 times a second. The hardware is polling the mouse 100 times a second...
And we throw away 90% of that information!
What a real-time event log might look like is similar or this:
MILISECONDS
0 QB64 runs loop. Mouse at 64, 128
1 Mouse at 64, 128.2
2 Mouse at 64, 128.4
3 Mouse at 64, 128.6
4 Mouse at 64, 128.8
5 Mouse at 64, 129.1
6 Mouse at 64, 129.3
7 Mouse at 64, 129.6
8 Mouse at 64, 129.8
9 Mouse at 64, 130.1
10 QB64 does loop. Mouse at 64, 130.4
Now, do we *really* care where the mouse was in that fraction between fractional seconds of our DO..LOOP? Or do we really only care about *where it’s at when QB64 loops back around to it again*??
We toss away a lot of the information, with the logic of: “I don’t care where it was 0.002 seconds ago, I what to know where it is NOW.”
Think of it like trying to pace off 1000 feet while walking. You don’t put your feet heel to toe and try and count every exact span of your foot. You just care about each individual step taken, and what your steady stride is. You ignore that fractional information, for the expediency of simply getting from Point A to Point B in a reasonable manner.
And that’s basically WHY bplus’s example works for us. We’re only reacting to the mouse’s state when we poll it; not whatever it might be between those loops.