Where is my mistake using _mousemovement keywords?

[TempodiBasic]

Hi Qb64pe community

I'm in trouble with a fine couple of QB64 keywords:  _MousemovementX & _MousemovementY

I think that the issue is raising from my bad code or bad knowledge about these two useful keywords...

here the first example taken from the wiki
mousemovementX wiki
mousemovementY wiki

Code: (Select All)

Rem _MOUSEMOVEMENTX / _MOUSEMOVEMENTY  STUDY

Rem example 1 from wiki
Screen 12
PX = 320: PY = 240 'center position
_MouseMove PX, PY ' set center of screen, pointer of mouse and center of circle at the same position
Do: _Limit 200
    Do While _MouseInput
        PX = PX + _MouseMovementX
        PY = PY + _MouseMovementY
    Loop
    Cls
    Circle (PX, PY), 10, 10
    Locate 1, 1: Print PX, PY
Loop Until InKey$ = Chr$(27) 'escape key exit

as you can see my adds are:
- the 2 REM lines 
- and the _MouseMove PX,PY line of code.
The issue, that I am not able to correct, comes out if you play moving the pointer of mouse some times along the horizonthal and vertical axis of the screen.

Can someone give me a feedback or an enlightment about this?

[bplus]

It's exact copy of example what do you think should happen?

Does need _display to stop the bloody blinking

Oh it goes off screen, did you see the next sample in Wiki that fixed that?

Eh here is my fix:

Code: (Select All)

Screen 12
PX = 320: PY = 240 'center position
Do: _Limit 200
    Do While _MouseInput
        mmx = _MouseMovementX
        mmy = _MouseMovementY
        If (PX + mmx) >= 0 And (PX + mmx) <= _Width Then PX = PX + mmx
        If (PY + mmy) >= 0 And (PY + mmy) <= _Height Then PY = PY + mmy
    Loop
    Cls
    Circle (PX, PY), 10, 10
    Locate 1, 1: Print PX, PY
    _Display
Loop Until InKey$ = Chr$(27) 'escape key exit

[TempodiBasic]

Hi Bplus
fine to meet you and thank you for your answer.

I am sorry for my bad comunication:
the issue is that the mouse pointer is fixed on the center of the circle at the beginning of the program AND when we move more and more the mouse  its position becomes more and more distant from the center of the circle.

No issue about the circle that disappears behind the border of the window of the application.
(Yes I have seen the second example from the wiki page and it has given me no information about this strange (not related) movement of pointer of mouse in front of that of the circle).
I hope that my communication becomes more clear and you can give me a good solution.
Thank you

[bplus]

How bout this?

Calc:
MMX = mx-oldmx
MMY = my-oldmy

On every loop reset oldmx, oldmy to mx, my

[TerryRitchie]

I believe _MOUSEMOVEMENTX and _MOUSEMOVEMENTY are not working correctly at this time. I have code from QB64 V.945 I wrote that utilizes these two statements and it works fine. If I try to run the code on later versions of QB64 these two statements fail work properly any longer. I ran across this when I was working on my latest mouse library a few months back.

[DSMan195276]

I believe _MOUSEMOVEMENTX and _MOUSEMOVEMENTY are not working correctly at this time. I have code from QB64 V.945 I wrote that utilizes these two statements and it works fine. If I try to run the code on later versions of QB64 these two statements fail work properly any longer. I ran across this when I was working on my latest mouse library a few months back.

Pete had a very similar question about them a year ago, they're working correctly, they just don't do what is expected here. They return the mouse movement information as given to us by Windows before it processes that information to determine where the cursor should move. There's two reasons this is beneficial:

1. The information is more accurate, as it's not impacted by the cursor speed or acceleration settings.
2. The movement information is not constrained by the dimensions of the screen, you still receive accurate movement information regardless of cursor position.

The use-case is things like fullscreen games, where the cursor is hidden and the mouse is controlling something like camera position. You don't want the player to be unable to move the camera when the invisible cursor hits the side of the screen, and you also don't want the cursor settings to impact the game controls.

Because of the things I listed above, movement information does not directly correlate to how the cursor moves, so you can't use it for that purpose (`_MouseX` and `_MouseY` are for that). I also suspect that back in the SDL version of QB64 it didn't/couldn't get this accurate information so it just calculated it off of change in cursor position, which is why this used to work. I personally wouldn't consider this a bug though, and additionally it's been like this since the early days of the GL version.

[TerryRitchie]

I believe _MOUSEMOVEMENTX and _MOUSEMOVEMENTY are not working correctly at this time. I have code from QB64 V.945 I wrote that utilizes these two statements and it works fine. If I try to run the code on later versions of QB64 these two statements fail work properly any longer. I ran across this when I was working on my latest mouse library a few months back.

Pete had a very similar question about them a year ago, they're working correctly, they just don't do what is expected here. They return the mouse movement information as given to us by Windows before it processes that information to determine where the cursor should move. There's two reasons this is beneficial:

1. The information is more accurate, as it's not impacted by the cursor speed or acceleration settings.
2. The movement information is not constrained by the dimensions of the screen, you still receive accurate movement information regardless of cursor position.

The use-case is things like fullscreen games, where the cursor is hidden and the mouse is controlling something like camera position. You don't want the player to be unable to move the camera when the invisible cursor hits the side of the screen, and you also don't want the cursor settings to impact the game controls.

Because of the things I listed above, movement information does not directly correlate to how the cursor moves, so you can't use it for that purpose (`_MouseX` and `_MouseY` are for that). I also suspect that back in the SDL version of QB64 it didn't/couldn't get this accurate information so it just calculated it off of change in cursor position, which is why this used to work. I personally wouldn't consider this a bug though, and additionally it's been like this since the early days of the GL version.

Thank you for the clarification. Makes complete sense now.

[TempodiBasic]

I believe _MOUSEMOVEMENTX and _MOUSEMOVEMENTY are not working correctly at this time. I have code from QB64 V.945 I wrote that utilizes these two statements and it works fine. If I try to run the code on later versions of QB64 these two statements fail work properly any longer. I ran across this when I was working on my latest mouse library a few months back.

Pete had a very similar question about them a year ago, they're working correctly, they just don't do what is expected here. They return the mouse movement information as given to us by Windows before it processes that information to determine where the cursor should move. There's two reasons this is beneficial:

1. The information is more accurate, as it's not impacted by the cursor speed or acceleration settings.
2. The movement information is not constrained by the dimensions of the screen, you still receive accurate movement information regardless of cursor position.

The use-case is things like fullscreen games, where the cursor is hidden and the mouse is controlling something like camera position. You don't want the player to be unable to move the camera when the invisible cursor hits the side of the screen, and you also don't want the cursor settings to impact the game controls.

Because of the things I listed above, movement information does not directly correlate to how the cursor moves, so you can't use it for that purpose (`_MouseX` and `_MouseY` are for that). I also suspect that back in the SDL version of QB64 it didn't/couldn't get this accurate information so it just calculated it off of change in cursor position, which is why this used to work. I personally wouldn't consider this a bug though, and additionally it's been like this since the early days of the GL version.

These informations are very interesting, the mousemovement (as a difference between the old and the actual position of mouse) for detecting the direction towards  mouse has been moved so it generates a specific action in a fullscreen application/game.

Moreover I must remember that results of _mousemovementX/Y have been taken from a mouseinput queque to the OS and there we find for default the relative movement along X and Y axises, but setting the flag to ABSOLUTE (0x8000) we take back the absolute X and Y on the Screen of Pc and not on the area of the application tha has focus.
References:
 MouseInput API 32
Mouse event API 32

So I agree strongly that  _mousemovementX/Y  give back the relative movement on X and Y axis, but I (peharps wrongly) expetc that on a cartesian plane if oldX = 1 and ActualX = 10 the function mousemovementX must return +9 and so if I calculate OldX + MovementX I must get the same value of the  ActualX and moreover _MouseX must return the same result because that is its job in the area of application that has the focus.
But it is an issue of OS mouse managing, not an issue of  QB64 mouse managing, so we must only accept this thing and it does not change for our desire.

[TempodiBasic]

here a combo use of _mousemovementX/Y and _mouseX/Y to get an unproject goal: detecting when mouse leaves the window of the application that is running.

detecting mouse leaving window's area.