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.
Leszek Godlewski
As described in the other thread
(http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-November/091997.html),
I've run into a case of SDL2 not recognizing a wireless Xbox 360
controller receiver properly on Debian Linux amd64 testing.
Apparently, the generated GUID is slightly different.
Device in question:
Bus 001 Device 015: ID 045e:0291 Microsoft Corp. Xbox 360 Wireless
Receiver for Windows
BurnSpamAddress
Steps to reproduce:
1. Grab the cursor with SDL_SetCursorGrab()
2. Alt-tab away from the window
3. Click on the titlebar of the window
This will cause the window to disappear underneath the taskbar!
This appears to be a general issue with ClipCursor() on windows, i.e. I am getting the same behavior if I call ClipCursor() directly.
It is caused by a feedback loop between the ClipCursor function and the modal resize/move event loop that handles mouse-based sizing on Windows.
Ghassan Al-Mashareqa
The SDL_ceil function is implemented incorrectly when HAVE_CEIL is not defined (HAVE_LIBC not defined).
The following code:
double val = SDL_ceil(2.3);
printf("%g", val);
prints "2.0", as STD_ceil is defined as:
double
SDL_ceil(double x)
{
#ifdef HAVE_CEIL
return ceil(x);
#else
return (double)(int)((x)+0.5);
#endif /* HAVE_CEIL */
}
This functions is used in the SDL_BuildAudioResampleCVT function of the audio subsystem (SDL_audiocvt.c), and causes a bug in that function.
Lets Android take care of which is the primary pointer (the one acting as the
mouse in SDL), reorganized the Java side code as well to make it easier to
understand.
If your application wants to have access to the full resolution even when the system has DPI scaling enabled, call SetProcessDPIAware() before calling SDL_Init()
e.g.
typedef BOOL (WINAPI *SetProcessDPIAware_t)(void);
HMODULE hMod = LoadLibrary("user32.dll");
if ( hMod ) {
SetProcessDPIAware_t pSetProcessDPIAware = GetProcAddress( hMod, "SetProcessDPIAware" );
if ( pSetProcessDPIAware ) {
pSetProcessDPIAware();
}
FreeLibrary( hMod );
}
David Ludwig
CarniBlood
Sam Lantinga
J?rgen P. Tjern?
Gabriel Jacobo
Ryan C. Gordon
James Legg
Edward Rudd
Brandon Schaefer
Philipp Wiesemann
dbrady