In addition to lots of bug fixes, here are the major changes in this release:
General:
Added SDL_GetTextureScaleMode() and SDL_SetTextureScaleMode() to get and set the scaling mode used for a texture
Added SDL_LockTextureToSurface(), similar to SDL_LockTexture() but the locked area is exposed as a SDL surface.
Added new blend mode, SDL_BLENDMODE_MUL, which does a modulate and blend operation
Added the hint SDL_HINT_DISPLAY_USABLE_BOUNDS to override the results of SDL_GetDisplayUsableBounds() for display index 0.
Added the window underneath the finger to the SDL_TouchFingerEvent
Added SDL_GameControllerTypeForIndex(), SDL_GameControllerGetType() to return the type of a game controller (Xbox 360, Xbox One, PS3, PS4, or Nintendo Switch Pro)
Added the hint SDL_HINT_GAMECONTROLLERTYPE to override the automatic game controller type detection
Added SDL_JoystickFromPlayerIndex() and SDL_GameControllerFromPlayerIndex() to get the device associated with a player index
Added SDL_JoystickSetPlayerIndex() and SDL_GameControllerSetPlayerIndex() to set the player index associated with a device
Added the hint SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS to specify whether Nintendo Switch Pro controllers should use the buttons as labeled or swapped to match positional layout. The default is to use the buttons as labeled.
Added support for Nintendo GameCube controllers to the HIDAPI driver, and a hint SDL_HINT_JOYSTICK_HIDAPI_GAMECUBE to control whether this is used.
Improved support for Xbox 360 and Xbox One controllers when using the HIDAPI driver
Added support for many game controllers, including:
8BitDo FC30 Pro
8BitDo M30 GamePad
BDA PS4 Fightpad
HORI Fighting Commander
Hyperkin Duke
Hyperkin X91
MOGA XP5-A Plus
NACON GC-400ES
NVIDIA Controller v01.04
PDP Versus Fighting Pad
Razer Raion Fightpad for PS4
Razer Serval
Stadia Controller
SteelSeries Stratus Duo
Victrix Pro Fight Stick for PS4
Xbox One Elite Series 2
Fixed blocking game controller rumble calls when using the HIDAPI driver
Added SDL_zeroa() macro to zero an array of elements
Added SDL_HasARMSIMD() which returns true if the CPU has ARM SIMD (ARMv6+) features
Windows:
Fixed crash when using the release SDL DLL with applications built with gcc
Fixed performance regression in event handling introduced in 2.0.10
Added support for SDL_SetThreadPriority() for UWP applications
Linux:
Added the hint SDL_HINT_VIDEO_X11_WINDOW_VISUALID to specify the visual chosen for new X11 windows
Added the hint SDL_HINT_VIDEO_X11_FORCE_EGL to specify whether X11 should use GLX or EGL by default
iOS / tvOS / macOS:
Added SDL_Metal_CreateView() and SDL_Metal_DestroyView() to create CAMetalLayer-backed NSView/UIView and attach it to the specified window.
iOS/ tvOS:
Added support for Bluetooth Steam Controllers as game controllers
tvOS:
Fixed support for surround sound on Apple TV
Android:
Added SDL_GetAndroidSDKVersion() to return the API level of the current device
Added support for audio capture using OpenSL-ES
Added support for Bluetooth Steam Controllers as game controllers
Fixed rare crashes when the app goes into the background or terminates
How come the default behavior for switch pro controllers is to use buttons as labeled? doesnāt that work against the point of the game controller API (for consistent bindings regardless of controllers)?
Edit: using it seemed to keep the button layouts like how they usually are. was this a typo in the announcement?
Because thatās the layout that people who use those controllers natively are used to, and matches on-screen button prompts. Also, for those reasons, thatās the default behavior of Steam.
If your application needs to use the buttons by position rather than label, you can just set SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS to 0.
FYI, GameCube controllers and NES/SNES controllers are affected by this hint as well.
Please fix SDL_MapRGB because it seems only blue if you use MapRGB then it has bug.
I try legacy format. like SDL_FillRect(screen, ref zero, SDL_Color.Red)
Result:
Why do SDL_MapRGB and SDL_MapRGBA have problem with wrong color. If I use real color like 0xffff0000 = RED, for SDL_MapRGB(A) seems blue in ārā That is like weird. Can you fix it?
The same reason SDL2 replaced SDL1. Removing the redundant code would break the interface, which is when a major version comes into play. Plans for SDL3 are already in place.
Extremely strange words. This is the first time I hear about the desire to release a new major version.
Removing the redundant code
What does this mean? If there are plans, what exactly do they relate to? Do you have links or other where you can get acquainted with this, probably I missed something or it was not public. If itās easier, what is supposed to be removed specifically?
In its current form, I personally do not see fatal excesses in SDL2
One example from the top of my head: There are now two versions of all the drawing functions; one for int coordinates and one for float coordinates. We donāt need the int ones, but they are there to keep compatibility.
Another example: Some of the internal workings can only be improved by breaking the format of the interface.
SDL2 was the release of a new major version. Thatās why we still have SDL1 in development because some projects still use it.
I think calling SDL1 āin developmentā is a bit of an overstatement, and I think the only reason people still occasionally fix things there is that thereās no fully functional SDL1.2-on-SDL2 wrapper yet.
So in case thereās any concrete plans for SDL 2.1 or 3.0 - please make sure to have a working wrapper for backwards compat before releasing the first version.
Greetings,
While using Sdl 2.0.10 calls to SDL_GetNumVideoDisplays() would return the correct number of displays attached to my machine(s). However, since Sdl 2.0.12, it only ever returns 1 display, when I have 2 (I have tried 2.0.12, 2.0.14, and 2.0.15).
A similar situation exists with SDL_GetNumVideoDrivers(). In 2.0.10 it would return 3: x11, dummy, and Wayland. Since 2.0.12 it only return x11 and dummy.
Goog Job. Thanks Dev Team
