MOUSEAXIS(0,1,2) fails after frame rate exceeds LIMITFPS
im using windows 7 and GLBasic IDE, Version: 14 & 15
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?
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?
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 :/
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
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.
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
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
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.
I found a solution!
This workaround snaps the mouse back to life.
Use these commands called in this order:
SLEEP 1.0
MOUSEAXIS
MOUSESTATE
i think this is a bug for sure, maybe this can be fixed?
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.
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).
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.
Quote from: Snoopy on 2019-Feb-21
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
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
Maybe, but seeing a SLEEP in a main loop bothers me a lot ;)
Instead of SLEEP
Using a timer variable that uses gettimerall() millseconds value to allow you to skip mousechecking on every loop.
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 :good:
Quote from: MrPlow on 2019-Feb-21
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
Do you have an example of your problem, Hemlos ?
Not your main code, just an example that sums up the problem you have in your pricinpale program.
Your problem intrigues me ;)
imagine flying around space in a space ship and your only control, the mouse, stops responding as you are flying into an asteroid field.
asteroid dinner my friend
:D Indeed, it's a very big problem for the player
Your problem interests me because I'm also developing a 3D project and have a similar problem, but not exactly the same as you.
But it's an FPS and not a spaceship simulation, that's probably the reason for the difference.
Glad you're found a solution and good luck on your project, Hemlos :good:
Quote from: Snoopy on 2019-Feb-25
:D Indeed, it's a very big problem for the player
Indeed it is....players will uninstall (i would) :giveup:
Quote
Glad you're found a solution and good luck on your project, Hemlos :good:
The solution is more like a workaround.
I did notice some more glitching after testing this workaround for several hours.
The failure still exists, just... not as bad though.
Too bad :(
With my solution, I totally solved my problem, even if yours is not quite the same, try anyway because I don't think it's a GLB bug, I think is one of the reasons why there is always an option in a 3D game to control the sensitivity of the mouse ;)
Quote from: Snoopy on 2019-Mar-01
Too bad :(
With my solution, I totally solved my problem, even if yours is not quite the same, try anyway because I don't think it's a GLB bug, I think is one of the reasons why there is always an option in a 3D game to control the sensitivity of the mouse ;)
How do you control a failure in output?
Im willing to try anything, but im pretty sure its a bug in glb, it has something to do with the internal timers somehow.
_______________________________________
*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.14.721 SN:a3f75373 - 3D, NET
Wordcount:3007 commands
compiling:
linking:
success
_______________________________________
*** Finished ***
Elapsed: 16.1 sec. Time: 19:37
Build: 1 succeeded.
Start debug session.
DECLARE entry not found: GetPointerTouchInfo
DECLARE entry not found: EnableMouseInPointer
_______________________________________
Injection started
I just noticed this in v15 debug mode output during compile.
Figgured it out..
MOUSEAXIS outputs are realtime, and you have to try and capture the output all through your program.
Even at the end of all nested loops.
What i mean is, MOUSEAXIS value can and does change several times between showscreen calls.
so i used this setup to capture the mouse output many times in the program loops:
function detectmouse
mX = MOUSEAXIS
self.CaptureX = mX
and then at the end of the main loop, just before the showscreen update the delta api mouse
function update_mouse
deltamouseX = CaptureX
delta stuff
CaptureX = 0 // RESET (showscreen should be next)
endfunction
ensure to reset the value so you can start capturing again, after the showscreen