This makes it possible to move windows by their title bar, even if they're in
relative mode, if you click the title bar when the window does not have focus.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2396
Previously we were postponing our -[NSOpenGLContext update] call to the next
SDL_GL_SwapWindow, even if the context was current on the current thread. This
changes it so that we will do the update immediately if it's the current
context.
If you're rendering on another thread, you need to call SDL_GL_SwapWindow once
after a resize event to ensure your drawable will produce non-garbage data.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2339
If the window has been created with values for SDL_GL_CONTEXT_PROFILE_MASK,
SDL_GL_CONTEXT_MAJOR_VERSION and SDL_GL_CONTEXT_MINOR_VERSION not matching those
required by the renderer, attempt to recreate the window.
This is needed on platforms where both GL and GLES 1/2 surfaces are supported
by the video backend, requiring that the window be recreated when switching
between context types.
Pressing the hardware back button on a Windows Phone 8 device will now cause SDL to emit a pair of key-down and key-up events, with the SDL scancode, SDL_SCANCODE_AC_BACK.
By default, if WinRT's native back-button-press events are not explicitly marked as 'handled', then Windows Phone will terminate the app. More details on Microsoft's reasoning behind this can be found on MSDN, at http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj247550(v=vs.105).aspx
To mark back-button-press events as 'handled', set SDL_HINT_WINRT_HANDLE_BACK_BUTTON to 1. Setting it to anything else will cause these events to not be marked as 'handled'.
Due to limitations in Windows Phone's APIs, SDL will emit a virtual key-up event immediately after the back button's key-down event is registered. Unfortunately, Windows Phone 8 only allows one to register for back-button-press events, and not back-button-release events.
This change is only relevant for Windows 8, 8.1, and RT apps, and only for those that are network-enabled. Such apps must feature a link to a privacy policy, which must be displayed via the Windows Settings charm. This is needed to pass Windows Store app-certification.
Using SDL_SetHint, along with SDL_HINT_WINRT_PRIVACY_POLICY_URL and optionally SDL_HINT_WINRT_PRIVACY_POLICY_LABEL, will cause SDL/WinRT to create a link inside the Windows Settings charm, as invoked from within an SDL-based app.
Network-enabled Windows Phone apps do not need to set this hint, and should provide some sort of in-app means to display their privacy policy. Microsoft does not appear to provide an OS-integrated means for displaying such on Windows Phone.
The destination target's alpha wasn't getting set correctly in many cases. Among other problems, this prevented some alpha-blended textures from displaying correctly in Windows Phone 8's multitasking screen.
The d3d11 renderer now uses the same blending settings found in the d3d9 renderer.
The projection and view matrices are now computed ahead of time, as they both get computed in the same spot, and typically not often. If this does, however, become a performance problem later on, this change can always be reverted.
Previously, the shaders would get compiled separately, the output of which would need to be packaged into the app. This change should make SDL's dll be the only binary needed to include SDL in a WinRT app.
Due to the new "tap and hold" IME in Mountain Lion and above, we were getting
inconsistent repeat of SDL_TEXTINPUT events. Disabling that functionality (since
you can't see the popover anyway) solves this.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2387
The DualShock 4 has all elements listed twice: once in the top-level list of
elements, and once in an "Application Collection" element at the top-level.
Each element has a proper cookie with a unique value, so now we descend into
each element collections, but before we add an element to the device's list,
we make sure we don't already have one with that cookie, probably from
another collection or a buggy device.
Tiemo Jung
All CPU detection functions SDL_Has* will return false, even if it is supported by the CPU, if SDL is compiled with MSVC and the target is x64.
The reason for this is that 'CPU_haveCPUID' will return 0 and macro 'cpuid' in SDL_cpuinfo.c is the fallback implementation, which sets all params to zero.
It is safe to assume that cpuid is supported on a CPU that runs windows x64, so CPU_haveCPUID can just return 1, and the empty macro can be replaced with a small wrap around the __cpuid intrinsic.
Felix Geyer
Starting from version 2.0.1 libsdl fails to build on Debian GNU/kFreeBSD in SDL_cpuinfo.c.
GNU/kFreeBSD defines __FreeBSD_kernel__ but not __FreeBSD__.
The #ifdef __FreeBSD__ check should be extended for __FreeBSD_kernel__, see the attached patch.
Build log:
libtool: compile: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -DUSING_GENERATED_CONFIG_H -Iinclude -I/?BUILDDIR?/libsdl2-2.0.1+dfsg1/include -mmmx -m3dnow -msse -msse2 -fvisibility=hidden -D_REENTRANT -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-kfreebsd-gnu/dbus-1.0/include -DHAVE_USBHID_H -DUSBHID_NEW -D_REENTRANT -Wall -c /?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c -fPIC -DPIC -o build/.libs/SDL_cpuinfo.o
/?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c: In function 'SDL_GetSystemRAM':
/?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c:632:35: error: 'HW_MEMSIZE' undeclared (first use in this function)
int mib[2] = {CTL_HW, HW_MEMSIZE};
^
/?BUILDDIR?/libsdl2-2.0.1+dfsg1/src/cpuinfo/SDL_cpuinfo.c:632:35: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [build/SDL_cpuinfo.lo] Error 1
Tim McDaniel
On OSX, an SDL app forces a system shutdown to be cancelled. This happens because [SDLAppDelegate applicationShouldTerminate] returns NSTerminateCancel. A better approach is to subclass NSApplication and override terminate to do nothing except call SDL_SendQuit. In response to a system shutdown notification, this allows the normal SDL Quit event processing to occur, and if the app then terminates, system shutdown occurs normally. Please see the attached patch, based on SDL 2.0.1.
Tim McDaniel
On OSX, the app name in the menu bar is not localized. This can be fixed using the following implementation for GetApplicationName in SDL_cocoaevents.m:
static NSString *
GetApplicationName(void)
{
NSDictionary *dict;
NSString *appName = 0;
appName = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleDisplayName"];
if (!appName)
appName = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleName"];
if (![appName length])
appName = [[NSProcessInfo processInfo] processName];
return appName;
}
- Use the SDL_AUDIO_MASK_DATATYPE bit when selecting an implementation
where it matters. Previously two existing AUDIO_F32 cases had been
written, but were unreachable.
- Add AUDIO_F32 case for SDL_ConvertSurround_4.
- Fix incorrect pointer arithmetic causing the 2 to 6 channel
conversion for 4 byte audio formats to read and write beyond the end
of the buffer.
Leonardo
Event watchers are being executed on the inverse order they are added because they are added to the head of the SDL_event_watchers list.
Since watchers are allowed to change events before they are reported (they shouldn't, imo), this breaks code that rely on watcher execution order (such as distributed event handling).
An easy scenario to see this behaving weird to the user is if you add an event watcher to check mouse coordinates and check them again in your event loop. If you add the watcher after renderer's one (which always happens after you have initialized renderer), you get the same event but different coordinates.
The proposed patch adds the event watcher in the tail of the list, not in the beginning, and correctly fixes this problem.
Alex Szpakowski
Currently the UIKit/EAGL backend for SDL's OpenGL context creation API doesn't support OpenGL ES 3, despite iOS 7+ being capable (on devices with the necessary hardware.)
I have attached a patch to add support. It's also slightly more future-proof, so eventual OpenGL ES 4+ capability on iOS should hopefully work without requiring changes to SDL's UIKit/EAGL backend.
Alex Szpakowski
On my Mac OS X system (10.9.1), the SDL_MOUSEWHEEL event reports negative X values when my trackpad scrolls to the right, and positive X values when my trackpad scrolls to the left. This is backwards from what I'd expect, and I don't think it matches the Windows wheel events.
The vertical scroll values are what I'd expect though, and are consistent what gets reported on Windows (positive Y for scrolling up, negative Y for scrolling down.)
This is with "scroll direction: natural" disabled in the OS X trackpad settings (i.e. my scroll direction in non-SDL OS X programs matches what happens in Windows and Linux.)
I also tested with the horizontal scroll on a real mouse (Logitech G500 without custom drivers), and the horizontal scroll values in SDL are still flipped.
I "solved" the issue for myself by changing this line in the Cocoa_HandleMouseWheel function:
float x = [event deltaX];
to this:
float x = -[event deltaX];
I believe it should work fine with that change - I found something similar in another codebase while looking online for my issue - but I haven't tested on anything below Mac OS 10.8.
Besides being a little more simple to use than the earlier IOKit HID API, and
less likely to be deprecated, it also has the added benefit of working with
the Sony DualShock 4 controller in Bluetooth mode out of the box, whereas
the previous API has a bug that makes it report bad data for the
controller.
Cleaned up several other things in this code, having gone over every line of
it. The remaining deprecated calls are also gone.
Testing:
* Set the SDL_HINT_MOUSE_RELATIVE_MODE_WARP hint true, run testsprite2, press Ctrl-R to enter relative mode, alt tab away from the window, then click on the title bar of the window. Didn't get the mouse button release before, and we do now.
CR: Yahn + Alfred
Sandu Liviu Catalin
I'm unable to compile the latest SDL (directly from the repository) even though I disabled every DirectX option since I don't need DirectX.
I allways het these errors:
D:\DevLibs\SDL\src\render\direct3d\SDL_render_d3d.c:1897:1: error: unknown type name 'IDirect3DDevice9'
D:\DevLibs\SDL\src\render\direct3d\SDL_render_d3d.c:1898:25: error: unknown type name 'SDL_Renderer'
ny00
SDL_RenderClear clears a render target with the wrong color, if the opengles2 renderer driver is used and the target texture's format is SDL_PIXELFORMAT_ARGB8888.
The bug is *not* reproduced if SDL_PIXELFORMAT_ABGR8888 is used as the texture format (the first from the renderer's list).
It is further not reproduced using any of the following renderer drivers: opengl, opengles (apparently powered by Gallium3D), software.
Finally, the correct color can be drawn using SDL_RenderFillRect (instead of SDL_RenderClear).
A few details about the current setup:
- OS: Ubuntu 12.04 for x86_64
- GPU: GeForce GTX 460
- GPU driver version: 331.20-0ubuntu1~xedgers~precise1 (from the xorg-edgers PPA)
---
Seth Williams
Sam,
It appears that the clear just needs to take the render target format into consideration.
Seth.
Haneef Mubarak
AVX is the successor to SSE* and is fairly widely available. As such, it really ought to be detectable.
This functionality ought to be trivial to implement, and not having it means being forced to write an ugly workaround to check for AVX (so that normal SSE can be used if AVX is not available).
Here is an example on detecting AVX from SO (it actually shows ways to cehck for all of teh fancy instructions):
http://stackoverflow.com/questions/6121792/how-to-check-if-a-cpu-supports-the-sse3-instruction-set
The reasoning behind this change is that source2 in -tools mode has a single OpenGL context that is used with multiple different windows. Some of those windows are created outside the engine (i.e. with Qt) and therefore we need to use SDL_CreateWindowFrom() to get an SDL_Window for those. The requirement for sharing an OpenGL context across multiple different windows is that each window has the same pixel format. To facilitate this, I now set SDL_HINT_VIDEO_WINDOW_SHARE_PIXEL_FORMAT for the main window before calling SDL_CreateWindowFrom(). When I do this, SDL_CreateWindowFrom() will:
1. Set the pixel format of the returned window to the same pixel format as this SDL_Window passed in with the hint
2. The flag SDL_WINDOW_OPENGL will be set on the new window so it can be used for OpenGL rendering.
I only currently implemented this for Win32/WGL so implementing it for other platforms (i.e. X11) remains a TODO.
CR: SamL
Some pseudocode that shows how this is used in Source2:
HWND hExternalHwnd; // HWND that was established outside of SDL
// Create main window (happens inside platwindow.cpp)
SDL_Window *mainWindow = SDL_CreateWindow( , SDL_WINDOW_OPENGL .. );
// Create GL context, happens inside rendersystemgl
SDL_GLContext onlyContext = SDL_GL_CreateContext( mainWindow );
// Now I need to create another window from hEternalHwnd for my swap chain that will have the same pixel format as mainWindow, so set the hint
SDL_SetHint( SDL_HINT_VIDEO_WINDOW_SHARE_PIXEL_FORMAT, CFmtStr( %p, mainWindow) );
// Create the secondary window. This returned window will have SDL_WINDOW_OPENGL set and share a pixel format with mainWindow from the hint
SDL_Window *secondaryWindow = SDL_CreateWindowFrom( hExternalHwnd );
// To render to the main window:
SDL_GL_MakeCurrent( mainWindow, onlyContext );
// Do some rendering to main window
// To render to the secondary window:
SDL_GLMakeCurrent( secondaryWindow, onlyContext );
// Do some rendering to secondary window
This fixes weird behavior on Mac where our first responder reverts to the window
itself, rather than the SDLTranslatorResponder, after the window has lost focus
once. This causes Escape to call cancelOperation: on the NSWindow, which by
default removes our fullscreen-ness.
When someone has turned off SDL_TEXTINPUT we should probably set another initial
responder that handles the Escape behavior, so that SDL_TEXTINPUT doesn't change
fullscreen behavior (and possibly other behavior) like it does now.
Previously, we'd minimize fullscreen windows (if
SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS was set) during SDL_DestroyWindow if they
had keyboard focus, because we call SDL_SetKeyboardFocus(NULL) which yields a
OnWindowsFocusLost event.
Related to https://bugzilla.libsdl.org/show_bug.cgi?id=1840
SDL 2.x recently accepted patches to enable OpenGL ES 2 support via Google's ANGLE library. The thought is to try to eventually merge SDL/WinRT's OpenGL code with SDL-official's.
