The syntax errors in the enum lists tell us that no one ever actually
compiled this `WINVER < _WIN32_WINNT_VISTA` fallback path. 2f5bc17 made
it increasingly unlikely for retro Windows builds to hit this path by
adding a new set of `WINVER` override rules to `SDL_windows.h` that
check for the presence of certain headers. `HAVE_MMDEVICEAPI_H` in
particular will be `#define`d for any CMake build with a ≥Vista-era
SDK, such as Visual Studio 2017's `v141_xp` toolset that 2f5bc17
targeted, and it's also unconditionally defined in the default
`SDL_build_config_windows.h` configuration used by the ready-made
Visual Studio project.
These fixes work for a XP-era configuration that undefines all of the
`HAVE_*_H` macros and `SDL_VIDEO_RENDER_D3D12` to make `SDL_windows.h`
fall through to the `#define _WIN32_WINNT _WIN32_WINNT_WINXP` case, on
both Visual Studio 2022 and Visual Studio 2017's `v141_xp` toolset.
Adds support for animated cursors on Cocoa, Wayland, Win32, and X11.
testcursor can take a semicolon separated list of filenames and load an animated cursor from them.
015cc6a broke texture format selection for this kind of surface if the
renderer's first texture format doesn't happen to have an alpha
channel. This happens for on-screen software renderers on Windows,
whose preferred format is the window's own `SDL_PIXELFORMAT_XRGB8888`.
This fixed check also cover the intent behind 015cc6a, assuming that
indexed and alpha formats are mutually exclusive.
Convert SDL_d3dmath.c functions to static inline in SDL_d3dmath.h to make
it less likely to conflict when static linking SDL. raylib's SDL backend
does not work with a "normal" upstream binary static link. It has these
errors:
/usr/bin/ld: /usr/local/lib64/libSDL3.a(SDL_d3dmath.c.o): in function `MatrixIdentity':
SDL/src/render/SDL_d3dmath.c:35: multiple definition of `MatrixIdentity'; CMakeFiles/raylib.dir/rcore.c.o:rcore.c:(.text+0x18470): first defined here
/usr/bin/ld: /usr/local/lib64/libSDL3.a(SDL_d3dmath.c.o): in function `MatrixMultiply':
SDL/src/render/SDL_d3dmath.c:44: multiple definition of `MatrixMultiply'; CMakeFiles/raylib.dir/rcore.c.o:rcore.c:(.text+0x18540): first defined here
collect2: error: ld returned 1 exit status
It works if these functions aren't emitted, (i.e.
!SDL_VIDEO_RENDER_D3D(11|12|GPU|VULKAN)
Or, if SDL is not linked static. Which I know is preferred anyway.
In raylib's case, it doesn't use this code anyway so it's not a problem
to build it yourself with them disabled. But it's a minor hassle to be
incompatible with static linking libraries from upstream.
I can't see any good reason for these functions to not be static inline
already, so I just put them in the header and deleted the .c.
Raylib's conflicting case is a library with a public function exposed to
users. But SDL's case is not.
- Moved all matrix functions from SDL_d3dmath.c to SDL_d3dmath.h as static inline
- Removed SDL_d3dmath.c from all project files (Visual Studio and Xcode)
- Functions affected: MatrixIdentity, MatrixMultiply, MatrixScaling,
MatrixTranslation, MatrixRotationX, MatrixRotationY, MatrixRotationZ
Changed SDL_TRY_ACQUIRE and SDL_TRY_ACQUIRE_SHARED success value
from 0 to true for functions that now return bool instead of int.
This fixes false positives/negatives in Clang's thread safety analysis.
Detect times that cross forward/backward across the zero timepoint, and handle them appropriately, so that events with an old timestamp don't mangle the time base offset, or have their timestamps mangled.
For SInput, the paddle order is left/right, which conflicted with the paddle order 1/Right, 2/Left.
The order has been fixed to properly apply the mapping strings generated to be 2/Left, 1/Right, 4/Left, 3/Right.
