A negative periodic magnitude doesn't exist in Windows' and MacOS' FF APIs
The periodic magnitude parameter of the SDL Haptic API is based on the Linux
FF API, so it means they are not directly compatible:
'dwMagnitude' is a 'DWORD', which is unsigned.
Fixes Bugzilla #2701.
This modifies SDL_PauseAudio behavior to pause all audio devices instead of
just the default one (required on Android, at least for testmultiaudio on my
Nexus 4 which reported 2 audio devices).
It also changes SDL_PauseAudioDevice to retain the device lock from pause until
resume in order to save battery in mobile devices.
Philipp Wiesemann
I attached a patch for an incomplete implementation of the messagebox parts.
It was not tested on lots of devices yet and features a very fragile workaround to block the calling SDL thread while the dialog is handled on Android's UI thread. Although it works for testmessage.c I assume there are lot of situations were it may fail (standby, device rotation and other changes). Also not all flags and colors are implemented.
On the other hand most uses of the messagebox are to show an error on start and fragility (or working at all) may not matter there.
since the window system doesn't do it for us like other platforms.
This prevents sticky keys and missed keys when going in and out
of focus, for example Alt would appear to stick if switching away
from an SDL app with Alt-Tab and had to be pressed again.
CR: Sam
This helps when modern versions of The Gimp (and lots of other things)
produces a 32-bit bitmap with an alpha channel, or anything with "BI_BITFIELDS"
format, since that data is now embedded in the bitmap info header instead of
directly following it and we would accidentally skip over embedded versions of
it.
Fixes Bugzilla #2714.
Alex Szpakowski
SDL's Cocoa backend uses the CGDisplayMode API to get refresh rate information about a display mode, but CGDisplayModeGetRefreshRate will return 0 on most non-CRT monitors.
The only way I know of to get correct refresh rate information in OS X is via the CoreVideo DisplayLink API.
I have attached a patch which tries to use the CVDisplayLinkGetNominalOutputVideoRefreshPeriod function if CGDisplayModeGetRefreshRate fails, which fixes display mode refresh rate information on the monitors I tested.
The CVDisplayLink API requires linking with the CoreVideo framework, and the patch updates the various build files to do so.
+ Handle HidePreeditText IBus signal.
+ Use SDL_GetKeyboardFocus instead of SDL_GetFocusWindow.
+ Move the X11 IBus SetFocus calls to the X11_DispatchFocus functions.
+ Simplify the IBus ifdefs when handling X11 KeyEvents.
+ Remove inotify watch when SDL_IBus_Quit is called.
Tim McDaniel
This patch replaces all use of NSAutoreleasePool with the Apple recommended @autoreleasepool. @autoreleasepool is supposedly more efficient, and since it is scope based it can't be accidentally not released.
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);
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.
This will (eventually) make SDL_GetQueuedAudioSize() more accurate, and thus
reduce latency. Right now this isn't implemented anywhere, so we assume data
fed to the audio callback is consumed by the hardware and immediately played
to completion.
For versions of XAudio2 with an IXAudio2SourceVoice::GetState() that offers a
flags parameter, we can use XAUDIO2_VOICE_NOSAMPLESPLAYED, since we don't
need this information in our current calls. According to MSDN, this makes the
the call about 3x faster.
This requires at least Xcode 4.5 and the iOS 6 SDK to build, but it doesn't change the minimum supported runtime version (iOS 5.1). Less than 2% of iOS users are running iOS 5, so I hope developers aren't trying to build SDL using an SDK which doesn't support iOS 6/7...
Nitz
In GL_CreateTexture function:
if (GL_CheckError("glGenTexures()", renderer) < 0) {
SDL_free(data);
return -1;
}
Here only data is getting free but data->pixels getting leak.
So have to free data->pixels before free data.
Previously, SDL would always expose display modes and window dimensions in terms of pixels, and would add an extra 'fake' display mode on retina screens which would contain the non-retina resolution. Calling SDL_CreateWindow with the dimensions of that fake display mode would not work.
Now, SDL only exposes display modes and window dimensions in terms of points rather than pixels. If the SDL_WINDOW_ALLOW_HIGHDPI flag is passed into SDL_CreateWindow, then any OpenGL contexts created from that window will be sized in pixels rather than points (retrievable with SDL_GL_GetDrawableSize.) Window dimensions and mouse coordinates are still in terms of points rather than pixels even with that flag.
This matches the behavior of SDL in OS X more closely, and lets users choose whether to make use of retina displays and lets them handle it properly.
Damian Kaczmarek
Basically this bug is probably not a common use case. My goal is to allow rendering totally without a window, for example to a screenshot and I need to rely on SDL_SetRenderTarget to properly work for a purely software renderer created by SDL_CreateSoftwareRenderer.
Pablo Mayobre
When generating a signed app with SDL 2.0.3 an issue comes up, watching at the Error Log points out that the issue lies in the src/main/android/SDL_android_main.c where the process name is defined as "SDL_app", this name turns into an erroneous name so it should be changed to "app_process"
chasesan
When using SDL_RenderCopyEx, I get a problem on some platforms where the output is offset by +/-1 on other platforms and not on others. I tried it with a center of both 0,0 (and offsetting by width/height) and NULL (for centered).
The rotation involved is 90, and/or -90 rotation. The rotation was a constant, no arithmetic was involved when inputting it into SDL_RenderCopyEx.
This occurred with 32x32, 24x24, and 16x16 texture sizes. I apologize that I don't have more precise information, as I received the information as a bug report myself. But I have tracked the problem down to here.
My program requires pixel perfect alignment on several different platforms, so this is something of a showstopper for me.
--
Sylvain
It appears the RenderCopyEx is done as expected,
this is the red rectangle which is not correctly positionned !
So, here's patch with a 0.5 float increment, like for opengles2, for DrawLines, and also Draw Points.
binarycrusader
Since changeset 358696c354a8, SDL 2.0 has been broken on Solaris when compiling with the Solaris Studio compiler (which uses the pthread implementation of SDL_AtomicLock).
Notably, it gets stuck at the MemoryBarrierRelease in SDL_GetErrBuf:
6585 # 218
6586 if (!tls_errbuf && !tls_being_created) {
6587 SDL_AtomicLock_REAL ( & tls_lock );
6588 if (!tls_errbuf) {
6589 SDL_TLSID slot;
6590 tls_being_created = SDL_TRUE;
6591 slot = SDL_TLSCreate_REAL ( );
6592 tls_being_created = SDL_FALSE;
6593 { SDL_SpinLock _tmp = 0 ; SDL_AtomicLock_REAL ( & _tmp ) ; SDL_AtomicUnlock_REAL ( & _tmp ) ; };
^^^ loops forever above
6594 tls_errbuf = slot;
6595 }
6596 SDL_AtomicUnlock_REAL ( & tls_lock );
6597 }
Running: testthread
(process id 28926)
^Cdbx: warning: Interrupt ignored but forwarded to child.
signal INT (Interrupt) in __nanosleep at 0xfe52a875
0xfe52a875: __nanosleep+0x0015: jae __nanosleep+0x23 [ 0xfe52a883, .+0xe ]
Current function is SDL_Delay_REAL
204 was_error = nanosleep(&tv, &elapsed);
(dbx) where
[1] __nanosleep(0xfeffe848, 0xfeffe850, 0xfe75a5ac, 0xfe5169d8), at 0xfe52a875
[2] nanosleep(0xfeffe848, 0xfeffe850), at 0xfe516a3b
=>[3] SDL_Delay_REAL(ms = 0), line 204 in "SDL_systimer.c"
[4] SDL_AtomicLock_REAL(lock = 0xfeffe88c), line 104 in "SDL_spinlock.c"
[5] SDL_GetErrBuf(), line 225 in "SDL_thread.c"
[6] SDL_ClearError_REAL(), line 216 in "SDL_error.c"
[7] SDL_InitSubSystem_REAL(flags = 0), line 116 in "SDL.c"
[8] SDL_Init_REAL(flags = 0), line 244 in "SDL.c"
[9] SDL_Init(a = 0), line 89 in "SDL_dynapi_procs.h"
[10] main(argc = 1, argv = 0xfeffe948), line 65 in "testthread.c"
As far as I can tell, this is because pthread_spin_trylock() always returns EBUSY for this particular lock; since it works in other places, I'm suspicious.
Different Solaris Studio compiler versions seem to make no difference.
I've verified this is broken on Linux as well if SDL_spinlock.c is modified to use the pthread implementation.
This appears to be because pthread_spin_init() and pthread_spin_destroy() are not used with the locks as required.
Wei Mingzhi
surface->map should be invalidated in SDL_SetSurfacePalette(), otherwise the palette would not be effective when blitting to another non-8bit surface which we previously blitted to.
Alex Szpakowski
Some minor changes to the Mac-specific backend code:
- Fixed up some code style issues (mostly brace style inconsistencies).
- Fixed a compiler warning in SDL_cocoaevents.m.
- Removed some useless code now that the 10.7 SDK is required to build SDL.
- Removed Gestalt(gestaltSystemVersion, ...) call and switched to NSAppKitVersionNumber for version checking code. Using Gestalt with gestaltSystemVersion will give 0x1090 in Mac OS 10.10+, and the whole Gestalt function was deprecated in Mac OS 10.8.
Alex Szpakowski
Since this commit https://hg.libsdl.org/SDL/rev/59b543340d63 , calling SDL_DestroyWindow will crash the program if the window has an active OpenGL context.
This is because the Cocoa_DestroyWindow code sets the window's driverdata to NULL and then calls [context setWindow:NULL], which tries to access the window's driverdata, resulting in a null pointer dereference.
I have attached a patch which fixes the issue by moving the line which sets the driverdata to NULL to after the lines which call functions that use the driverdata pointer.
Notes:
- Support for the 'Guide' button does not seem to be possible, as
XInputGetStateEx is not available on WinRT.
- Haptic support appears to be working on WinRT now!
- SDL/WinRT does not allow calls to LoadLibrary or LoadLibraryEx. The calls
to those were removed by this change, but only when compiling for WinRT.
Non-WinRT Windows will continue to detect and load XInput via LoadLibrary and
GetProcAddress calls.
If the EGL extension EGL_KHR_create_context is available, we can use it to
set the core/compatability profile and the minimum OpenGL version.
Use this if it is available to get the context requested by the GL attributes.
SDL/WinRT currently uses a separate XInput backend from SDL/Win32, as WinRT
has no support for DirectInput. This change makes SDL/WinRT's XInput
code snag some recently-changed bits from the Win32-specific,
DirectInput + XInput backend, in order to get the SDL_GameController API
working again on WinRT, insofar that axes map to the correct parts.
TODO:
- test all buttons, making sure WinRT maps buttons the same way that Win32 does
- consider making the Win32 and WinRT codebases share more stuff, minus
the sort of duplication happening via this change. Maybe simulate, or
stub-out, DirectInput calls when on WinRT?
Todd Seiler
Call Stack:
#0 0x0000000101c29291 in Cocoa_StartTextInput at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoakeyboard.m:512
#1 0x0000000101c110c5 in SDL_SetKeyboardFocus at /Users/Todd/Desktop/codes/sources/SDL/src/events/SDL_keyboard.c:643
#2 0x0000000101c32be4 in SetupWindowData at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoawindow.m:981
#3 0x0000000101c32d2a in Cocoa_CreateWindowFrom at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoawindow.m:1092
#4 0x0000000101c99999 in SDL_CreateWindowFrom_REAL at /Users/Todd/Desktop/codes/sources/SDL/src/video/SDL_video.c:1338
#5 0x0000000101ce1484 in SDL_CreateWindowFrom at /Users/Todd/Desktop/codes/sources/SDL/src/dynapi/SDL_dynapi_procs.h:547
#6 0x0000000100018a5e in SceneRenderer at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/SceneRenderer.cpp:138
#7 0x0000000100017ca5 in SceneRenderer at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/SceneRenderer.cpp:145
#8 0x000000010000cd96 in App::execute(int, char**) at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/App.cpp:28
#9 0x0000000100004402 in main at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/main.cpp:8
This issue occurred when using Ogre3D Graphics engine on Mac (cocoa) to create the window. Then handing the window handle off to SDL_CreateWindowFrom().
In Ogre3D application you do the following:
window_ = root_->initialise(true, "Ogre Window 2");
loadOgreResources();
Ogre::WindowEventUtilities::addWindowEventListener(window_, this);
#if OGRE_PLATFORM == OGRE_PLATFORM_APPLE
NSWindow* Data = 0;
window_->getCustomAttribute("WINDOW", &Data);
sdl_window_ = SDL_CreateWindowFrom((void*)Data);
#endif
It results in a crash in this function:
SDL_cocoakeyboard.m
void
Cocoa_StartTextInput(_THIS)
{
SDL_VideoData *data = (SDL_VideoData *) _this->driverdata;
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
SDL_Window *window = SDL_GetKeyboardFocus();
NSWindow *nswindow = nil;
if (window)
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow;
// ...
}
The crash occurred because "driverdata" was nil. Before this function call, a call to SetupWindowData is called:
SDL_cocoawindow.m
static int
SetupWindowData(_THIS, SDL_Window * window, NSWindow *nswindow, SDL_bool created)
{
// ...
if ([nswindow isKeyWindow]) {
window->flags |= SDL_WINDOW_INPUT_FOCUS;
SDL_SetKeyboardFocus(data->window);
}
/* Prevents the window's "window device" from being destroyed when it is
* hidden. See http://www.mikeash.com/pyblog/nsopenglcontext-and-one-shot.html
*/
[nswindow setOneShot:NO];
/* All done! */
[pool release];
window->driverdata = data;
return 0;
}
As you can see: "window->driverdata = data" is performed after the "SDL_SetKeyboardFocus()" call, which eventually leads to "Cocoa_StartTextInput()" where the crash occurs.
Alex Szpakowski
SDL's code for exposing the accelerometer as a joystick on iOS currently uses UIAccelerometer, which was superseded by the CoreMotion framework and deprecated since iOS 5.
The UIAccelerometer code still works (for now), but it also throws deprecation warnings whenever SDL is built for iOS, since SDL's deployment target is no longer below iOS 5.
I've created a patch which replaces the old UIAccelerometer code with a replacement based on the CoreMotion framework. It has identical functionality (to SDL users), however iOS apps are now required to link to the CoreMotion framework when using SDL.
This adds support for all XInput devices, exposed through the SDL joystick API.
The button and axis reporting for XInput devices has been changed to match DirectInput and other platforms.
The game controller xinput mapping has been updated so this change is seamless.
There is a new hint, SDL_HINT_XINPUT_USE_OLD_JOYSTICK_MAPPING, for any applications that have hardcoded the old xinput button and axis set. This hint will be removed in SDL 2.1.
Rainer Deyke
If 'SDL_OpenAudio' is called with 'obtained == NULL', 'prepare_audiospec' performs a bad 'memcpy' with the destination and source pointing to the same block of memory. The problem appears to be on in 'SDL_OpenAudio', which calls open_audio_device with 'obtained = desired' when 'obtained == NULL'. 'open_audio_device' cannot deal with 'desired' and 'obtained' pointing to the same block of memory but can deal with 'obtained == NULL'
Testing:
* For each theme in Windows 7, Windows 7 Basic, and Windows 7 Classic:
- Ran testsprite2
- Pressed Ctrl-G to grab the mouse
- Alt-tabbed away, verified mouse is no longer grabbed
- Alt-tabbed back, verified that mouse was grabbed
- Alt-tabbed away
- Clicked in the window, verified mouse was grabbed
- Alt-tabbed away
- Grabbed the title bar and dragged the window around successfully, verified that mouse was grabbed when move modal loop completed
- Alt-tabbed away
- Clicked the minimize button on the title bar, the window was successfully minimized
- Clicked on the icon in the task bar, the window was restored and the mouse grabbed again
- Alt-tabbed away
- Clicked the close button on the title bar, the window was successfully closed
