premake/README-windows.txt
author Sam Lantinga <slouken@libsdl.org>
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.
icculus@7925
     1
Use the Visual Studio batch files (located in the VisualC folder) to
icculus@7925
     2
conveniently generate solutions for Visual Studio 2008, 2010, and 2012.
icculus@7925
     3
It also contains a cleaner script and a convenient script for automatically
icculus@7925
     4
running all the test suites.
icculus@7925
     5
icculus@7925
     6
There is a script (check.bin.compatibility.vs2010.bat) in VisualC\build-scripts
icculus@7925
     7
which will build <sdl_root>\VisualC (which is not generated by this premake
icculus@7925
     8
system) and build SDL2.dll using the generated SDL2.sln in the VS2010 folder. It
icculus@7925
     9
will copy the SDL2.dll over to each test project in <sdl_root>\VisualC and
icculus@7925
    10
subsequently run those tests to verify binary compatibility between the SDL2.dll
icculus@7925
    11
that came from the premake solution and the executables which were built using
icculus@7925
    12
the old solution files.
icculus@7925
    13
icculus@7925
    14
The windows project currently depends on most of the libraries inherently
icculus@7925
    15
added to the links list by Visual Studio. The additional libraries SDL2 depends
icculus@7925
    16
on are as follows:
icculus@7925
    17
icculus@7925
    18
  -imm32
icculus@7925
    19
  -oleaut32
icculus@7925
    20
  -winmm
icculus@7925
    21
  -version
icculus@7925
    22
  -OpenGL32
icculus@7925
    23
  -DirectX
icculus@7925
    24
icculus@7925
    25
OpenGL32 is an optional dependency. If it is not located for whatever reason,
icculus@7925
    26
SDL2 will build fine without it. DirectX is another optional dependency for
icculus@7925
    27
SDL2. Unlike the manually-created VS projects, the meta-build system supports
icculus@7925
    28
not having DirectX support and still being able to build and run through most of
icculus@7925
    29
the projects (using the OpenGL renderer or the software renderer).
icculus@7925
    30
icculus@7925
    31
Run the clean script to clear out the directory of VS-related files and
icculus@7925
    32
binaries.
icculus@7925
    33
icculus@7925
    34
Ben:
icculus@7925
    35
Please note that the script for building the VS2012 solution from the
icculus@7925
    36
command prompt seems to not be working properly. This issue is
icculus@7925
    37
currently unresolved.