Sdl 2.0.12 released!

Thanks to all the people who contributed code and feedback, SDL 2.0.12 is now available!
https://www.libsdl.org/download-2.0.php

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
5 Likes

Do Re Mi Fa So La Minooor Si :grinning: Goog Job. Thanks Dev Team

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.

Just bought a USB PowerA Switch controller, but it doesn’t appear to be working on SDL, but does in Chrome/Steam.

The Blend_MUL effect is pretty nice by the way.

When does SDL3 will come out ?

1 Like

Hi,

Are there more details available on the Windows note:

Fixed performance regression in event handling introduced in 2.0.10

Could this explain possible ‘laggy’ mouse events and stuttering in window redraws – at worst apparently freezing for a few seconds?

Why should we need SDL3? Do you think a major API revamp is needed? Any non solvable issues with actual architecture?

Hello everyone,

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?

PS I don’t know where do I report bug?

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

(sorry for my english i used a translator)

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.