Author Topic: Experiments with _MOUSEINPUT  (Read 471 times)

0 Members and 1 Guest are viewing this topic.

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Experiments with _MOUSEINPUT
« 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)
  2.  
  3. PRINT " press ESC to end program  "
  4.  
  5.     IF INKEY$ = CHR$(27) THEN SYSTEM
  6.  
  7.     mouse% = _MOUSEINPUT
  8.  
  9.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  10.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  11.         f% = 0: g% = 0: m% = 0: n% = 0
  12.     END IF
  13.  
  14.     IF mouse% = 0 AND g% = 1 THEN
  15.         f% = 1
  16.         n% = n% + 1
  17.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%
  18.     END IF
  19.  
  20.     IF mouse% = -1 AND f% = 0 THEN
  21.         g% = 1
  22.         m% = m% + 1
  23.  
  24.         'n% = 0
  25.     END IF
  26.  
  27.  
  28.  
« Last Edit: January 11, 2021, 01:43:34 AM by NOVARSEG »

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Re: Experiments with _MOUSEINPUT
« Reply #1 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)
  2.  
  3. PRINT " press ESC to end program  "
  4.  
  5. PRINT " press space bar to switch LOOP delay on and off "
  6. a = 0
  7.  
  8.  
  9.  
  10.  
  11.     i$ = INKEY$
  12.  
  13.     IF i$ = CHR$(27) THEN SYSTEM
  14.  
  15.     IF a = 1 THEN _DELAY .01: LOCATE 7, 10: PRINT "Delay = ON "
  16.     IF a = 0 THEN LOCATE 7, 10: PRINT "Delay = OFF"
  17.  
  18.     IF i$ = CHR$(32) AND a = 1 THEN a = 0: i$ = ""
  19.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  20.  
  21.     mouse% = _MOUSEINPUT
  22.  
  23.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  24.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  25.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  26.     END IF
  27.  
  28.     IF mouse% = 0 AND g% = 1 THEN
  29.         f% = 1
  30.         n% = n% + 1
  31.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%
  32.     END IF
  33.  
  34.     IF mouse% = -1 AND f% = 0 THEN
  35.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  36.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  37.         g% = 1
  38.         m% = m% + 1
  39.     END IF
  40.  
  41.  
  42.  
« Last Edit: January 13, 2021, 12:50:29 AM by NOVARSEG »

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Re: Experiments with _MOUSEINPUT
« Reply #2 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)
  2.  
  3. PRINT "Press ESC to end program  "
  4.  
  5. PRINT "Press space bar to switch LOOP delay on and off "
  6. a = 0
  7.  
  8.  
  9.     i$ = INKEY$
  10.  
  11.     IF i$ = CHR$(27) THEN SYSTEM
  12.  
  13.     IF a = 1 THEN _DELAY .01: LOCATE 7, 10: PRINT "Delay = ON "
  14.     IF a = 0 THEN LOCATE 7, 10: PRINT "Delay = OFF"
  15.  
  16.     IF i$ = CHR$(32) AND a = 1 THEN a = 0: i$ = ""
  17.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  18.  
  19.     mouse% = _MOUSEINPUT
  20.  
  21.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  22.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  23.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  24.     END IF
  25.  
  26.     IF mouse% = 0 AND g% = 1 THEN
  27.         f% = 1
  28.         n% = n% + 1
  29.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%; "     "
  30.     END IF
  31.  
  32.     IF mouse% = -1 AND f% = 0 THEN
  33.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  34.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  35.         wheel% = wheel% + _MOUSEWHEEL
  36.         LOCATE 21, 10: PRINT "Wheel "; wheel%
  37.         g% = 1
  38.         m% = m% + 1
  39.     END IF
  40.  
  41.  
  42.  





« Last Edit: January 13, 2021, 02:53:23 AM by NOVARSEG »

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3234
    • Steve’s QB64 Archive Forum
Re: Experiments with _MOUSEINPUT
« Reply #3 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.
« Last Edit: January 13, 2021, 06:22:12 AM by SMcNeill »
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Re: Experiments with _MOUSEINPUT
« Reply #4 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.



« Last Edit: January 13, 2021, 09:00:18 PM by NOVARSEG »

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3234
    • Steve’s QB64 Archive Forum
Re: Experiments with _MOUSEINPUT
« Reply #5 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.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Re: Experiments with _MOUSEINPUT
« Reply #6 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)
  2.  
  3. PRINT "Press ESC to end program  "
  4.  
  5. PRINT "Press space bar to switch _LIMIT values "
  6. a = 0
  7.  
  8.  
  9.     i$ = INKEY$
  10.  
  11.     IF i$ = CHR$(27) THEN SYSTEM
  12.  
  13.     IF a = 1 THEN _LIMIT 500: LOCATE 7, 10: PRINT " _LIMIT = 500  "
  14.     IF a = 0 THEN _LIMIT 1000: LOCATE 7, 10: PRINT " _LIMIT  = 1000 "
  15.  
  16.     IF i$ = CHR$(32) AND a = 1 THEN a = 0: i$ = ""
  17.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  18.  
  19.  
  20.  
  21.     mouse% = _MOUSEINPUT
  22.  
  23.     IF mouse% = -1 AND g% = 1 AND f% = 1 THEN
  24.         LOCATE 12, 10: PRINT "Consecutive _mouseinput = 0  "; n%; "     "
  25.         f% = 0: g% = 0: m% = 0: n% = 0: j% = 0
  26.     END IF
  27.  
  28.     IF mouse% = 0 AND g% = 1 THEN
  29.         f% = 1
  30.         n% = n% + 1
  31.         LOCATE 14, 10: PRINT "Consecutive _mouseinput = -1 "; m%; "     "
  32.     END IF
  33.  
  34.     IF mouse% = -1 AND f% = 0 THEN
  35.         LOCATE 17, 10: PRINT "X Position "; _MOUSEX
  36.         LOCATE 19, 10: PRINT "Y Position "; _MOUSEY
  37.         wheel% = wheel% + _MOUSEWHEEL
  38.         LOCATE 21, 10: PRINT "Wheel "; wheel%
  39.         g% = 1
  40.         m% = m% + 1
  41.     END IF
  42.  
  43.  











« Last Edit: January 14, 2021, 12:21:00 AM by NOVARSEG »

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Re: Experiments with _MOUSEINPUT
« Reply #7 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)
  2.  
  3. PRINT "Press ESC to end program  "
  4.  
  5. PRINT "Press space bar to switch _LIMIT values "
  6. a = 0
  7.  
  8.  
  9.     i$ = INKEY$
  10.  
  11.     IF i$ = CHR$(27) THEN SYSTEM
  12.  
  13.     IF a = 2 THEN _LIMIT 50: LOCATE 7, 10: PRINT " _LIMIT = 50  "
  14.     IF a = 1 THEN _LIMIT 500: LOCATE 7, 10: PRINT " _LIMIT = 500  "
  15.     IF a = 0 THEN _LIMIT 1000: LOCATE 7, 10: PRINT " _LIMIT  = 1000 "
  16.  
  17.  
  18.     IF i$ = CHR$(32) AND a = 2 THEN a = 0: i$ = ""
  19.     IF i$ = CHR$(32) AND a = 1 THEN a = 2: i$ = ""
  20.     IF i$ = CHR$(32) AND a = 0 THEN a = 1: i$ = ""
  21.  
  22.  
  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.  
  47.  
« Last Edit: January 15, 2021, 12:27:31 AM by NOVARSEG »

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Re: Experiments with _MOUSEINPUT
« Reply #8 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.

« Last Edit: January 15, 2021, 02:33:02 AM by NOVARSEG »

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3234
    • Steve’s QB64 Archive Forum
Re: Experiments with _MOUSEINPUT
« Reply #9 on: January 15, 2021, 02:11:30 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??
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline NOVARSEG

  • Forum Regular
  • Posts: 174
Re: Experiments with _MOUSEINPUT
« Reply #10 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.)

« Last Edit: January 15, 2021, 09:59:56 PM by NOVARSEG »

Offline NOVARSEG

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



« Last Edit: January 16, 2021, 01:16:29 AM by NOVARSEG »