Simon Hug
I had a look at this and made some additions to SDL_wave.c.
The attached patch adds many checks and error messages. For some reason I also added A-law and ?-law decoders. Forgot exactly why... but hey, they're small.
The WAVE format is seriously underspecified (at least by the documents that are publicly available on the internet) and it's a shame Microsoft never put something better out there. The language used in them is so loose at times, it's not surprising the encoders and decoders behave very differently. The Windows Media Player doesn't even support MS ADPCM correctly.
The patch also adds some hints to make the decoder more strict at the cost of compatibility with weird WAVE files.
I still think it needs a bit of cleaning up (Not happy with the MultiplySize function. Don't like the name and other SDL code may want to use something like this too.) and some duplicated code may be folded together. It does work in this state and I have thrown all kinds of WAVE files at it. The AFL files also pass with it and some even play (obviously just noise). Crafty little fuzzer.
Any critique would be welcome. I have a fork of SDL with a audio-loadwav branch over here if someone wants to use the commenting feature of Bitbucket:
https://bitbucket.org/ChliHug/SDL
I also cobbled some Lua scripts together to create WAVE test files:
https://bitbucket.org/ChliHug/gendat
ace
I got this bug in SDL_ttf:
https://bugzilla.libsdl.org/show_bug.cgi?id=4524
Sylvain proposed solution:
SDL_RWseek(RWops, 0, RW_SEEK_SET);
And it works, but i can use it my project, because it written in C# with SDL2-CS wrapper and there not export for macroses:
#define SDL_RWsize(ctx) (ctx)->size(ctx)
#define SDL_RWseek(ctx, offset, whence) (ctx)->seek(ctx, offset, whence)
#define SDL_RWtell(ctx) (ctx)->seek(ctx, 0, RW_SEEK_CUR)
#define SDL_RWread(ctx, ptr, size, n) (ctx)->read(ctx, ptr, size, n)
#define SDL_RWwrite(ctx, ptr, size, n) (ctx)->write(ctx, ptr, size, n)
#define SDL_RWclose(ctx) (ctx)->close(ctx)
Therefore, I suggest replacing this macros with functions so that they can be exported and used in bindings
java layer runs as if separate mouse and touch was 1,
Use SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS
for generating synthetic touch/mouse events
Note that a single USB device is responsible for all 4 joysticks, so a large
rewrite of the DeviceDriver functions was necessary to allow a single device to
produce multiple joysticks.
Visual Studio doesn't define __ARM_ARCH nor _ARM_NEON, but _M_ARM and _M_ARM64,
so SDL_HasNEON() was bypassed.
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE doesn't see to be defined (but still works
when defined as 19).
Only __ARM_NEON is defined with Android NDK and arm64-v8a
Tested on ndk-r18, ndk-r13 and also Xcode.
(Visual Studio needs a different fix).
Fixes Bugzilla #4409.
Luke Dashjr
Bug 3993 was "fixed" by #undef'ing bool. But this breaks C99's stdbool.h bool too.
For example, mpv's build fails with:
../audio/out/ao_sdl.c:35:5: error: unknown type name ?bool?
It seems ill-advised to be #undef'ing *anything* here - what if the code including SDL_cpuinfo.h actually wants to use altivec?
Daniel Gibson
Even though my game (dhewm3) doesn't use SDL_INIT_JOYSTICK, SDL_PumpEvent() calls SDL_JoystickUpdate() which ends up calling hid_enumerate() every three seconds, and sometimes on my Win7 box hid_enumerate() takes about 5 seconds, which causes the whole game to freeze for that time.
zen3d
While trying to build Pixie lisp (https://github.com/pixie-lang/pixie), which uses SDL for multimedia output, the mandelbrot example won't build. The problem is that internally pixie uses a templated function to dump a value, and gcc chokes because SDL_PIXELFORMAT_RGA8888 is an anonymous enum.
I solved the problem locally by changing from:
enum {
SDL_PIXELFORMAT_UNKNOWN,
... etc. ...
SDL_PIXELFORMAT_YUYV = ... etc ...
};
to:
typedef enum {
SDL_PIXELFORMAT_UNKNOWN,
... etc. ...
SDL_PIXELFORMAT_YUYV = ... etc ...
} SDL_PIXELFORMAT_ENUM;
The net result of this change is that the enum containing SDL_PIXELFORMAT_* is no longer an anonymous enum and can now be used by a templated function.
This local change fixes Pixie lisp for me.
I did notice that you use the idiom
typedef enum {
... etc ...
} SDL_FOO;
elsewhere in your code, so that change to SDL_PIXELFORMAT doesn't look like it would have a negative impact.
Touch device types include SDL_TOUCH_DEVICE_DIRECT (a touch screen with window-relative coordinates for touches), SDL_TOUCH_DEVICE_INDIRECT_ABSOLUTE (a trackpad-style device with absolute device coordinates), and SDL_TOUCH_DEVICE_INDIRECT_RELATIVE (a trackpad-style device with screen cursor-relative coordinates).
Phone screens are an example of a direct device type. Mac trackpads are the indirect-absolute touch device type. The Apple TV remote is an indirect-relative touch device type.
If you enable this, you'll need to link with CoreBluetooth.framework and add something like this to your Info.plist:
<key>NSBluetoothPeripheralUsageDescription</key>
<string>MyApp would like to remain connected to nearby bluetooth Game Controllers and Game Pads even when you're not using the app.</string>
Otherwise if SDL_POWER_DISABLED is disabled (eg with --disable-power):
... with clang -pedantic:
src/power/SDL_power.c:48:50: warning: use of GNU empty initializer extension [-Wgnu-empty-initializer]
static SDL_GetPowerInfo_Impl implementations[] = {
^
src/power/SDL_power.c:48:50: warning: zero size arrays are an extension [-Wzero-length-array]
2 warnings generated.
... with gcc -pedantic:
src/power/SDL_power.c:48:50: warning: ISO C forbids empty initializer braces [-Wpedantic]
src/power/SDL_power.c:48:50: warning: ISO C forbids empty initializer braces [-Wpedantic]
static SDL_GetPowerInfo_Impl implementations[] = {
^
src/power/SDL_power.c:48:30: error: zero or negative size array ?implementations?
static SDL_GetPowerInfo_Impl implementations[] = {
^~~~~~~~~~~~~~~
... with Watcom:
./src/power/SDL_power.c(85): Error! E1112: Initializer list cannot be empty
Author: Anthony Pesch <inolen@gmail.com>
Date: Fri May 4 20:21:21 2018 -0400
Added SDL_AUDIO_ALLOW_SAMPLES_CHANGE flag enabling users of SDL_OpenAudioDevice to get
the sample size of the actual hardware buffer vs having a stream created to handle the
delta
add HAVE_ENDPOINTVOLUME_H, HAVE_MMDEVICEAPI_H and HAVE_AUDIOCLIENT_H
in SDL_config.h.in, SDL_config.h.cmake, SDL_config_windows.h, and in
SDL_config_winrt.h.
Sylvain
Patch a few warnings when using:
-Wmissing-prototypes -Wdocumentation -Wdocumentation-unknown-command
They are automatically enabled with -Wall
Anthony @ POW Games
SDL_CreateTextureFromSurface makes an internal call to SDL_GetColorKey which can return an error and spams the error log with "Surface doesn't have a colorkey" even though the original function didn't return an error.
lectem
The SDL_syswm.h header includes the windows.h header after including begin_code.h which changes the structure packing alignment.
It seems this is not safe as suggested by the following warning :
warning C4121: 'JOBOBJECT_IO_RATE_CONTROL_INFORMATION_NATIVE_V2': alignment of a member was sensitive to packing
Felix Geyer
Forwarding from https://bugs.debian.org/892087 quoting verbatim:
The SDL2 header SDL_cpuinfo.h generates gcc warnings if the program using
it compiles with the -Wundef warning. (In particular, this means that QEMU
builds using it fail on at least sparc hosts, since QEMU dev builds
use both -Wundef and -Werror.).
/usr/include/SDL2/SDL_cpuinfo.h:63:5: warning: "HAVE_IMMINTRIN_H" is not defined, evaluates to 0 [-Wundef]
#if HAVE_IMMINTRIN_H && !defined(SDL_DISABLE_IMMINTRIN_H)
This tries to load vulkan.framework or libvulkan.1.dylib before MoltenVK.framework
or libMoltenVK.dylib. In the previous version, layers would not work for applications
run-time loading the default library.
Callum McGing
This patch allows the user to disable the behaviour that blocks the compositor through a new hint: SDL_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR. This allows tools or other windowed applications to behave properly under KWin.
This variable can be set to the following values:
"0" - The indicator bar is not hidden (default for windowed applications)
"1" - The indicator bar is hidden and is shown when the screen is touched (useful for movie playback applications)
"2" - The indicator bar is dim and the first swipe makes it visible and the second swipe performs the "home" action (default for fullscreen applications)