_MOUSEWHEEL reset

[Clippy]

I have noticed a slight delay when scrolling and I figured out why. The return value clearing is done in every other _MOUSEINPUT read. This makes every other read do nothing. So I added another _MOUSEINPUT after the read to zero it out right away.

Code: [Select]

DO: _LIMIT 10
  i = _MOUSEINPUT
  Scroll = _MOUSEWHEEL
  PRINT Scroll
  i = _MOUSEINPUT '<<<<<< comment out to see the difference
LOOP UNTIL INKEY$ = CHR$(13) ' press Enter to quit

When commented out it reads 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

With two mouse inputs it reads 1 1 1 1 1 1 1 0 0 0 -1 -1 -1 -1

Could QB64 find a way to clear the value otherwise? Perhaps clear it immediately after _MOUSEWHEEL is read. The delays are noticeable!

[SMcNeill]

Why are you using a _LIMIT 100 and DELAY .1 both?  Are you certain it's not something the double pause is causing?

[Galleon]

The value of _MOUSEINPUT is relative (because it is a wheel) therefore it must be set back to 0 or it would imply the wheel is still being turned.

Your solution is a poor one because it means you are handling input in two areas. It's a bit like this code:

Code: [Select]

DO
a$=inkey$
if a$="1" then print "1"
b$=inkey$
if b$="2" then print "2"
LOOP
The solution to your problem is to process mouse input in a loop without a limit or delay.

[Clippy]

Yeah, but for every mouse input read you only get HALF of the wheel values at the same time. The wheel must be read TWICE as many times as the input and MUST LAG!

No, I don't usually put delays in a mouse read loop or use _MOUSEINPUT TWICE and that WOULD cause you to miss OTHER READS! It just ILLUSTRATES what is happening internally!
TWICE the reads is a BUILT IN DELAY!

As for the _LIMIT, that was ALREADY IN Galleon's code! WHY WOULDN'T you use _LIMIT?

I don't see a need to read a value just to RESET it! OF COURSE THE CODE IS STUPID! But so is the internal code. Reset it any way you want, but give us just the clicks. We don't need to VERIFY that the relative value was zeroed out!

Where else COULD you reset the value except after a read? That's the problem! You can't reset it after each _MOUSEINPUT...  Right now that is what you are doing HALF the time!

THERE IS NO DELAY IN MY CODE EXCEPT FOR THE _DELAY SO TAKE IT OUT and THEN compare the two silly! It WILL be harder to see!

Code: [Select]

DO: _LIMIT 10 '<<<<<<<<<< increase if you must
  i = _MOUSEINPUT
  Scroll = _MOUSEWHEEL
  PRINT Scroll
  i = _MOUSEINPUT '<<<<<< comment out to see the difference in lag
LOOP UNTIL INKEY$ = CHR$(13) ' press Enter to quit

Comment out the second _MOUSEINPUT and see HOW LONG it LAGS BEHIND USER INPUT!

Presently we can read TWICE the X and Y coordinate values in the same routine.

It would seem to be relatively SIMPLE to clear the value AFTER it is read INTERNALLY! SUBs and FUNCTIONs do it automatically...    I see little reason for somebody to want to read it and get the same results twice in a loop.

[Clippy]

_WHEEL does it too

Code: [Select]

n = _DEVICES
DO: _LIMIT 10 '<<<<<<<<<< increase if you must
  w = wheel(2)
  PRINT w
LOOP UNTIL INKEY$ = CHR$(13) ' press Enter to quit


FUNCTION wheel (dev)
IF _DEVICEINPUT(dev) THEN 'mouse is normally #2 device
  Scroll = _WHEEL(3) 'mouse scroll only
  PRINT Scroll
  i = _DEVICEINPUT(dev) '<<<<<< comment out to see the difference in lag
  wheel = Scroll
END IF
END FUNCTION


[Galleon]

As for the _LIMIT, that was ALREADY IN Galleon's code! WHY WOULDN'T you use _LIMIT?

Sigh
That's why you need a second DO LOOP without _DELAY/_LIMIT inside your primary one just to process mouse-input.

[Clippy]

Sure, but scrolling has to catch up twice as long and you lose stuff in a closed loop while everything catches up. That's when you miss button clicks etc. That's when I use consecutive reads.

If you want to catch up, use this:

Code: [Select]

SUB Catchup
DO WHILE _MOUSEINPUT: LOOP
END SUB 

The fact is that having to loop twice as long to catch up scroll input makes it that much more likely that button presses and releases will be lost in that loop. Otherwise you have to read and deal with everything INSIDE of that loop. Then your program becomes Loop City. 

When everything is inside a read loop, things get slowed down too...

[Clippy]

Button reads are done one loop at a time. When 2 keys are pressed, they come up in sequential loops following the "Keyboard" PRINT every time. This tells me that button status and values are only found for one key in the loop at a time.

Code: [Select]

FOR i = 1 TO _DEVICES 'DEVICES MUST be read first!
  PRINT STR$(i) + ") " + _DEVICE$(i) + " Buttons:"; _LASTBUTTON(i); ",Axis:"; _LASTAXIS(i); ",Wheel:"; _LASTWHEEL(i)
NEXT
IF K$ = "Y" THEN dummy = _MOUSEMOVEMENTX 'enable relative mouse movement reads
PRINT

DO
  x& = _DEVICEINPUT 'determines which device is currently being used
  IF x& = 1 THEN
    PRINT "Keyboard: ";
    FOR b = 1 TO _LASTBUTTON(x&)
      bb = _BUTTONCHANGE(b)
      IF bb THEN PRINT b; bb; _BUTTON(b);
      bb = _BUTTONCHANGE(b)  ' <<<<<<<<< repeats same values so nothing is cleared
      IF bb THEN PRINT b; bb; _BUTTON(b);
    NEXT
    PRINT
  END IF
LOOP UNTIL INKEY$ = CHR$(27) 'escape key exit

I can read multiple key presses using one INP loop. I might as well add EXIT FOR after I find a value...

I found that 512 keys aren't read (of course). Key positions range from 140 to 450:

http://qb64.net/wiki/index.php?title=Controller_Devices#.5BKEYBOARD.5D

My laptop does not have all of the keys...I wonder how this would change on other keyboards. The key number order is quite obtuse.

I realize that a lot of these things may be built into the Library functions used by QB64. However, I think it would be advantageous to see if we could make them more efficient while everything is being updated. 

We should never have to use STRIG and STICK again...