Aaron Barany
Add SDL_HINT_VIDEO_EXTERNAL_CONTEXT hint to notify SDL that the graphics context is external. This disables the automatic context save/restore behavior on Android and avoids using OpenGL by default when SDL_WINDOW_VUKLAN isn't set.
When the application wishes to manage the OpenGL contexts on Android, this avoids cases where SDL unbinds the context and creates new contexts, which can interfere with the application's operation.
When using Vulkan and Metal renderer implementations, this avoids SDL forcing OpenGL to be enabled on certain platforms. While using the SDL_WINDOW_VULKAN flag can be used to achieve the same thing, it also causes Vulkan to be loaded. If the application uses Vulkan directly, this is not necessary, and fails window creation when using Metal due to Vulkan not being present. (assuming MoltenVK isn't installed)
Using (1 << 14) instead of 0x4000 might be clearer for the maintainer, but
it makes it harder to look up these flags when debugging an app. The value
has to be written once by one person, the has to be read by tons of people
over and over.
The Offscreen video driver is intended to be used for headless rendering
as well as allows for multiple GPUs to be used for headless rendering
Currently only supports EGL (OpenGL / ES) or Framebuffers
Adds a hint to specifiy which EGL device to use: SDL_HINT_EGL_DEVICE
Adds testoffscreen.c which can be used to test the backend out
Disabled by default for now
When using a recent version of CMake (3.14+), this should make it possible to:
- build SDL for iOS, both static and dynamic
- build SDL test apps (as iOS .app bundles)
- generate a working SDL_config.h for iOS (using SDL_config.h.cmake as a basis)
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=iOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: iphoneos, iphonesimulator, iphoneos12.4, /full/path/to/iPhoneOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;armv7s")
Examples:
- for Simulator, using the latest, installed SDK:
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
- for Device, using the latest, installed SDK, 64-bit only
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64
- for Device, using the latest, installed SDK, mixed 32/64 bit
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"
- for Device, using a specific SDK revision (iOS 12.4, in this example):
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64
- for Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
cmake path/to/SDL -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
This is currently supported on Linux and macOS. iOS and Android are not
supported at all, Windows support could be added with some changes to the libusb
backend. The Visual Studio and Xcode projects do not use this feature.
Based on Valve Software's hid.cpp, written in collaboration with Andrew Eikum.
The real problem is that SDL_atomic.c was built in thumb mode instead of ARM mode, which is required to use the mcr instruction on ARM platforms. Added a compiler error to catch this case so we don't generate code that does infinite recursion.
I also added a potentially better way to handle things on Linux ARM platforms, based on comments in the Chromium headers, which we can try out after 2.0.10 ships.
It causes the HIDAPI devices to always be opened on enumeration, which causes crashes in the Windows drivers when multiple applications are reading and writing at the same time. We can revisit this after 2.0.10 release.
Dzmitry Malyshau
Current code, search paths, and error messages are written to only consider MoltenVK on macOS as a Vulkan Portability implementation. It's not the only implementation available to the users. gfx-portability [1] has been shown to run a number of titles well, including Dota2, Dolphin Emulator, and vkQuake3, often out-performing MoltenVK in frame rate and stability (see Dolphin benchmark [2]).
There is no reason for SDL to be that specific, it's not using any MVK-specific functions other than the WSI initialization ("VK_MVK_macos_surface"). gfx-portability exposes this extension as well, and a more generic WSI extension is in process. It would be good if SDL was written in a more generic way that expect a Vulkan Portability library as opposed to MoltenVK specifically.
[1] https://github.com/gfx-rs/portability
[2] https://gfx-rs.github.io/2019/03/22/dolphin-macos-performance.html
Simon Hug
Attached is a minor cleanup patch. It changes the option name of one hint to something better, puts one or two more checks in, and adds explicit casting where warnings could appear otherwise.
I hope the naming of the hints and their options is acceptable. It would be kind of awkward to change them after they get released with an official SDL version.
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
Sam Lantinga
Ozkan Sezer
Cameron Cawley
EXL
Ryan C. Gordon
Ben Avison
Sylvain Becker
Brandon Schaefer
David Ludwig
Alex Szpakowski
Ethan Lee