GetTempPath2() is only available on Windows 11 and Windows 10 systems with full updates. We want to be compatible back to earlier versions of Windows and the only difference between the two calls is the behavior for processes running as SYSTEM, which we don't expect for SDL applications using notifications.
Amazon's store link was still "http://" instead of "https://", and since they
don't have the physical CD in stock anymore (and probably won't ever again), I
added a link to the album on Amazon Music, for those that want to access it.
It does better version checking and has better compatibility.
This also fixes a crash in GameInputRedist.dll when attempting to load v3 when v2 is installed on the system. In this case, a thread is created in GameInputCreate() which is not cleaned up when the object is released, and can crash later with a NULL pointer dereference.
Otherwise, a device that is disconnected in the standard audio device thread
might keep failing WaitDevice() in a tight loop, each one generating a new
main thread callback. In normal situations, this is wasteful, but if the
app isn't pumping the event loop quickly (or at all!), this will quickly eat
up all the memory in a machine.
Now we note that the device is zombified right away, and device thread
iteration will use this to replace the implementation with the Zombie
equivalents once it owns the device lock.
The main thread callback will progress to device->zombie==2, which it uses to
decide if this is a duplicate disconnect notification. Since it also owns the
lock at this point, it takes the moment to set the Zombie implementation up,
too.
This allows things (like the WASAPI backend) to check for a non-zero zombie
state immediately without having to worry if the main thread callback ran, and
for the standard audio threads to also move to the Zombie implementation
without waiting on that callback.
(The Zombie implementation is used to make a dead device keep processing, so
things that need the audio device to make progress to function will keep
working, and things blindly pushing to an audio stream won't queue up endless
data that isn't being consumed.)
Fixes#15745.
Originally, macOS had opposite Y axis inversion as every other platform, likely to correct for an issue with the virtual gamepad reported by the old 360Controller driver.
Wired Xbox 360 controllers using native macOS drivers were first reported to be broken in https://github.com/libsdl-org/SDL/issues/11002. The inversion was removed in https://github.com/libsdl-org/SDL/commit/7da728a642f2acfbba9543a3587363908d7aa1c3, presumably breaking 360Controller usage, but fixing wired 360 controller using the new native support in macOS 15 and above. However, this change was reverted without explanation in https://github.com/libsdl-org/SDL/commit/d7b1ba1bfca7c9bf4f57075258ccfa0e0c6b2051 which added explicit support for the Steam Virtual Gamepad. Presumably, Steam on macOS reports inverted Y axes to match what SDL expected on the platform. However, this reversion broke the native macOS controller support. The incorrect inversion also breaks using off-brand 360-class gamepads via the libusb backend of HIDRAW.
If we lose focus during startup, we need to unlock the activity mutex before waiting for the focus lifecycle event, otherwise it will never be delivered.
Reproduced using testcontroller with a DualSense controller attached and the "Allow the app to access the USB device?" dialog popped up.
This fixes a deadlock when a call comes in from Java that takes the activity lock and then tries to send an event, which takes the event lock, at the same time the application thread takes the event lock and then calls SDL_RequestAndroidPermission(), which takes the activity lock.
Fixes https://github.com/libsdl-org/SDL/issues/15772
Fixes https://github.com/libsdl-org/SDL/issues/15771
Nintorch
Brenton Bostick
Frank Praznik
Sam Lantinga
SDL Wiki Bot
Anonymous MaartenandSam Lantinga
Ryan C. Gordon
Anonymous Maarten
expikr
Alejandro Perez
QwertyChouskie
Sylvain
Sanjay Govind
Ozkan Sezer
COMRADECHOnKy