The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
Clarify that grabbing the mouse only works with one window at a time; this was
always true at the system level, though SDL could previously get confused
by multiple simultaneous grabs, so now we explicitly break any existing
grab before starting a new one and document it as such.
Also track the window that is currently grabbed, and provide an API to query
for that window. This makes it easy to automate mouse ungrabbing at
breakpoints with gdb7's scripting, since the scripts can now know which window
to ungrab.
In 2.1, we should probably change this API to SDL_GrabInput(win) and
SDL_UngrabInput(void), or something.
This extension allows the user to specify whether a full flush is performed when making a context not current.
The only way to set this currently is at context creation, so this patch provides that functionality.
Defualt behaviour is set at FLUSH, as per the spec.
This patch does not contain the changes to WGL, appleGL or other platforms as I do not have access to GL 4.5 hardware on those platforms.
Full details on the use of KHR_context_flush_control can be found here:
https://www.opengl.org/registry/specs/KHR/context_flush_control.txt
This fills in the core pieces and fully implements it for Mac OS X.
Most other platforms, at the moment, will report a disconnected device if
it fails to write audio, but don't notice if the system's device list changed
at all.
64-bit Linux uses a "long" instead of "long long" for 64-bit ints.
Added a special-case this so SDL_PRI?64 doesn't trigger compiler warnings
when used with SDL's 64-bit datatypes on 64-bit Linux.
Yes this seems confusing as on mac+linux Long is either 32 or 64bits depending on the architecture, but this is how the X11 protocol is defined. Thus 5 is the correct value for the nelts here. Not 5 or 10 depending on the architecture.
More info on the confusion https://bugs.freedesktop.org/show_bug.cgi?id=16802
- Added new custom launch screen code. It uses the launch screen nib when available on iOS 8+, the launch images dictionary if the launch screen nib isn't available, and the old standard image names if the launch image dictionary isn't in the plist.
The launch screen is now hidden during the first call to SDL_PumpEvents rather than SDL_CreateWindow so apps can have the launch screen still visible if they do time-consuming loading after creating their window. It also fades out in roughly the same way as the system launch screen behavior.
It can be disabled by setting the SDL_IPHONE_LAUNCHSCREEN define in SDL_config_iphoneos.h to 0.
- A blank UIView is now created and displayed when the window is first created. The old behavior was to defer creating any view until SDL_GL_CreateContext, which prevented rotation, touch events, and other windowing-related things from working until then. This also makes it easier to use SDL_GetWindowWMInfo after creating a window.
- Moved the keyboard and animation callback code from SDL's UIView subclasses to its UIViewController subclass, which lets them work properly in all cases when a SDL window is valid, even before SDL_GL_CreateContext is called and after SDL_GL_DeleteContext is called.
- SDL_GL_CreateContext, SDL_GL_SwapWindow, SDL_GL_MakeCurrent, and SDL_GL_DeleteContext are more robust.
- Fixed some edge cases where SDL windows weren't rotating properly or their reported sizes were out of sync with their actual sizes.
- Removed all calls to [UIApplication setStatusBarOrientation:]. It doesn't seem to work as expected in all cases in recent iOS versions.
- Some code style cleanup.
Jonas Kulla
The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c.
I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.
This is a little macro magic to use malloc() directly instead of SDL_malloc(),
etc, so static analysis tests that know about the C runtime can function
properly, and understand that we are dealing with heap allocations, etc.
This changed our static analysis report from 5 outstanding bugs to 30.
5x as many bugs were hidden by SDL_malloc() not being recognized as malloc()
by the static analyzer!
SDL_WinRTRunApp() is used on WinRT to launch a main(int, char **)-style
function. It has optional, and experimental support for launching content
inside a XAML control, backed by a main() function running on a separate thread.
This is provided via it's 2nd parameter, which can be a pointer to a XAML
control. (If NULL, XAML support will not be used.)
This change renames the experimental feature's parameter (to SDL_WinRTRunApp())
as "reserved", until such time as the functionality is ready for use. It will
likely be renamed again in the future, when running SDL on top of a XAML control
via a separate thread, becomes reasonably usable.
With this commit, you can compile SDL2 with Emscripten
( http://emscripten.org/ ), and make your SDL-based C/C++ program
into a web app.
This port was due to the efforts of several people, including: Charlie Birks,
Sathyanarayanan Gunasekaran, Jukka Jyl?nki, Alon Zakai, Edward Rudd,
Bruce Mitchener, and Martin Gerhardy. (Thanks, everyone!)
The expected use case is for games that are designed with multiple aspect ratios already in mind and leave optional margins on the edges of the game which won't hurt if they are cut off.
An example use case is a game is designed for wide-screen/16:9, but then wants to deploy on an iPad which is 4:3. Normally, SDL will letterbox, which will shrink things and result in wasted space. But the designer already thought about 4:3 and designed the edges of the game so they could be cut off without any functional loss. So rather than wasting space with letterboxing, "overscan" mode will zoom the rendering to fill up the entire screen. Parts on the edges will be drawn offscreen, but since the game was already designed with this in mind, it is fine. The end result is the iPad (4:3) experience is much better since it feels like a game designed for that screen aspect ratio.
This patch introduces a new SDL_hint: SDL_HINT_RENDER_LOGICAL_SIZE_MODE.
Valid values are "letterbox" or "0" for letterboxing and "overscan" or "1" for overscan.
The default mode is letterbox to preserve existing behavior.
// Example usage:
SDL_SetHint(SDL_HINT_RENDER_LOGICAL_SIZE_MODE, "overscan");
SDL_RenderSetLogicalSize(renderer, SCREEN_WIDTH, SCREEN_HEIGHT);
Elias Vanderstuyft
"Horizontal" is not very precise, use "Positive phase" instead.
"Positive" because it's actually waveform(2*pi*t + phase) instead of waveform(2*pi*t - phase).
Elias Vanderstuyft
It's not obvious from the general "haptic direction" description what the SDL direction actually means in terms of force magnitude sign,
currently its meaning is only reflected by the example.
This change does a few things, all with regards to the WinRT implementation of
SDL_GetPrefPath():
1. it fixes a bug whereby SDL_GetPrefPath() did not create the directory it
returned. On other SDL platforms, SDL_GetPrefPath() will create separate
directories for its 'org' and 'app' folders. Without this, attempts to create
files in the pref-path would fail, unless those directories were first created
by the app, or by some other library the app used. This change makes sure
that these directories get created, before SDL_GetPrefPath() returns to its
caller(s).
2. it defaults to having SDL_GetPrefPath() return a WinRT 'Local' folder
on all platforms. Previously, for Windows Store apps, it would have used a
different, 'Roaming' folder. Files in Roaming folders can be automatically,
and synchronized across multiple devices by Windows. This synchronization can
happen while the app runs, with new files being copied into a running app's
pref-path. Unless an app is specifically designed to handle this scenario,
there is a chance that save-data could be overwritten in unwanted or
unexpected ways.
The default is now to use a Local folder, which does not get synchronized, and
which is arguably a bit safer to use. Apps that wish to use Roaming folders
can do so by setting SDL_HINT_WINRT_PREF_PATH_ROOT to "roaming", however it
is recommended that one first read Microsoft's documentation for Roaming
files, a link to which is provided in README-winrt.md.
To preserve older pref-path selection behavior (found in SDL 2.0.3, as well as
many pre-2.0.4 versions of SDL from hg.libsdl.org), which uses a Roaming path
in Windows Store apps, and a Local path in Windows Phone, set
SDL_HINT_WINRT_PREF_PATH_ROOT to "old".
Please note that Roaming paths are not supported on Windows Phone 8.0, due to
limitations in the OS itself. Attempts to use this will fail.
(Windows Phone 8.1 does not have this limitation, however.)
3. It makes SDL_GetPrefPath(), when on Windows Phone 8.0, and when
SDL_HINT_WINRT_PREF_PATH_ROOT is set to "roaming", return NULL, rather than
silently defaulting to a Local path (then switching to a Roaming path if and
when the user upgraded to Windows Phone 8.1).
WinRT apps can set a default, preferred orientation via a .appxmanifest file.
SDL was overriding this on app startup, and making the app use all possible
orientations (landscape and portrait).
Thanks to Eric Wing for the heads up on this!
SDL_HINT_WINRT_PREF_PATH_ROOT allows WinRT apps to alter the path that
SDL_GetPrefPath() returns. Setting it to "local" uses the app's
OS-defined Local folder, setting it to "roaming" uses the app's OS-defined
Roaming folder.
Roaming folder support is not available in Windows Phone 8.0. Attempts to
make SDL_GetPrefPath() return a Roaming folder on this OS will be ignored.
Various bits of documentation on this were added to SDL_hints.h, and to
README-winrt.md
The "future-dev" branch of MSOpenTech's ANGLE/WinRT repository (at
https://github.com/msopentech/angle) includes support for Windows Phone 8.1.
This change allows it to be used in conjunction with SDL's OpenGL functions.
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.
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
skaller
using gcc 4.2 (the default) on Mac OSX 10.6.8
CC build/SDL_dynapi.lo
In file included from /Users/johnskaller/SDL/src/dynapi/SDL_dynapi.c:31:
include/SDL_syswm.h:211:39: error: missing binary operator before token "("
The fault appears to be here:
#if defined(__OBJC__) && __has_feature(objc_arc)
that the __has_feature macro is not supported by gcc 4.2.
The code works fine with my clang 3.3svn.
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.
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.
1) Moves all READMEs to docs/
2) Renames them to *.md, adds some Markdown with the idea to add a lot more
3) Moves the doxyfile config to doc/ and makes it parse the headers at ../include as well as the md files in docs.
4) Skips SDL_opengl*.h headers from the docs
5) Minor fixes to doxyfile
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.
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.
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.
Alex Szpakowski
Now that SDL for iOS requires at least iOS 5.1 at runtime, there are several old codepaths in the UIKit backend which can be removed. I've attached a patch which does so.
Author: Sam Clegg <sbc@chromium.org>
Date: Fri Jun 20 12:52:11 2014
Fix win32 build which was failing due to missing PRIs64.
This change adds definitions for the C99 PRIs16 and PRIu64
which are missing from <stdint.h> on at last win32 and
possibly other platforms.
These already existed in testgesture.c so I removed them
from there also.
J?rgen Tjern?
If you #define NO_SDL_GLEXT before including SDL_opengl.h, it still includes the platform-provided glext.h. The comments indicate that this define is intended to be used when you provide your own glext.h (quote from SDL_opengl.h: "Define this if you have your own version of glext.h and want to disable the version included in SDL_opengl.h.")
This is a problem because glext.h depends on the contents of gl.h, and it's practical to let SDL_opengl.h pick the right #include for gl.h for our platform.
An existing hint lets apps that don't need the timer resolution changed avoid
this, to save battery, etc, but this fixes several problems in timing, audio
callbacks not firing fast enough, etc.
Fixes Bugzilla #2944.
There were several good arguments for this: it's how Windows works with
WM_NCHITTEST, SDL doesn't need to manage a list of rects, it allows more
control over the regions (how do you use rects to cleanly surround a circular
button?), the callback can be more optimized than a iterating a list of
rects, and you don't have to send an updated list of rects whenever the
window resizes or layout changes.
SDL/WinRT did have support for OpenGL ES 2 via an older version of ANGLE/WinRT,
however its API changed a few months ago, and SDL/WinRT would crash when trying
to use it. It would also occasionally crash when using the older version.
This changeset should make SDL/WinRT work with the latest version, as
available via MS Open Tech's git repository of it at
https://github.com/msopentech/angle
Older versions of ANGLE/WinRT (from either https://github.com/stammen/angleproject
or https://bitbucket.org/DavidLudwig/angleproject) will need to be updated to
MS Open Tech's latest version.
Fix to allow using SDL when compiling with v110_xp or v120_xp -- compiling with VS2012/VS2013 with the XP targeting option.
In order to ensure that we can target Windows XP we compile with the v120_xp toolset instead of v120. This means that we use an earlier SDK version and it means that winapifamily.h is not available. Compiling for this old SDK can be detected using the _USING_V110_SDK71_ define which is set through the %(PreprocessorDefinitions) option.
The D3D11 renderer is now slightly faster than D3D9 on my Windows 8 machine (testsprite2 runs at 3400 FPS vs 3100 FPS)
This will need tweaking to fix the Windows RT build.
- SDL_WINDOW_FULLSCREEN works as always (change resolution, lock to window).
- SDL_WINDOW_FULLSCREEN_DESKTOP now puts the window in its own Space, and
hides the menu bar, but you can slide between Spaces and Command-Tab between
apps without the window minimizing, etc.
- SDL_WINDOW_RESIZABLE windows will get the new 10.7+ "toggle fullscreen"
window decoration and menubar item. As far as the app is concerned, this is
no different than resizing a window, but it gives the end-user more power.
- The hint for putting fullscreen windows into the Spaces system is gone,
since Spaces can't enforce the requested resolution. It's a perfect match
for FULLSCREEN_DESKTOP, though, so this is all automated now.
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.
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.
This lets it know, for example, that when you do this...
SDL_assert(ptr != NULL);
...that (ptr) is definitely not NULL at this point in the program, for the
sake of static analysis. While a buggy program could definitely trigger this
assertion, Clang assumes your assertion check is covering it and won't
report possible NULL dereferences after this point.
Since SDL_assert might continue if the user clicks "ignore", without this
change Clang would notice you checked for NULL (meaning that NULL is a real
possibility here) and still wrote code outside of that test branch that
dereferences the pointer, and thus would always trigger false positives.
Static analysis is fun!
