Bad Mouse Coordinates on Mac OS X

Input
1

Hi, I used to do XNA development many years ago and I did a little bit with MonoGame about 2 years ago as well all on a Windows platform.

Recently, I got my first MacBook Pro and I decided to try getting my most recent project running again, with the interest of expanding on it. After fixing all of the obvious compilation issues and finally being able to run the game, I noticed right away that something was off. My mouse wasn’t interacting with my menu buttons because the Mouse class wasn’t returning the proper coordinates when I did a Mouse.GetState().Position (or .X or .Y).

After playing around with it for a while and Googling with no results, here is the information I can provide about the predicament:

  • Coordinates returned by Mouse.GetState() are HALF of what they should be to be consistent with where things are drawn in the game. For example: when I expect the mouse to be at x=20, y=20, Mouse.GetState() will tell me it is at x=10, y=10.
  • Calling Mouse.SetPosition(x, y); behaves as expected, placing the mouse where it is expected to be placed. This is really boggling to me, although, I don’t know how the underlying structure handles these calls…
  • I have never faced this issue in my experience with MonoGame on Windows, XNA, or game development in general.

Does anybody have a clue what is going on here? I believe this is strictly a Mac OS X issue and may not even be related to MonoGame at all, but instead it may have to do with my display settings or something… Just to give a little more info, I’m developing using Xamarin Studio Community with the MonoGame Add-in.

Any help appreciated, thanks.

2

I also don’t get the right mouse position, but on windows dx. The mouse position is slightly off in the y-direction. The Position returned by getState is a little bit above the real mouse cursor position. The error scales with the distance of the cursor from the top of the window. So at the bottom the difference between real cursor Position and mouse getState being greater.

3

Yeah, when you ask for the mouse pos, you get the >screen< coordinates…
So if you are running in a window, you need to take this into account…

You can get the mouse >changes< instead, and update a cursor-sprite with these changes each frame… Like you would do for the paddle in a pong game.

That way, you can keep the mouse within window bounds, and have much more control with everything… When the game is paused, and the mouse logic stops running, users get their normal mouse back…

4

If it’s exactly half it could be a dpi issue because of the retina display. I think there are some open issues in the MG GitHub repo on retina displays.

5

Thanks for the tip!

Following this issue I figured if I installed the latest dev build, version 3.6, then the problem might be solved, and sure enough it was.

1 Like