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.
