Mouse Routines

[Ophelius]

Hi,
I just recently discovered QB64, and as a huge user of QB45 in the 90's and early 2000's, QB64 is just an amazing upgrade!
That being said, I've been toying around with the built-in mouse routines and omg are they inefficient! I don't see the logic in having it only update when it changes, it makes you need all these awkward loops to do simple things. Is there an advantage I'm not understanding?

Here's some routines I modified from online examples that use assembly to read the values at any time, not just when they change:

Code: QB64: [Select]

1. FUNCTION MouseX% ()
2.  
3.     STATIC AsmMouseX%(), InitDone%
4.  
5.     IF InitDone% = 0 THEN
6.         Asm$ = "B80300CD33891EAA0A890EBB0B8916CC0CCB"
7.         Bytes% = LEN(Asm$) \ 2
8.         REDIM AsmMouseX%(Bytes%)
9.  
10.         DEF SEG = VARSEG(AsmMouseX%(0))
11.         FOR i% = 0 TO Bytes% - 1
12.             POKE VARPTR(AsmMouseX%(0)) + i%, VAL("&H" + MID$(Asm$, (i% * 2) + 1, 2))
13.         NEXT i%
14.         DEF SEG
15.         InitDone% = 1
16.  
17.     END IF
18.  
19.     DEF SEG = VARSEG(AsmMouseX%(0))
20.     CALL ABSOLUTE(VARPTR(AsmMouseX%(0)))
21.     DEF SEG
22.  
23.     MouseX% = (PEEK(&HBBB) + PEEK(&HBBC) * 256)
24.  
25. END FUNCTION
26.  
27. FUNCTION MouseY% ()
28.     STATIC AsmMouseY%(), InitDone%
29.  
30.     IF InitDone% = 0 THEN
31.         Asm$ = "B80300CD33891EAA0A890EBB0B8916CC0CCB"
32.         Bytes% = LEN(Asm$) \ 2
33.         REDIM AsmMouseY%(Bytes%)
34.  
35.         DEF SEG = VARSEG(AsmMouseY%(0))
36.         FOR i% = 0 TO Bytes% - 1
37.             POKE VARPTR(AsmMouseY%(0)) + i%, VAL("&H" + MID$(Asm$, (i% * 2) + 1, 2))
38.         NEXT i%
39.         DEF SEG
40.         InitDone% = 1
41.  
42.     END IF
43.  
44.     DEF SEG = VARSEG(AsmMouseY%(0))
45.     CALL ABSOLUTE(VARPTR(AsmMouseY%(0)))
46.     DEF SEG
47.  
48.     MouseY% = (PEEK(&HCCC) + PEEK(&HCCD) * 256)
49.  
50. END FUNCTION
51.  
52. FUNCTION MouseB% ()
53.     '0 = none, 1 = left, 2=right, 3=both
54.     STATIC AsmMouseB%(), InitDone%
55.  
56.     IF InitDone% = 0 THEN
57.         Asm$ = "B80300CD33891EAA0A890EBB0B8916CC0CCB"
58.         Bytes% = LEN(Asm$) \ 2
59.         REDIM AsmMouseB%(Bytes%)
60.  
61.         DEF SEG = VARSEG(AsmMouseB%(0))
62.         FOR i% = 0 TO Bytes% - 1
63.             POKE VARPTR(AsmMouseB%(0)) + i%, VAL("&H" + MID$(Asm$, (i% * 2) + 1, 2))
64.         NEXT i%
65.         DEF SEG
66.         InitDone% = 1
67.  
68.     END IF
69.  
70.     DEF SEG = VARSEG(AsmMouseB%(0))
71.     CALL ABSOLUTE(VARPTR(AsmMouseB%(0)))
72.     DEF SEG
73.  
74.     MouseB% = PEEK(&HAAA)
75.  
76. END FUNCTION
77.  
78. SUB MouseOn ()
79.     STATIC AsmMouseOn%(), InitDone%
80.  
81.     IF InitDone% = 0 THEN
82.         Asm$ = "B80100CD33891EAA0A890EBB0B8916CC0CCB"
83.         Bytes% = LEN(Asm$) \ 2
84.         REDIM AsmMouseOn%(Bytes%)
85.  
86.         DEF SEG = VARSEG(AsmMouseOn%(0))
87.         FOR i% = 0 TO Bytes% - 1
88.             POKE VARPTR(AsmMouseOn%(0)) + i%, VAL("&H" + MID$(Asm$, (i% * 2) + 1, 2))
89.         NEXT i%
90.         DEF SEG
91.         InitDone% = 1
92.     END IF
93.  
94.     DEF SEG = VARSEG(AsmMouseOn%(0))
95.     CALL ABSOLUTE(VARPTR(AsmMouseOn%(0)))
96.     DEF SEG
97.  
98. END SUB
99.  
100. SUB MouseOff ()
101.     STATIC AsmMouseOff%(), InitDone%
102.  
103.     IF InitDone% = 0 THEN
104.         Asm$ = "B80200CD33891EAA0A890EBB0B8916CC0CCB"
105.         Bytes% = LEN(Asm$) \ 2
106.         REDIM AsmMouseOff%(Bytes%)
107.  
108.         DEF SEG = VARSEG(AsmMouseOff%(0))
109.         FOR i% = 0 TO Bytes% - 1
110.             POKE VARPTR(AsmMouseOff%(0)) + i%, VAL("&H" + MID$(Asm$, (i% * 2) + 1, 2))
111.         NEXT i%
112.         DEF SEG
113.         InitDone% = 1
114.     END IF
115.  
116.     DEF SEG = VARSEG(AsmMouseOff%(0))
117.     CALL ABSOLUTE(VARPTR(AsmMouseOff%(0)))
118.     DEF SEG
119.  
120. END SUB
121.  

To me this is way better, whenever you need the current mouse values you just use these functions:

Code: QB64: [Select]

1. MouseOn
2. Do
3.    locate 1,1: Print MouseX, MouseY, MouseB
4. loop until inkey$ <> ""
5.  

What are your thoughts?

[TerryRitchie]

First, Welcome to the Forum :-)

Which "built-in" mouse routines are you referring to? These..

_MOUSEX, _MOUSEY, _MOUSEBUTTON(), _MOUSEINPUT, _MOUSEWHEEL, etc..?

These commands are a god-send compared to what was available back in the QB45 days. Could you provide some code examples of what you are referring to?

[FellippeHeitor]

It's really just a matter of getting used to the new approach. You replace a call to MouseOn with a single line of WHILE _MOUSEINPUT: WEND in your main program loop and you're good to go. All mouse functions will contain the current data.

Code: QB64: [Select]

1. DO
2.     WHILE _MOUSEINPUT: WEND
3.     LOCATE 1,1: PRINT _MouseX, _MouseY, _MouseButton(1)
4. LOOP UNTIL INKEY$ <> ""

Welcome to the forum.

[Ophelius]

First, Welcome to the Forum :-)

Which "built-in" mouse routines are you referring to? These..

_MOUSEX, _MOUSEY, _MOUSEBUTTON(), _MOUSEINPUT, _MOUSEWHEEL, etc..?

These commands are a god-send compared to what was available back in the QB45 days. Could you provide some code examples of what you are referring to?

Yes, all of those. Maybe I just didn't put too much thought into it. Like this for example:

Code: QB64: [Select]

1.   DO WHILE _MOUSEINPUT '      Check the mouse status
2.     PRINT _MOUSEX, _MOUSEY, _MOUSEBUTTON(1), _MOUSEWHEEL
3.   LOOP
4.  

This will only get you the values when they change, and you can't just print _MouseX etc without using _Mouseinput first.
All the examples in the help for _MouseInput, _MouseButton, etc have all these Do:Loops where it can be a lot simpler. I've used a lot of libraries in the past and none managed mouse inputs this way, they all have simple functions that return the current values when called. Maybe I'm just not used to it. So what's the advantage?

[TerryRitchie]

FellippeHeitor's example is the best approach.

_MOUSEINPUT polls the mouse for status. QB64 keeps track of all mouse events even when using something like the INPUT command. As long as _MOUSEINPUT is true (-1) there is data to be collected. If you want the latest mouse information you need to clear _MOUSEINPUT using a loop until it is false (0) like so:

WHILE _MOUSEINPUT: WEND

Now that all the previous mouse information has been cleared the next call to any mouse command will be the most recent.

[Ophelius]

Ah, I see, thanks guys. I guess it's just about wrapping my head around a new approach, I'm used to the old way which works for my coding styles. Either way, I was just curious, and the routines I posted are there and works fine if someone want's to use them.

[TerryRitchie]

You're welcome :-)  The new mouse commands were a bit strange for me as well when I first discovered QB64 but over the years have found them incredibly easy to use and manipulate.

[TerryRitchie]

Here's a little demo to show how the _MOUSEINPUT command can be used to your advantage:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. CLS
3. INPUT "Click around on the screen a few times then press ENTER", a$
4. WHILE _MOUSEINPUT
5.     IF _MOUSEBUTTON(1) THEN
6.         LINE -(_MOUSEX, _MOUSEY), _RGB32(255, 255, 255)
7.         clicks = clicks + 1
8.     END IF
9. WEND
10. PRINT "You clicked"; clicks; " times"

Even when the INPUT command has taken over QB64 is monitoring the mouse.

[Ophelius]

Here's a little demo to show how the _MOUSEINPUT command can be used to your advantage:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. CLS
3. INPUT "Click around on the screen a few times then press ENTER", a$
4. WHILE _MOUSEINPUT
5.     IF _MOUSEBUTTON(1) THEN
6.         LINE -(_MOUSEX, _MOUSEY), _RGB32(255, 255, 255)
7.         clicks = clicks + 1
8.     END IF
9. WEND
10. PRINT "You clicked"; clicks; " times"

Even when the INPUT command has taken over QB64 is monitoring the mouse.

Ok, I understand the advantage now, that is much better.
Edit: Although this does seem strange to me since the program is both in the Input loop and While:Wend loop at the same time? How is this possible? If it's in the documentation please point me to it so I can understand. Thanks

[TerryRitchie]

I'm not sure what you mean by the program being in two loops.

QB64 buffers the mouse input. You can check if there is information in the buffer by verifying that _MOUSEINPUT is true (-1). If it is you can use any of the mouse commands to grab that instance in time. _MOUSEINPUT has been placed in a WHILE:WEND loop to keep reporting about the status of the buffer. When _MOUSEINPUT is finally false (0) the buffer has been cleared.

You see this happen in Windows when you start clicking on things and Windows can't keep up, but it still remembers where and what your mouse did, even when it was busy beforehand, and catches up with you.

[Ophelius]

I'm not sure what you mean by the program being in two loops.

QB64 buffers the mouse input. You can check if there is information in the buffer by verifying that _MOUSEINPUT is true (-1). If it is you can use any of the mouse commands to grab that instance in time. _MOUSEINPUT has been placed in a WHILE:WEND loop to keep reporting about the status of the buffer. When _MOUSEINPUT is finally false (0) the buffer has been cleared.

You see this happen in Windows when you start clicking on things and Windows can't keep up, but it still remembers where and what your mouse did, even when it was busy beforehand, and catches up with you.

What I mean is that in QB45, you were stuck on the Input line until the user pressed enter(caught in the input loop, program halts until enter is pressed). The example given shows an input, but somehow it's also checking the while:wend at the same time? Is this not procedural programming anymore?

[FellippeHeitor]

You are still stuck in the INPUT call until enter is pressed, the difference with the QB64 approach is that there is a buffer, which stores mouse data generated while the program was stuck in the INPUT call. After enter is pressed, you can keep reading the buffer, as in Terry's example, or flush it, as in my example, so that you always have the current mouse data, instead of buffer history. Both approaches have their advantages.

The example given shows an input, but somehow it's also checking the while:wend at the same time?

The while: wend block won't be checked again until INPUT is done with.

[Ophelius]

Ooh ok I see, there's a buffer. Makes sense now. Thanks