We are fast-tracking this release for a security update to SDL_image, so please try this ASAP with your games and applications and report any issues to bugzilla: https://bugzilla.libsdl.org
In addition to lots of bug fixes and build improvements, here are the major changes in this release:
General:
Added SDL_fmod() and SDL_log10()
Each of the SDL math functions now has the corresponding float version
Added SDL_SetYUVConversionMode() and SDL_GetYUVConversionMode() to control the formula used when converting to and from YUV colorspace. The options are JPEG, BT.601, and BT.709
Windows:
Implemented WASAPI support on Windows UWP and removed the deprecated XAudio2 implementation
Added resampling support on WASAPI on Windows 7 and above
Windows UWP:
Added SDL_WinRTGetDeviceFamily() to find out what type of device your application is running on
Mac OSX / iOS / tvOS:
Added a Metal 2D render implementation
Added SDL_RenderGetMetalLayer() and SDL_RenderGetMetalCommandEncoder() to insert your own drawing into SDL rendering when using the Metal implementation
iOS:
Added the hint SDL_HINT_IOS_HIDE_HOME_INDICATOR to control whether the home indicator bar on iPhone X should be hidden. This defaults to dimming the indicator for fullscreen applications and showing the indicator for windowed applications.
iOS / Android:
Added SDL_IsAndroidTV() to tell whether the application is running on Android TV
Added the hint SDL_HINT_RETURN_KEY_HIDES_IME to control whether the return key on the software keyboard should hide the keyboard or send a key event (the default)
Android:
SDL now requires the API 19 SDK to build, but can still target devices down to API 14 (Android 4.0.1)
Android / tvOS:
Added the hint SDL_HINT_TV_REMOTE_AS_JOYSTICK to control whether TV remotes should be listed as joystick devices (the default) or send keyboard events.
Linux:
Added the hint SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR to control whether the X server should skip the compositor for the SDL application. This defaults to “1”
Added the hint SDL_HINT_VIDEO_DOUBLE_BUFFER to control whether the Raspberry Pi and KMSDRM video drivers should use double or triple buffering (the default)
Could you not release only the updated SDL_image, or is SDL2 itself somehow implicated in the security issue? ‘Fast-tracking’ sounds like a recipe for yet another unstable release of SDL2 (I am still using 2.0.5 because so many problems have been reported with later versions).
My difficulty is that it’s often my customers who experience the problems, and I can’t really expect them to be guinea pigs. For example I switched to using 2.0.6 for my Windows build and although I personally didn’t encounter any problems (other than having to set the audio driver to fix sound glitches) I immediately started to receive reports that my app was no longer working. Realistically I had no choice but to revert to 2.0.5.
So - and I know this isn’t helpful to you - I have adopted a philosophy of “if it ain’t broke, don’t fix it”. Unless I experience a specific problem with SDL 2.0.5, or there is some new feature introduced that will be very useful in my app, I don’t want to risk inconveniencing my customers by repeating my previous mistake.
I wish you luck with 2.0.8. If there are no reports of any significant problems over an extended period of time I may once again consider updating, but ‘once bitten, twice shy’.
Currently when building a debug build with cmake on Android the library name is not the same as the release library. This does not go well with android requiring the library name explicitly in java code.
In light of macOS new 2018 x64 only rules it might be good if you relaease for MacOS differently now. A 64bit build and a universal one ( or maybe just 64bit?).
I looked into it, and you can thin the archives yourself, as you need to resign your app and frameworks for Mac OS X app release. We can provide a 64-bit only build after release if people think it’s valuable.