MOUSEAXIS fails

[Hemlos]

MOUSEAXIS(0,1,2) fails after frame rate exceeds LIMITFPS
im using windows 7 and GLBasic IDE, Version: 14 & 15

[dreamerman]

I know that v14 has some strengths in compiling for mobiles but is there any special reason to use v14 on pc? Does it appear also in v15/v16?
Do You have any portion of test code to verify this issue on other setups?

[dreamerman]

GLBasic version 15 is available on main site in download section, it states thats v14 but it's installer for v15, v16 currently is available only on Steam.
v15: http://www.glbasic.com/files/glbasic_sdk.exe
Basic tutorial code like this is enough to see the issue?

Code: (glbasic) [Select]

WHILE TRUE
   PRINT "X:" + MOUSEAXIS(0), 0,  0
   PRINT "Y:" + MOUSEAXIS(1), 0, 20
   PRINT "Z:" + MOUSEAXIS(2), 0, 40
   PRINT "A:" + MOUSEAXIS(3), 0, 60
   PRINT "B:" + MOUSEAXIS(4), 0, 80
   PRINT "C:" + MOUSEAXIS(5), 0,100
   SHOWSCREEN
WEND
didn't have time to check this :/

[Hemlos]

that might do the trick, i already see a problem with the output.
when you move and stop the mouse and continue to move again(same direction)....zero
thats bad, because it supposed to be velocity, not screen position.
ps. it might take a few hours to really see the mouse stop working
pps. the installer on this site might be for v15, however it installed:  GLBasic IDE, Version: 14.497

[dreamerman]

I noticed that issue, it's more visible when running in windowed mode. Looks like mouse cursor isn't grabber properly and when you move it to the edge of screen (it's visible as other windows/system ui are hovered) the velocity is 0, even if you still move mouse in that direction. Maybe some trick with SetMouse would fix this, checked on v14 & v15, same result.

If You didn't uninstall v14, then both versions will sit in same 'Start' submenu, or only v14 will be available there (yet both versions have separate entries in installed programs list). You need to find proper GLBasic_v15 directory in Your 'Program Files' and make new shortcut for editor. Same 'issue' here as I've 3 different versions of GLB installed currently, but this isn't a real problem.

[Hemlos]

failure only seems to happen when the program hits the limit of fps.
its as if the mouse isnt limited to LIMITFPS, and only responding slow.
limitfps -1 doesnt help

these definetly stop working completely, its driving me loopy
mouse x
mouse y
mousewheel

[Hemlos]

after alot of testing, it seems , mouseaxes x and y are fixed in v15
yet, the mousewheel is still having a glitchyness
This is happening only when the frame rate starts low and works its way up to LIMITFPS
It seems like mouseaxis is not catching all movement between frames after that.
At that point of reaching the limit, it is when the command is failing.
ill try v16 sometime soon

[dreamerman]

hm.. according to help file the result of MouseAxis is Integer, but MouseState returns floats, interesting..
Mostly I'm using MouseState in my projects so didn't encounter any issues with that, if I remember correctly, only in one project mouse wheel is needed - for zooming, but with short test I didn't noticed any problems either, will need to take a look into it later.
btw. leaved pc for 15 minutes with that basic tutorial code, buttons and wheel response are ok, only that issue with mouse x&y velocity - it's zeroed when cursor hits screen bounds - when windowed.

[Hemlos]

I found a solution!
This workaround snaps the mouse back to life.

Use these commands called in this order:

Code: (glbasic) [Select]

SLEEP 1.0
MOUSEAXIS
MOUSESTATE
i think this is a bug for sure, maybe this can be fixed?

[SnooPI]

I already noticed this bug but I think that using a SLEEP in a main loop is not good.
Try not to multiply the speed of the mouse_velocity by a delta time but with a mouse_speed variable that the player of your game will be able to modify in the options.

Code: (glbasic) [Select]

delta_time = GETTIMER()
// mouse_x_velocity = mouse_x_velocity * delta_time
// mouse_y_velocity = mouse_y_velocity * delta_time
mouse_x_velocity = mouse_x_velocity * mouse_speed  // A variable between 0.0 --- 1.0 ----> 2.0 (or more) it's the player who will choose.
mouse_y_velocity = mouse_y_velocity * mouse_speed

And use this code in your main loop instead of MOUSEAXIS to get the velocity (and if everything works well, you'll be able to test with MOUSEAXIS).
   

Code: (glbasic) [Select]

MOUSESTATE mouse_x, mouse_y, mouse_b1, mouse_b2

// Your rendering ....

SETMOUSE screen_x_center, screen_y_center
mouse_x_velocity = mouse_x - screen_x_center
mouse_y_velocity = mouse_y - screen_y_center

I hope it will help you.

[Hemlos]

Try not to multiply the speed of the mouse_velocity by a delta time but with a mouse_speed variable that the player of your game will be able to modify in the options.

without sleep its breaking the raw output. sleep 1 does the trick.
furthermore, with sleep 1, you can use a delta time no prob

Code: (glbasic) [Select]

                sleep 1
self.M2X% = MOUSEAXIS(0) // raw x
self.M2Y% = MOUSEAXIS(1) // raw y
self.M2W% = MOUSEAXIS(2) // wheel +/- raw
self.M2B1% = MOUSEAXIS(3) // button 1 raw
self.M2B2% = MOUSEAXIS(4) // button 2 raw
self.M2B3% = MOUSEAXIS(5) // button 3 raw
MOUSESTATE self.M1X, self.M1Y, self.M1B1, self.M1B2 // this is for 2d mouse position & button clicks


[SnooPI]

Maybe, but seeing a SLEEP in a main loop bothers me a lot 

[MrPlow]

Instead of SLEEP

Using a timer variable that uses gettimerall() millseconds value to allow you to skip mousechecking on every loop.

[SnooPI]

When I reread Hemlos' comments, I thought it was a similar problem, but in fact it was not quite like mine (for me, it was with MOUSESTATE and only when there had a loss of FPS for a long time).
Moreover, I think my problem is not a GLB bug.

For the problem of Hemlos, you have probably the best solution MrPlow

[Hemlos]

Instead of SLEEP

Using a timer variable that uses gettimerall() millseconds value to allow you to skip mousechecking on every loop.

i use timers for all kinds of stuff
only sleep does the fix