author Sam Lantinga <>
Sun, 17 Aug 2014 14:57:52 -0700
changeset 9086 c5e33f9a0d03
parent 7925 f090a47eb7f7
permissions -rwxr-xr-x
Fixed bug 2655 - OSX: Window position and global mouse coord spaces are different

Tim McDaniel

On OSX, with revision 8729, the coordinate space for window position and the coordinate space for global mouse position don't match. For a non-fullscreen window, the window position is global relative to the bottom of the menubar. The global mouse position is relative to the top of the screen. This affects Cocoa_WarpMouse and potentially other things as well. Further, the coordinate system for window position is now affected by what screen it is on. For example, if I have two equal size screens oriented side by side such that the tops of the screens are equal in global space, with the menubar on one screen, and a window straddles the two screens, the window's y position makes no sense. The window's y position depends on what screen "most" of the window is on. So if I move the window horizontally just a bit, the y position of my window is now different by the size of the menubar, even though the window was not moved vertically.

I'd like to reiterate that this was a fairly fundamental change (and a breaking change for us). If SDL OSX is to really support multi-display configurations, this is especially problematic.

If the real concern is preventing windows from going under the menubar, then perhaps a solution involving something like overriding [NSWindow constrainFrameRect] would be less problematic than redefining the global window coord space for the main display.
     1 Use the Visual Studio batch files (located in the VisualC folder) to
     2 conveniently generate solutions for Visual Studio 2008, 2010, and 2012.
     3 It also contains a cleaner script and a convenient script for automatically
     4 running all the test suites.
     6 There is a script (check.bin.compatibility.vs2010.bat) in VisualC\build-scripts
     7 which will build <sdl_root>\VisualC (which is not generated by this premake
     8 system) and build SDL2.dll using the generated SDL2.sln in the VS2010 folder. It
     9 will copy the SDL2.dll over to each test project in <sdl_root>\VisualC and
    10 subsequently run those tests to verify binary compatibility between the SDL2.dll
    11 that came from the premake solution and the executables which were built using
    12 the old solution files.
    14 The windows project currently depends on most of the libraries inherently
    15 added to the links list by Visual Studio. The additional libraries SDL2 depends
    16 on are as follows:
    18   -imm32
    19   -oleaut32
    20   -winmm
    21   -version
    22   -OpenGL32
    23   -DirectX
    25 OpenGL32 is an optional dependency. If it is not located for whatever reason,
    26 SDL2 will build fine without it. DirectX is another optional dependency for
    27 SDL2. Unlike the manually-created VS projects, the meta-build system supports
    28 not having DirectX support and still being able to build and run through most of
    29 the projects (using the OpenGL renderer or the software renderer).
    31 Run the clean script to clear out the directory of VS-related files and
    32 binaries.
    34 Ben:
    35 Please note that the script for building the VS2012 solution from the
    36 command prompt seems to not be working properly. This issue is
    37 currently unresolved.