If this application is being run under Wine but Steam doesn't know that, Steam won't set STEAM_COMPAT_PROTON. So we'll use wine_get_version() to detect that we're running under Wine instead.
(cherry picked from commit e2e8f86076)
Other blitters seem to handle zero width/height destinations correctly.
Signed-off-by: Marcin Serwin <marcin@serwin.dev>
(cherry picked from commit 53ee410d7a)
When the upload needs realignment, a new buffer is created to do the
upload, and the source data is copied to the new buffer. This commit
fixes the issue where the memcopy can read off the end of the source
buffer since it is reading based on destination pitch instead of source
pitch.
(cherry picked from commit 6a01d6e7d3)
Correcting it when it is subsequently hidden and re-mapped will cause the position to be double offset by the size of the borders.
(cherry picked from commit a71b2f0a93)
pa_channel_map_init_auto() with PA_CHANNEL_MAP_WAVEEX does the wrong
thing as it just takes the lest significant bits of
WAVEFORMATEXTENSIBLE's dwChannelMask in order. This doesn't match SDL's
chosen channel ordering.
The implementation here mirrors what we do for PipeWire.
(cherry picked from commit 0d2f081d41)
libdecor 0.3, which changes the signature of libdecor_new and
libdecor_decorate to use a const pointer to the interface struct, has
not yet been released. In the latest release, libdecor 0.2.4, the
interface struct is a mutable pointer.
This doesn't affect typical upstream builds with
SDL_WAYLAND_LIBDECOR_SHARED=ON, in which case we're casting a pointer
returned by dlsym(); but Linux distributions that want tighter control
over dependencies often prefer to link them in the normal way, in which
case the build will fail if the signature doesn't match.
Fixes: 33834360 "wayland: Fix libdecor incompatible pointer types"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8b64dd67d2)
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
(cherry picked from commit 705ced8cf5)
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.
(cherry picked from commit 901173aee6)
