Please try this 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 cross-platform Vulkan graphics support in SDL_vulkan.h
SDL_Vulkan_LoadLibrary()
SDL_Vulkan_GetVkGetInstanceProcAddr()
SDL_Vulkan_GetInstanceExtensions()
SDL_Vulkan_CreateSurface()
SDL_Vulkan_GetDrawableSize()
SDL_Vulkan_UnloadLibrary()
This is all the platform-specific code you need to bring up Vulkan on all SDL platforms. You can look at an example in test/testvulkan.c
Added SDL_ComposeCustomBlendMode() to create custom blend modes for 2D rendering
Added SDL_HasNEON() which returns whether the CPU has NEON instruction support
Added support for many game controllers, including the Nintendo Switch Pro Controller
Added support for inverted axes and separate axis directions in game controller mappings
Added functions to return information about a joystick before it’s opened:
SDL_JoystickGetDeviceVendor()
SDL_JoystickGetDeviceProduct()
SDL_JoystickGetDeviceProductVersion()
SDL_JoystickGetDeviceType()
SDL_JoystickGetDeviceInstanceID()
Added functions to return information about an open joystick:
SDL_JoystickGetVendor()
SDL_JoystickGetProduct()
SDL_JoystickGetProductVersion()
SDL_JoystickGetType()
SDL_JoystickGetAxisInitialState()
Added functions to return information about an open game controller:
SDL_GameControllerGetVendor()
SDL_GameControllerGetProduct()
SDL_GameControllerGetProductVersion()
Added SDL_GameControllerNumMappings() and SDL_GameControllerMappingForIndex() to be able to enumerate the built-in game controller mappings
Added SDL_LoadFile() and SDL_LoadFile_RW() to load a file into memory
Added SDL_DuplicateSurface() to make a copy of a surface
Added an experimental JACK audio driver
Implemented non-power-of-two audio resampling, optionally using libsamplerate to perform the resampling
Added the hint SDL_HINT_AUDIO_RESAMPLING_MODE to control the quality of resampling
Added the hint SDL_HINT_RENDER_LOGICAL_SIZE_MODE to control the scaling policy for SDL_RenderSetLogicalSize():
“0” or “letterbox” - Uses letterbox/sidebars to fit the entire rendering on screen (the default)
“1” or “overscan” - Will zoom the rendering so it fills the entire screen, allowing edges to be drawn offscreen
Added the hints SDL_HINT_MOUSE_NORMAL_SPEED_SCALE and SDL_HINT_MOUSE_RELATIVE_SPEED_SCALE to scale the mouse speed when being read from raw mouse input
Added the hint SDL_HINT_TOUCH_MOUSE_EVENTS to control whether SDL will synthesize mouse events from touch events
Windows:
The new default audio driver on Windows is WASAPI and supports hot-plugging devices and changing the default audio device
The old XAudio2 audio driver is deprecated and will be removed in the next release
Added hints SDL_HINT_WINDOWS_INTRESOURCE_ICON and SDL_HINT_WINDOWS_INTRESOURCE_ICON_SMALL to specify a custom icon resource ID for SDL windows
The hint SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING is now on by default for compatibility with .NET languages and various Windows debuggers
Updated the GUID format for game controller mappings, older mappings will be automatically converted on load
Implemented the SDL_WINDOW_ALWAYS_ON_TOP flag on Windows
Linux:
Added an experimental KMS/DRM video driver for embedded development
Is the new audio driver (WASAPI) compatible with SDL_mixer? Init gives no error, but I’m getting “Unsupported audio format” whenever I try to play anything (WAV / MOD) now. Works fine with 2.0.5.
I dug a little deeper Ryan. I can re-create this in 2.0.5 if I call Mix_OpenAudio() with AUDIO_F32SYS, instead of AUDIO_U16SYS. I read in your other post about WASAPI only using 32bit floats, and having to do some magic if you wanted to use a different format. Does SDL_mixer need to fall in line in this regards?
I’m using MIX_INIT_MODPLUG, Mix_SetDistance, Mix_SetPanning, Mix_Volume.
Currently with 2.0.5 it only works with AUDIO_S16SYS. If I use AUDIO_S32SYS, music plays twice the speed? AUDIO_F32SYS is silent, no errors, so I don’t know how to fix it or what I’m doing wrong. I guess 2.0.6 is forcing AUDIO_F32SYS internally.
Thanks Ryan, you’re the man. I’ve noticed Sam has added SDL_mixer updates within the last few hours. Any chance of rolling out version 2.0.2 of mixer at the same time as 2.0.6? I have big problems compiling the source, so only link the libs.
I think I have found a regression in the SDL2 2.0.6 prerelease checkout from Mercurial that practically breaks the graphics of my game “Rocks’n’Diamonds” (https://www.artsoft.org/rocksndiamonds/) and potentially every SDL2 program that uses SDL_SetColorKey() followed by SDL_ConvertSurface() to set a certain pixel color in a surface as being transparent and convert the surface to a different surface format (in my case to the “native” format for blitting to the target background surface).
At least for my game, this is a real show-stopper with SDL2 2.0.6.
Expected behaviour: All images in the menu and game where the background of the image file is 100% black should be transparent.
Observed behaviour: All images in the game that should be transparent are non-transparent now. Immediately visible at the “door” looking broken on the right side of the screen directly after starting the program. (In addition, all 100% white pixels of the images are transparent now.)
Some debugging revealed that the color key (explicitly set after loading the image files) was changed from totally black (0x00000000) on the old surface to totally white (0x00ffffff) on the new surface created by SDL_ConvertSurface().
I have used “hg bisect” to track down this problem, and found it to be caused by the following commit:
changeset: 11253:ecc1f6b82d95
user: Sam Lantinga slouken@libsdl.org
date: Sat Aug 12 16:59:00 2017 -0700
summary: Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently
Undoing this specific commit in the SDL2 code fixes the problem, which can be reproduced with the Rocks’n’Diamonds source code (download and extract from link above and do a “make run”). I was able to reproduce this problem with Linux (Ubuntu 12.04 x64) and Mac OS X (10.11.6) with the latest SDL2 checkout from Mercurial.
I will also report this problem with a minimal code example and example PNG image file to Bugzilla this evening.
Also after fixing that I had some strange issues on app startup. Sometimes if the app is not started so that the phone is already in the orientation required by the app, the screen size is distorted and I get a quit event immediately (and a crash after that). This might be some kind of timing issue with the startup because it did not happen every time or on every app I tested. Also when I tried to debug the problem it did not happen (likely because there is a delay when the app is waiting for the debugger).
I didn’t have time to investigate it further yet. You can reproduce the issue with a quite minimal test app on almost every startup (when the device/emulator is in portrait and the app want’s to be in landscape): eg. my cmake build test: https://github.com/suikki/simpleSDL
It contains a minimal example program and a patch.
Since my last post, I have further investigated and debugged the problem. Unfortunately, I wasn’t able to find the root cause for the corrupted color key, which is copied over to the new surface in SDL_ConvertSurface() by blitting it as a pixel since the change introduced by the patch for bug 2979. However, the problem can be solved by using this new code only for those cases it addresses: 16-bit “565 format” surfaces. Using the previous code for all other surface formats should solve the problem for all surface formats (as can be seen when running the example programs attached to both bug reports, which both work fine now).
So the patch attached to the above bug report should hopefully fix this problem for SDL2 2.0.6 – please have a look at it.
Hey, thanks for reporting this issue.
Indeed, the patch was incomplete. It was missing the case where the input surface has colormap / palette. It has to be shared so that the conversion is performed correctly.
I reopened and submitted a patch in https://bugzilla.libsdl.org/show_bug.cgi?id=2979
I also tried with your game and that’s fixing the issue.
It was missing the case where the input surface has colormap / palette.
That totally explains why this problem apparently did not happen to that many other people! Indeed I wasn’t aware of the fact that my game mostly uses 8-bit images with colormap/palette when looking at that problem.
I also tried with your game and that’s fixing the issue.
Thanks a lot for your effort! Your patch indeed perfectly fixes the problem!
Hello,
You added a jitter filter for joystick (SDL_Joystick.c in SDL_PrivateJoystickAxis at line 664).
With the current setting, with a 900° steering wheel, you need to rotate wheel 5.625° before getting an update.
This is really noticeable in game.
I think there should be an option to disable this, and access raw input value, because:
high quality joysticks and steering wheels don’t need it (i do not have jitter on Xbox One gamepad).
game with mouse smoothing algorithm usually have an option to disable it. it should be the same with jitter filter.
jitter does not affect game where character/object you control have momentum.
game should handle joystick input smoothing (they already handle dead zone, linearity, and saturation).
