09-26-2023, 08:40 PM
(09-26-2023, 07:40 PM)DSMan195276 Wrote:Thank you for the clarification. Makes complete sense now.(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.