Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Where is my mistake using _mousemovement keywords?
#8
(09-26-2023, 07:40 PM)DSMan195276 Wrote:
(09-18-2023, 04:12 AM)TerryRitchie Wrote: 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.
Reply


Messages In This Thread
RE: Where is my mistake using _mousemovement keywords? - by TempodiBasic - 09-26-2023, 09:50 PM



Users browsing this thread: 6 Guest(s)