GLBasic forum

Main forum => Bug Reports => Topic started by: Hemlos on 2019-Feb-04

Title: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-04
MOUSEAXIS(0,1,2) fails after frame rate exceeds LIMITFPS
im using windows 7 and GLBasic IDE, Version: 14 & 15



Title: Re: MOUSEAXIS fails
Post by: dreamerman on 2019-Feb-04
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?
Title: Re: MOUSEAXIS fails
Post by: dreamerman on 2019-Feb-05
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 :/
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-06
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
Title: Re: MOUSEAXIS fails
Post by: dreamerman on 2019-Feb-06
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.

Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-09
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
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-10
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
Title: Re: MOUSEAXIS fails
Post by: dreamerman on 2019-Feb-10
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.
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-11
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?
Title: Re: MOUSEAXIS fails
Post by: SnooPI on 2019-Feb-21
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.
Title: Re: MOUSEAXIS fails
Post by: Hemlos 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
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
Title: Re: MOUSEAXIS fails
Post by: SnooPI on 2019-Feb-21
Maybe, but seeing a SLEEP in a main loop bothers me a lot  ;)
Title: Re: MOUSEAXIS fails
Post by: 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.
Title: Re: MOUSEAXIS fails
Post by: SnooPI on 2019-Feb-21
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:
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-22
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
Title: Re: MOUSEAXIS fails
Post by: SnooPI on 2019-Feb-23
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 ;)
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-23
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
Title: Re: MOUSEAXIS fails
Post by: SnooPI on 2019-Feb-25
  :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:
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Feb-28
  :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.
Title: Re: MOUSEAXIS fails
Post by: SnooPI 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  ;)
Title: Re: MOUSEAXIS fails
Post by: Hemlos 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.
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Mar-01
Code: (glbasic) [Select]
_______________________________________
*** 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.
Title: Re: MOUSEAXIS fails
Post by: Hemlos on 2019-Mar-09
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