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.
Andreas Falkenhahn
SDL_RenderReadPixels() doesn't seem to work when trying to read pixels from a texture that has been created using SDL_TEXTUREACCESS_TARGET and has been selected as the render target using SDL_SetRenderTarget().
I am attaching a small program that demonstrates the issue. I get the following result here:
READ PIXEL RETURN: 0 --- COLOR CHECK: ff000000
But it should be:
READ PIXEL RETURN: 0 --- COLOR CHECK: ffff0000
Tested with SDL 2.0.3 on Windows 7.
Nitz
In SDL_CreateTextureFromSurface:
SDL_PixelFormat *dst_fmt;
/* Set up a destination surface for the texture update */
dst_fmt = SDL_AllocFormat(format);
temp = SDL_ConvertSurface(surface, dst_fmt, 0);
Here is need of NULL check for dst_fmt because there are chances of NULL return from SDL_AllocFormat(format);
Tobias Himmer
this patch adds a check to the CMake build script to detect whether the VideoCore API is available.
If it is found, it enables SDL_VIDEO_DRIVER_RPI and will also add the needed include/library directory flags to CMAKE_C_FLAGS so the subsequent check for GLES succeeds in picking up the headers.
Seems to work fine on Raspbian.
Patch from Benoit Pierre:
video: fix clipping handling in SDL_UpperBlitScaled
- honor destination clipping rectangle
- update both destination and source rectangles when clipping source
rectangle to source surface and destination rectangle to destination
clip rectangle
- don't change scaling factors when clipping
N.B.:
- when no scaling is involved (source and destination width/height are
the same), SDL_UpperBlit is used (so SDL_BlitScaled behaves like
SDL_BlitSurface)
- the final destination rectangle after all clipping is performed is
saved back to dstrect (like for SDL_UpperBlit)
There was a misconception that Linux's saturation and deadband parameters -
on which the corresponding SDL parameters were based - use only half of the
possible range.
Thanks, Elias!
Partially fixes Bugzilla #2686.
The _xgetbv intrinsic was being used in ARM builds of SDL/WinRT, which was
leading to linker errors. This commit limits _xgetbv use to the platforms on
which it is available, x86 and x64.
Sam Lantinga
Ryan C. Gordon
Philipp Wiesemann
David Ludwig
Alex Szpakowski
Alfred Reynolds