Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
Xbox Elite controllers use AUX1-AUX4 to represent the paddle buttons when using the HIDAPI driver
PS4 and PS5 controllers use AUX1 to represent the touchpad button
Nintendo Switch Pro controllers use AUX1 to represent the capture button
This driver supports the Razer Atrox Arcade Stick
Some of the quirks of this driver, inherent in Windows Gaming Input:
* There will never appear to be controllers connected at startup. You must support hot-plugging in order to see these controllers.
* You can't read the state of the guide button
* You can't get controller events in the background
Fixed a case where partial trigger pull could be bound to another button
There is a fundamental problem not resolved by this commit:
Some controllers have axes (triggers, pedals, etc.) that don't start at zero, but we're guaranteed that if we get a value that it's correct. For these controllers, the current code works, where we take the first value we get and use that as the zero point and generate axis motion starting from that point on.
Other controllers have digital axes (D-pad) that assume a zero starting point, and the first value we get is the min or max axis value when the D-pad is moved. For these controllers, the current code thinks that the zero point is the axis value after the D-pad motion and this doesn't work.
My hypothesis is that the first class of devices is more common and that we should solve for that, and add an exception to SDL_JoystickAxesCenteredAtZero() as needed for the second class of devices.
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().
Misa
Sam Lantinga
Ozkan Sezer
Philipp Wiesemann