Also updates the naming of these Xbox Wireless Controllers connected via USB (and thus the third-party Xbox Controller Driver) to match.
The Xbox Wireless Controller entries are now listed, in order, via USB, bia Bluetooh (with older firmware) and via Bluetooth (with firmware 3.1.1221.0).
This is a bleeding edge API, added to Windows 10 Anniversary Edition (build
1607, specifically).
https://msdn.microsoft.com/en-us/library/windows/desktop/mt774976(v=vs.85).aspx
Nothing supports this yet, including WinDbg, Visual Studio, minidumps, etc,
so we still need to also use the RaiseException hack. But presumably tools
will use this API as a more robust and universal way to get thread names
sooner or later, so we'll start broadcasting to it now.
Firmware revision 3.1.1221.0 changes the mapping of the Xbox One S
controller in Bluetooth mode. Aside from changing the layout of
other buttons, this revision also changes the triggers to act as
Accelerator and Brake axes from the simulation controls page.
The Darwin sysjoystick code didn't previously map anything at these
axes, making it impossible to detect input on these two buttons.
This defaults to the internal SDL resampler, since that's the likely default
without a system-wide install of libsamplerate, but those that need more can
tweak this.
This currently favors libsamplerate over the fast path (quality over speed),
but I'm not sure that's the correct approach, as there may be surprising
changes in performance metrics depending on what packages are available on
a user's system. That being said, currently, the only thing with access to
SDL_AudioStream is an SDL audio device's thread, and it might be mostly idle
otherwise, so maybe this is generally good.
Turns out that iterating from 0 to channels-1 was a serious performance hit!
These cases now tend to match or beat the original audio resampler's speed!
This allows us to avoid an extra copy, allocate less memory and reduce cache
pressure. On the downside: we have to do a lot of tapdancing to resample the
buffer in reverse when the output is growing.
It's expensive and (hopefully) unnecessary. If this becomes an overflow
problem, we could multiply both values by 0.5f before adding them, but let's
see if we can get by without the extra multiplication first.
We never seem to overflow the source buffer now; this might have been a
leftover from a bug that was covered by Vitaly's fixes?
Removing this conditional makes the resampler 10-20% faster. Left an
assert in there for debug builds, in case this still happens.
white.magic
The logic which decides if a device enumerated via the direct input system in the function EnumJoysticksCallback in SDL_dinputjoystick.c is processed is discarding valid joystick devices due to the assumption that devices of the type DI8DEVTYPE_SUPPLEMENTAL are not valid devices.
This change was added with 2.0.4 with this commit http://hg.libsdl.org/SDL/rev/1b9d40126645 that is linked to this bug report https://bugzilla.libsdl.org/show_bug.cgi?id=2460 which indicates that in that case devices of the type DI8DEVTYPE_SUPPLEMENTAL were not desirable as they caused a singular device to emit multiple "device added" events.
Since then there appear to have been a few fixes to handle devices that fall into various other classes in the following two commits:
http://hg.libsdl.org/SDL/rev/10ffb4787d7a and http://hg.libsdl.org/SDL/rev/6a2bbac05728
Two devices I have reports of failing to be listed when the DI8DEVTYPE_SUPPLEMENTAL type is excluded are ECS Gametric Throttle and Thrustmaster MFD Cougar.
Sam Lantinga
I verified that the OUYA controller shows up as a single device with this change, so I've reverted the change to ignore supplemental devices, leaving framework in place to easily add devices that we want to ignore.
Removed some needless things ("len / sizeof (Uint8)"), and made sure the
int32 -> float code uses doubles to avoid working with large integer values
in a 32-bit float.
