Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: NOVARSEG on January 11, 2021, 12:05:59 am

Title: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 11, 2021, 12:05:59 am
I found in general that _MOUSEINPUT returns -1 if there is mouse movements and 0 for no mouse movement.

When the mouse is moving, there are 2 consecutive -1 values returned.  After those  2 values, even when the mouse is moving, there are an undetermined (variable) number if consecutive 0 (zeros) returned.

With the mouse still moving, another 2 consecutive -1 values are returned and then again after those values , more zeros are returned.  It does not seem like any ordinary buffer system.


Also, when any mouse button is held down, with no mouse movement, then only a single -1 value is returned.

If any mouse button is held down while moving the mouse, then 2 consecutive -1 are returned

The consecutive -1 values returned are very stable but the consecutive number of zeros returned are variable.

It looks like the 2 consecutive - 1 values are returned as soon as the mouse is moved.

As the mouse is moved, there would be times between pixels where there are no valid data and that is probably when _mouseinput returns zeros. I noticed the faster I moved the mouse the smaller the number of consecutive zeros returned.

The question is why are two consecutive  -1 values returned? .

Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(1000, 800, 32)
  5.  
  6. PRINT " press ESC to end program  "
  8.  
  9.     IF INKEY$ = CHR$(27) THEN SYSTEM
  10.  
  11.     mouse% = _MOUSEINPUT
  12.  
  13.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  14.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  15.         f% = 0: g% = 0: m% = 0: n% = 0
  16.     END IF
  17.  
  18.     IF mouse% = 0 AND g% = 1 THEN
  19.         f% = 1
  20.         n% = n% + 1
  21.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%
  22.     END IF
  23.  
  24.     IF mouse% = -1 AND f% = 0 THEN
  25.         g% = 1
  26.         m% = m% + 1
  27.  
  28.         'n% = 0
  29.     END IF
  30.  
  31.  
  34.  
Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 12, 2021, 09:50:10 pm
Added a delay to the loop and now get very different results.

See how windows stores mouse movement data in the mouse buffer (wherever and whatever that is)

Move the mouse a distance, then stop,  and watch the mouse positions update.

When the positions stop updating, the consecutive _mouseinputs that = -1 will update, revealing how many data items were in the buffer.   This is always an even number.

To make this more interesting,  gonna change the code in a few minutes so the user can switch the delay on and off by pressing the space bar.

With the delay = ON, the number of items in the buffer far exceeds the number of positions represented by a change in the  X, Y positions.  That suggest  there are a lot of zeros stored in the buffer between valid data. 

Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(1000, 800, 32)
  5.  
  6. PRINT " press ESC to end program  "
  8.  
  9. PRINT " press space bar to switch LOOP delay on and off "
  10. a = 0
  11.  
  12.  
  13.  
  15.  
  16.     i$ = INKEY$
  17.  
  18.     IF i$ = CHR$(27) THEN SYSTEM
  19.  
  20.     IF a = 1 THEN _DELAY .01: LOCATE 7, 10: PRINT "Delay = ON "
  21.     IF a = 0 THEN LOCATE 7, 10: PRINT "Delay = OFF"
  22.  
  23.     IF i$ = CHR$(32) AND a = 1 THEN a = 0: i$ = ""
  24.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  25.  
  26.     mouse% = _MOUSEINPUT
  27.  
  28.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  29.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  30.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  31.     END IF
  32.  
  33.     IF mouse% = 0 AND g% = 1 THEN
  34.         f% = 1
  35.         n% = n% + 1
  36.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%
  37.     END IF
  38.  
  39.     IF mouse% = -1 AND f% = 0 THEN
  40.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  41.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  42.         g% = 1
  43.         m% = m% + 1
  44.     END IF
  45.  
  46.  
  49.  
Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 13, 2021, 01:53:56 am
The following code sort of works

Quote
WHILE _MOUSEINPUT: WEND
        my% = _MOUSEY
        mx% = _MOUSEX
        lb% = _MOUSEBUTTON(1)

but

it erases data that windows saved in the mouse buffer.  If  _mouseinput  is in a slow loop  then a higher percentage of the data  will be erased.   

If windows goes to the trouble of storing the mouse data then why erase it?

In a fast loop, every data item in the buffer , when(while) _mouseinput = -1, can be read (in real time) as can be seen in the code presented in this thread.    It makes no sense to do

WHILE _MOUSEINPUT: WEND

especially in a fast loop or  even in a slow loop.


*** Code updated
 ***mousewheel added

For every click of the mouse wheel, there will be two  data items stored in the buffer.

With the delay = ON , rapidly scroll the wheel and you will  see a number of data items (_mouseinput = -1) stored in the buffer.

Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(1000, 800, 32)
  5.  
  6. PRINT "Press ESC to end program  "
  8.  
  9. PRINT "Press space bar to switch LOOP delay on and off "
  10. a = 0
  11.  
  13.  
  14.     i$ = INKEY$
  15.  
  16.     IF i$ = CHR$(27) THEN SYSTEM
  17.  
  18.     IF a = 1 THEN _DELAY .01: LOCATE 7, 10: PRINT "Delay = ON "
  19.     IF a = 0 THEN LOCATE 7, 10: PRINT "Delay = OFF"
  20.  
  21.     IF i$ = CHR$(32) AND a = 1 THEN a = 0: i$ = ""
  22.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  23.  
  24.     mouse% = _MOUSEINPUT
  25.  
  26.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  27.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  28.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  29.     END IF
  30.  
  31.     IF mouse% = 0 AND g% = 1 THEN
  32.         f% = 1
  33.         n% = n% + 1
  34.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%; "     "
  35.     END IF
  36.  
  37.     IF mouse% = -1 AND f% = 0 THEN
  38.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  39.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  40.         wheel% = wheel% + _MOUSEWHEEL
  41.         LOCATE 21, 10: PRINT "Wheel "; wheel%
  42.         g% = 1
  43.         m% = m% + 1
  44.     END IF
  45.  
  46.  
  49.  





Title: Re: Experiments with _MOUSEINPUT
Post by: SMcNeill on January 13, 2021, 05:59:07 am
Quote
it erases data that windows saved in the mouse buffer.  If  _mouseinput  is in a slow loop  then a higher percentage of the data  will be erased.   

If windows goes to the trouble of storing the mouse data then why erase it?

Quick question:  How much information is too much information? 

Do you need to know where your mouse cursor is every minute?  Every second?  Every millisecond?  Every nanosecond?  Every 1/1000000000000000000000000000000000000th of a second?

Fractions are an infinite thing, and you have to decide how small you need something.  A cake cut into fourths is tasty; a cake cut into millionths is just powder.

By setting a _LIMIT in your program, you’re saying, “I only need interactions with a user LIMIT times per second.”  With _LIMIT 10 in your main loop, you’re only running the loop 10 times per second, and who gives a hoot about what’s going on between those decaseconds? 

So what if the user pressed the button 397 times in 1/10th of a second?!!  Your program is only going to make one cycle in that 1/10th of a second, so all you react to is one singular press; the rest you toss into the garbage.  To do otherwise, your program would have to run 397 cycles to process each of those button events, which at a limit of 10 per second means it would take 39.7 seconds to process one burst of the user’s awesome button clicking skills!!

And WTH wants that type of program???


Here's a quick example of what I'm talking about:

Code: [Select]
DIM ArrayX(100000) AS INTEGER, ArrayY(100000) AS INTEGER

DO
    count = 0
    WHILE _MOUSEINPUT
        count = count + 1
        ArrayX(count) = _MOUSEX
        ArrayY(count) = _MOUSEY
    WEND
    PRINT count; "position events in 1/5th second"
    _DISPLAY
    _LIMIT 5
LOOP UNTIL _MOUSEBUTTON(1)
At the best, this little program is only going to run 5 loops per second, since I set the limit to 5.  Scroll the mouse across the screen and see how many movement events you've triggered in each 1/5th of a second.  I think my best would be about 130, or so, on my system -- which means if I read and processed each and every one of them, I'd need 26 seconds to process every 1/5th second of user input!

The user would move their mouse across the screen a few dozen times, click the button twice, and then get to go home and enjoy a whole day off from work just because my program is now going to take the rest of their evening to track EACH AND EVERY fragment of a pixel which their mouse moved in that time!

Here, a second illustration of what I'm talking about:

Code: Text: [Select]
  1. SCREEN _NEWIMAGE(1024, 720, 32)
  2. DIM ArrayX(100000) AS INTEGER, ArrayY(100000) AS INTEGER
  3.  
  4. FOR fivepasses = 1 TO 5
  5.     DO
  6.         count = 0
  7.         WHILE _MOUSEINPUT
  8.             count = count + 1
  9.             ArrayX(count) = _MOUSEX
  10.             ArrayY(count) = _MOUSEY
  11.         WEND
  12.         _DELAY .2
  13.     LOOP UNTIL count <> 0
  14.     PRINT "In 1/5th of a second, your mouse was at:"
  15.     FOR i = 1 TO count
  16.         PRINT "("; ArrayX(i); ","; ArrayY(i); ")";
  17.     NEXT
  18. NEXT

As you can see, you're generating many more results than what you can reasonably expect to deal with.  You don't need to know where the mouse was every 1/1000th of a second, when your program is only going to be cycling every 1/5th of a second.  Clear the mouse buffer and deal with where the mouse is at, WHEN your loop cycles through, and toss out all the other garbage that happened in the past.
Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 13, 2021, 08:55:59 pm
Thanks Steve

Windows keeps track of every bit of mouse data and I see why there are times when too much data is not a good thing.

However, all of this overabundance of data results from a LOOP that is running too slow. Windows is storing information faster than the LOOP can remove it.

The question is: What is at fault here? Is windows storing data too fast or is our LOOP too slow?

Are there any good reasons for the way that windows stores mouse data?

Are there any ways that LOOPs can be sped up?

If _mouseinput is in a fast loop, then all the mouse data is removed and processed in real time.   There are no noticeable delays in the mouse response.



Title: Re: Experiments with _MOUSEINPUT
Post by: SMcNeill on January 13, 2021, 11:13:15 pm
The reason why you use _LIMIT is so your program plays nice and doesn’t use 100% CPU power and melt your fans.

Try this:

DO: LOOP UNTIL _KEYHIT

Now, what’s the CPU usage on that program?  What’s your fans doing?  How hot is your system running?


At the end of the day, it’s all up to you to decide how much information you need from the mouse, for your stuff.  Me, personally, I’ve never seen ANY program that needs 100% of the mouse input, but I’d love for someone to show me one.  I’ll be waiting with bated breath to see what you manage to come up with to show us.
Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 14, 2021, 12:15:06 am
  Working on optimizations.

There are practical ways to use the mouse.  My objective was to use all the mouse data without overloading the CPU.  A fast loop is needed but that heats up the CPU if too fast. 

A very slow loop will still track the mouse data but at the expense of a time lag.

So the practical solution is to adjust the speed of the loop to reduce the time lag to acceptable levels and to reduce CPU usage. The objective is to use ALL the mouse data generated by windows.  My code shows how _LIMIT can be accurately set.    A value of 500 (_LIMIT 500)will start to show a backlog of data in the buffer,  A value of 1000 shows very little backlog and no noticeable time delay.

Updated code

Switch _LIMIT values with spacebar

Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(1000, 800, 32)
  5.  
  6. PRINT "Press ESC to end program  "
  8.  
  9. PRINT "Press space bar to switch _LIMIT values "
  10. a = 0
  11.  
  13.  
  14.     i$ = INKEY$
  15.  
  16.     IF i$ = CHR$(27) THEN SYSTEM
  17.  
  18.     IF a = 1 THEN _LIMIT 500: LOCATE 7, 10: PRINT " _LIMIT = 500  "
  19.     IF a = 0 THEN _LIMIT 1000: LOCATE 7, 10: PRINT " _LIMIT  = 1000 "
  20.  
  21.     IF i$ = CHR$(32) AND a = 1 THEN a = 0: i$ = ""
  22.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  23.  
  24.  
  25.  
  26.     mouse% = _MOUSEINPUT
  27.  
  28.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  29.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  30.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  31.     END IF
  32.  
  33.     IF mouse% = 0 AND g% = 1 THEN
  34.         f% = 1
  35.         n% = n% + 1
  36.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%; "     "
  37.     END IF
  38.  
  39.     IF mouse% = -1 AND f% = 0 THEN
  40.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  41.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  42.         wheel% = wheel% + _MOUSEWHEEL
  43.         LOCATE 21, 10: PRINT "Wheel "; wheel%
  44.         g% = 1
  45.         m% = m% + 1
  46.     END IF
  47.  
  48.  











Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 15, 2021, 12:21:37 am
Was trying other LIMIT values and found something real interesting.

The mouse response is super slow with a  _LIMIT 50

There is noticeable time lag even with _LIMIT 500 but you would think that _LIMIT 50 would give 10 times more time lag.  Not so , more like a 1000 times more time lag.  Is _LIMIT giving a linear response?

See here the code
press space bar to switch _LIMIT 50, _LIMIT 500 or _LIMIT 1000

Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(1000, 800, 32)
  5.  
  6. PRINT "Press ESC to end program  "
  8.  
  9. PRINT "Press space bar to switch _LIMIT values "
  10. a = 0
  11.  
  13.  
  14.     i$ = INKEY$
  15.  
  16.     IF i$ = CHR$(27) THEN SYSTEM
  17.  
  18.     IF a = 2 THEN _LIMIT 50: LOCATE 7, 10: PRINT " _LIMIT = 50  "
  19.     IF a = 1 THEN _LIMIT 500: LOCATE 7, 10: PRINT " _LIMIT = 500  "
  20.     IF a = 0 THEN _LIMIT 1000: LOCATE 7, 10: PRINT " _LIMIT  = 1000 "
  21.  
  22.  
  23.     IF i$ = CHR$(32) AND a = 2 THEN a = 0: i$ = ""
  24.     IF i$ = CHR$(32) AND a = 1 THEN a = 2: i$ = ""
  25.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  26.  
  27.  
  28.  
  29.     mouse% = _MOUSEINPUT
  30.  
  31.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  32.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  33.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  34.     END IF
  35.  
  36.     IF mouse% = 0 AND g% = 1 THEN
  37.         f% = 1
  38.         n% = n% + 1
  39.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%; "     "
  40.     END IF
  41.  
  42.     IF mouse% = -1 AND f% = 0 THEN
  43.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  44.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  45.         wheel% = wheel% + _MOUSEWHEEL
  46.         LOCATE 21, 10: PRINT "Wheel "; wheel%
  47.         g% = 1
  48.         m% = m% + 1
  49.     END IF
  50.  
  51.  
  54.  
Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 15, 2021, 01:24:21 am
Tried a simple FOR NEXT loop as the delay. With a count of 400,000 the response was similar to a _LIMIT 500

With a count of 800,000 the mouse lag was not twice but maybe 10 times more than expected.  So _LIMIT is not to blame.  Trying to figure out why.

Later

Looks like the mouse delay equals the loop delay times the number of data items in the buffer.

  With a  _LIMIT  of about 1000 the LOOP keeps up with windows.

Anyway I'm gonna leave this thread for now.

Title: Re: Experiments with _MOUSEINPUT
Post by: SMcNeill on January 15, 2021, 02:11:30 am
Quote from: NOVARSEG on January 15, 2021, 01:24:21 am
Tried a simple FOR NEXT loop as the delay. With a count of 400,000 the response was similar to a _LIMIT 500

With a count of 800,000 the mouse lag was not twice but maybe 10 times more than expected.  So _LIMIT is not to blame.  Trying to figure out why.

_LIMIT just sets a maximum number of loops that you make in a second; it has no control if your processes are slower than that.

For example: _LIMIT 100000 <— This says you’ll run a maximum of 100,000 times in a second.  Now, inside your loop, add a PRINT statement and count how many times you can print to your screen in a second — it’s constantly less than that.  Since you’re already running under 100,000 loops per second, that _LIMIT does nothing.

Keep working at it.  I’m still anxiously waiting to see you write a program that needs 100% of that overwhelming amount of mouse data.  I’m honestly wondering just what the heck you’re trying to do that has to be so precise!  Open heart surgery with your mouse??
Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 15, 2021, 08:31:36 pm
Hi Steve

Was comparing a FOR NEXT with a count of  400,000 to a _LIMIT 500. I disabled _LIMIT in the FOR NEXT test.


I understand your example. 

Not every program is the same.  The main loop in a program might be slower than _LIMIT will compensate for. Not disputing that. 

from the WIKI

Quote
_LIMIT measures its interval from the previous time that it was called and minor adjustments are automatically made to ensure that the number of times a loop is repeated is correct overall.

In the case where _LIMIT 1000 can compensate for an existing loop delay, it makes no sense to automatically do

WHILE _MOUSEINPUT: WEND (or something equivalent)

(using _LIMIT 1000 as a typical value that gives good mouse response and eats that overwhelming amount of mouse data for lunch.)

Title: Re: Experiments with _MOUSEINPUT
Post by: NOVARSEG on January 16, 2021, 12:58:41 am
Got code working to show how _LIMIT compensates for main loop delay.

The LIMIT is set to 1000 for fast mouse response.  Press the Z key to increase the count of a FOR NEXT loop and X to decrease the count.  You can see _LIMIT 1000 actively compensating the main loop delay to regulate the loop to nearly one second per 1000 loops.

If the FOR NEXT count is too large, LIMIT will not be able to compensate and the overall loops per second will decrease and mouse response will deteriorate.   The loss of compensation is seen when time for 1000 loops is greater than 1 second.

Compensation is lost at a FOR NEXT count of about 300,000


Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(1000, 800, 32)
  3.  
  6.  
  7.  
  10.  
  11. PRINT "Press ESC to end program  "
  13.  
  14. PRINT "Press z to increase or x to decrease main loop delay"
  15. a = 0
  16.  
  18.  
  19.     _LIMIT 1000
  20.  
  21.  
  22.     IF z& = 0 THEN t1# = TIMER
  23.     z& = z& + 1
  24.     IF z& = 1000 THEN
  25.         t2# = TIMER
  26.         LOCATE 8, 10: PRINT "Time in seconds "; t2# - t1#; "      "
  27.         z& = 0
  28.     END IF
  29.  
  30.     FOR x = 1 TO n
  31.     NEXT x
  32.  
  33.  
  34.     i$ = INKEY$
  35.  
  36.  
  37.     IF i$ = "z" AND n < 1000000 THEN n = n + 1000
  38.     IF i$ = "x" AND n >= 1000 THEN n = n - 1000
  39.     LOCATE 9, 10: PRINT "FOR NEXT count "; n; "   simulates main loop delay "
  40.  
  41.     IF i$ = CHR$(27) THEN SYSTEM
  42.  
  43.     ' IF a = 2 THEN _LIMIT 50: LOCATE 7, 10: PRINT " _LIMIT = 50  "
  44.     'IF a = 1 THEN _LIMIT 500: LOCATE 7, 10: PRINT " _LIMIT = 500  "
  45.     ' IF a = 0 THEN _LIMIT 1000: LOCATE 7, 10: PRINT " _LIMIT  = 1000 "
  46.  
  47.  
  48.     ' IF i$ = CHR$(32) AND a = 2 THEN a = 0: i$ = ""
  49.     ' IF i$ = CHR$(32) AND a = 1 THEN a = 2: i$ = ""
  50.     ' IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  51.  
  52.  
  53.  
  54.     mouse% = _MOUSEINPUT
  55.  
  56.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  57.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  58.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  59.     END IF
  60.  
  61.     IF mouse% = 0 AND g% = 1 THEN
  62.         f% = 1
  63.         n% = n% + 1
  64.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%; "     "
  65.     END IF
  66.  
  67.     IF mouse% = -1 AND f% = 0 THEN
  68.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  69.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  70.         wheel% = wheel% + _MOUSEWHEEL
  71.         LOCATE 21, 10: PRINT "Wheel "; wheel%
  72.         g% = 1
  73.         m% = m% + 1
  74.     END IF
  75.  
  76.  



Text Only | Text with Attachments