chore(build): use SDL3

vendor/sdl-3.2.10/docs/INTRO-androidstudio.md

@@ -0,0 +1,17 @@
+
+# Introduction to SDL with Android Studio
+
+We'll start by creating a simple project to build and run [hello.c](hello.c)
+
+- Use our handy script to create a template project:
+```sh
+./build-scripts/create-android-project.py org.libsdl.hello docs/hello.c
+```
+- Run Android Studio and open the newly created build/org.libsdl.hello directory
+- Build and run!
+
+A more complete example is available at:
+
+https://github.com/Ravbug/sdl3-sample
+
+Additional information and troubleshooting is available in [README-android.md](README-android.md)

vendor/sdl-3.2.10/docs/INTRO-cmake.md

@@ -0,0 +1,57 @@
+
+# Introduction to SDL with CMake
+
+The easiest way to use SDL is to include it as a subproject in your project.
+
+We'll start by creating a simple project to build and run [hello.c](hello.c)
+
+# Get a copy of the SDL source:
+```sh
+git clone https://github.com/libsdl-org/SDL.git vendored/SDL
+```
+
+# Create the file CMakeLists.txt
+```cmake
+cmake_minimum_required(VERSION 3.16)
+project(hello)
+
+# set the output directory for built objects.
+# This makes sure that the dynamic library goes into the build directory automatically.
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/$<CONFIGURATION>")
+set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/$<CONFIGURATION>")
+
+# This assumes the SDL source is available in vendored/SDL
+add_subdirectory(vendored/SDL EXCLUDE_FROM_ALL)
+
+# Create your game executable target as usual
+add_executable(hello WIN32 hello.c)
+
+# Link to the actual SDL3 library.
+target_link_libraries(hello PRIVATE SDL3::SDL3)
+```
+
+# Configure and Build:
+```sh
+cmake -S . -B build
+cmake --build build
+```
+
+# Run:
+The executable should be in the `build` directory:
+
+```sh
+cd build
+./hello
+```
+
+If there wasn't an executable there despite the above Build section running successfully, it's likely because you're following this guide using the Visual Studio toolchain, it should instead be in the `build/Debug` directory:
+```sh
+cd build/Debug
+./hello
+```
+
+A more complete example is available at:
+
+https://github.com/Ravbug/sdl3-sample
+
+Additional information and troubleshooting is available in [README-cmake.md](README-cmake.md)

vendor/sdl-3.2.10/docs/INTRO-emscripten.md

@@ -0,0 +1,50 @@
+
+# Introduction to SDL with Emscripten
+
+The easiest way to use SDL is to include it as a subproject in your project.
+
+We'll start by creating a simple project to build and run [hello.c](hello.c)
+
+First, you should have the Emscripten SDK installed from:
+
+https://emscripten.org/docs/getting_started/downloads.html
+
+Create the file CMakeLists.txt
+```cmake
+cmake_minimum_required(VERSION 3.16)
+project(hello)
+
+# set the output directory for built objects.
+# This makes sure that the dynamic library goes into the build directory automatically.
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/$<CONFIGURATION>")
+set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/$<CONFIGURATION>")
+
+# This assumes the SDL source is available in vendored/SDL
+add_subdirectory(vendored/SDL EXCLUDE_FROM_ALL)
+
+# on Web targets, we need CMake to generate a HTML webpage. 
+if(EMSCRIPTEN)
+  set(CMAKE_EXECUTABLE_SUFFIX ".html" CACHE INTERNAL "")
+endif()
+
+# Create your game executable target as usual
+add_executable(hello WIN32 hello.c)
+
+# Link to the actual SDL3 library.
+target_link_libraries(hello PRIVATE SDL3::SDL3)
+```
+
+Build:
+```sh
+emcmake cmake -S . -B build
+cd build
+emmake make
+```
+
+You can now run your app by pointing a webserver at your build directory and connecting a web browser to it, opening hello.html
+
+A more complete example is available at:
+
+https://github.com/Ravbug/sdl3-sample
+
+Additional information and troubleshooting is available in [README-emscripten.md](README-emscripten.md)

vendor/sdl-3.2.10/docs/INTRO-mingw.md

@@ -0,0 +1,95 @@
+# Introduction to SDL with MinGW
+
+Without getting deep into the history, MinGW is a long running project that aims to bring gcc to Windows. That said, there's many distributions, versions, and forks floating around. We recommend installing [MSYS2](https://www.msys2.org/), as it's the easiest way to get a modern toolchain with a package manager to help with dependency management. This would allow you to follow the MSYS2 section below. 
+
+Otherwise you'll want to follow the "Other Distributions" section below.
+
+We'll start by creating a simple project to build and run [hello.c](hello.c).
+
+# MSYS2
+
+Open the `MSYS2 UCRT64` prompt and then ensure you've installed the following packages. This will get you working toolchain, CMake, Ninja, and of course SDL3.
+
+```sh
+pacman -S mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-ninja mingw-w64-ucrt-x86_64-cmake mingw-w64-ucrt-x86_64-sdl3
+```
+
+## Create the file CMakeLists.txt
+```cmake
+cmake_minimum_required(VERSION 3.26)
+project(hello C CXX)
+
+find_package(SDL3 REQUIRED)
+
+add_executable(hello)
+
+target_sources(hello
+PRIVATE
+    hello.c
+)
+
+target_link_libraries(hello SDL3::SDL3)
+```
+
+## Configure and Build:
+```sh
+cmake -S . -B build
+cmake --build build
+```
+
+## Run:
+
+The executable is in the `build` directory:
+```sh
+cd build
+./hello
+```
+
+# Other Distributions
+
+Things can get quite complicated with other distributions of MinGW. If you can't follow [the cmake intro](INTRO-cmake.md), perhaps due to issues getting cmake to understand your toolchain, this section should work.
+
+## Acquire SDL
+
+Download the `SDL3-devel-<version>-mingw.zip` asset from [the latest release.](https://github.com/libsdl-org/SDL/releases/latest) Then extract it inside your project folder such that the output of `ls SDL3-<version>` looks like `INSTALL.md  LICENSE.txt  Makefile  README.md  cmake  i686-w64-mingw32  x86_64-w64-mingw32`.
+
+## Know your Target Architecture
+
+It is not uncommon for folks to not realize their distribution is targeting 32bit Windows despite things like the name of the toolchain, or the fact that they're running on a 64bit system. We'll ensure we know up front what we need:
+
+Create a file named `arch.c` with the following contents:
+```c
+#include <stddef.h>
+#include <stdio.h>
+int main() {
+    #if defined(__x86_64__) || defined(_M_X64) || defined(i386) || defined(__i386__) || defined(__i386) || defined(_M_IX86)
+        size_t ptr_size = sizeof(int*);
+        if (4 == ptr_size) puts("i686-w64-mingw32");
+        else if (8 == ptr_size) puts("x86_64-w64-mingw32");
+        else puts("Unknown Architecture");
+    #else
+        puts("Unknown Architecture");
+    #endif
+    return 0;
+}
+```
+
+Then run
+
+```sh
+gcc arch.c
+./a.exe
+```
+
+This should print out which library directory we'll need to use when compiling, keep this value in mind, you'll need to use it when compiling in the next section as `<arch>`. If you get "Unknown Architecture" please [report a bug](https://github.com/libsdl-org/SDL/issues).
+
+
+## Build and Run
+
+Now we should have everything needed to compile and run our program. You'll need to ensure to replace `<version>` with the version of the release of SDL3 you downloaded, as well as use the `<arch>` we learned in the previous section.
+
+```sh
+gcc hello.c -o hello.exe -I SDL3-<version>/<arch>/include -L SDL3-<version>/<arch>/lib -lSDL3 -mwindows 
+cp SDL3-<version>/<arch>/bin/SDL3.dll SDL3.dll
+./hello.exe
+```

vendor/sdl-3.2.10/docs/INTRO-visualstudio.md

@@ -0,0 +1,16 @@
+
+# Introduction to SDL with Visual Studio
+
+The easiest way to use SDL is to include it as a subproject in your project.
+
+We'll start by creating a simple project to build and run [hello.c](hello.c)
+
+- Get a copy of the SDL source, you can clone the repo, or download the "Source Code" asset from [the latest release.](https://github.com/libsdl-org/SDL/releases/latest)
+  - If you've downloaded a release, make sure to extract the contents somewhere you can find it.
+- Create a new project in Visual Studio, using the C++ Empty Project template
+- Add hello.c to the Source Files
+- Right click the solution, select add an existing project, navigate to `VisualC/SDL` from within the source you cloned or downloaded above and add SDL.vcxproj
+- Select your main project and go to Project -> Add -> Reference and select SDL3
+- Select your main project and go to Project -> Properties, set the filter at the top to "All Configurations" and "All Platforms", select C/C++ -> General and add the SDL include directory to "Additional Include Directories"
+- Build and run!
+

vendor/sdl-3.2.10/docs/INTRO-xcode.md

@@ -0,0 +1,16 @@
+
+# Introduction to SDL with Xcode
+
+The easiest way to use SDL is to include it as a subproject in your project.
+
+We'll start by creating a simple project to build and run [hello.c](hello.c)
+
+- Create a new project in Xcode, using the App template and selecting Objective C as the language
+- Remove the .h and .m files that were automatically added to the project
+- Remove the main storyboard that was automatically added to the project
+- On iOS projects, select the project, select the main target, select the Info tab, look for "Custom iOS Target Properties", and remove "Main storyboard base file name" and "Application Scene Manifest"
+- Right click the project and select "Add Files to [project]", navigate to the SDL docs directory and add the file hello.c
+- Right click the project and select "Add Files to [project]", navigate to the SDL Xcode/SDL directory and add SDL.xcodeproj
+- Select the project, select the main target, select the General tab, look for "Frameworks, Libaries, and Embedded Content", and add SDL3.framework
+- Build and run!
+

vendor/sdl-3.2.10/docs/README-android.md

@@ -0,0 +1,653 @@
+Android
+================================================================================
+
+Matt Styles wrote a tutorial on building SDL for Android with Visual Studio:
+http://trederia.blogspot.de/2017/03/building-sdl2-for-android-with-visual.html
+
+The rest of this README covers the Android gradle style build process.
+
+
+Requirements
+================================================================================
+
+Android SDK (version 35 or later)
+https://developer.android.com/sdk/index.html
+
+Android NDK r15c or later
+https://developer.android.com/tools/sdk/ndk/index.html
+
+Minimum API level supported by SDL: 21 (Android 5.0)
+
+
+How the port works
+================================================================================
+
+- Android applications are Java-based, optionally with parts written in C
+- As SDL apps are C-based, we use a small Java shim that uses JNI to talk to
+  the SDL library
+- This means that your application C code must be placed inside an Android
+  Java project, along with some C support code that communicates with Java
+- This eventually produces a standard Android .apk package
+
+The Android Java code implements an "Activity" and can be found in:
+android-project/app/src/main/java/org/libsdl/app/SDLActivity.java
+
+The Java code loads your game code, the SDL shared library, and
+dispatches to native functions implemented in the SDL library:
+src/core/android/SDL_android.c
+
+
+Building a simple app
+================================================================================
+
+For simple projects you can use the script located at build-scripts/create-android-project.py
+
+There's two ways of using it:
+
+    ./create-android-project.py com.yourcompany.yourapp < sources.list
+    ./create-android-project.py com.yourcompany.yourapp source1.c source2.c ...sourceN.c
+
+sources.list should be a text file with a source file name in each line
+Filenames should be specified relative to the current directory, for example if
+you are in the build-scripts directory and want to create the testgles.c test, you'll
+run:
+
+    ./create-android-project.py org.libsdl.testgles ../test/testgles.c
+
+One limitation of this script is that all sources provided will be aggregated into
+a single directory, thus all your source files should have a unique name.
+
+Once the project is complete the script will tell you how to build the project.
+If you want to create a signed release APK, you can use the project created by this
+utility to generate it.
+
+Running the script with `--help` will list all available options, and their purposes.
+
+Finally, a word of caution: re running create-android-project.py wipes any changes you may have
+done in the build directory for the app!
+
+
+Building a more complex app
+================================================================================
+
+For more complex projects, follow these instructions:
+
+1. Get the source code for SDL and copy the 'android-project' directory located at SDL/android-project to a suitable location in your project.
+
+   The 'android-project' directory can basically be seen as a sort of starting point for the android-port of your project. It contains the glue code between the Android Java 'frontend' and the SDL code 'backend'. It also contains some standard behaviour, like how events should be handled, which you will be able to change.
+
+2. If you are _not_ already building SDL as a part of your project (e.g. via CMake add_subdirectory() or FetchContent) move or [symlink](https://en.wikipedia.org/wiki/Symbolic_link) the SDL directory into the 'android-project/app/jni' directory. Alternatively you can [use the SDL3 Android Archive (.aar)](#using-the-sdl3-android-archive-aar), see bellow for more details.
+
+    This is needed as SDL has to be compiled by the Android compiler.
+
+3. Edit 'android-project/app/build.gradle' to include any assets that your app needs by adding 'assets.srcDirs' in 'sourceSets.main'.
+
+    For example: `assets.srcDirs = ['../../assets', '../../shaders']`
+
+If using CMake:
+
+4. Edit 'android-project/app/build.gradle' to set 'buildWithCMake' to true and set 'externalNativeBuild' cmake path to your top level CMakeLists.txt.
+
+    For example: `path '../../CMakeLists.txt'`
+
+5. Change the target containing your main function to be built as a shared library called "main" when compiling for Android. (e.g. add_executable(MyGame main.c) should become add_library(main SHARED main.c) on Android)
+
+If using Android Makefiles:
+
+4. Edit 'android-project/app/jni/src/Android.mk' to include your source files. They should be separated by spaces after the 'LOCAL_SRC_FILES := ' declaration.
+
+To build your app, run `./gradlew installDebug` or `./gradlew installRelease` in the project directory. It will build and install your .apk on any connected Android device. If you want to use Android Studio, simply open your 'android-project' directory and start building.
+
+Additionally the [SDL_helloworld](https://github.com/libsdl-org/SDL_helloworld) project contains a small example program with a functional Android port that you can use as a reference.
+
+Here's an explanation of the files in the Android project, so you can customize them:
+
+    android-project/app
+        build.gradle            - build info including the application version and SDK
+        src/main/AndroidManifest.xml	- package manifest. Among others, it contains the class name of the main Activity and the package name of the application.
+        jni/			- directory holding native code
+        jni/Application.mk	- Application JNI settings, including target platform and STL library
+        jni/Android.mk		- Android makefile that can call recursively the Android.mk files in all subdirectories
+        jni/CMakeLists.txt	- Top-level CMake project that adds SDL as a subproject
+        jni/SDL/		- (symlink to) directory holding the SDL library files
+        jni/SDL/Android.mk	- Android makefile for creating the SDL shared library
+        jni/src/		- directory holding your C/C++ source
+        jni/src/Android.mk	- Android makefile that you should customize to include your source code and any library references
+        jni/src/CMakeLists.txt	- CMake file that you may customize to include your source code and any library references
+        src/main/assets/	- directory holding asset files for your application
+        src/main/res/		- directory holding resources for your application
+        src/main/res/mipmap-*	- directories holding icons for different phone hardware
+        src/main/res/values/strings.xml	- strings used in your application, including the application name
+        src/main/java/org/libsdl/app/SDLActivity.java - the Java class handling the initialization and binding to SDL. Be very careful changing this, as the SDL library relies on this implementation. You should instead subclass this for your application.
+
+
+Using the SDL3 Android Archive (.aar)
+================================================================================
+
+The Android archive allows use of SDL3 in your Android project, without needing to copy any SDL C or JAVA source into your project.
+For integration with CMake/ndk-build, it uses [prefab](https://google.github.io/prefab/).
+
+Copy the archive to a `app/libs` directory in your project and add the following to `app/gradle.build`:
+```
+android {
+    /* ... */
+    buildFeatures {
+        prefab true
+    }
+}
+dependencies {
+    implementation files('libs/SDL3-X.Y.Z.aar') /* Replace with the filename of the actual SDL3-x.y.z.aar file you downloaded */
+    /* ... */
+}
+```
+
+If you use CMake, add the following to your CMakeLists.txt:
+```
+find_package(SDL3 REQUIRED CONFIG)
+target_link_libraries(yourgame PRIVATE SDL3::SDL3)
+```
+
+If you use ndk-build, add the following before `include $(BUILD_SHARED_LIBRARY)` to your `Android.mk`:
+```
+LOCAL_SHARED_LIBARARIES := SDL3 SDL3-Headers
+```
+And add the following at the bottom:
+```
+# https://google.github.io/prefab/build-systems.html
+# Add the prefab modules to the import path.
+$(call import-add-path,/out)
+# Import @PROJECT_NAME@ so we can depend on it.
+$(call import-module,prefab/@PROJECT_NAME@)
+```
+
+The `build-scripts/create-android-project.py` script can create a project using Android aar-chives from scratch:
+```
+build-scripts/create-android-project.py --variant aar com.yourcompany.yourapp < sources.list
+```
+
+Customizing your application name
+================================================================================
+
+To customize your application name, edit AndroidManifest.xml and build.gradle to replace
+"org.libsdl.app" with an identifier for your product package.
+
+Then create a Java class extending SDLActivity and place it in a directory
+under src matching your package, e.g.
+
+    app/src/main/java/com/gamemaker/game/MyGame.java
+
+Here's an example of a minimal class file:
+
+    --- MyGame.java --------------------------
+    package com.gamemaker.game;
+
+    import org.libsdl.app.SDLActivity;
+
+    /**
+     * A sample wrapper class that just calls SDLActivity
+     */
+
+    public class MyGame extends SDLActivity { }
+
+    ------------------------------------------
+
+Then replace "SDLActivity" in AndroidManifest.xml with the name of your
+class, .e.g. "MyGame"
+
+
+Customizing your application icon
+================================================================================
+
+Conceptually changing your icon is just replacing the "ic_launcher.png" files in
+the drawable directories under the res directory. There are several directories
+for different screen sizes.
+
+
+Loading assets
+================================================================================
+
+Any files you put in the "app/src/main/assets" directory of your project
+directory will get bundled into the application package and you can load
+them using the standard functions in SDL_iostream.h.
+
+There are also a few Android specific functions that allow you to get other
+useful paths for saving and loading data:
+* SDL_GetAndroidInternalStoragePath()
+* SDL_GetAndroidExternalStorageState()
+* SDL_GetAndroidExternalStoragePath()
+* SDL_GetAndroidCachePath()
+
+See SDL_system.h for more details on these functions.
+
+The asset packaging system will, by default, compress certain file extensions.
+SDL includes two asset file access mechanisms, the preferred one is the so
+called "File Descriptor" method, which is faster and doesn't involve the Dalvik
+GC, but given this method does not work on compressed assets, there is also the
+"Input Stream" method, which is automatically used as a fall back by SDL. You
+may want to keep this fact in mind when building your APK, specially when large
+files are involved.
+For more information on which extensions get compressed by default and how to
+disable this behaviour, see for example:
+
+http://ponystyle.com/blog/2010/03/26/dealing-with-asset-compression-in-android-apps/
+
+
+Activity lifecycle
+================================================================================
+
+On Android the application goes through a fixed life cycle and you will get
+notifications of state changes via application events. When these events
+are delivered you must handle them in an event callback because the OS may
+not give you any processing time after the events are delivered.
+
+e.g.
+
+    bool HandleAppEvents(void *userdata, SDL_Event *event)
+    {
+        switch (event->type)
+        {
+        case SDL_EVENT_TERMINATING:
+            /* Terminate the app.
+               Shut everything down before returning from this function.
+            */
+            return false;
+        case SDL_EVENT_LOW_MEMORY:
+            /* You will get this when your app is paused and iOS wants more memory.
+               Release as much memory as possible.
+            */
+            return false;
+        case SDL_EVENT_WILL_ENTER_BACKGROUND:
+            /* Prepare your app to go into the background.  Stop loops, etc.
+               This gets called when the user hits the home button, or gets a call.
+
+               You should not make any OpenGL graphics calls or use the rendering API,
+               in addition, you should set the render target to NULL, if you're using
+               it, e.g. call SDL_SetRenderTarget(renderer, NULL).
+            */
+            return false;
+        case SDL_EVENT_DID_ENTER_BACKGROUND:
+            /* Your app is NOT active at this point. */
+            return false;
+        case SDL_EVENT_WILL_ENTER_FOREGROUND:
+            /* This call happens when your app is coming back to the foreground.
+               Restore all your state here.
+            */
+            return false;
+        case SDL_EVENT_DID_ENTER_FOREGROUND:
+            /* Restart your loops here.
+               Your app is interactive and getting CPU again.
+
+               You have access to the OpenGL context or rendering API at this point.
+               However, there's a chance (on older hardware, or on systems under heavy load),
+               where the graphics context can not be restored. You should listen for the
+               event SDL_EVENT_RENDER_DEVICE_RESET and recreate your OpenGL context and
+               restore your textures when you get it, or quit the app.
+            */
+            return false;
+        default:
+            /* No special processing, add it to the event queue */
+            return true;
+        }
+    }
+
+    int main(int argc, char *argv[])
+    {
+        SDL_SetEventFilter(HandleAppEvents, NULL);
+
+        ... run your main loop
+
+        return 0;
+    }
+
+
+Note that if you are using main callbacks instead of a standard C main() function,
+your SDL_AppEvent() callback will run as these events arrive and you do not need to
+use SDL_SetEventFilter.
+
+If SDL_HINT_ANDROID_BLOCK_ON_PAUSE hint is set (the default),
+the event loop will block itself when the app is paused (ie, when the user
+returns to the main Android dashboard). Blocking is better in terms of battery
+use, and it allows your app to spring back to life instantaneously after resume
+(versus polling for a resume message).
+
+You can control activity re-creation (eg. onCreate()) behaviour. This allows you
+to choose whether to keep or re-initialize java and native static datas, see
+SDL_HINT_ANDROID_ALLOW_RECREATE_ACTIVITY in SDL_hints.h.
+
+
+Insets and Safe Areas
+================================================================================
+
+As of Android 15, SDL windows cover the entire screen, extending under notches
+and system bars. The OS expects you to take those into account when displaying
+content and SDL provides the function SDL_GetWindowSafeArea() so you know what
+area is available for interaction. Outside of the safe area can be potentially
+covered by system bars or used by OS gestures.
+
+
+Mouse / Touch events
+================================================================================
+
+In some case, SDL generates synthetic mouse (resp. touch) events for touch
+(resp. mouse) devices.
+To enable/disable this behavior, see SDL_hints.h:
+- SDL_HINT_TOUCH_MOUSE_EVENTS
+- SDL_HINT_MOUSE_TOUCH_EVENTS
+
+
+Misc
+================================================================================
+
+For some device, it appears to works better setting explicitly GL attributes
+before creating a window:
+  SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
+  SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
+  SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);
+
+
+Threads and the Java VM
+================================================================================
+
+For a quick tour on how Linux native threads interoperate with the Java VM, take
+a look here: https://developer.android.com/guide/practices/jni.html
+
+If you want to use threads in your SDL app, it's strongly recommended that you
+do so by creating them using SDL functions. This way, the required attach/detach
+handling is managed by SDL automagically. If you have threads created by other
+means and they make calls to SDL functions, make sure that you call
+Android_JNI_SetupThread() before doing anything else otherwise SDL will attach
+your thread automatically anyway (when you make an SDL call), but it'll never
+detach it.
+
+
+If you ever want to use JNI in a native thread (created by "SDL_CreateThread()"),
+it won't be able to find your java class and method because of the java class loader
+which is different for native threads, than for java threads (eg your "main()").
+
+the work-around is to find class/method, in you "main()" thread, and to use them
+in your native thread.
+
+see:
+https://developer.android.com/training/articles/perf-jni#faq:-why-didnt-findclass-find-my-class
+
+
+Using STL
+================================================================================
+
+You can use STL in your project by creating an Application.mk file in the jni
+folder and adding the following line:
+
+    APP_STL := c++_shared
+
+For more information go here:
+	https://developer.android.com/ndk/guides/cpp-support
+
+
+Using the emulator
+================================================================================
+
+There are some good tips and tricks for getting the most out of the
+emulator here: https://developer.android.com/tools/devices/emulator.html
+
+Especially useful is the info on setting up OpenGL ES 2.0 emulation.
+
+Notice that this software emulator is incredibly slow and needs a lot of disk space.
+Using a real device works better.
+
+
+Troubleshooting
+================================================================================
+
+You can see if adb can see any devices with the following command:
+
+    adb devices
+
+You can see the output of log messages on the default device with:
+
+    adb logcat
+
+You can push files to the device with:
+
+    adb push local_file remote_path_and_file
+
+You can push files to the SD Card at /sdcard, for example:
+
+    adb push moose.dat /sdcard/moose.dat
+
+You can see the files on the SD card with a shell command:
+
+    adb shell ls /sdcard/
+
+You can start a command shell on the default device with:
+
+    adb shell
+
+You can remove the library files of your project (and not the SDL lib files) with:
+
+    ndk-build clean
+
+You can do a build with the following command:
+
+    ndk-build
+
+You can see the complete command line that ndk-build is using by passing V=1 on the command line:
+
+    ndk-build V=1
+
+If your application crashes in native code, you can use ndk-stack to get a symbolic stack trace:
+	https://developer.android.com/ndk/guides/ndk-stack
+
+If you want to go through the process manually, you can use addr2line to convert the
+addresses in the stack trace to lines in your code.
+
+For example, if your crash looks like this:
+
+    I/DEBUG   (   31): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 400085d0
+    I/DEBUG   (   31):  r0 00000000  r1 00001000  r2 00000003  r3 400085d4
+    I/DEBUG   (   31):  r4 400085d0  r5 40008000  r6 afd41504  r7 436c6a7c
+    I/DEBUG   (   31):  r8 436c6b30  r9 435c6fb0  10 435c6f9c  fp 4168d82c
+    I/DEBUG   (   31):  ip 8346aff0  sp 436c6a60  lr afd1c8ff  pc afd1c902  cpsr 60000030
+    I/DEBUG   (   31):          #00  pc 0001c902  /system/lib/libc.so
+    I/DEBUG   (   31):          #01  pc 0001ccf6  /system/lib/libc.so
+    I/DEBUG   (   31):          #02  pc 000014bc  /data/data/org.libsdl.app/lib/libmain.so
+    I/DEBUG   (   31):          #03  pc 00001506  /data/data/org.libsdl.app/lib/libmain.so
+
+You can see that there's a crash in the C library being called from the main code.
+I run addr2line with the debug version of my code:
+
+    arm-eabi-addr2line -C -f -e obj/local/armeabi/libmain.so
+
+and then paste in the number after "pc" in the call stack, from the line that I care about:
+000014bc
+
+I get output from addr2line showing that it's in the quit function, in testspriteminimal.c, on line 23.
+
+You can add logging to your code to help show what's happening:
+
+    #include <android/log.h>
+
+    __android_log_print(ANDROID_LOG_INFO, "foo", "Something happened! x = %d", x);
+
+If you need to build without optimization turned on, you can create a file called
+"Application.mk" in the jni directory, with the following line in it:
+
+    APP_OPTIM := debug
+
+
+Memory debugging
+================================================================================
+
+The best (and slowest) way to debug memory issues on Android is valgrind.
+Valgrind has support for Android out of the box, just grab code using:
+
+    git clone https://sourceware.org/git/valgrind.git
+
+... and follow the instructions in the file `README.android` to build it.
+
+One thing I needed to do on macOS was change the path to the toolchain,
+and add ranlib to the environment variables:
+export RANLIB=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-ranlib
+
+Once valgrind is built, you can create a wrapper script to launch your
+application with it, changing org.libsdl.app to your package identifier:
+
+    --- start_valgrind_app -------------------
+    #!/system/bin/sh
+    export TMPDIR=/data/data/org.libsdl.app
+    exec /data/local/Inst/bin/valgrind --log-file=/sdcard/valgrind.log --error-limit=no $*
+    ------------------------------------------
+
+Then push it to the device:
+
+    adb push start_valgrind_app /data/local
+
+and make it executable:
+
+    adb shell chmod 755 /data/local/start_valgrind_app
+
+and tell Android to use the script to launch your application:
+
+    adb shell setprop wrap.org.libsdl.app "logwrapper /data/local/start_valgrind_app"
+
+If the setprop command says "could not set property", it's likely that
+your package name is too long and you should make it shorter by changing
+AndroidManifest.xml and the path to your class file in android-project/src
+
+You can then launch your application normally and waaaaaaaiiittt for it.
+You can monitor the startup process with the logcat command above, and
+when it's done (or even while it's running) you can grab the valgrind
+output file:
+
+    adb pull /sdcard/valgrind.log
+
+When you're done instrumenting with valgrind, you can disable the wrapper:
+
+    adb shell setprop wrap.org.libsdl.app ""
+
+
+Graphics debugging
+================================================================================
+
+If you are developing on a compatible Tegra-based tablet, NVidia provides
+Tegra Graphics Debugger at their website. Because SDL3 dynamically loads EGL
+and GLES libraries, you must follow their instructions for installing the
+interposer library on a rooted device. The non-rooted instructions are not
+compatible with applications that use SDL3 for video.
+
+The Tegra Graphics Debugger is available from NVidia here:
+https://developer.nvidia.com/tegra-graphics-debugger
+
+
+A note regarding the use of the "dirty rectangles" rendering technique
+================================================================================
+
+If your app uses a variation of the "dirty rectangles" rendering technique,
+where you only update a portion of the screen on each frame, you may notice a
+variety of visual glitches on Android, that are not present on other platforms.
+This is caused by SDL's use of EGL as the support system to handle OpenGL ES/ES2
+contexts, in particular the use of the eglSwapBuffers function. As stated in the
+documentation for the function "The contents of ancillary buffers are always
+undefined after calling eglSwapBuffers".
+
+
+Ending your application
+================================================================================
+
+Two legitimate ways:
+
+- return from your main() function. Java side will automatically terminate the
+Activity by calling Activity.finish().
+
+- Android OS can decide to terminate your application by calling onDestroy()
+(see Activity life cycle). Your application will receive an SDL_EVENT_QUIT you
+can handle to save things and quit.
+
+Don't call exit() as it stops the activity badly.
+
+NB: "Back button" can be handled as a SDL_EVENT_KEY_DOWN/UP events, with Keycode
+SDLK_AC_BACK, for any purpose.
+
+
+Known issues
+================================================================================
+
+- The number of buttons reported for each joystick is hardcoded to be 36, which
+is the current maximum number of buttons Android can report.
+
+
+Building the SDL tests
+================================================================================
+
+SDL's CMake build system can create APK's for the tests.
+It can build all tests with a single command without a dependency on gradle or Android Studio.
+The APK's are signed with a debug certificate.
+The only caveat is that the APK's support a single architecture.
+
+### Requirements
+- SDL source tree
+- CMake
+- ninja or make
+- Android Platform SDK
+- Android NDK
+- Android Build tools
+- Java JDK (version should be compatible with Android)
+- keytool (usually provided with the Java JDK), used for generating a debug certificate
+- zip
+
+### CMake configuration
+
+When configuring the CMake project, you need to use the Android NDK CMake toolchain, and pass the Android home path through `SDL_ANDROID_HOME`.
+```
+cmake .. -DCMAKE_TOOLCHAIN_FILE=<path/to/android.toolchain.cmake> -DANDROID_ABI=<android-abi> -DSDL_ANDROID_HOME=<path-to-android-sdk-home> -DANDROID_PLATFORM=23 -DSDL_TESTS=ON
+```
+
+Remarks:
+- `android.toolchain.cmake` can usually be found at `$ANDROID_HOME/ndk/x.y.z/build/cmake/android.toolchain.cmake`
+- `ANDROID_ABI` should be one of `arm64-v8a`, `armeabi-v7a`, `x86` or `x86_64`.
+- When CMake is unable to find required paths, use `cmake-gui` to override required `SDL_ANDROID_` CMake cache variables.
+
+### Building the APK's
+
+For the `testsprite` executable, the `testsprite-apk` target will build the associated APK:
+```
+cmake --build . --target testsprite-apk
+```
+
+APK's of all tests can be built with the `sdl-test-apks` target:
+```
+cmake --build . --target sdl-test-apks
+```
+
+### Installation/removal of the tests
+
+`testsprite.apk` APK can be installed on your Android machine using the `install-testsprite` target:
+```
+cmake --build . --target install-testsprite
+```
+
+APK's of all tests can be installed with the `install-sdl-test-apks` target:
+```
+cmake --build . --target install-sdl-test-apks
+```
+
+All SDL tests can be uninstalled with the `uninstall-sdl-test-apks` target:
+```
+cmake --build . --target uninstall-sdl-test-apks
+```
+
+### Starting the tests
+
+After installation, the tests can be started using the Android Launcher GUI.
+Alternatively, they can also be started using CMake targets.
+
+This command will start the testsprite executable:
+```
+cmake --build . --target start-testsprite
+```
+
+There is also a convenience target which will build, install and start a test:
+```
+cmake --build . --target build-install-start-testsprite
+```
+
+Not all tests provide a GUI. For those, you can use `adb logcat` to read the output.

vendor/sdl-3.2.10/docs/README-bsd.md

@@ -0,0 +1,6 @@
+# FreeBSD / OpenBSD / NetBSD
+
+SDL is fully supported on BSD platforms, and is built using [CMake](README-cmake.md).
+
+If you want to run on the console, you can take a look at [KMSDRM support on BSD](README-kmsbsd.md)
+

vendor/sdl-3.2.10/docs/README-cmake.md

@@ -0,0 +1,364 @@
+# CMake
+
+[www.cmake.org](https://www.cmake.org/)
+
+The CMake build system is supported with the following environments:
+
+* Android
+* Emscripten
+* FreeBSD
+* Haiku
+* Linux
+* macOS, iOS, tvOS, and visionOS with support for XCode
+* Microsoft Visual Studio
+* MinGW and Msys
+* NetBSD
+* Nintendo 3DS
+* PlayStation 2
+* PlayStation Portable
+* PlayStation Vita
+* RISC OS
+
+## Building SDL on Windows
+
+Assuming you're in the SDL source directory, building and installing to C:/SDL can be done with:
+```sh
+cmake -S . -B build
+cmake --build build --config RelWithDebInfo
+cmake --install build --config RelWithDebInfo --prefix C:/SDL
+```
+
+## Building SDL on UNIX
+
+SDL will build with very few dependencies, but for full functionality you should install the packages detailed in [README-linux.md](README-linux.md).
+
+Assuming you're in the SDL source directory, building and installing to /usr/local can be done with:
+```sh
+cmake -S . -B build
+cmake --build build
+sudo cmake --install build --prefix /usr/local
+```
+
+## Building SDL on macOS
+
+Assuming you're in the SDL source directory, building and installing to ~/SDL can be done with:
+```sh
+cmake -S . -B build -DSDL_FRAMEWORK=ON -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
+cmake --build build
+cmake --install build --prefix ~/SDL
+```
+
+## Building SDL tests
+
+You can build the SDL test programs by adding `-DSDL_TESTS=ON` to the first cmake command above:
+```sh
+cmake -S . -B build -DSDL_TESTS=ON
+```
+and then building normally. The test programs will be built and can be run from `build/test/`.
+
+## Building SDL examples
+
+You can build the SDL example programs by adding `-DSDL_EXAMPLES=ON` to the first cmake command above:
+```sh
+cmake -S . -B build -DSDL_EXAMPLES=ON
+```
+and then building normally. The example programs will be built and can be run from `build/examples/`.
+
+## Including SDL in your project
+
+SDL can be included in your project in 2 major ways:
+- using a system SDL library, provided by your (UNIX) distribution or a package manager
+- using a vendored SDL library: this is SDL copied or symlinked in a subfolder.
+
+The following CMake script supports both, depending on the value of `MYGAME_VENDORED`.
+
+```cmake
+cmake_minimum_required(VERSION 3.5)
+project(mygame)
+
+# Create an option to switch between a system sdl library and a vendored SDL library
+option(MYGAME_VENDORED "Use vendored libraries" OFF)
+
+if(MYGAME_VENDORED)
+    # This assumes you have added SDL as a submodule in vendored/SDL
+    add_subdirectory(vendored/SDL EXCLUDE_FROM_ALL)
+else()
+    # 1. Look for a SDL3 package,
+    # 2. look for the SDL3-shared component, and
+    # 3. fail if the shared component cannot be found.
+    find_package(SDL3 REQUIRED CONFIG REQUIRED COMPONENTS SDL3-shared)
+endif()
+
+# Create your game executable target as usual
+add_executable(mygame WIN32 mygame.c)
+
+# Link to the actual SDL3 library.
+target_link_libraries(mygame PRIVATE SDL3::SDL3)
+```
+
+### A system SDL library
+
+For CMake to find SDL, it must be installed in [a default location CMake is looking for](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure).
+
+The following components are available, to be used as an argument of `find_package`.
+
+| Component name | Description                                                                                                                                                      |
+|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| SDL3-shared    | The SDL3 shared library, available through the `SDL3::SDL3-shared` target                                                                                        |
+| SDL3-static    | The SDL3 static library, available through the `SDL3::SDL3-static` target                                                                                        |
+| SDL3_test      | The SDL3_test static library, available through the `SDL3::SDL3_test` target                                                                                     |
+| SDL3           | The SDL3 library, available through the `SDL3::SDL3` target. This is an alias of `SDL3::SDL3-shared` or `SDL3::SDL3-static`. This component is always available. |
+| Headers        | The SDL3 headers, available through the `SDL3::Headers` target. This component is always available.                                                              |
+
+SDL's CMake support guarantees a `SDL3::SDL3` target.
+Neither `SDL3::SDL3-shared` nor `SDL3::SDL3-static` are guaranteed to exist.
+
+### Using a vendored SDL
+
+This only requires a copy of SDL in a subdirectory + `add_subdirectory`.
+Alternatively, use [FetchContent](https://cmake.org/cmake/help/latest/module/FetchContent.html).
+Depending on the configuration, the same targets as a system SDL package are available.
+
+## CMake configuration options
+
+### Build optimized library
+
+By default, CMake provides 4 build types: `Debug`, `Release`, `RelWithDebInfo` and `MinSizeRel`.
+The main difference(s) between these are the optimization options and the generation of debug info.
+To configure SDL as an optimized `Release` library, configure SDL with:
+```sh
+cmake ~/SDL -DCMAKE_BUILD_TYPE=Release
+```
+To build it, run:
+```sh
+cmake --build . --config Release
+```
+
+### Shared or static
+
+By default, only a dynamic (=shared) SDL library is built and installed.
+The options `-DSDL_SHARED=` and `-DSDL_STATIC=` accept boolean values to change this.
+
+Exceptions exist:
+- some platforms don't support dynamic libraries, so only `-DSDL_STATIC=ON` makes sense.
+- a static Apple framework is not supported
+
+### Man pages
+
+Configuring with `-DSDL_INSTALL_DOCS=TRUE` installs man pages.
+
+We recommend package managers of unix distributions to install SDL3's man pages.
+This adds an extra build-time dependency on Perl.
+
+### Pass custom compile options to the compiler
+
+- Use [`CMAKE_<LANG>_FLAGS`](https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html) to pass extra
+flags to the compiler.
+- Use [`CMAKE_EXE_LINKER_FLAGS`](https://cmake.org/cmake/help/latest/variable/CMAKE_EXE_LINKER_FLAGS.html) to pass extra option to the linker for executables.
+- Use [`CMAKE_SHARED_LINKER_FLAGS`](https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LINKER_FLAGS.html) to pass extra options to the linker for shared libraries.
+
+#### Examples
+
+- build a SDL library optimized for (more) modern x64 microprocessor architectures.
+
+  With gcc or clang:
+    ```sh
+    cmake ~/sdl -DCMAKE_C_FLAGS="-march=x86-64-v3" -DCMAKE_CXX_FLAGS="-march=x86-64-v3"
+    ```
+  With Visual C:
+    ```sh
+    cmake .. -DCMAKE_C_FLAGS="/ARCH:AVX2" -DCMAKE_CXX_FLAGS="/ARCH:AVX2"
+    ```
+
+### Apple
+
+CMake documentation for cross building for Apple:
+[link](https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-ios-tvos-visionos-or-watchos)
+
+#### iOS/tvOS/visionOS
+
+CMake 3.14+ natively includes support for iOS, tvOS and watchOS. visionOS requires CMake 3.28+.
+SDL binaries may be built using Xcode or Make, possibly among other build-systems.
+
+When using a compatible version of CMake, it should be possible to:
+
+- build SDL dylibs, both static and dynamic dylibs
+- build SDL frameworks, only shared
+- build SDL test apps
+
+#### Frameworks
+
+Configure with `-DSDL_FRAMEWORK=ON` to build a SDL framework instead of a dylib shared library.
+Only shared frameworks are supported, no static ones.
+
+#### Platforms
+
+Use `-DCMAKE_SYSTEM_NAME=<value>` to configure the platform. CMake can target only one platform at a time.
+
+| Apple platform  | `CMAKE_SYSTEM_NAME` value |
+|-----------------|---------------------------|
+| macOS (MacOS X) | `Darwin`                  |
+| iOS             | `iOS`                     |
+| tvOS            | `tvOS`                    |
+| visionOS        | `visionOS`                |
+| watchOS         | `watchOS`                 |
+
+#### Universal binaries
+
+A universal binaries, can be built by configuring CMake with
+`-DCMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures>`.
+
+For example `-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"` will build binaries that run on both Intel cpus and Apple silicon.
+
+SDL supports following Apple architectures:
+
+| Platform                   | `CMAKE_OSX_ARCHITECTURES` value |
+|----------------------------|---------------------------------|
+| 64-bit ARM (Apple Silicon) | `arm64`                         |
+| x86_64                     | `x86_64`                        |
+| 32-bit ARM                 | `armv7s`                        |
+
+CMake documentation: [link](https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_ARCHITECTURES.html)
+
+#### Simulators and/or non-default macOS platform SDK
+
+Use `-DCMAKE_OSX_SYSROOT=<value>` to configure a different platform SDK.
+The value can be either the name of the SDK, or a full path to the sdk (e.g. `/full/path/to/iPhoneOS.sdk`).
+
+| SDK                  | `CMAKE_OSX_SYSROOT` value |
+|----------------------|---------------------------|
+| iphone               | `iphoneos`                |
+| iphonesimulator      | `iphonesimulator`         |
+| appleTV              | `appletvos`               |
+| appleTV simulator    | `appletvsimulator`        |
+| visionOS             | `xr`                      |
+| visionOS simulator   | `xrsimulator`             |
+| watchOS              | `watchos`                 |
+| watchOS simulator    | `watchsimulator`          |
+
+Append with a version number to target a specific SDK revision: e.g. `iphoneos12.4`, `appletvos12.4`.
+
+CMake documentation: [link](https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_SYSROOT.html)
+
+#### Examples
+
+- for macOS, building a dylib and/or static library for x86_64 and arm64:
+
+    ```bash
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" -DCMAKE_OSX_DEPLOYMENT_TARGET=10.11
+
+- for macOS, building an universal framework for x86_64 and arm64:
+
+    ```bash
+    cmake ~/sdl -DSDL_FRAMEWORK=ON -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" -DCMAKE_OSX_DEPLOYMENT_TARGET=10.11
+
+- for iOS-Simulator, using the latest, installed SDK:
+
+    ```bash
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64 -DCMAKE_OSX_DEPLOYMENT_TARGET=9.0
+    ```
+
+- for iOS-Device, using the latest, installed SDK, 64-bit only
+
+    ```bash
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_OSX_DEPLOYMENT_TARGET=9.0
+    ```
+
+- for iOS-Device, using the latest, installed SDK, mixed 32/64 bit
+
+    ```cmake
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s" -DCMAKE_OSX_DEPLOYMENT_TARGET=9.0
+    ```
+
+- for iOS-Device, using a specific SDK revision (iOS 12.4, in this example):
+
+    ```cmake
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64
+    ```
+
+- for iOS-Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
+
+    ```cmake
+    cmake ~/sdl -DSDL_TESTS=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64 -DCMAKE_OSX_DEPLOYMENT_TARGET=9.0
+    ```
+
+- for tvOS-Simulator, using the latest, installed SDK:
+
+    ```cmake
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=tvOS -DCMAKE_OSX_SYSROOT=appletvsimulator -DCMAKE_OSX_ARCHITECTURES=x86_64 -DCMAKE_OSX_DEPLOYMENT_TARGET=9.0
+    ```
+
+- for tvOS-Device, using the latest, installed SDK:
+
+    ```cmake
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=tvOS -DCMAKE_OSX_SYSROOT=appletvos -DCMAKE_OSX_ARCHITECTURES=arm64` -DCMAKE_OSX_DEPLOYMENT_TARGET=9.0
+    ```
+
+- for QNX/aarch64, using the latest, installed SDK:
+
+    ```cmake
+    cmake ~/sdl -DCMAKE_TOOLCHAIN_FILE=~/sdl/build-scripts/cmake-toolchain-qnx-aarch64le.cmake -DSDL_X11=0
+    ```
+
+## SDL-specific CMake options
+
+SDL can be customized through (platform-specific) CMake options.
+The following table shows generic options that are available for most platforms.
+At the end of SDL CMake configuration, a table shows all CMake options along with its detected value.
+
+| CMake option                  | Valid values | Description                                                                                         |
+|-------------------------------|--------------|-----------------------------------------------------------------------------------------------------|
+| `-DSDL_SHARED=`               | `ON`/`OFF`   | Build SDL shared library (not all platforms support this) (`libSDL3.so`/`libSDL3.dylib`/`SDL3.dll`) |
+| `-DSDL_STATIC=`               | `ON`/`OFF`   | Build SDL static library (`libSDL3.a`/`SDL3-static.lib`)                                            |
+| `-DSDL_TEST_LIBRARY=`         | `ON`/`OFF`   | Build SDL test library (`libSDL3_test.a`/`SDL3_test.lib`)                                           |
+| `-DSDL_TESTS=`                | `ON`/`OFF`   | Build SDL test programs (**requires `-DSDL_TEST_LIBRARY=ON`**)                                      |
+| `-DSDL_DISABLE_INSTALL=`      | `ON`/`OFF`   | Don't create a SDL install target                                                                   |
+| `-DSDL_DISABLE_INSTALL_DOCS=` | `ON`/`OFF`   | Don't install the SDL documentation                                                                 |
+| `-DSDL_INSTALL_TESTS=`        | `ON`/`OFF`   | Install the SDL test programs                                                                       |
+
+### Incompatibilities
+
+#### `SDL_LIBC=OFF` and sanitizers
+
+Building with `-DSDL_LIBC=OFF` will make it impossible to use the sanitizer, such as the address sanitizer.
+Configure your project with `-DSDL_LIBC=ON` to make use of sanitizers.
+
+## CMake FAQ
+
+### CMake fails to build without X11 or Wayland support
+
+Install the required system packages prior to running CMake.
+See [README-linux](linux#build-dependencies) for the list of dependencies on Linux.
+Other unix operationg systems should provide similar packages.
+
+If you **really** don't need to show windows, add `-DSDL_UNIX_CONSOLE_BUILD=ON` to the CMake configure command.
+
+### How do I copy a SDL3 dynamic library to another location?
+
+Use [CMake generator expressions](https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#target-dependent-expressions).
+Generator expressions support multiple configurations, and are evaluated during build system generation time.
+
+On Windows, the following example copies `SDL3.dll` to the directory where `mygame.exe` is built.
+```cmake
+if(WIN32)
+    add_custom_command(
+        TARGET mygame POST_BUILD
+        COMMAND "${CMAKE_COMMAND}" -E copy $<TARGET_FILE:SDL3::SDL3-shared> $<TARGET_FILE_DIR:mygame>
+        VERBATIM
+    )
+endif()
+```
+On Unix systems, `$<TARGET_FILE:...>` will refer to the dynamic library (or framework),
+and you might need to use `$<TARGET_SONAME_FILE:tgt>` instead.
+
+Most often, you can avoid copying libraries by configuring your project with absolute [`CMAKE_LIBRARY_OUTPUT_DIRECTORY`](https://cmake.org/cmake/help/latest/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY.html)
+and [`CMAKE_RUNTIME_OUTPUT_DIRECTORY`](https://cmake.org/cmake/help/latest/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY.html) paths.
+When using a multi-config generator (such as Visual Studio or Ninja Multi-Config), eventually add `/$<CONFIG>` to both paths.
+
+### Linking against a static SDL library fails due to relocation errors
+
+On unix platforms, all code that ends up in shared libraries needs to be built as relocatable (=position independent) code.
+However, by default CMake builds static libraries as non-relocatable.
+Configuring SDL with `-DCMAKE_POSITION_INDEPENDENT_CODE=ON` will result in a static `libSDL3.a` library
+which you can link against to create a shared library.
+

vendor/sdl-3.2.10/docs/README-contributing.md

@@ -0,0 +1,107 @@
+# Contributing to SDL
+
+We appreciate your interest in contributing to SDL, this document will describe how to report bugs, contribute code or ideas or edit documentation.
+
+**Table Of Contents**
+
+-   [Filing a GitHub issue](#filing-a-github-issue)
+    -   [Reporting a bug](#reporting-a-bug)
+    -   [Suggesting enhancements](#suggesting-enhancements)
+-   [Contributing code](#contributing-code)
+    -   [Forking the project](#forking-the-project)
+    -   [Following the style guide](#following-the-style-guide)
+    -   [Running the tests](#running-the-tests)
+    -   [Opening a pull request](#opening-a-pull-request)
+    -   [Continuous integration](#continuous-integration)
+-   [Contributing to the documentation](#contributing-to-the-documentation)
+    -   [Editing a function documentation](#editing-a-function-documentation)
+    -   [Editing the wiki](#editing-the-wiki)
+
+## Filing a GitHub issue
+
+### Reporting a bug
+
+If you think you have found a bug and would like to report it, here are the steps you should take:
+
+-   Before opening a new issue, ensure your bug has not already been reported on the [GitHub Issues page](https://github.com/libsdl-org/SDL/issues).
+-   On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
+-   Include details about your environment, such as your Operating System and SDL version.
+-   If possible, provide a small example that reproduces your bug.
+
+### Suggesting enhancements
+
+If you want to suggest changes for the project, here are the steps you should take:
+
+-   Check if the suggestion has already been made on:
+    -   the [issue tracker](https://github.com/libsdl-org/SDL/issues);
+    -   the [discourse forum](https://discourse.libsdl.org/);
+    -   or if a [pull request](https://github.com/libsdl-org/SDL/pulls) already exists.
+-   On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
+-   Describe what change you would like to happen.
+
+## Contributing code
+
+This section will cover how the process of forking the project, making a change and opening a pull request.
+
+### Forking the project
+
+The first step consists in making a fork of the project, this is only necessary for the first contribution.
+
+Head over to https://github.com/libsdl-org/SDL and click on the `Fork` button in the top right corner of your screen, you may leave the fields unchanged and click `Create Fork`.
+
+You will be redirected to your fork of the repository, click the green `Code` button and copy the git clone link.
+
+If you had already forked the repository, you may update it from the web page using the `Fetch upstream` button.
+
+### Following the style guide
+
+Code formatting is done using a custom `.clang-format` file, you can learn more about how to run it [here](https://clang.llvm.org/docs/ClangFormat.html).
+
+Some legacy code may not be formatted, so please avoid formatting the whole file at once and only format around your changes.
+
+For your commit message to be properly displayed on GitHub, it should contain:
+
+-   A short description of the commit of 50 characters or less on the first line.
+-   If necessary, add a blank line followed by a long description, each line should be 72 characters or less.
+
+For example:
+
+```
+Fix crash in SDL_FooBar.
+
+This addresses the issue #123456 by making sure Foo was successful
+before calling Bar.
+```
+
+### Running the tests
+
+Tests allow you to verify if your changes did not break any behaviour, here are the steps to follow:
+
+-   Before pushing, run the `testautomation` suite on your machine, there should be no more failing tests after your change than before.
+-   After pushing to your fork, Continuous Integration (GitHub Actions) will ensure compilation and tests still pass on other systems.
+
+### Opening a pull request
+
+-   Head over to your fork's GitHub page.
+-   Click on the `Contribute` button and `Open Pull Request`.
+-   Fill out the pull request template.
+-   If any changes are requested, you can add new commits to your fork and they will be automatically added to the pull request.
+
+### Continuous integration
+
+For each push and/or pull request, GitHub Actions will try to build SDL and the test suite on most supported platforms.
+
+Its behaviour can be influenced slightly by including SDL-specific tags in your commit message:
+- `[sdl-ci-filter GLOB]` limits the platforms for which to run ci.
+- `[sdl-ci-artifacts]` forces SDL artifacts, which can then be downloaded from the summary page.
+- `[sdl-ci-trackmem-symbol-names]` makes sure the final report generated by `--trackmem` contains symbol names.
+
+## Contributing to the documentation
+
+### Editing a function documentation
+
+The wiki documentation for API functions is synchronised from the headers' doxygen comments. As such, all modifications to syntax; function parameters; return value; version; related functions should be done in the header directly.
+
+### Editing the wiki
+
+Other changes to the wiki should done directly from https://wiki.libsdl.org/  ... Just click the "edit" link at the bottom of any page!

vendor/sdl-3.2.10/docs/README-documentation-rules.md

@@ -0,0 +1,410 @@
+# Rules for documentation
+
+These are the rules for the care and feeding of wikiheaders.pl.
+
+
+## No style guide
+
+When adding or editing documentation, we don't (currently) have a style guide
+for what it should read like, so try to make it consistent with the rest of
+the existing text. It generally should read more like technical reference
+manuals and not sound conversational in tone.
+
+Most of these rules are about how to make sure the documentation works on
+a _technical_ level, as scripts need to parse it, and there are a few simple
+rules we need to obey to cooperate with those scripts.
+
+## The wiki and headers share the same text.
+
+There is a massive Perl script (`build-scripts/wikiheaders.pl`, hereafter
+referred to as "wikiheaders") that can read both the wiki and the public
+headers, and move changes in one across to the other.
+
+If you prefer to use the wiki, go ahead and edit there. If you prefer to use
+your own text editor, or command line tools to batch-process text, etc, you
+can [clone the wiki as a git repo](https://github.com/libsdl-org/sdlwiki) and
+work locally.
+
+
+## Don't taunt wikiheaders.
+
+The script isn't magic; it's a massive pile of Regular Expressions and not
+a full C or markdown parser. While it isn't _fragile_, if you try to do clever
+things, you might confuse it. This is to the benefit of documentation, though,
+where we would rather you not do surprising things.
+
+
+## We _sort of_ write in Doxygen format.
+
+To document a symbol, we use something that looks like Doxygen (and Javadoc)
+standard comment format:
+
+```c
+/**
+ * This is a function that does something.
+ *
+ * It can be used for frozzling bobbles. Be aware that the Frozulator module
+ * _must_ be initialized before calling this.
+ *
+ * \param frozzlevel The amount of frozzling to perform.
+ * \param color What color bobble to frozzle. 0 is red, 1 is green.
+ * \returns the number of bobbles that were actually frozzled, -1 on error.
+ *
+ * \threadsafety Do not call this from two threads at once, or the bobbles
+ *               won't all frozzle correctly!
+ *
+ * \since This function is available since SDL 7.3.1.
+ *
+ * \sa SDL_DoSomethingElse
+ */
+extern SDL_DECLSPEC int SDLCALL SDL_DoSomething(int frozzlevel, int color);
+```
+
+Note the `/**` at the start of the comment. That's a "Doxygen-style" comment,
+and wikiheaders will treat this differently than a comment with one `*`, as
+this signifies that this is not just a comment, but _documentation_.
+
+These comments _must_ start in the first column of the line, or wikiheaders
+will ignore them, even with the "/**" start (we should improve the script
+someday to handle this, but currently this is a requirement).
+
+We do _not_ parse every magic Doxygen tag, and we don't parse them in `@param`
+format. The goal here was to mostly coexist with people that might want
+to run Doxygen on the SDL headers, not to build Doxygen from scratch. That
+being said, compatibility with Doxygen is not a hard requirement here.
+
+wikiheaders uses these specific tags to turn this comment into a (hopefully)
+well-formatted wiki page, and also can generate manpages and books in LaTeX
+format from it!
+
+Text markup in the headers is _always_ done in Markdown format! But less is
+more: try not to markup text more than necessary.
+
+
+## Doxygen tags we support:
+
+- `\brief one-line description` (Not required, and wikiheaders will remove tag).
+- `\param varname description` (One for each function/macro parameter)
+- `\returns description` (One for each function, don't use on `void` returns).
+- `\sa` (each of these get tucked into a "See Also" section on the wiki)
+- `\since This function is available since SDL 3.0.0.` (one per Doxygen comment)
+- `\threadsafety description` (one per function/macro).
+- `\deprecated description` (one per symbol, if symbol is deprecated!)
+
+Other Doxygen things might exist in the headers, but they aren't understood
+by wikiheaders.
+
+
+## Use Markdown.
+
+The wiki also supports MediaWiki format, but we are transitioning away from it.
+The headers always use Markdown. If you're editing the wiki from a git clone,
+just make .md files and the wiki will know what to do with them.
+
+
+## Most things in the headers can be documented.
+
+wikiheaders understands functions, typedefs, structs/unions/enums, `#defines`
+... basically most of what makes up a C header. Just slap a Doxygen-style
+comment in front of most things and it'll work.
+
+
+## Defines right below typedefs and functions bind.
+
+Any `#define` directly below a function or non-struct/union/enum typedef is
+considered part of that declaration. This happens to work well with how our
+headers work, as these defines tend to be bitflags and such that are related
+to that symbol.
+
+wikiheaders will include those defines in the syntax section of the wiki
+page, and generate stub pages for each define that simply says "please refer
+to (The Actual Symbol You Care About)" with a link. It will also pull in
+any blank lines and most preprocessor directives for the syntax text, too.
+
+Sometimes an unrelated define, by itself, just happens to be right below one
+of these symbols in the header. The easiest way to deal with this is either
+to document that define with a Doxygen-style comment, if it makes sense to do
+so, or just add a normal C comment right above it if not, so wikiheaders
+doesn't bind it to the previous symbol.
+
+
+## Don't document the `SDL_test*.h` headers.
+
+These are in the public headers but they aren't really considered public APIs.
+They live in a separate library that doesn't, or at least probably shouldn't,
+ship to end users. As such, we don't want it documented on the wiki.
+
+For now, we do this by not having any Doxygen-style comments in these files.
+Please keep it that way! If you want to document these headers, just don't
+use the magic two-`*` comment.
+
+
+## The first line is the summary.
+
+The first line of a piece of documentation is meant to be a succinct
+description. This is what Doxygen would call the `\brief` tag. wikiheaders
+will split this text out until the first period (end of sentence!), and when
+word wrapping, shuffle the overflow into a new paragraph below it.
+
+
+## Split paragraphs with a blank line.
+
+And don't indent them at all (indenting in Markdown is treated as preformatted
+text).
+
+wikiheaders will wordwrap header comments so they fit in 80 columns, so if you
+don't leave a blank line between paragraphs, they will smush into a single
+block of text when wordwrapping.
+
+
+## Don't worry about word wrapping.
+
+If you don't word-wrap your header edits perfectly (and you won't, I promise),
+wikiheaders will send your change to the wiki, and then to make things match,
+send it right back to the headers with correct word wrapping. Since this
+happens right after you push your changes, you might as well just write
+however you like and assume the system will clean it up for you.
+
+
+## Things that start with `SDL_` will automatically become wiki links.
+
+wikiheaders knows to turn these into links to other pages, so if you reference
+an SDL symbol in the header documentation, you don't need to link to it.
+You can optionally wrap the symbol in backticks, and wikiheaders will know to
+link the backticked thing. It will not generate links in three-backtick
+code/preformatted blocks.
+
+
+## URLs will automatically become links.
+
+You can use Markdown's `[link markup format](https://example.com/)`, but
+sometimes it's clearer to list bare URLs; the URL will be visible on the
+wiki page, but also clickable to follow the link. This is up to your judgment
+on a case-by-case basis.
+
+
+## Hide stuff from wikiheaders.
+
+If all else fails, you can block off pieces of the header with this
+magic line (whitespace is ignored):
+
+```c
+#ifndef SDL_WIKI_DOCUMENTATION_SECTION
+```
+
+Everything between this line and the next `#endif` will just be skipped by
+wikiheaders. Note that wikiheaders is not a C preprocessor! Don't try to
+nest conditionals or use `!defined`.
+
+Just block off sections if you need to. And: you almost never need to.
+
+
+## Hide stuff from the compiler.
+
+If you need to put something that's only of interest to wikiheaders, the
+convention is to put it in a block like this:
+
+```c
+#ifdef SDL_WIKI_DOCUMENTATION_SECTION
+```
+
+Generally this is used when there's a collection of preprocessor conditionals
+to define the same symbol differently in different circumstances. You put
+that symbol in this block with some reasonable generic version _and the
+Doxygen-style comment_. Because wikiheaders doesn't care about this
+preprocessor magic, and the C compiler can be as fancy as it wants, this is
+strictly a useful convention.
+
+
+## Struct/union/enum typedefs must have the name on the first line.
+
+This is because wikiheaders is not a full C parser. Don't write this:
+
+```c
+typedef struct
+{
+    int a;
+    int b;
+} SDL_MyStruct;
+```
+
+...make sure the name is at the start, too:
+
+```c
+typedef struct SDL_MyStruct
+{
+    int a;
+    int b;
+} SDL_MyStruct;
+```
+
+wikiheaders will complain loudly if you don't do this, and exit with an
+error message.
+
+
+## Don't repeat type names in `\param` and `\returns` sections.
+
+Wikiheaders will explicitly mention the datatype for each parameter and the
+return value, linking to the datatype's wikipage. Users reading the headers
+can see the types in the function signature right below the documentation
+comment. So don't mention the type a second time in the documentation if
+possible. It looks cluttered and repetitive to do so.
+
+
+## Code examples go in the wiki.
+
+We don't want the headers cluttered up with code examples. These live on the
+wiki pages, and wikiheaders knows to not bridge them back to the headers.
+
+Put them in a `## Code Examples` section, and make sure to wrap them in a
+three-backtick-c section for formatting purposes. Only write code in C,
+please.
+
+
+## Do you _need_ a code example?
+
+Most code examples aren't actually useful. If your code example is just
+`SDL_CreateWindow("Hello SDL", 640, 480, 0);` then just delete it; if all
+you're showing is how to call a function in C, it's not a useful code example.
+Not all functions need an example. One with complex setup or usage details
+might, though!
+
+
+## Code examples are compiled by GitHub Actions.
+
+On each change to the wiki, there is a script that pulls out all the code
+examples into discrete C files and attempts to compile them, and complains
+if they don't work.
+
+
+## Unrecognized sections are left alone in the wiki.
+
+A wiki section that starts with `## Section Name` (or `== Section Name ==` in
+MediaWiki format) that isn't one of the recognized names will be left alone
+by wikiheaders. Recognized sections might get overwritten with new content
+from the headers, but the wiki file will not have other sections cleaned out
+(this is how Code Examples remain wiki only, for example). You can use this
+to add Wiki-specific text, or stuff that doesn't make sense in a header, or
+would merely clutter it up.
+
+A possibly-incomplete list of sections that will be overwritten by changes
+to the headers:
+
+- The page title line, and the "brief" one-sentence description section.
+- "Deprecated"
+- "Header File"
+- "Syntax"
+- "Function Parameters"
+- "Macro Parameters"
+- "Fields"
+- "Values"
+- "Return Value"
+- "Remarks"
+- "Thread Safety"
+- "Version"
+- "See Also"
+
+
+## It's okay to repeat yourself.
+
+Each individual piece of documentation becomes a separate page on the wiki, so
+small repeated details can just exist in different pieces of documentation. If
+it's complicated, it's not unreasonable to say "Please refer to
+SDL_SomeOtherFunction for more details" ... wiki users can click right
+through, header users can search for the function name.
+
+
+## The docs directory is bridged to the wiki, too.
+
+You might be reading this document on the wiki! Any `README-*.md` files in
+the docs directory are bridged to the wiki, so `docs/README-linux.md` lands
+at https://wiki.libsdl.org/SDL3/README/linux ...these are just copied directly
+without any further processing by wikiheaders, and changes go in both
+directions.
+
+
+## The wiki can have its own pages, too.
+
+If a page name isn't a symbol that wikiheaders sees in the headers, or a
+README in the source's `docs` directory, or a few other exceptions, it'll
+assume it's an unrelated wiki page and leave it alone. So feel free to
+write any wiki-only pages that make sense and not worry about it junking
+up the headers!
+
+
+## Wiki categories are (mostly) managed automatically.
+
+The wiki will see this pattern as the last thing on a page and treat it as a
+list of categories that page belongs to:
+
+```
+----
+[CategoryStuff](CategoryStuff), [CategoryWhatever](CategoryWhatever)
+```
+
+You can use this to simply tag a page as part of a category, and the user can
+click directly to see other pages in that category. The wiki will
+automatically manage a `Category*` pages that list any tagged pages.
+
+You _should not_ add tags to the public headers. They don't mean anything
+there. wikiheaders will add a few tags that make sense when generating wiki
+content from the header files, and it will preserve other tags already present
+on the page, so if you want to add extra categories to something, tag it on
+the wiki itself.
+
+The wiki uses some magic HTML comment tags to decide how to list items on
+Category pages and let other content live on the page as well. You can
+see an example of this in action at:
+
+https://raw.githubusercontent.com/libsdl-org/sdlwiki/main/SDL3/CategoryEvents.md
+
+
+## Categorizing the headers.
+
+To put a symbol in a specific category, we use three approaches in SDL:
+
+- Things in the `SDL_test*.h` headers aren't categorized at all (and you
+  shouldn't document them!)
+- Most files are categorized by header name: we strip off the leading `SDL_`
+  and capitalize the first letter of what's left. So everything in SDL_audio.h
+  is in the "Audio" category, everything in SDL_video.h is in the "Video"
+  category, etc.
+- If wikiheaders sees a comment like this on a line by itself...
+  ```c
+  /* WIKI CATEGORY: Blah */
+  ```
+  ...then all symbols below that will land in the "Blah" category. We use this
+  at the top of a few headers where the simple
+  chop-off-SDL_-and-captialize-the-first-letter trick doesn't work well, but
+  one could theoretically use this for headers that have some overlap in
+  category.
+
+
+## Category documentation lives in headers.
+
+To document a category (text that lives before the item lists on a wiki
+category page), you have to follow a simple rule:
+
+The _first_ Doxygen-style comment in a header must start with:
+
+```
+/**
+ * # CategoryABC
+```
+
+If these conditions aren't met, wikiheaders will assume that documentation
+belongs to whatever is below it instead of the Category.
+
+The text of this comment will be added to the appropriate wiki Category page,
+at the top, replacing everything in the file until it sees a line that starts
+with an HTML comment (`<!--`), or a line that starts with `----`. Everything
+after that in the wiki file will be preserved.
+
+Likewise, when bridging _back_ to the headers, if wikiheaders sees one of
+these comments, it'll copy the top section of the Category page back into the
+comment.
+
+Beyond stripping the initial ` * ` portion off each line, these comments are
+treated as pure Markdown. They don't support any Doxygen tags like `\sa` or
+`\since`.
+

vendor/sdl-3.2.10/docs/README-dynapi.md

@@ -0,0 +1,138 @@
+# Dynamic API
+
+Originally posted on Ryan's Google+ account.
+
+Background:
+
+- The Steam Runtime has (at least in theory) a really kick-ass build of SDL,
+  but developers are shipping their own SDL with individual Steam games.
+  These games might stop getting updates, but a newer SDL might be needed later.
+  Certainly we'll always be fixing bugs in SDL, even if a new video target isn't
+  ever needed, and these fixes won't make it to a game shipping its own SDL.
+- Even if we replace the SDL in those games with a compatible one, that is to
+  say, edit a developer's Steam depot (yuck!), there are developers that are
+  statically linking SDL that we can't do this for. We can't even force the
+  dynamic loader to ignore their SDL in this case, of course.
+- If you don't ship an SDL with the game in some form, people that disabled the
+  Steam Runtime, or just tried to run the game from the command line instead of
+  Steam might find themselves unable to run the game, due to a missing dependency.
+- If you want to ship on non-Steam platforms like GOG or Humble Bundle, or target
+  generic Linux boxes that may or may not have SDL installed, you have to ship
+  the library or risk a total failure to launch. So now, you might have to have
+  a non-Steam build plus a Steam build (that is, one with and one without SDL
+  included), which is inconvenient if you could have had one universal build
+  that works everywhere.
+- We like the zlib license, but the biggest complaint from the open source
+  community about the license change is the static linking. The LGPL forced this
+  as a legal, not technical issue, but zlib doesn't care. Even those that aren't
+  concerned about the GNU freedoms found themselves solving the same problems:
+  swapping in a newer SDL to an older game often times can save the day.
+  Static linking stops this dead.
+
+So here's what we did:
+
+SDL now has, internally, a table of function pointers. So, this is what SDL_Init
+now looks like:
+
+```c
+bool SDL_Init(SDL_InitFlags flags)
+{
+    return jump_table.SDL_Init(flags);
+}
+```
+
+Except that is all done with a bunch of macro magic so we don't have to maintain
+every one of these.
+
+What is jump_table.SDL_init()? Eventually, that's a function pointer of the real
+SDL_Init() that you've been calling all this time. But at startup, it looks more
+like this:
+
+```c
+bool SDL_Init_DEFAULT(SDL_InitFlags flags)
+{
+    SDL_InitDynamicAPI();
+    return jump_table.SDL_Init(flags);
+}
+```
+
+SDL_InitDynamicAPI() fills in jump_table with all the actual SDL function
+pointers, which means that this `_DEFAULT` function never gets called again.
+First call to any SDL function sets the whole thing up.
+
+So you might be asking, what was the value in that? Isn't this what the operating
+system's dynamic loader was supposed to do for us? Yes, but now we've got this
+level of indirection, we can do things like this:
+
+```bash
+export SDL3_DYNAMIC_API=/my/actual/libSDL3.so.0
+./MyGameThatIsStaticallyLinkedToSDL
+```
+
+And now, this game that is statically linked to SDL, can still be overridden
+with a newer, or better, SDL. The statically linked one will only be used as
+far as calling into the jump table in this case. But in cases where no override
+is desired, the statically linked version will provide its own jump table,
+and everyone is happy.
+
+So now:
+- Developers can statically link SDL, and users can still replace it.
+  (We'd still rather you ship a shared library, though!)
+- Developers can ship an SDL with their game, Valve can override it for, say,
+  new features on SteamOS, or distros can override it for their own needs,
+  but it'll also just work in the default case.
+- Developers can ship the same package to everyone (Humble Bundle, GOG, etc),
+  and it'll do the right thing.
+- End users (and Valve) can update a game's SDL in almost any case,
+  to keep abandoned games running on newer platforms.
+- Everyone develops with SDL exactly as they have been doing all along.
+  Same headers, same ABI. Just get the latest version to enable this magic.
+
+
+A little more about SDL_InitDynamicAPI():
+
+Internally, InitAPI does some locking to make sure everything waits until a
+single thread initializes everything (although even SDL_CreateThread() goes
+through here before spinning a thread, too), and then decides if it should use
+an external SDL library. If not, it sets up the jump table using the current
+SDL's function pointers (which might be statically linked into a program, or in
+a shared library of its own). If so, it loads that library and looks for and
+calls a single function:
+
+```c
+Sint32 SDL_DYNAPI_entry(Uint32 version, void *table, Uint32 tablesize);
+```
+
+That function takes a version number (more on that in a moment), the address of
+the jump table, and the size, in bytes, of the table.
+Now, we've got policy here: this table's layout never changes; new stuff gets
+added to the end. Therefore SDL_DYNAPI_entry() knows that it can provide all
+the needed functions if tablesize <= sizeof its own jump table. If tablesize is
+bigger (say, SDL 3.0.4 is trying to load SDL 3.0.3), then we know to abort, but
+if it's smaller, we know we can provide the entire API that the caller needs.
+
+The version variable is a failsafe switch.
+Right now it's always 1. This number changes when there are major API changes
+(so we know if the tablesize might be smaller, or entries in it have changed).
+Right now SDL_DYNAPI_entry gives up if the version doesn't match, but it's not
+inconceivable to have a small dispatch library that only supplies this one
+function and loads different, otherwise-incompatible SDL libraries and has the
+right one initialize the jump table based on the version. For something that
+must generically catch lots of different versions of SDL over time, like the
+Steam Client, this isn't a bad option.
+
+Finally, I'm sure some people are reading this and thinking,
+"I don't want that overhead in my project!"
+
+To which I would point out that the extra function call through the jump table
+probably wouldn't even show up in a profile, but lucky you: this can all be
+disabled. You can build SDL without this if you absolutely must, but we would
+encourage you not to do that. However, on heavily locked down platforms like
+iOS, or maybe when debugging, it makes sense to disable it. The way this is
+designed in SDL, you just have to change one #define, and the entire system
+vaporizes out, and SDL functions exactly like it always did. Most of it is
+macro magic, so the system is contained to one C file and a few headers.
+However, this is on by default and you have to edit a header file to turn it
+off. Our hopes is that if we make it easy to disable, but not too easy,
+everyone will ultimately be able to get what they want, but we've gently
+nudged everyone towards what we think is the best solution.

vendor/sdl-3.2.10/docs/README-emscripten.md

@@ -0,0 +1,350 @@
+# Emscripten
+
+## The state of things
+
+(As of October 2024, but things move quickly and we don't update this
+document often.)
+
+In modern times, all the browsers you probably care about (Chrome, Firefox,
+Edge, and Safari, on Windows, macOS, Linux, iOS and Android), support some
+reasonable base configurations:
+
+- WebAssembly (don't bother with asm.js any more)
+- WebGL (which will look like OpenGL ES 2 or 3 to your app).
+- Threads (see caveats, though!)
+- Game controllers
+- Autoupdating (so you can assume they have a recent version of the browser)
+
+All this to say we're at the point where you don't have to make a lot of
+concessions to get even a fairly complex SDL-based game up and running.
+
+
+## RTFM
+
+This document is a quick rundown of some high-level details. The
+documentation at [emscripten.org](https://emscripten.org/) is vast
+and extremely detailed for a wide variety of topics, and you should at
+least skim through it at some point.
+
+
+## Porting your app to Emscripten
+
+Many many things just need some simple adjustments and they'll compile
+like any other C/C++ code, as long as SDL was handling the platform-specific
+work for your program.
+
+First: assembly language code has to go. Replace it with C. You can even use
+[x86 SIMD intrinsic functions in Emscripten](https://emscripten.org/docs/porting/simd.html)!
+
+Second: Middleware has to go. If you have a third-party library you link
+against, you either need an Emscripten port of it, or the source code to it
+to compile yourself, or you need to remove it.
+
+Third: If your program starts in a function called main(), you need to get
+out of it and into a function that gets called repeatedly, and returns quickly,
+called a mainloop.
+
+Somewhere in your program, you probably have something that looks like a more
+complicated version of this:
+
+```c
+void main(void)
+{
+    initialize_the_game();
+    while (game_is_still_running) {
+        check_for_new_input();
+        think_about_stuff();
+        draw_the_next_frame();
+    }
+    deinitialize_the_game();
+}
+```
+
+This will not work on Emscripten, because the main thread needs to be free
+to do stuff and can't sit in this loop forever. So Emscripten lets you set up
+a [mainloop](https://emscripten.org/docs/porting/emscripten-runtime-environment.html#browser-main-loop).
+
+```c
+static void mainloop(void)   /* this will run often, possibly at the monitor's refresh rate */
+{
+    if (!game_is_still_running) {
+        deinitialize_the_game();
+        #ifdef __EMSCRIPTEN__
+        emscripten_cancel_main_loop();  /* this should "kill" the app. */
+        #else
+        exit(0);
+        #endif
+    }
+
+    check_for_new_input();
+    think_about_stuff();
+    draw_the_next_frame();
+}
+
+void main(void)
+{
+    initialize_the_game();
+    #ifdef __EMSCRIPTEN__
+    emscripten_set_main_loop(mainloop, 0, 1);
+    #else
+    while (1) { mainloop(); }
+    #endif
+}
+```
+
+Basically, `emscripten_set_main_loop(mainloop, 0, 1);` says "run
+`mainloop` over and over until I end the program." The function will
+run, and return, freeing the main thread for other tasks, and then
+run again when it's time. The `1` parameter does some magic to make
+your main() function end immediately; this is useful because you
+don't want any shutdown code that might be sitting below this code
+to actually run if main() were to continue on, since we're just
+getting started.
+
+Another option is to use SDL' main callbacks, which handle this for you
+without platform-specific code in your app. Please refer to
+[the wiki](https://wiki.libsdl.org/SDL3/README/main-functions#main-callbacks-in-sdl3)
+or `docs/README-main-functions.md` in the SDL source code.
+
+
+
+There's a lot of little details that are beyond the scope of this
+document, but that's the biggest initial set of hurdles to porting
+your app to the web.
+
+
+## Do you need threads?
+
+If you plan to use threads, they work on all major browsers now. HOWEVER,
+they bring with them a lot of careful considerations. Rendering _must_
+be done on the main thread. This is a general guideline for many
+platforms, but a hard requirement on the web.
+
+Many other things also must happen on the main thread; often times SDL
+and Emscripten make efforts to "proxy" work to the main thread that
+must be there, but you have to be careful (and read more detailed
+documentation than this for the finer points).
+
+Even when using threads, your main thread needs to set an Emscripten
+mainloop (or use SDL's main callbacks) that runs quickly and returns, or
+things will fail to work correctly.
+
+You should definitely read [Emscripten's pthreads docs](https://emscripten.org/docs/porting/pthreads.html)
+for all the finer points. Mostly SDL's thread API will work as expected,
+but is built on pthreads, so it shares the same little incompatibilities
+that are documented there, such as where you can use a mutex, and when
+a thread will start running, etc.
+
+
+IMPORTANT: You have to decide to either build something that uses
+threads or something that doesn't; you can't have one build
+that works everywhere. This is an Emscripten (or maybe WebAssembly?
+Or just web browsers in general?) limitation. If you aren't using
+threads, it's easier to not enable them at all, at build time.
+
+If you use threads, you _have to_ run from a web server that has
+[COOP/COEP headers set correctly](https://web.dev/why-coop-coep/)
+or your program will fail to start at all.
+
+If building with threads, `__EMSCRIPTEN_PTHREADS__` will be defined
+for checking with the C preprocessor, so you can build something
+different depending on what sort of build you're compiling.
+
+
+## Audio
+
+Audio works as expected at the API level, but not exactly like other
+platforms.
+
+You'll only see a single default audio device. Audio recording also works;
+if the browser pops up a prompt to ask for permission to access the
+microphone, the SDL_OpenAudioDevice call will succeed and start producing
+silence at a regular interval. Once the user approves the request, real
+audio data will flow. If the user denies it, the app is not informed and
+will just continue to receive silence.
+
+Modern web browsers will not permit web pages to produce sound before the
+user has interacted with them (clicked or tapped on them, usually); this is
+for several reasons, not the least of which being that no one likes when a
+random browser tab suddenly starts making noise and the user has to scramble
+to figure out which and silence it.
+
+SDL will allow you to open the audio device for playback in this
+circumstance, and your audio callback will fire, but SDL will throw the audio
+data away until the user interacts with the page. This helps apps that depend
+on the audio callback to make progress, and also keeps audio playback in sync
+once the app is finally allowed to make noise.
+
+There are two reasonable ways to deal with the silence at the app level:
+if you are writing some sort of media player thing, where the user expects
+there to be a volume control when you mouseover the canvas, just default
+that control to a muted state; if the user clicks on the control to unmute
+it, on this first click, open the audio device. This allows the media to
+play at start, and the user can reasonably opt-in to listening.
+
+Many games do not have this sort of UI, and are more rigid about starting
+audio along with everything else at the start of the process. For these, your
+best bet is to write a little Javascript that puts up a "Click here to play!"
+UI, and upon the user clicking, remove that UI and then call the Emscripten
+app's main() function. As far as the application knows, the audio device was
+available to be opened as soon as the program started, and since this magic
+happens in a little Javascript, you don't have to change your C/C++ code at
+all to make it happen.
+
+Please see the discussion at https://github.com/libsdl-org/SDL/issues/6385
+for some Javascript code to steal for this approach.
+
+
+## Rendering
+
+If you use SDL's 2D render API, it will use GLES2 internally, which
+Emscripten will turn into WebGL calls. You can also use OpenGL ES 2
+directly by creating a GL context and drawing into it.
+
+If the browser (and hardware) support WebGL 2, you can create an OpenGL ES 3
+context.
+
+Calling SDL_RenderPresent (or SDL_GL_SwapWindow) will not actually
+present anything on the screen until your return from your mainloop
+function.
+
+
+## Building SDL/emscripten
+
+
+SDL currently requires at least Emscripten 3.16.0 to build. Newer versions
+are likely to work, as well.
+
+
+Build:
+
+This works on Linux/Unix and macOS. Please send comments about Windows.
+
+Make sure you've [installed emsdk](https://emscripten.org/docs/getting_started/downloads.html)
+first, and run `source emsdk_env.sh` at the command line so it finds the
+tools.
+
+(These cmake options might be overkill, but this has worked for me.)
+
+```bash
+mkdir build
+cd build
+emcmake cmake ..
+# you can also do `emcmake cmake -G Ninja ..` and then use `ninja` instead of this command.
+emmake make -j4
+```
+
+If you want to build with thread support, something like this works:
+
+```bash
+mkdir build
+cd build
+emcmake cmake -DSDL_THREADS=ON ..
+# you can also do `emcmake cmake -G Ninja ..` and then use `ninja` instead of this command.
+emmake make -j4
+```
+
+To build the tests, add `-DSDL_TESTS=ON` to the `emcmake cmake` command line.
+To build the examples, add `-DSDL_EXAMPLES=ON` to the `emcmake cmake` command line.
+
+
+## Building your app
+
+You need to compile with `emcc` instead of `gcc` or `clang` or whatever, but
+mostly it uses the same command line arguments as Clang.
+
+Link against the libSDL3.a file you generated by building SDL.
+
+Usually you would produce a binary like this:
+
+```bash
+gcc -o mygame mygame.c  # or whatever
+```
+
+But for Emscripten, you want to output something else:
+
+```bash
+emcc -o index.html mygame.c
+```
+
+This will produce several files...support Javascript and WebAssembly (.wasm)
+files. The `-o index.html` will produce a simple HTML page that loads and
+runs your app. You will (probably) eventually want to replace or customize
+that file and do `-o index.js` instead to just build the code pieces.
+
+If you're working on a program of any serious size, you'll likely need to
+link with `-s ALLOW_MEMORY_GROWTH=1 -s MAXIMUM_MEMORY=1gb` to get access
+to more memory. If using pthreads, you'll need the `-s MAXIMUM_MEMORY=1gb`
+or the app will fail to start on iOS browsers, but this might be a bug that
+goes away in the future.
+
+
+## Data files
+
+Your game probably has data files. Here's how to access them.
+
+Filesystem access works like a Unix filesystem; you have a single directory
+tree, possibly interpolated from several mounted locations, no drive letters,
+'/' for a path separator. You can access them with standard file APIs like
+open() or fopen() or SDL_IOStream. You can read or write from the filesystem.
+
+By default, you probably have a "MEMFS" filesystem (all files are stored in
+memory, but access to them is immediate and doesn't need to block). There are
+other options, like "IDBFS" (files are stored in a local database, so they
+don't need to be in RAM all the time and they can persist between runs of the
+program, but access is not synchronous). You can mix and match these file
+systems, mounting a MEMFS filesystem at one place and idbfs elsewhere, etc,
+but that's beyond the scope of this document. Please refer to Emscripten's
+[page on the topic](https://emscripten.org/docs/porting/files/file_systems_overview.html)
+for more info.
+
+The _easiest_ (but not the best) way to get at your data files is to embed
+them in the app itself. Emscripten's linker has support for automating this.
+
+```bash
+emcc -o index.html loopwave.c --embed-file ../test/sample.wav@/sounds/sample.wav
+```
+
+This will pack ../test/sample.wav in your app, and make it available at
+"/sounds/sample.wav" at runtime. Emscripten makes sure this data is available
+before your main() function runs, and since it's in MEMFS, you can just
+read it like you do on other platforms. `--embed-file` can also accept a
+directory to pack an entire tree, and you can specify the argument multiple
+times to pack unrelated things into the final installation.
+
+Note that this is absolutely the best approach if you have a few small
+files to include and shouldn't worry about the issue further. However, if you
+have hundreds of megabytes and/or thousands of files, this is not so great,
+since the user will download it all every time they load your page, and it
+all has to live in memory at runtime.
+
+[Emscripten's documentation on the matter](https://emscripten.org/docs/porting/files/packaging_files.html)
+gives other options and details, and is worth a read.
+
+
+## Debugging
+
+Debugging web apps is a mixed bag. You should compile and link with
+`-gsource-map`, which embeds a ton of source-level debugging information into
+the build, and make sure _the app source code is available on the web server_,
+which is often a scary proposition for various reasons.
+
+When you debug from the browser's tools and hit a breakpoint, you can step
+through the actual C/C++ source code, though, which can be nice.
+
+If you try debugging in Firefox and it doesn't work well for no apparent
+reason, try Chrome, and vice-versa. These tools are still relatively new,
+and improving all the time.
+
+SDL_Log() (or even plain old printf) will write to the Javascript console,
+and honestly I find printf-style debugging to be easier than setting up a build
+for proper debugging, so use whatever tools work best for you.
+
+
+## Questions?
+
+Please give us feedback on this document at [the SDL bug tracker](https://github.com/libsdl-org/SDL/issues).
+If something is wrong or unclear, we want to know!
+
+
+

vendor/sdl-3.2.10/docs/README-gdk.md

@@ -0,0 +1,174 @@
+GDK
+=====
+
+This port allows SDL applications to run via Microsoft's Game Development Kit (GDK).
+
+Windows (GDK) and  Xbox One/Xbox Series (GDKX) are both supported and all the required code is included in this public SDL release. However, only licensed Xbox developers have access to the GDKX libraries which will allow you to build the Xbox targets.
+
+
+Requirements
+------------
+
+* Microsoft Visual Studio 2022 (in theory, it should also work in 2017 or 2019, but this has not been tested)
+* Microsoft GDK October 2023 Update 1 or newer (public release [here](https://github.com/microsoft/GDK/releases/tag/October_2023_Update_1))
+* For Xbox, you will need the corresponding GDKX version (licensed developers only)
+* To publish a package or successfully authenticate a user, you will need to create an app id/configure services in Partner Center. However, for local testing purposes (without authenticating on Xbox Live), the test identifiers used by the GDK test programs in the included solution work.
+
+
+Windows GDK Status
+------
+
+The Windows GDK port supports the full set of Win32 APIs, renderers, controllers, input devices, etc., as the normal Windows x64 build of SDL.
+
+* Additionally, the GDK port adds the following:
+  * Compile-time platform detection for SDL programs. The `SDL_PLATFORM_GDK` is `#define`d on every GDK platform, and the  `SDL_PLATFORM_WINGDK` is `#define`d on Windows GDK, specifically. (This distinction exists because other GDK platforms support a smaller subset of functionality. This allows you to mark code for "any" GDK separate from Windows GDK.)
+  * GDK-specific setup:
+    * Initializing/uninitializing the game runtime, and initializing Xbox Live services
+    * Creating a global task queue and setting it as the default for the process. When running any async operations, passing in `NULL` as the task queue will make the task get added to the global task queue.
+
+  * An implementation on `WinMain` that performs the above GDK setup that you can use by #include'ing SDL_main.h in the source file that includes your standard main() function. If you are unable to do this, you can instead manually call `SDL_RunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters. To use `SDL_RunApp`, `#define SDL_MAIN_HANDLED` before `#include <SDL3/SDL_main.h>`.
+  * Global task queue callbacks are dispatched during `SDL_PumpEvents` (which is also called internally if using `SDL_PollEvent`).
+  * You can get the handle of the global task queue through `SDL_GetGDKTaskQueue`, if needed. When done with the queue, be sure to use `XTaskQueueCloseHandle` to decrement the reference count (otherwise it will cause a resource leak).
+
+* Single-player games have some additional features available:
+  * Call `SDL_GetGDKDefaultUser` to get the default XUserHandle pointer.
+  * `SDL_GetPrefPath` still works, but only for single-player titles.
+
+  These functions mostly wrap around async APIs, and thus should be treated as synchronous alternatives. Also note that the single-player functions return on any OS errors, so be sure to validate the return values!
+
+* What doesn't work:
+  * Compilation with anything other than through the included Visual C++ solution file
+
+## VisualC-GDK Solution
+
+The included `VisualC-GDK/SDL.sln` solution includes the following targets for the Gaming.Desktop.x64 configuration:
+
+* SDL3 (DLL) - This is the typical SDL3.dll, but for Gaming.Desktop.x64.
+* tests/testgamecontroller - Standard SDL test program demonstrating controller functionality.
+* tests/testgdk - GDK-specific test program that demonstrates using the global task queue to login a user into Xbox Live.
+  *NOTE*: As of the June 2022 GDK, you cannot test user logins without a valid Title ID and MSAAppId. You will need to manually change the identifiers in the `MicrosoftGame.config` to your valid IDs from Partner Center if you wish to test this.
+* tests/testsprite - Standard SDL test program demonstrating sprite drawing functionality.
+
+If you set one of the test programs as a startup project, you can run it directly from Visual Studio.
+
+Windows GDK Setup, Detailed Steps
+---------------------
+
+These steps assume you already have a game using SDL that runs on Windows x64 along with a corresponding Visual Studio solution file for the x64 version. If you don't have this, it's easiest to use one of the test program vcxproj files in the `VisualC-GDK` directory as a starting point, though you will still need to do most of the steps below.
+
+### 1. Add a Gaming.Desktop.x64 Configuration ###
+
+In your game's existing Visual Studio Solution, go to Build > Configuration Manager. From the "Active solution platform" drop-down select "New...". From the drop-down list, select Gaming.Desktop.x64 and copy the settings from the x64 configuration.
+
+### 2. Build SDL3 for GDK ###
+
+Open `VisualC-GDK/SDL.sln` in Visual Studio, you need to build the SDL3 target for the Gaming.Desktop.x64 platform (Release is recommended). You will need to copy/keep track of the `SDL3.dll`, `XCurl.dll` (which is output by Gaming.Desktop.x64), and `SDL3.lib` output files for your game project.
+
+*Alternatively*, you could setup your solution file to instead reference the SDL3 project file targets from the SDL source, and add those projects as a dependency. This would mean that SDL3 would be built when your game is built.
+
+### 3. Configuring Project Settings ###
+
+While the Gaming.Desktop.x64 configuration sets most of the required settings, there are some additional items to configure for your game project under the Gaming.Desktop.x64 Configuration:
+
+*  Under C/C++ > General > Additional Include Directories, make sure the `SDL/include` path is referenced
+* Under Linker > General > Additional Library Directories, make sure to reference the path where the newly-built SDL3.lib are
+* Under Linker > Input > Additional Dependencies, you need the following:
+  * `SDL3.lib`
+  * `xgameruntime.lib`
+  * `../Microsoft.Xbox.Services.GDK.C.Thunks.lib`
+* Note that in general, the GDK libraries depend on the MSVC C/C++ runtime, so there is no way to remove this dependency from a GDK program that links against GDK.
+
+### 4. Setting up SDL_main ###
+
+Rather than using your own implementation of `WinMain`, it's recommended that you instead `#include <SDL3/SDL_main.h>` and declare a standard main function. If you are unable to do this, you can instead manually call `SDL_RunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters; in that case `#define SDL_MAIN_HANDLED` before including SDL_main.h
+
+### 5. Required DLLs ###
+
+The game will not launch in the debugger unless required DLLs are included in the directory that contains the game's .exe file. You need to make sure that the following files are copied into the directory:
+
+* Your SDL3.dll
+* "$(Console_GRDKExtLibRoot)Xbox.Services.API.C\DesignTime\CommonConfiguration\Neutral\Lib\Release\Microsoft.Xbox.Services.GDK.C.Thunks.dll"
+* XCurl.dll
+
+You can either copy these in a post-build step, or you can add the dlls into the project and set its Configuration Properties > General > Item type to "Copy file," which will also copy them into the output directory.
+
+### 6. Setting up MicrosoftGame.config ###
+
+You can copy `VisualC-GDK/tests/testgdk/MicrosoftGame.config` and use that as a starting point in your project. Minimally, you will want to change the Executable Name attribute, the DefaultDisplayName, and the Description.
+
+This file must be copied into the same directory as the game's .exe file. As with the DLLs, you can either use a post-build step or the "Copy file" item type.
+
+For basic testing, you do not need to change anything else in `MicrosoftGame.config`. However, if you want to test any Xbox Live services (such as logging in users) _or_ publish a package, you will need to setup a Game app on Partner Center.
+
+Then, you need to set the following values to the values from Partner Center:
+
+* Identity tag - Name and Publisher attributes
+* TitleId
+* MSAAppId
+
+### 7. Adding Required Logos
+
+Several logo PNG files are required to be able to launch the game, even from the debugger. You can use the sample logos provided in `VisualC-GDK/logos`. As with the other files, they must be copied into the same directory as the game's .exe file.
+
+
+### 8. Copying any Data Files ###
+
+When debugging GDK games, there is no way to specify a working directory. Therefore, any required game data must also be copied into the output directory, likely in a post-build step.
+
+
+### 9. Build and Run from Visual Studio ###
+
+At this point, you should be able to build and run your game from the Visual Studio Debugger. If you get any linker errors, make sure you double-check that you referenced all the required libs.
+
+If you are testing Xbox Live functionality, it's likely you will need to change to the Sandbox for your title. To do this:
+
+1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
+2. Switch the sandbox name with:
+   `XblPCSandbox SANDBOX.#`
+3. (To switch back to the retail sandbox):
+   `XblPCSandbox RETAIL`
+
+### 10. Packaging and Installing Locally
+
+You can use one of the test program's `PackageLayout.xml` as a starting point. Minimally, you will need to change the exe to the correct name and also reference any required game data. As with the other data files, it's easiest if you have this copy to the output directory, although it's not a requirement as you can specify relative paths to files.
+
+To create the package:
+
+1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
+2. `cd` to the directory containing the `PackageLayout.xml` with the correct paths (if you use the local path as in the sample package layout, this would be from your .exe output directory)
+3. `mkdir Package` to create an output directory
+4. To package the file into the `Package` directory, use:
+    `makepkg pack /f PackageLayout.xml /lt /d . /nogameos /pc /pd Package`
+5. To install the package, use:
+   `wdapp install PACKAGENAME.msixvc`
+6. Once the package is installed, you can run it from the start menu.
+7. As with when running from Visual Studio, if you need to test any Xbox Live functionality you must switch to the correct sandbox.
+
+Xbox GDKX Setup
+---------------------
+In general, the same process in the Windows GDK instructions work. There are just a few additional notes:
+* For Xbox One consoles, use the Gaming.Xbox.XboxOne.x64 target
+* For Xbox Series consoles, use the Gaming.Xbox.Scarlett.x64 target
+* The Xbox One target sets the `SDL_PLATFORM_XBOXONE` define and the Xbox Series target sets the `SDL_PLATFORM_XBOXSERIES` define
+* You don't need to link against the Xbox.Services Thunks lib nor include that dll in your package (it doesn't exist for Xbox)
+* The shader blobs for Xbox are created in a pre-build step for the Xbox targets, rather than included in the source (due to NDA and version compatibility reasons)
+* To create a package, use:
+  `makepkg pack /f PackageLayout.xml /lt /d . /pd Package`
+* To install the package, use:
+  `xbapp install [PACKAGE].xvc`
+* For some reason, if you make changes that require SDL3.dll to build, and you are running through the debugger (instead of a package), you have to rebuild your .exe target for the debugger to recognize the dll has changed and needs to be transferred to the console again
+* While there are successful releases of Xbox titles using this port, it is not as extensively tested as other targets
+
+Troubleshooting
+---------------
+
+#### Xbox Live Login does not work
+
+As of June 2022 GDK, you must have a valid Title Id and MSAAppId in order to test Xbox Live functionality such as user login. Make sure these are set correctly in the `MicrosoftGame.config`. This means that even testgdk will not let you login without setting these properties to valid values.
+
+Furthermore, confirm that your PC is set to the correct sandbox.
+
+
+#### "The current user has already installed an unpackaged version of this app. A packaged version cannot replace this." error when installing
+
+Prior to June 2022 GDK, running from the Visual Studio debugger would still locally register the app (and it would appear on the start menu). To fix this, you have to uninstall it (it's simplest to right click on it from the start menu to uninstall it).

vendor/sdl-3.2.10/docs/README-haiku.md

@@ -0,0 +1,4 @@
+# Haiku OS
+
+SDL is fully supported on Haiku OS, and is built using [CMake](README-cmake.md).
+

vendor/sdl-3.2.10/docs/README-highdpi.md

@@ -0,0 +1,36 @@
+
+SDL 3.0 has new support for high DPI displays. Interfaces provided by SDL uses the platform's native coordinates unless otherwise specified.
+
+To reconcile platform differences in their approach to high-density scaling, SDL provides the following interfaces:
+- `SDL_GetWindowSize()`          retrieves the window dimensions in native coordinates.
+- `SDL_GetWindowSizeInPixels()`  retrieves the window dimensions in pixels-addressable.
+- `SDL_GetDisplayContentScale()` retrieves the suggested amplification factor when drawing in native coordinates.
+- `SDL_GetWindowDisplayScale()`  retrieves the suggested amplification factor when drawing in pixels-addressable.
+- `SDL_GetWindowPixelDensity()`  retrieves how many addressable pixels correspond to one unit of native coordinates.
+- `SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED`    is emitted when the value retrievable from `SDL_GetWindowSizeInPixels()` changes.
+- `SDL_EVENT_WINDOW_DISPLAY_SCALE_CHANGED` is emitted when the value retrievable from `SDL_GetWindowDisplayScale()` changes.
+- Windows created with `SDL_WINDOW_HIGH_PIXEL_DENSITY` will ask the platform to display addressable pixels at their natural scale.
+
+## Numeric example
+
+Given a fullscreen window spanning a 3840x2160 monitor set to 2x display or 200% scaling, the following tabulates the effect of creating a window with or without `SDL_WINDOW_HIGH_PIXEL_DENSITY` on MacOS and Win32:
+
+| Value                          | MacOS (Default) | MacOS (HD) | Win32 (Default & HD) |
+|--------------------------------|-----------------|------------|----------------------|
+| `SDL_GetWindowSize()`          | 1920x1080       | 1920x1080  | 3840x2160            |
+| `SDL_GetWindowSizeInPixels()`  | 1920x1080       | 3840x2160  | 3840x2160            |
+| `SDL_GetDisplayContentScale()` | 1.0             | 1.0        | 2.0                  |
+| `SDL_GetWindowDisplayScale()`  | 1.0             | 2.0        | 2.0                  |
+| `SDL_GetWindowPixelDensity()`  | 1.0             | 2.0        | 1.0                  |
+
+Observe the philosophical difference between the approaches taken by MacOS and Win32:
+- Win32 coordinate system always deals in physical device pixels, high DPI support is achieved by providing an advisory hint for the developer to enlarge drawn objects. Ignoring the advisory scale factor results in graphics appearing tiny.
+- MacOS coordinate system always deals in physical content sizes, high DPI support is achieved by providing an optional flag for the developer to request finer granularity. Omitting the granularity request results in graphics appearing coarse.
+
+## Explanation
+
+Displays now have a content display scale, which is the expected scale for content based on the DPI settings of the display. For example, a 4K display might have a 2.0 (200%) display scale, which means that the user expects UI elements to be twice as big on this display, to aid in readability. You can query the display content scale using `SDL_GetDisplayContentScale()`, and when this changes you get an `SDL_EVENT_WINDOW_DISPLAY_SCALE_CHANGED` event.
+
+The window size is now distinct from the window pixel size, and the ratio between the two is the window pixel density. If the window is created with the `SDL_WINDOW_HIGH_PIXEL_DENSITY` flag, SDL will try to match the native pixel density for the display, otherwise it will try to have the pixel size match the window size. You can query the window pixel density using `SDL_GetWindowPixelDensity()`. You can query the window pixel size using `SDL_GetWindowSizeInPixels()`, and when this changes you get an `SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED` event. You are guaranteed to get a `SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED` event when a window is created and resized, and you can use this event to create and resize your graphics context for the window.
+
+The window has a display scale, which is the scale from the pixel resolution to the desired content size, e.g. the combination of the pixel density and the content scale. For example, a 3840x2160 window displayed at 200% on Windows, and a 1920x1080 window with the high density flag on a 2x display on macOS will both have a pixel size of 3840x2160 and a display scale of 2.0.  You can query the window display scale using `SDL_GetWindowDisplayScale()`, and when this changes you get an `SDL_EVENT_WINDOW_DISPLAY_SCALE_CHANGED` event.

vendor/sdl-3.2.10/docs/README-ios.md

@@ -0,0 +1,260 @@
+iOS
+======
+
+Building the Simple DirectMedia Layer for iOS 11.0+
+==============================================================================
+
+Please note that building SDL requires at least Xcode 12.2 and the iOS 14.2 SDK.
+
+Instructions:
+
+1. Open SDL.xcodeproj (located in Xcode/SDL) in Xcode.
+2. Select your desired target, and hit build.
+
+
+Using the Simple DirectMedia Layer for iOS
+==============================================================================
+
+1. Run Xcode and create a new project using the iOS Game template, selecting the Objective C language and Metal game technology.
+2. In the main view, delete all files except for Assets and LaunchScreen
+3. Right click the project in the main view, select "Add Files...", and add the SDL project, Xcode/SDL/SDL.xcodeproj
+4. Select the project in the main view, go to the "Info" tab and under "Custom iOS Target Properties" remove the line "Main storyboard file base name"
+5. Select the project in the main view, go to the "Build Settings" tab, select "All", and edit "Header Search Path" and drag over the SDL "Public Headers" folder from the left
+6. Select the project in the main view, go to the "Build Phases" tab, select "Link Binary With Libraries", and add SDL3.framework from "Framework-iOS"
+7. Select the project in the main view, go to the "General" tab, scroll down to "Frameworks, Libraries, and Embedded Content", and select "Embed & Sign" for the SDL library.
+8. Add the source files that you would normally have for an SDL program, making sure to have #include <SDL3/SDL_main.h> at the top of the file containing your main() function.
+9. Add any assets that your application needs.
+10. Enjoy!
+
+
+TODO: Add information regarding App Store requirements such as icons, etc.
+
+
+Notes -- Retina / High-DPI and window sizes
+==============================================================================
+
+Window and display mode sizes in SDL are in points rather than in pixels.
+On iOS this means that a window created on an iPhone 6 will have a size in
+points of 375 x 667, rather than a size in pixels of 750 x 1334. All iOS apps
+are expected to size their content based on points rather than pixels,
+as this allows different iOS devices to have different pixel densities
+(Retina versus non-Retina screens, etc.) without apps caring too much.
+
+SDL_GetWindowSize() and mouse coordinates are in points rather than pixels,
+but the window will have a much greater pixel density when the device supports
+it, and the SDL_GetWindowSizeInPixels() can be called to determine the size
+in pixels of the drawable screen framebuffer.
+
+The SDL 2D rendering API will automatically handle this for you, by default
+providing a rendering area in points, and you can call SDL_SetRenderLogicalPresentation()
+to gain access to the higher density resolution.
+
+Some OpenGL ES functions such as glViewport expect sizes in pixels rather than
+sizes in points. When doing 2D rendering with OpenGL ES, an orthographic projection
+matrix using the size in points (SDL_GetWindowSize()) can be used in order to
+display content at the same scale no matter whether a Retina device is used or not.
+
+
+Notes -- Application events
+==============================================================================
+
+On iOS the application goes through a fixed life cycle and you will get
+notifications of state changes via application events. When these events
+are delivered you must handle them in an event callback because the OS may
+not give you any processing time after the events are delivered.
+
+e.g.
+
+    bool HandleAppEvents(void *userdata, SDL_Event *event)
+    {
+        switch (event->type)
+        {
+        case SDL_EVENT_TERMINATING:
+            /* Terminate the app.
+               Shut everything down before returning from this function.
+            */
+            return false;
+        case SDL_EVENT_LOW_MEMORY:
+            /* You will get this when your app is paused and iOS wants more memory.
+               Release as much memory as possible.
+            */
+            return false;
+        case SDL_EVENT_WILL_ENTER_BACKGROUND:
+            /* Prepare your app to go into the background.  Stop loops, etc.
+               This gets called when the user hits the home button, or gets a call.
+            */
+            return false;
+        case SDL_EVENT_DID_ENTER_BACKGROUND:
+            /* This will get called if the user accepted whatever sent your app to the background.
+               If the user got a phone call and canceled it, you'll instead get an SDL_EVENT_DID_ENTER_FOREGROUND event and restart your loops.
+               When you get this, you have 5 seconds to save all your state or the app will be terminated.
+               Your app is NOT active at this point.
+            */
+            return false;
+        case SDL_EVENT_WILL_ENTER_FOREGROUND:
+            /* This call happens when your app is coming back to the foreground.
+               Restore all your state here.
+            */
+            return false;
+        case SDL_EVENT_DID_ENTER_FOREGROUND:
+            /* Restart your loops here.
+               Your app is interactive and getting CPU again.
+            */
+            return false;
+        default:
+            /* No special processing, add it to the event queue */
+            return true;
+        }
+    }
+
+    int main(int argc, char *argv[])
+    {
+        SDL_SetEventFilter(HandleAppEvents, NULL);
+
+        ... run your main loop
+
+        return 0;
+    }
+
+
+Note that if you are using main callbacks instead of a standard C main() function, your SDL_AppEvent() callback will run as these events arrive and you do not need to use SDL_SetEventFilter.
+
+
+Notes -- Keyboard
+==============================================================================
+
+The SDL keyboard API has been extended to support on-screen keyboards:
+
+void SDL_StartTextInput()
+	-- enables text events and reveals the onscreen keyboard.
+
+void SDL_StopTextInput()
+	-- disables text events and hides the onscreen keyboard.
+
+bool SDL_TextInputActive()
+	-- returns whether or not text events are enabled (and the onscreen keyboard is visible)
+
+
+Notes -- Mouse
+==============================================================================
+
+iOS now supports Bluetooth mice on iPad, but by default will provide the mouse input as touch. In order for SDL to see the real mouse events, you should set the key UIApplicationSupportsIndirectInputEvents to true in your Info.plist
+
+From iOS 17 onward, the key now defaults to true.
+
+
+Notes -- Reading and Writing files
+==============================================================================
+
+Each application installed on iPhone resides in a sandbox which includes its own application home directory. Your application may not access files outside this directory.
+
+When your SDL based iPhone application starts up, it sets the working directory to the main bundle, where your application resources are stored. You cannot write to this directory. Instead, you should write document files to the directory returned by SDL_GetUserFolder(SDL_FOLDER_DOCUMENTS) and preferences to the directory returned by SDL_GetPrefPath().
+
+More information on this subject is available here:
+http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html
+
+
+Notes -- xcFramework
+==============================================================================
+
+The SDL.xcodeproj file now includes a target to build SDL3.xcframework. An xcframework is a new (Xcode 11) uber-framework which can handle any combination of processor type and target OS platform.
+
+In the past, iOS devices were always an ARM variant processor, and the simulator was always i386 or x86_64, and thus libraries could be combined into a single framework for both simulator and device. With the introduction of the Apple Silicon ARM-based machines, regular frameworks would collide as CPU type was no longer sufficient to differentiate the platform. So Apple created the new xcframework library package.
+
+The xcframework target builds into a Products directory alongside the SDL.xcodeproj file, as SDL3.xcframework. This can be brought in to any iOS project and will function properly for both simulator and device, no matter their CPUs. Note that Intel Macs cannot cross-compile for Apple Silicon Macs. If you need AS compatibility, perform this build on an Apple Silicon Mac.
+
+This target requires Xcode 11 or later. The target will simply fail to build if attempted on older Xcodes.
+
+In addition, on Apple platforms, main() cannot be in a dynamically loaded library.
+However, unlike in SDL2, in SDL3 SDL_main is implemented inline in SDL_main.h, so you don't need to link against a static libSDL3main.lib, and you don't need to copy a .c file from the SDL3 source either.
+This means that iOS apps which used the statically-linked libSDL3.lib and now link with the xcframwork can just `#include <SDL3/SDL_main.h>` in the source file that contains their standard `int main(int argc, char *argv[])` function to get a header-only SDL_main implementation that calls the `SDL_RunApp()` with your standard main function.
+
+Using an xcFramework is similar to using a regular framework. However, issues have been seen with the build system not seeing the headers in the xcFramework. To remedy this, add the path to the xcFramework in your app's target ==> Build Settings ==> Framework Search Paths and mark it recursive (this is critical). Also critical is to remove "*.framework" from Build Settings ==> Sub-Directories to Exclude in Recursive Searches. Clean the build folder, and on your next build the build system should be able to see any of these in your code, as expected:
+
+#include "SDL_main.h"
+#include <SDL.h>
+#include <SDL_main.h>
+
+
+Notes -- iPhone SDL limitations
+==============================================================================
+
+Windows:
+	Full-size, single window applications only.  You cannot create multi-window SDL applications for iPhone OS.  The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow() the flag SDL_WINDOW_BORDERLESS).
+
+Textures:
+	The optimal texture formats on iOS are SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_XBGR8888, and SDL_PIXELFORMAT_RGB24 pixel formats.
+
+
+Notes -- CoreBluetooth.framework
+==============================================================================
+
+SDL_JOYSTICK_HIDAPI is disabled by default. It can give you access to a lot
+more game controller devices, but it requires permission from the user before
+your app will be able to talk to the Bluetooth hardware. "Made For iOS"
+branded controllers do not need this as we don't have to speak to them
+directly with raw bluetooth, so many apps can live without 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>
+
+
+Game Center
+==============================================================================
+
+Game Center integration might require that you break up your main loop in order to yield control back to the system. In other words, instead of running an endless main loop, you run each frame in a callback function, using:
+
+    bool SDL_SetiOSAnimationCallback(SDL_Window * window, int interval, SDL_iOSAnimationCallback callback, void *callbackParam);
+
+This will set up the given function to be called back on the animation callback, and then you have to return from main() to let the Cocoa event loop run.
+
+e.g.
+
+    extern "C"
+    void ShowFrame(void*)
+    {
+        ... do event handling, frame logic and rendering ...
+    }
+
+    int main(int argc, char *argv[])
+    {
+        ... initialize game ...
+
+    #ifdef SDL_PLATFORM_IOS
+        // Initialize the Game Center for scoring and matchmaking
+        InitGameCenter();
+
+        // Set up the game to run in the window animation callback on iOS
+        // so that Game Center and so forth works correctly.
+        SDL_SetiOSAnimationCallback(window, 1, ShowFrame, NULL);
+    #else
+        while ( running ) {
+            ShowFrame(0);
+            DelayFrame();
+        }
+    #endif
+        return 0;
+    }
+
+
+Note that if you are using main callbacks instead of a standard C main() function, your SDL_AppIterate() callback is already doing this and you don't need to use SDL_SetiOSAnimationCallback.
+
+
+Deploying to older versions of iOS
+==============================================================================
+
+SDL supports deploying to older versions of iOS than are supported by the latest version of Xcode, all the way back to iOS 11.0
+
+In order to do that you need to download an older version of Xcode:
+https://developer.apple.com/download/more/?name=Xcode
+
+Open the package contents of the older Xcode and your newer version of Xcode and copy over the folders in Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
+
+Then open the file Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist and add the versions of iOS you want to deploy to the key Root/DefaultProperties/DEPLOYMENT_TARGET_SUGGESTED_VALUES
+
+Open your project and set your deployment target to the desired version of iOS
+
+Finally, remove GameController from the list of frameworks linked by your application and edit the build settings for "Other Linker Flags" and add -weak_framework GameController

vendor/sdl-3.2.10/docs/README-kmsbsd.md

@@ -0,0 +1,27 @@
+KMSDRM on *BSD
+==================================================
+
+KMSDRM is supported on FreeBSD and OpenBSD. DragonFlyBSD works but requires being a root user. NetBSD isn't supported yet because the application will crash when creating the KMSDRM screen.
+
+WSCONS support has been brought back, but only as an input backend. It will not be brought back as a video backend to ease maintenance.
+
+OpenBSD note: Note that the video backend assumes that the user has read/write permissions to the /dev/drm* devices.
+
+
+SDL WSCONS input backend features
+===================================================
+1. It is keymap-aware; it will work properly with different keymaps.
+2. It has mouse support.
+3. Accent input is supported.
+4. Compose keys are supported.
+5. AltGr and Meta Shift keys work as intended.
+
+Partially working or no input on OpenBSD/NetBSD.
+==================================================
+
+The WSCONS input backend needs read/write access to the /dev/wskbd* devices, without which it will not work properly. /dev/wsmouse must also be read/write accessible, otherwise mouse input will not work.
+
+Partially working or no input on FreeBSD.
+==================================================
+
+The evdev devices are only accessible to the root user by default. Edit devfs rules to allow access to such devices. The /dev/kbd* devices are also only accessible to the root user by default. Edit devfs rules to allow access to such devices.

vendor/sdl-3.2.10/docs/README-linux.md

@@ -0,0 +1,98 @@
+Linux
+================================================================================
+
+By default SDL will only link against glibc, the rest of the features will be
+enabled dynamically at runtime depending on the available features on the target
+system. So, for example if you built SDL with XRandR support and the target
+system does not have the XRandR libraries installed, it will be disabled
+at runtime, and you won't get a missing library error, at least with the
+default configuration parameters.
+
+
+Build Dependencies
+--------------------------------------------------------------------------------
+
+Ubuntu 18.04, all available features enabled:
+
+    sudo apt-get install build-essential git make \
+    pkg-config cmake ninja-build gnome-desktop-testing libasound2-dev libpulse-dev \
+    libaudio-dev libjack-dev libsndio-dev libx11-dev libxext-dev \
+    libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev libxss-dev \
+    libxkbcommon-dev libdrm-dev libgbm-dev libgl1-mesa-dev libgles2-mesa-dev \
+    libegl1-mesa-dev libdbus-1-dev libibus-1.0-dev libudev-dev
+
+Ubuntu 22.04+ can also add `libpipewire-0.3-dev libwayland-dev libdecor-0-dev liburing-dev` to that command line.
+
+Fedora 35, all available features enabled:
+
+    sudo yum install gcc git-core make cmake \
+    alsa-lib-devel pulseaudio-libs-devel nas-devel pipewire-devel \
+    libX11-devel libXext-devel libXrandr-devel libXcursor-devel libXfixes-devel \
+    libXi-devel libXScrnSaver-devel dbus-devel ibus-devel \
+    systemd-devel mesa-libGL-devel libxkbcommon-devel mesa-libGLES-devel \
+    mesa-libEGL-devel vulkan-devel wayland-devel wayland-protocols-devel \
+    libdrm-devel mesa-libgbm-devel libusb-devel libdecor-devel \
+    pipewire-jack-audio-connection-kit-devel \
+
+Fedora 39+ can also add `liburing-devel` to that command line.
+
+NOTES:
+- The sndio audio target is unavailable on Fedora (but probably not what you
+  should want to use anyhow).
+
+openSUSE Tumbleweed:
+
+    sudo zypper in libunwind-devel libusb-1_0-devel Mesa-libGL-devel libxkbcommon-devel libdrm-devel \
+    libgbm-devel pipewire-devel libpulse-devel sndio-devel Mesa-libEGL-devel
+
+Arch:
+    sudo pacman -S alsa-lib cmake hidapi ibus jack libdecor libgl libpulse libusb libx11 libxcursor libxext libxinerama libxkbcommon libxrandr libxrender libxss mesa ninja pipewire sndio vulkan-driver vulkan-headers wayland wayland-protocols
+
+
+Joystick does not work
+--------------------------------------------------------------------------------
+
+If you compiled or are using a version of SDL with udev support (and you should!)
+there's a few issues that may cause SDL to fail to detect your joystick. To
+debug this, start by installing the evtest utility. On Ubuntu/Debian:
+
+    sudo apt-get install evtest
+
+Then run:
+
+    sudo evtest
+
+You'll hopefully see your joystick listed along with a name like "/dev/input/eventXX"
+Now run:
+
+    cat /dev/input/event/XX
+
+If you get a permission error, you need to set a udev rule to change the mode of
+your device (see below)
+
+Also, try:
+
+    sudo udevadm info --query=all --name=input/eventXX
+
+If you see a line stating ID_INPUT_JOYSTICK=1, great, if you don't see it,
+you need to set up an udev rule to force this variable.
+
+A combined rule for the Saitek Pro Flight Rudder Pedals to fix both issues looks
+like:
+
+    SUBSYSTEM=="input", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
+    SUBSYSTEM=="input", ATTRS{idProduct}=="0764", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
+
+You can set up similar rules for your device by changing the values listed in
+idProduct and idVendor. To obtain these values, try:
+
+    sudo udevadm info -a --name=input/eventXX | grep idVendor
+    sudo udevadm info -a --name=input/eventXX | grep idProduct
+
+If multiple values come up for each of these, the one you want is the first one of each.
+
+On other systems which ship with an older udev (such as CentOS), you may need
+to set up a rule such as:
+
+    SUBSYSTEM=="input", ENV{ID_CLASS}=="joystick", ENV{ID_INPUT_JOYSTICK}="1"
+

vendor/sdl-3.2.10/docs/README-macos.md

@@ -0,0 +1,251 @@
+# macOS
+
+These instructions are for people using Apple's macOS.
+
+From the developer's point of view, macOS is a sort of hybrid Mac and
+Unix system, and you have the option of using either traditional
+command line tools or Apple's IDE Xcode.
+
+# Command Line Build
+
+To build SDL using the command line, use the CMake build script:
+
+```bash
+mkdir build
+cd build
+cmake .. -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
+cmake --build .
+sudo cmake --install .
+```
+
+
+You can also build SDL as a Universal library (a single binary for both
+64-bit Intel and ARM architectures):
+
+```bash
+mkdir build
+cd build
+cmake .. "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
+cmake --build .
+sudo cmake --install .
+```
+
+Please note that building SDL requires at least Xcode 12.2 and the macOS 11.0 SDK.
+
+To use the library once it's built, you essential have two possibilities:
+use the traditional autoconf/automake/make method, or use Xcode.
+
+
+# Caveats for using SDL with macOS
+
+If you register your own NSApplicationDelegate (using [NSApp setDelegate:]),
+SDL will not register its own. This means that SDL will not terminate using
+SDL_Quit if it receives a termination request, it will terminate like a
+normal app, and it will not send a SDL_EVENT_DROP_FILE when you request to open a
+file with the app. To solve these issues, put the following code in your
+NSApplicationDelegate implementation:
+
+
+```objc
+- (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
+{
+    if (SDL_GetEventState(SDL_EVENT_QUIT) == SDL_ENABLE) {
+        SDL_Event event;
+        SDL_zero(event);
+        event.type = SDL_EVENT_QUIT;
+        SDL_PushEvent(&event);
+    }
+
+    return NSTerminateCancel;
+}
+
+- (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
+{
+    if (SDL_GetEventState(SDL_EVENT_DROP_FILE) == SDL_ENABLE) {
+        SDL_Event event;
+        SDL_zero(event);
+        event.type = SDL_EVENT_DROP_FILE;
+        event.drop.file = SDL_strdup([filename UTF8String]);
+        return SDL_PushEvent(&event);
+    }
+
+    return NO;
+}
+```
+
+# Using the Simple DirectMedia Layer with a traditional Makefile
+
+An existing build system for your SDL app has good chances to work almost
+unchanged on macOS, as long as you link with the SDL framework. However,
+to produce a "real" Mac binary that you can distribute to users, you need
+to put the generated binary into a so called "bundle", which is basically
+a fancy folder with a name like "MyCoolGame.app".
+
+To get this build automatically, add something like the following rule to
+your Makefile.am:
+
+```make
+bundle_contents = APP_NAME.app/Contents
+APP_NAME_bundle: EXE_NAME
+	mkdir -p $(bundle_contents)/MacOS
+	mkdir -p $(bundle_contents)/Resources
+	echo "APPL????" > $(bundle_contents)/PkgInfo
+	$(INSTALL_PROGRAM) $< $(bundle_contents)/MacOS/
+```
+
+You should replace `EXE_NAME` with the name of the executable. `APP_NAME` is
+what will be visible to the user in the Finder. Usually it will be the same
+as `EXE_NAME` but capitalized. E.g. if `EXE_NAME` is "testgame" then `APP_NAME`
+usually is "TestGame". You might also want to use `@PACKAGE@` to use the
+package name as specified in your configure.ac file.
+
+If your project builds more than one application, you will have to do a bit
+more. For each of your target applications, you need a separate rule.
+
+If you want the created bundles to be installed, you may want to add this
+rule to your Makefile.am:
+
+```make
+install-exec-hook: APP_NAME_bundle
+	rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
+	mkdir -p $(DESTDIR)$(prefix)/Applications/
+	cp -r $< /$(DESTDIR)$(prefix)Applications/
+```
+
+This rule takes the Bundle created by the rule from step 3 and installs them
+into "$(DESTDIR)$(prefix)/Applications/".
+
+Again, if you want to install multiple applications, you will have to augment
+the make rule accordingly.
+
+But beware! That is only part of the story! With the above, you end up with
+a barebones .app bundle, which is double-clickable from the Finder. But
+there are some more things you should do before shipping your product...
+
+1. You'll need to copy the SDL framework into the Contents/Frameworks
+   folder in your bundle, so it is included along with your application.
+
+2. Add an 'Info.plist' to your application. That is a special XML file which
+   contains some meta-information about your application (like some copyright
+   information, the version of your app, the name of an optional icon file,
+   and other things). Part of that information is displayed by the Finder
+   when you click on the .app, or if you look at the "Get Info" window.
+   More information about Info.plist files can be found on Apple's homepage.
+
+
+As a final remark, let me add that I use some of the techniques (and some
+variations of them) in [Exult](https://github.com/exult/exult) and
+[ScummVM](https://github.com/scummvm/scummvm); both are available in source on
+the net, so feel free to take a peek at them for inspiration!
+
+
+# Using the Simple DirectMedia Layer with Xcode
+
+These instructions are for using Apple's Xcode IDE to build SDL applications.
+
+## First steps
+
+The first thing to do is to unpack the Xcode.tar.gz archive in the
+top level SDL directory (where the Xcode.tar.gz archive resides).
+Because Stuffit Expander will unpack the archive into a subdirectory,
+you should unpack the archive manually from the command line:
+
+```bash
+cd [path_to_SDL_source]
+tar zxf Xcode.tar.gz
+```
+
+This will create a new folder called Xcode, which you can browse
+normally from the Finder.
+
+## Building the Framework
+
+The SDL Library is packaged as a framework bundle, an organized
+relocatable folder hierarchy of executable code, interface headers,
+and additional resources. For practical purposes, you can think of a
+framework as a more user and system-friendly shared library, whose library
+file behaves more or less like a standard UNIX shared library.
+
+To build the framework, simply open the framework project and build it.
+By default, the framework bundle "SDL.framework" is installed in
+/Library/Frameworks. Therefore, the testers and project stationary expect
+it to be located there. However, it will function the same in any of the
+following locations:
+
+* ~/Library/Frameworks
+* /Local/Library/Frameworks
+* /System/Library/Frameworks
+
+## Build Options
+
+There are two "Build Styles" (See the "Targets" tab) for SDL.
+"Deployment" should be used if you aren't tweaking the SDL library.
+"Development" should be used to debug SDL apps or the library itself.
+
+## Building the Testers
+
+Open the SDLTest project and build away!
+
+## Using the Project Stationary
+
+Copy the stationary to the indicated folders to access it from
+the "New Project" and "Add target" menus. What could be easier?
+
+## Setting up a new project by hand
+
+Some of you won't want to use the Stationary so I'll give some tips:
+
+(this is accurate as of Xcode 12.5.)
+
+* Click "File" -> "New" -> "Project...
+* Choose "macOS" and then "App" from the "Application" section.
+* Fill out the options in the next window. User interface is "XIB" and
+  Language is "Objective-C".
+* Remove "main.m" from your project
+* Remove "MainMenu.xib" from your project
+* Remove "AppDelegates.*" from your project
+* Add "\$(HOME)/Library/Frameworks/SDL.framework/Headers" to include path
+* Add "\$(HOME)/Library/Frameworks" to the frameworks search path
+* Add "-framework SDL -framework Foundation -framework AppKit" to "OTHER_LDFLAGS"
+* Add your files
+* Clean and build
+
+## Building from command line
+
+Use `xcode-build` in the same directory as your .pbxproj file
+
+## Running your app
+
+You can send command line args to your app by either invoking it from
+the command line (in *.app/Contents/MacOS) or by entering them in the
+Executables" panel of the target settings.
+
+# Implementation Notes
+
+Some things that may be of interest about how it all works...
+
+## Working directory
+
+In SDL 1.2, the working directory of your SDL app is by default set to its
+parent, but this is no longer the case in SDL 2.0 and later. SDL2 does not
+change the working directory, which means it'll be whatever the command line
+prompt that launched the program was using, or if launched by double-clicking
+in the Finder, it will be "/", the _root of the filesystem_. Plan accordingly!
+You can use SDL_GetBasePath() to find where the program is running from and
+chdir() there directly.
+
+
+## You have a Cocoa App!
+
+Your SDL app is essentially a Cocoa application. When your app
+starts up and the libraries finish loading, a Cocoa procedure is called,
+which sets up the working directory and calls your main() method.
+You are free to modify your Cocoa app with generally no consequence
+to SDL. You cannot, however, easily change the SDL window itself.
+Functionality may be added in the future to help this.
+
+# Bug reports
+
+Bugs are tracked at [the GitHub issue tracker](https://github.com/libsdl-org/SDL/issues/).
+Please feel free to report bugs there!
+

vendor/sdl-3.2.10/docs/README-main-functions.md

@@ -0,0 +1,236 @@
+# Where an SDL program starts running.
+
+## History
+
+SDL has a long, complicated history with starting a program.
+
+In most of the civilized world, an application starts in a C-callable
+function named "main". You probably learned it a long time ago:
+
+```c
+int main(int argc, char **argv)
+{
+    printf("Hello world!\n");
+    return 0;
+}
+```
+
+But not all platforms work like this. Windows apps might want a different
+function named "WinMain", for example, so SDL set out to paper over this
+difference.
+
+Generally how this would work is: your app would always use the "standard"
+`main(argc, argv)` function as its entry point, and `#include` the proper
+SDL header before that, which did some macro magic. On platforms that used
+a standard `main`, it would do nothing and what you saw was what you got.
+
+But those other platforms! If they needed something that _wasn't_ `main`,
+SDL's macro magic would quietly rename your function to `SDL_main`, and
+provide its own entry point that called it. Your app was none the wiser and
+your code worked everywhere without changes.
+
+
+## The main entry point in SDL3
+
+Previous versions of SDL had a static library, SDLmain, that you would link
+your app against. SDL3 still has the same macro tricks, but the static library
+is gone. Now it's supplied by a "single-header library," which means you
+`#include <SDL3/SDL_main.h>` and that header will insert a small amount of
+code into the source file that included it, so you no longer have to worry
+about linking against an extra library that you might need on some platforms.
+You just build your app and it works.
+
+You should _only_ include SDL_main.h from one file (the umbrella header,
+SDL.h, does _not_ include it), and know that it will `#define main` to
+something else, so if you use this symbol elsewhere as a variable name, etc,
+it can cause you unexpected problems.
+
+SDL_main.h will also include platform-specific code (WinMain or whatnot) that
+calls your _actual_ main function. This is compiled directly into your
+program.
+
+If for some reason you need to include SDL_main.h in a file but also _don't_
+want it to generate this platform-specific code, you should define a special
+macro before including the header:
+
+
+```c
+#define SDL_MAIN_NOIMPL
+```
+
+If you are moving from SDL2, remove any references to the SDLmain static
+library from your build system, and you should be done. Things should work as
+they always have.
+
+If you have never controlled your process's entry point (you are using SDL
+as a module from a general-purpose scripting language interpreter, or you're
+using SDL in a plugin for some otherwise-unrelated app), then there is nothing
+required of you here; there is no startup code in SDL's entry point code that
+is required, so using SDL_main.h is completely optional. Just start using
+the SDL API when you are ready.
+
+
+## Main callbacks in SDL3
+
+There is a second option in SDL3 for how to structure your program. This is
+completely optional and you can ignore it if you're happy using a standard
+"main" function.
+
+Some platforms would rather your program operate in chunks. Most of the time,
+games tend to look like this at the highest level:
+
+```c
+int main(int argc, char **argv)
+{
+    initialize();
+    while (keep_running()) {
+        handle_new_events();
+        do_one_frame_of_stuff();
+    }
+    deinitialize();
+}
+```
+
+There are platforms that would rather be in charge of that `while` loop:
+iOS would rather you return from main() immediately and then it will let you
+know that it's time to update and draw the next frame of video. Emscripten
+(programs that run on a web page) absolutely requires this to function at all.
+Video targets like Wayland can notify the app when to draw a new frame, to
+save battery life and cooperate with the compositor more closely.
+
+In most cases, you can add special-case code to your program to deal with this
+on different platforms, but SDL3 offers a system to handle this transparently on
+the app's behalf.
+
+To use this, you have to redesign the highest level of your app a little. Once
+you do, it'll work on all supported SDL platforms without problems and
+`#ifdef`s in your code.
+
+Instead of providing a "main" function, under this system, you would provide
+several functions that SDL will call as appropriate.
+
+Using the callback entry points works on every platform, because on platforms
+that don't require them, we can fake them with a simple loop in an internal
+implementation of the usual SDL_main.
+
+The primary way we expect people to write SDL apps is still with SDL_main, and
+this is not intended to replace it. If the app chooses to use this, it just
+removes some platform-specific details they might have to otherwise manage,
+and maybe removes a barrier to entry on some future platform. And you might
+find you enjoy structuring your program like this more!
+
+
+## How to use main callbacks in SDL3
+
+To enable the callback entry points, you include SDL_main.h with an extra define,
+from a single source file in your project:
+
+```c
+#define SDL_MAIN_USE_CALLBACKS
+#include <SDL3/SDL_main.h>
+```
+
+Once you do this, you do not write a "main" function at all (and if you do,
+the app will likely fail to link). Instead, you provide the following
+functions:
+
+First:
+
+```c
+SDL_AppResult SDL_AppInit(void **appstate, int argc, char **argv);
+```
+
+This will be called _once_ before anything else. argc/argv work like they
+always do. If this returns SDL_APP_CONTINUE, the app runs. If it returns
+SDL_APP_FAILURE, the app calls SDL_AppQuit and terminates with an exit
+code that reports an error to the platform. If it returns SDL_APP_SUCCESS,
+the app calls SDL_AppQuit and terminates with an exit code that reports
+success to the platform. This function should not go into an infinite
+mainloop; it should do any one-time startup it requires and then return.
+
+If you want to, you can assign a pointer to `*appstate`, and this pointer
+will be made available to you in later functions calls in their `appstate`
+parameter. This allows you to avoid global variables, but is totally
+optional. If you don't set this, the pointer will be NULL in later function
+calls.
+
+
+Then:
+
+```c
+SDL_AppResult SDL_AppIterate(void *appstate);
+```
+
+This is called over and over, possibly at the refresh rate of the display or
+some other metric that the platform dictates. This is where the heart of your
+app runs. It should return as quickly as reasonably possible, but it's not a
+"run one memcpy and that's all the time you have" sort of thing. The app
+should do any game updates, and render a frame of video. If it returns
+SDL_APP_FAILURE, SDL will call SDL_AppQuit and terminate the process with an
+exit code that reports an error to the platform. If it returns
+SDL_APP_SUCCESS, the app calls SDL_AppQuit and terminates with an exit code
+that reports success to the platform. If it returns SDL_APP_CONTINUE, then
+SDL_AppIterate will be called again at some regular frequency. The platform
+may choose to run this more or less (perhaps less in the background, etc),
+or it might just call this function in a loop as fast as possible. You do
+not check the  event queue in this function (SDL_AppEvent exists for that).
+
+Next:
+
+```c
+SDL_AppResult SDL_AppEvent(void *appstate, SDL_Event *event);
+```
+
+This will be called whenever an SDL event arrives. Your app should not call
+SDL_PollEvent, SDL_PumpEvent, etc, as  SDL will manage all this for you. Return
+values are the same as from SDL_AppIterate(), so you can terminate in response
+to SDL_EVENT_QUIT, etc.
+
+
+Finally:
+
+```c
+void SDL_AppQuit(void *appstate, SDL_AppResult result);
+```
+
+This is called once before terminating the app--assuming the app isn't being
+forcibly killed or crashed--as a last chance to clean up. After this returns,
+SDL will call SDL_Quit so the app doesn't have to (but it's safe for the app
+to call it, too). Process termination proceeds as if the app returned normally
+from main(), so atexit handles will run, if your platform supports that.
+
+If you set `*appstate` during SDL_AppInit, this is where you should free that
+data, as this pointer will not be provided to your app again.
+
+The SDL_AppResult value that terminated the app is provided here, in case
+it's useful to know if this was a successful or failing run of the app.
+
+
+## Summary and Best Practices
+
+- **Always Include SDL_main.h in One Source File:** When working with SDL,
+  remember that SDL_main.h must only be included in one source file in your
+  project. Including it in multiple files will lead to conflicts and undefined
+  behavior.
+
+- **Avoid Redefining main:** If you're using SDL's entry point system (which
+  renames `main` to `SDL_main`), do not define `main` yourself. SDL takes care
+  of this for you, and redefining it can cause issues, especially when linking
+  with SDL libraries.
+
+- **Using SDL's Callback System:** If you're working with more complex
+  scenarios, such as requiring more control over your application's flow
+  (e.g., with games or apps that need extensive event handling), consider
+  using SDL's callback system. Define the necessary callbacks and SDL will
+  handle initialization, event processing, and cleanup automatically.
+
+- **Platform-Specific Considerations:** On platforms like Windows, SDL handles
+  the platform-specific entry point (like `WinMain`) automatically. This means
+  you don't need to worry about writing platform-specific entry code when
+  using SDL.
+
+- **When to Skip SDL_main.h:** If you do not require SDL's custom entry point
+  (for example, if you're integrating SDL into an existing application or a
+  scripting environment), you can omit SDL_main.h. However, this will limit
+  SDL's ability to abstract away platform-specific entry point details.
+

vendor/sdl-3.2.10/docs/README-n3ds.md

@@ -0,0 +1,28 @@
+# Nintendo 3DS
+
+SDL port for the Nintendo 3DS [Homebrew toolchain](https://devkitpro.org/) contributed by:
+
+-   [Pierre Wendling](https://github.com/FtZPetruska)
+
+Credits to:
+
+-   The awesome people who ported SDL to other homebrew platforms.
+-   The Devkitpro team for making all the tools necessary to achieve this.
+
+## Building
+
+To build for the Nintendo 3DS, make sure you have devkitARM and cmake installed and run:
+
+```bash
+cmake -S. -Bbuild -DCMAKE_TOOLCHAIN_FILE="$DEVKITPRO/cmake/3DS.cmake" -DCMAKE_BUILD_TYPE=Release
+cmake --build build
+cmake --install build
+```
+
+## Notes
+
+-   Currently only software rendering is supported.
+-   SDL3_main should be used to ensure ROMFS is enabled - this is done with `#include <SDL3/SDL_main.h>` in the source file that contains your main function.
+-   By default, the extra L2 cache and higher clock speeds of the New 2/3DS lineup are enabled. If you wish to turn it off, use `osSetSpeedupEnable(false)` in your main function.
+-   `SDL_GetBasePath` returns the romfs root instead of the executable's directory.
+-   The Nintendo 3DS uses a cooperative threading model on a single core, meaning a thread will never yield unless done manually through the `SDL_Delay` functions, or blocking waits (`SDL_LockMutex`, `SDL_WaitSemaphore`, `SDL_WaitCondition`, `SDL_WaitThread`). To avoid starving other threads, `SDL_TryWaitSemaphore` and `SDL_WaitSemaphoreTimeout` will yield if they fail to acquire the semaphore, see https://github.com/libsdl-org/SDL/pull/6776 for more information.

vendor/sdl-3.2.10/docs/README-ngage.md

@@ -0,0 +1,5 @@
+Support for the Nokia N-Gage has been removed from SDL3 (but will make a
+comeback when newer compilers are available for the platform).
+
+SDL2 still supports this platform.
+

vendor/sdl-3.2.10/docs/README-platforms.md

@@ -0,0 +1,40 @@
+# Platforms
+
+## Supported Platforms
+
+- [Android](README-android.md)
+- [Emscripten](README-emscripten.md)
+- [FreeBSD](README-bsd.md)
+- [Haiku OS](README-haiku.md)
+- [iOS](README-ios.md)
+- [Linux](README-linux.md)
+- [macOS](README-macos.md)
+- [NetBSD](README-bsd.md)
+- [Nintendo Switch](README-switch.md)
+- [Nintendo 3DS](README-3ds.md)
+- [OpenBSD](README-bsd.md)
+- [PlayStation 2](README-ps2.md)
+- [PlayStation 4](README-ps4.md)
+- [PlayStation 5](README-ps5.md)
+- [PlayStation Portable](README-psp.md)
+- [PlayStation Vita](README-vita.md)
+- [RISC OS](README-riscos.md)
+- [SteamOS](README-steamos.md)
+- [tvOS](README-ios.md)
+- [Windows](README-windows.md)
+- [Windows GDK](README-gdk.md)
+- [Xbox](README-gdk.md)
+
+## Unsupported Platforms
+
+If your favorite system is listed below, we aren't working on it. However, if you send reasonable patches and are willing to support the port in the long term, we are happy to take a look!
+
+All of these still work with [SDL2](/SDL2), which is an incompatible API, but an option if you need to support these platforms still.
+
+- Google Stadia
+- NaCL
+- Nokia N-Gage
+- OS/2
+- QNX
+- WinPhone
+- WinRT/UWP

vendor/sdl-3.2.10/docs/README-porting.md

@@ -0,0 +1,65 @@
+Porting
+=======
+
+* Porting To A New Platform
+
+  The first thing you have to do when porting to a new platform, is look at
+include/SDL_platform.h and create an entry there for your operating system.
+The standard format is "SDL_PLATFORM_X", where X is the name of the OS.
+Ideally SDL_platform_defines.h will be able to auto-detect the system it's building
+on based on C preprocessor symbols.
+
+There are two basic ways of building SDL at the moment:
+
+1. CMake:  cmake -S . -B build && cmake --build build && cmake --install install
+
+   If you have a system that supports CMake, then you might try this.  Edit CMakeLists.txt,
+
+   take a look at the large section labelled:
+
+	"Platform-specific options and settings!"
+
+   Add a section for your platform, and then re-run 'cmake -S . -B build' and build!
+
+2. Using an IDE:
+
+   If you're using an IDE or other non-configure build system, you'll probably want to create a custom `SDL_build_config.h` for your platform.  Edit `include/build_config/SDL_build_config.h`, add a section for your platform, and create a custom `SDL_build_config_{platform}.h`, based on `SDL_build_config_minimal.h` and `SDL_build_config.h.cmake`
+
+   Add the top level include directory to the header search path, and then add
+   the following sources to the project:
+
+	src/*.c
+	src/atomic/*.c
+	src/audio/*.c
+	src/cpuinfo/*.c
+	src/events/*.c
+	src/file/*.c
+	src/haptic/*.c
+	src/joystick/*.c
+	src/power/*.c
+	src/render/*.c
+	src/render/software/*.c
+	src/stdlib/*.c
+	src/thread/*.c
+	src/timer/*.c
+	src/video/*.c
+	src/audio/disk/*.c
+	src/audio/dummy/*.c
+	src/filesystem/dummy/*.c
+	src/video/dummy/*.c
+	src/haptic/dummy/*.c
+	src/joystick/dummy/*.c
+	src/thread/generic/*.c
+	src/timer/dummy/*.c
+	src/loadso/dummy/*.c
+
+
+Once you have a working library without any drivers, you can go back to each
+of the major subsystems and start implementing drivers for your platform.
+
+If you have any questions, don't hesitate to ask on the SDL mailing list:
+	http://www.libsdl.org/mailing-list.php
+
+Enjoy!
+	Sam Lantinga				(slouken@libsdl.org)
+

vendor/sdl-3.2.10/docs/README-ps2.md

@@ -0,0 +1,47 @@
+PS2
+======
+SDL port for the Sony Playstation 2 contributed by:
+- Francisco Javier Trujillo Mata
+
+
+Credit to
+   - The guys that ported SDL to PSP & Vita because I'm taking them as reference.
+   - David G. F. for helping me with several issues and tests.
+
+## Building
+To build SDL library for the PS2, make sure you have the latest PS2Dev status and run:
+```bash
+cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=$PS2DEV/ps2sdk/ps2dev.cmake
+cmake --build build
+cmake --install build
+```
+
+## Notes
+If you trying to debug a SDL app through [ps2client](https://github.com/ps2dev/ps2client) you need to avoid the IOP reset, otherwise you will lose the connection with your computer.
+So to avoid the reset of the IOP CPU, you need to call to the macro `SDL_PS2_SKIP_IOP_RESET();`.
+It could be something similar as:
+```c
+.....
+
+SDL_PS2_SKIP_IOP_RESET();
+
+int main(int argc, char *argv[])
+{
+.....
+```
+For a release binary is recommendable to reset the IOP always.
+
+Remember to do a clean compilation every time you enable or disable the `SDL_PS2_SKIP_IOP_RESET` otherwise the change won't be reflected.
+
+## Getting PS2 Dev
+[Installing PS2 Dev](https://github.com/ps2dev/ps2dev)
+
+## Running on PCSX2 Emulator
+[PCSX2](https://github.com/PCSX2/pcsx2)
+
+[More PCSX2 information](https://pcsx2.net/)
+
+## To Do
+- PS2 Screen Keyboard
+- Dialogs
+- Others

vendor/sdl-3.2.10/docs/README-ps4.md

@@ -0,0 +1,3 @@
+# Sony PlayStation 4
+
+SDL3 runs on the PS4! There are commercial games shipping with this port. This port is kept in a separate repository, but is available for free, under the zlib license, to anyone that is under NDA for PlayStation development with Sony. Please contact Ryan (icculus at icculus dot org) for details.

vendor/sdl-3.2.10/docs/README-ps5.md

@@ -0,0 +1,3 @@
+# Sony PlayStation 5
+
+SDL3 runs on the PS5! There are commercial games shipping with this port. This port is kept in a separate repository, but is available for free, under the zlib license, to anyone that is under NDA for PlayStation development with Sony. Please contact Ryan (icculus at icculus dot org) for details.

vendor/sdl-3.2.10/docs/README-psp.md

@@ -0,0 +1,36 @@
+PSP
+======
+SDL port for the Sony PSP contributed by:
+- Captian Lex
+- Francisco Javier Trujillo Mata
+- Wouter Wijsman
+
+
+Credit to
+   Marcus R.Brown,Jim Paris,Matthew H for the original SDL 1.2 for PSP
+   Geecko for his PSP GU lib "Glib2d"
+
+## Building
+To build SDL library for the PSP, make sure you have the latest PSPDev status and run:
+```bash
+cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=$PSPDEV/psp/share/pspdev.cmake
+cmake --build build
+cmake --install build
+```
+
+
+## Getting PSP Dev
+[Installing PSP Dev](https://github.com/pspdev/pspdev)
+
+## Running on PPSSPP Emulator
+[PPSSPP](https://github.com/hrydgard/ppsspp)
+
+[Build Instructions](https://github.com/hrydgard/ppsspp/wiki/Build-instructions)
+
+
+## Compiling a HelloWorld
+[PSP Hello World](https://pspdev.github.io/basic_programs.html#hello-world)
+
+## To Do
+- PSP Screen Keyboard
+- Dialogs

vendor/sdl-3.2.10/docs/README-riscos.md

@@ -0,0 +1,35 @@
+RISC OS
+=======
+
+Requirements:
+
+* RISC OS 3.5 or later.
+* [SharedUnixLibrary](http://www.riscos.info/packages/LibraryDetails.html#SharedUnixLibraryarm).
+* [DigitalRenderer](http://www.riscos.info/packages/LibraryDetails.html#DRendererarm), for audio support.
+* [Iconv](http://www.netsurf-browser.org/projects/iconv/), for `SDL_iconv` and related functions.
+
+
+Compiling:
+----------
+
+Currently, SDL for RISC OS only supports compiling with GCCSDK under Linux.
+
+The following commands can be used to build SDL for RISC OS using CMake:
+
+    cmake -Bbuild-riscos -DCMAKE_TOOLCHAIN_FILE=$GCCSDK_INSTALL_ENV/toolchain-riscos.cmake -DRISCOS=ON -DCMAKE_INSTALL_PREFIX=$GCCSDK_INSTALL_ENV -DCMAKE_BUILD_TYPE=Release
+    cmake --build build-riscos
+    cmake --install build-riscos
+
+When using GCCSDK 4.7.4 release 6 or earlier versions, the builtin atomic functions are broken, meaning it's currently necessary to compile with `-DSDL_GCC_ATOMICS=OFF` using CMake. Newer versions of GCCSDK don't have this problem.
+
+
+Current level of implementation
+-------------------------------
+
+The video driver currently provides full screen video support with keyboard and mouse input. Windowed mode is not yet supported, but is planned in the future. Only software rendering is supported.
+
+The filesystem APIs return either Unix-style paths or RISC OS-style paths based on the value of the `__riscosify_control` symbol, as is standard for UnixLib functions.
+
+The audio, loadso, thread and timer APIs are currently provided by UnixLib.
+
+The joystick, locale and power APIs are not yet implemented.

vendor/sdl-3.2.10/docs/README-steamos.md

@@ -0,0 +1,10 @@
+# SteamOS
+
+SteamOS is literally a Linux system, and uses the same binaries you distribute to generic Linux Steam users, so generally speaking, all the other [Linux advice](README-linux.md) applies.
+
+If you are shipping a Linux game on Steam, or explicitly targeting SteamOS, the system is guaranteed to provide SDL. The Steam Client will set up the dynamic loader path so that a known-good copy of SDL is available to any program that needs it before launching a game. Steam provides all major versions of SDL to date, in this manner, for both x86 and amd64, in addition to several add-on libraries like `SDL_image` and `SDL_mixer`. When shipping a Linux game on Steam, do not ship a build of SDL with your game. Link against SDL as normal, and expect it to be available on the player's system. This allows Valve to make fixes and improvements to their SDL and those fixes to flow on to your game.
+
+We are obsessive about SDL3 having a backwards-compatible ABI. Whether you build your game using the Steam Runtime SDK or just about any other copy of SDL, it _should_ work with the one that ships with Steam.
+
+In fact, it's not a bad idea to just copy the SDL build out of the Steam Runtime if you plan to ship a Linux game for non-Steam platforms, too, since you know it's definitely well-built.
+

vendor/sdl-3.2.10/docs/README-strings.md

@@ -0,0 +1,7 @@
+# String policies in SDL3.
+
+## Encoding.
+
+Unless otherwise specified, all strings in SDL, across all platforms, are
+UTF-8 encoded and can represent the full range of [Unicode](https://unicode.org).
+

vendor/sdl-3.2.10/docs/README-switch.md

@@ -0,0 +1,3 @@
+# Nintendo Switch
+
+SDL3 runs on the Nintendo Switch! There are commercial games shipping with this port. This port is kept in a separate repository, but is available for free, under the zlib license, to anyone that is under NDA for Switch development with Nintendo. Please contact Ryan (icculus at icculus dot org) for details.

vendor/sdl-3.2.10/docs/README-touch.md

@@ -0,0 +1,81 @@
+Touch
+===========================================================================
+System Specific Notes
+===========================================================================
+Linux:
+The linux touch system is currently based off event streams, and proc/bus/devices. The active user must be given permissions to read /dev/input/TOUCHDEVICE, where TOUCHDEVICE is the event stream for your device. Currently only Wacom tablets are supported. If you have an unsupported tablet contact me at jim.tla+sdl_touch@gmail.com and I will help you get support for it.
+
+Mac:
+The Mac and iPhone APIs are pretty. If your touch device supports them then you'll be fine. If it doesn't, then there isn't much we can do.
+
+iPhone:
+Works out of box.
+
+Windows:
+Unfortunately there is no windows support as of yet. Support for Windows 7 is planned, but we currently have no way to test. If you have a Windows 7 WM_TOUCH supported device, and are willing to help test please contact me at jim.tla+sdl_touch@gmail.com
+
+
+Events
+===========================================================================
+SDL_EVENT_FINGER_DOWN:
+Sent when a finger (or stylus) is placed on a touch device.
+Fields:
+* event.tfinger.touchId  - the Id of the touch device.
+* event.tfinger.fingerId - the Id of the finger which just went down.
+* event.tfinger.x        - the x coordinate of the touch (0..1)
+* event.tfinger.y        - the y coordinate of the touch (0..1)
+* event.tfinger.pressure - the pressure of the touch (0..1)
+
+SDL_EVENT_FINGER_MOTION:
+Sent when a finger (or stylus) is moved on the touch device.
+Fields:
+Same as SDL_EVENT_FINGER_DOWN but with additional:
+* event.tfinger.dx       - change in x coordinate during this motion event.
+* event.tfinger.dy       - change in y coordinate during this motion event.
+
+SDL_EVENT_FINGER_UP:
+Sent when a finger (or stylus) is lifted from the touch device.
+Fields:
+Same as SDL_EVENT_FINGER_DOWN.
+
+
+Functions
+===========================================================================
+SDL provides the ability to access the underlying SDL_Finger structures.
+These structures should _never_ be modified.
+
+The following functions are included from SDL_touch.h
+
+Devices are tracked by instance ID, of type SDL_TouchID.
+
+To get a list of available device SDL_TouchID values, call SDL_GetTouchDevices().
+This returns an array of device IDs, terminated by a zero ID. Optionally, you can
+get a count of IDs by passing a non-NULL int* to SDL_GetTouchDevices() if you'd
+rather not iterate the whole array to get this number.
+
+A SDL_TouchID may be used to get pointers to SDL_Finger.
+
+SDL_GetNumTouchFingers(touchID) may be used to get the number of fingers currently down on the device.
+
+The most common reason to access SDL_Finger is to query the fingers outside the event. In most cases accessing the fingers is using the event. This would be accomplished by code like the following:
+
+      float x = event.tfinger.x;
+      float y = event.tfinger.y;
+
+
+
+To get a SDL_Finger, call SDL_GetTouchFinger(SDL_TouchID touchID, int index), where touchID is a SDL_TouchID, and index is the requested finger.
+This returns a SDL_Finger *, or NULL if the finger does not exist, or has been removed.
+A SDL_Finger is guaranteed to be persistent for the duration of a touch, but it will be de-allocated as soon as the finger is removed. This occurs when the SDL_EVENT_FINGER_UP event is _added_ to the event queue, and thus _before_ the SDL_EVENT_FINGER_UP event is polled.
+As a result, be very careful to check for NULL return values.
+
+A SDL_Finger has the following fields:
+* x, y:
+	The current coordinates of the touch.
+* pressure:
+	The pressure of the touch.
+
+
+Please direct questions/comments to:
+   jim.tla+sdl_touch@gmail.com
+   (original author, API was changed since)

vendor/sdl-3.2.10/docs/README-versions.md

@@ -0,0 +1,60 @@
+# Versioning
+
+## Since 2.23.0
+
+SDL follows an "odd/even" versioning policy, similar to GLib, GTK, Flatpak
+and older versions of the Linux kernel:
+
+* The major version (first part) increases when backwards compatibility
+    is broken, which will happen infrequently.
+
+* If the minor version (second part) is divisible by 2
+    (for example 2.24.x, 2.26.x), this indicates a version of SDL that
+    is believed to be stable and suitable for production use.
+
+    * In stable releases, the patchlevel or micro version (third part)
+        indicates bugfix releases. Bugfix releases should not add or
+        remove ABI, so the ".0" release (for example 2.24.0) should be
+        forwards-compatible with all the bugfix releases from the
+        same cycle (for example 2.24.1).
+
+    * The minor version increases when new API or ABI is added, or when
+        other significant changes are made. Newer minor versions are
+        backwards-compatible, but not fully forwards-compatible.
+        For example, programs built against SDL 2.24.x should work fine
+        with SDL 2.26.x, but programs built against SDL 2.26.x will not
+        necessarily work with 2.24.x.
+
+* If the minor version (second part) is not divisible by 2
+    (for example 2.23.x, 2.25.x), this indicates a development prerelease
+    of SDL that is not suitable for stable software distributions.
+    Use with caution.
+
+    * The patchlevel or micro version (third part) increases with
+        each prerelease.
+
+    * Each prerelease might add new API and/or ABI.
+
+    * Prereleases are backwards-compatible with older stable branches.
+        For example, 2.25.x will be backwards-compatible with 2.24.x.
+
+    * Prereleases are not guaranteed to be backwards-compatible with
+        each other. For example, new API or ABI added in 2.25.1
+        might be removed or changed in 2.25.2.
+        If this would be a problem for you, please do not use prereleases.
+
+    * Only upgrade to a prerelease if you can guarantee that you will
+        promptly upgrade to the stable release that follows it.
+        For example, do not upgrade to 2.23.x unless you will be able to
+        upgrade to 2.24.0 when it becomes available.
+
+    * Software distributions that have a freeze policy (in particular Linux
+        distributions with a release cycle, such as Debian and Fedora)
+        should usually only package stable releases, and not prereleases.
+
+## Before 2.23.0
+
+Older versions of SDL followed a similar policy, but instead of the
+odd/even rule applying to the minor version, it applied to the patchlevel
+(micro version, third part). For example, 2.0.22 was a stable release
+and 2.0.21 was a prerelease.

vendor/sdl-3.2.10/docs/README-vita.md

@@ -0,0 +1,33 @@
+PS Vita
+=======
+SDL port for the Sony Playstation Vita and Sony Playstation TV
+
+Credit to
+* xerpi, cpasjuste and rsn8887 for initial (vita2d) port
+* vitasdk/dolcesdk devs
+* CBPS discord (Namely Graphene and SonicMastr)
+
+Building
+--------
+To build for the PSVita, make sure you have vitasdk and cmake installed and run:
+```sh
+cmake -S. -Bbuild -DCMAKE_TOOLCHAIN_FILE=${VITASDK}/share/vita.toolchain.cmake -DCMAKE_BUILD_TYPE=Release
+cmake --build build
+cmake --install build
+```
+
+
+Notes
+-----
+* gles1/gles2 support and renderers are disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PVR=ON`
+  These renderers support 720p and 1080i resolutions. These can be specified with:
+  `SDL_SetHint(SDL_HINT_VITA_RESOLUTION, "720");` and `SDL_SetHint(SDL_HINT_VITA_RESOLUTION, "1080");`
+* Desktop GL 1.X and 2.X support and renderers are also disabled by default and also can be enabled with `-DVIDEO_VITA_PVR=ON` as long as gl4es4vita is present in your SDK.
+  They support the same resolutions as the gles1/gles2 backends and require specifying `SDL_SetHint(SDL_HINT_VITA_PVR_OPENGL, "1");`
+  anytime before video subsystem initialization.
+* gles2 support via PIB is disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PIB=ON`
+* By default SDL emits mouse events for touch events on every touchscreen.
+  Vita has two touchscreens, so it's recommended to use `SDL_SetHint(SDL_HINT_TOUCH_MOUSE_EVENTS, "0");` and handle touch events instead.
+  Individual touchscreens can be disabled with:
+  `SDL_SetHint(SDL_HINT_VITA_ENABLE_FRONT_TOUCH, "0");` and `SDL_SetHint(SDL_HINT_VITA_ENABLE_BACK_TOUCH, "0");`
+* Support for L2/R2/R3/R3 buttons, haptic feedback and gamepad led only available on PSTV, or when using external ds4 gamepad on vita.

vendor/sdl-3.2.10/docs/README-wayland.md

@@ -0,0 +1,242 @@
+Wayland
+=======
+Wayland is a replacement for the X11 window system protocol and architecture and is favored over X11 by default in SDL3
+for communicating with desktop compositors. It works well for the majority of applications, however, applications may
+encounter limitations or behavior that is different from other windowing systems.
+
+## Common issues:
+
+### Legacy, DPI-unaware applications are blurry
+
+- Wayland handles high-DPI displays by scaling the desktop, which causes applications that are not designed to be
+  DPI-aware to be automatically scaled by the window manager, which results in them being blurry. SDL can _attempt_ to
+  scale these applications such that they will be output with a 1:1 pixel aspect, however this may be buggy, especially
+  with odd-sized windows and/or scale factors that aren't quarter-increments (125%, 150%, etc...). To enable this, set
+  the environment variable `SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1`
+
+### Window decorations are missing, or the decorations look strange
+
+- On some desktops (i.e. GNOME), Wayland applications use a library
+  called [libdecor](https://gitlab.freedesktop.org/libdecor/libdecor) to provide window decorations. If this library is
+  not installed, the decorations will be missing. This library uses plugins to generate different decoration styles, and
+  if a plugin to generate native-looking decorations is not installed (i.e. the GTK plugin), the decorations will not
+  appear to be 'native'.
+
+### Windows do not appear immediately after creation
+
+- Wayland requires that the application initially present a buffer before the window becomes visible. Additionally,
+  applications _must_ have an event loop and processes messages on a regular basis, or the application can appear
+  unresponsive to both the user and desktop compositor.
+
+### The display reported as the primary by ```SDL_GetPrimaryDisplay()``` is incorrect
+
+- Wayland doesn't natively have the concept of a primary display, so SDL attempts to determine it by querying various
+  system settings, and falling back to a selection algorithm if this fails. If it is incorrect, it can be manually
+  overridden by setting the ```SDL_VIDEO_DISPLAY_PRIORITY``` hint.
+
+### ```SDL_SetWindowPosition()``` doesn't work on non-popup windows
+
+- Wayland does not allow toplevel windows to position themselves programmatically.
+
+### Retrieving the global mouse cursor position when the cursor is outside a window doesn't work
+
+- Wayland only provides applications with the cursor position within the borders of the application windows. Querying
+  the global position when an application window does not have mouse focus returns 0,0 as the actual cursor position is
+  unknown. In most cases, applications don't actually need the global cursor position and should use the window-relative
+  coordinates as provided by the mouse movement event or from ```SDL_GetMouseState()``` instead.
+
+### Warping the mouse cursor to or from a point outside the window doesn't work
+
+- The cursor can be warped only within the window with mouse focus, provided that the `zwp_pointer_confinement_v1`
+  protocol is supported by the compositor.
+
+### The application icon can't be set via ```SDL_SetWindowIcon()```
+
+- Wayland requires compositor support for the `xdg-toplevel-icon-v1` protocol to set window icons programmatically.
+  Otherwise, the launcher icon from the associated desktop entry file, aka a `.desktop` file, will typically be used.
+  Please see the [Desktop Entry Specification](https://specifications.freedesktop.org/desktop-entry-spec/latest/) for
+  more information on the format of this file. Note that if your application manually sets the application ID via the
+  `SDL_APP_ID` hint string, the desktop entry file name should match the application ID. For example, if your
+  application ID is set to `org.my_org.sdl_app`, the desktop entry file should be named `org.my_org.sdl_app.desktop`.
+
+### Keyboard grabs don't work when running under XWayland
+
+- On GNOME based desktops, the dconf setting `org/gnome/mutter/wayland/xwayland-allow-grabs` must be enabled.
+
+## Using custom Wayland windowing protocols with SDL windows
+
+Under normal operation, an `SDL_Window` corresponds to an XDG toplevel window, which provides a standard desktop window.
+If an application wishes to use a different windowing protocol with an SDL window (e.g. wlr_layer_shell) while still
+having SDL handle input and rendering, it needs to create a custom, roleless surface and attach that surface to its own
+toplevel window.
+
+This is done by using `SDL_CreateWindowWithProperties()` and setting the
+`SDL_PROP_WINDOW_CREATE_WAYLAND_SURFACE_ROLE_CUSTOM_BOOLEAN` property to `true`. Once the window has been
+successfully created, the `wl_display` and `wl_surface` objects can then be retrieved from the
+`SDL_PROP_WINDOW_WAYLAND_DISPLAY_POINTER` and `SDL_PROP_WINDOW_WAYLAND_SURFACE_POINTER` properties respectively.
+
+Surfaces don't receive any size change notifications, so if an application changes the window size, it must inform SDL
+that the surface size has changed by calling SDL_SetWindowSize() with the new dimensions.
+
+Custom surfaces will automatically handle scaling internally if the window was created with the
+`SDL_PROP_WINDOW_CREATE_HIGH_PIXEL_DENSITY_BOOLEAN` property set to `true`. In this case, applications should
+not manually attach viewports or change the surface scale value, as SDL will handle this internally. Calls
+to `SDL_SetWindowSize()` should use the logical size of the window, and `SDL_GetWindowSizeInPixels()` should be used to
+query the size of the backbuffer surface in pixels. If this property is not set or is `false`, applications can
+attach their own viewports or change the surface scale manually, and the SDL backend will not interfere or change any
+values internally. In this case, calls to `SDL_SetWindowSize()` should pass the requested surface size in pixels, not
+the logical window size, as no scaling calculations will be done internally.
+
+All window functions that control window state aside from `SDL_SetWindowSize()` are no-ops with custom surfaces.
+
+Please see the minimal example in `tests/testwaylandcustom.c` for an example of how to use a custom, roleless surface
+and attach it to an application-managed toplevel window.
+
+## Importing external surfaces into SDL windows
+
+Wayland windows and surfaces are more intrinsically tied to the client library than other windowing systems, therefore,
+when importing surfaces, it is necessary for both SDL and the application or toolkit to use the same `wl_display`
+object. This can be set/queried via the global `SDL_PROP_GLOBAL_VIDEO_WAYLAND_WL_DISPLAY_POINTER` property. To
+import an external `wl_display`, set this property before initializing the SDL video subsystem, and read the value to
+export the internal `wl_display` after the video subsystem has been initialized. Setting this property after the video
+subsystem has been initialized has no effect, and reading it when the video subsystem is uninitialized will either
+return the user provided value, if one was set while in the uninitialized state, or NULL.
+
+Once this is done, and the application has created or obtained the `wl_surface` to be wrapped in an `SDL_Window`, the
+window is created with `SDL_CreateWindowWithProperties()` with the
+`SDL_PROP_WINDOW_CREATE_WAYLAND_WL_SURFACE_POINTER` property to set to the `wl_surface` object that is to be
+imported by SDL.
+
+SDL receives no notification regarding size changes on external surfaces or toplevel windows, so if the external surface
+needs to be resized, SDL must be informed by calling SDL_SetWindowSize() with the new dimensions.
+
+If desired, SDL can automatically handle the scaling for the surface by setting the
+`SDL_PROP_WINDOW_CREATE_HIGH_PIXEL_DENSITY_BOOLEAN` property to `true`, however, if the surface being imported
+already has, or will have, a viewport/fractional scale manager attached to it by the application or an external toolkit,
+a protocol violation will result. Avoid setting this property if importing surfaces from toolkits such as Qt or GTK.
+
+If the window is flagged as high pixel density, calls to `SDL_SetWindowSize()` should pass the logical size of the
+window and `SDL_GetWindowSizeInPixels()` should be used to retrieve the backbuffer size in pixels. Otherwise, calls to
+`SDL_SetWindowSize()` should pass the requested surface size in pixels, not the logical window size, as no scaling
+calculations will be done internally.
+
+All window functions that control window state aside from `SDL_SetWindowSize()` are no-ops with external surfaces.
+
+An example of how to use external surfaces with a `wl_display` owned by SDL can be seen in `tests/testnativewayland.c`,
+and the following is a minimal example of interoperation with Qt 6, with Qt owning the `wl_display`:
+
+```c++
+#include <QApplication>
+#include <QWindow>
+#include <qpa/qplatformnativeinterface.h>
+
+#include <SDL3/SDL.h>
+
+int main(int argc, char *argv[])
+{
+    int ret = -1;
+    int done = 0;
+    SDL_PropertiesID props;
+    SDL_Event e;
+    SDL_Window *sdlWindow = NULL;
+    SDL_Renderer *sdlRenderer = NULL;
+    struct wl_display *display = NULL;
+    struct wl_surface *surface = NULL;
+
+    /* Initialize Qt */
+    QApplication qtApp(argc, argv);
+    QWindow qtWindow;
+
+    /* The windowing system must be Wayland. */
+    if (QApplication::platformName() != "wayland") {
+        goto exit;
+    }
+
+    {
+        /* Get the wl_display object from Qt */
+        QNativeInterface::QWaylandApplication *qtWlApp = qtApp.nativeInterface<QNativeInterface::QWaylandApplication>();
+        display = qtWlApp->display();
+
+        if (!display) {
+            goto exit;
+        }
+    }
+
+    /* Set SDL to use the existing wl_display object from Qt and initialize. */
+    SDL_SetPointerProperty(SDL_GetGlobalProperties(), SDL_PROP_GLOBAL_VIDEO_WAYLAND_WL_DISPLAY_POINTER, display);
+    SDL_Init(SDL_INIT_VIDEO | SDL_INIT_EVENTS);
+
+    /* Create a basic, frameless QWindow */
+    qtWindow.setFlags(Qt::FramelessWindowHint);
+    qtWindow.setGeometry(0, 0, 640, 480);
+    qtWindow.show();
+
+    {
+        /* Get the native wl_surface backing resource for the window */
+        QPlatformNativeInterface *qtNative = qtApp.platformNativeInterface();
+        surface = (struct wl_surface *)qtNative->nativeResourceForWindow("surface", &qtWindow);
+
+        if (!surface) {
+            goto exit;
+        }
+    }
+
+    /* Create a window that wraps the wl_surface from the QWindow.
+     * Qt objects should not be flagged as DPI-aware or protocol violations will result.
+     */
+    props = SDL_CreateProperties();
+    SDL_SetPointerProperty(props, SDL_PROP_WINDOW_CREATE_WAYLAND_WL_SURFACE_POINTER, surface);
+    SDL_SetBooleanProperty(props, SDL_PROP_WINDOW_CREATE_OPENGL_BOOLEAN, true);
+    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_WIDTH_NUMBER, 640);
+    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_HEIGHT_NUMBER, 480);
+    sdlWindow = SDL_CreateWindowWithProperties(props);
+    SDL_DestroyProperties(props);
+    if (!sdlWindow) {
+        goto exit;
+    }
+
+    /* Create a renderer */
+    sdlRenderer = SDL_CreateRenderer(sdlWindow, NULL);
+    if (!sdlRenderer) {
+        goto exit;
+    }
+
+    /* Draw a blue screen for the window until ESC is pressed or the window is no longer visible. */
+    while (!done) {
+        while (SDL_PollEvent(&e)) {
+            if (e.type == SDL_EVENT_KEY_DOWN && e.key.key == SDLK_ESCAPE) {
+                done = 1;
+            }
+        }
+
+        qtApp.processEvents();
+
+        /* Update the backbuffer size if the window scale changed. */
+        qreal scale = qtWindow.devicePixelRatio();
+        SDL_SetWindowSize(sdlWindow, SDL_lround(640. * scale), SDL_lround(480. * scale));
+
+        if (qtWindow.isVisible()) {
+            SDL_SetRenderDrawColor(sdlRenderer, 0, 0, 255, SDL_ALPHA_OPAQUE);
+            SDL_RenderClear(sdlRenderer);
+            SDL_RenderPresent(sdlRenderer);
+        } else {
+            done = 1;
+        }
+    }
+
+    ret = 0;
+
+exit:
+    /* Cleanup */
+    if (sdlRenderer) {
+        SDL_DestroyRenderer(sdlRenderer);
+    }
+    if (sdlWindow) {
+        SDL_DestroyWindow(sdlWindow);
+    }
+
+    SDL_Quit();
+    return ret;
+}
+```
+

vendor/sdl-3.2.10/docs/README-windows.md

@@ -0,0 +1,128 @@
+# Windows
+
+## Old systems
+
+WinRT, Windows Phone, and UWP are no longer supported.
+
+All desktop Windows versions, back to Windows XP, are still supported.
+
+## LLVM and Intel C++ compiler support
+
+SDL will build with the Visual Studio project files with LLVM-based compilers, such as the Intel oneAPI C++
+compiler, but you'll have to manually add the "-msse3" command line option
+to at least the SDL_audiocvt.c source file, and possibly others. This may
+not be necessary if you build SDL with CMake instead of the included Visual
+Studio solution.
+
+Details are here: https://github.com/libsdl-org/SDL/issues/5186
+
+## MinGW-w64 compiler support
+
+SDL can be built with MinGW-w64 and CMake. Minimum tested MinGW-w64 version is 8.0.3.
+
+On a Windows host, you first need to install and set up the MSYS2 environment, which provides the MinGW-w64 toolchain. Install MSYS2, typically to `C:\msys64`, and follow the instructions on the MSYS2 wiki to use the MinGW-w64 shell to update all components in the MSYS2 environment. This generally amounts to running `pacman -Syuu` from the mingw64 shell, but refer to MSYS2's documentation for more details. Once the MSYS2 environment has been updated, install the x86_64 MinGW toolchain from the mingw64 shell with the command `pacman -S mingw-w64-x86_64-toolchain`. (You can additionally install `mingw-w64-i686-toolchain` if you intend to build 32-bit binaries as well. The remainder of this section assumes you only want to build 64-bit binaries.)
+
+To build and install SDL, you can use PowerShell or any CMake-compatible IDE. First, install CMake, Ninja, and Git. These tools can be installed using any number of tools, such as the MSYS2's `pacman`, `winget`, `Chocolatey`, or by manually downloading and running the installers. Clone SDL to an appropriate location with `git` and run the following commands from the root of the cloned repository:
+
+```sh
+mkdir build
+cmake -S . -B build -G Ninja -DCMAKE_TOOLCHAIN_FILE=build-scripts/cmake-toolchain-mingw64-x86_64.cmake
+cmake --build build --parallel
+cmake --install build --prefix C:/Libraries
+```
+
+This installs SDL to `C:\Libraries`. You can specify another directory of your choice as desired. Ensure that your `CMAKE_PREFIX_PATH` includes `C:\Libraries` when you want to build against this copy of SDL. The simplest way to do this is to pass it to CMake as an option at configuration time:
+
+```sh
+cmake .. -G Ninja -DCMAKE_PREFIX_PATH=C:/Libraries
+```
+
+You will also need to configure CMake to use the MinGW-w64 toolchain to build your own project. Here is a minimal toolchain file that you could use for this purpose:
+
+```
+set(CMAKE_SYSTEM_NAME Windows)
+set(CMAKE_SYSTEM_PROCESSOR x86_64)
+
+find_program(CMAKE_C_COMPILER NAMES x86_64-w64-mingw32-gcc REQUIRED)
+find_program(CMAKE_CXX_COMPILER NAMES x86_64-w64-mingw32-g++ REQUIRED)
+find_program(CMAKE_RC_COMPILER NAMES x86_64-w64-mingw32-windres windres REQUIRED)
+```
+
+Save this in your project and refer to it at configuration time with the option `-DCMAKE_TOOLCHAIN_FILE`.
+
+On Windows, you also need to copy `SDL3.dll` to an appropriate directory so that the game can find it at runtime. For guidance, see [README-cmake.md](README-cmake.md#how-do-i-copy-a-sdl3-dynamic-library-to-another-location).
+
+Below is a minimal `CMakeLists.txt` file to build your game linked against a system SDL that was built with the MinGW-w64 toolchain. See [README-cmake.md](README-cmake.md) for more details on including SDL in your CMake project.
+
+```cmake
+cmake_minimum_required(VERSION 3.15)
+project(mygame)
+
+find_package(SDL3 REQUIRED CONFIG COMPONENTS SDL3-shared)
+
+add_executable(mygame WIN32 mygame.c)
+target_link_libraries(mygame PRIVATE SDL3::SDL3)
+
+# On Windows, copy SDL3.dll to the build directory
+if(WIN32)
+    add_custom_command(
+        TARGET mygame POST_BUILD
+        COMMAND "${CMAKE_COMMAND}" -E copy $<TARGET_FILE:SDL3::SDL3-shared> $<TARGET_FILE_DIR:mygame>
+        VERBATIM
+    )
+endif()
+```
+
+## OpenGL ES 2.x support
+
+SDL has support for OpenGL ES 2.x under Windows via two alternative
+implementations.
+
+The most straightforward method consists in running your app in a system with
+a graphic card paired with a relatively recent (as of November of 2013) driver
+which supports the WGL_EXT_create_context_es2_profile extension. Vendors known
+to ship said extension on Windows currently include nVidia and Intel.
+
+The other method involves using the
+[ANGLE library](https://code.google.com/p/angleproject/). If an OpenGL ES 2.x
+context is requested and no WGL_EXT_create_context_es2_profile extension is
+found, SDL will try to load the libEGL.dll library provided by ANGLE.
+
+To obtain the ANGLE binaries, you can either compile from source from
+https://chromium.googlesource.com/angle/angle or copy the relevant binaries
+from a recent Chrome/Chromium install for Windows. The files you need are:
+
+- libEGL.dll
+- libGLESv2.dll
+- d3dcompiler_46.dll (supports Windows Vista or later, better shader
+  compiler) *or* d3dcompiler_43.dll (supports Windows XP or later)
+
+If you compile ANGLE from source, you can configure it so it does not need the
+d3dcompiler_* DLL at all (for details on this, see their documentation).
+However, by default SDL will try to preload the d3dcompiler_46.dll to
+comply with ANGLE's requirements. If you wish SDL to preload
+d3dcompiler_43.dll (to support Windows XP) or to skip this step at all, you
+can use the SDL_HINT_VIDEO_WIN_D3DCOMPILER hint (see SDL_hints.h for more
+details).
+
+Known Bugs:
+
+- SDL_GL_SetSwapInterval is currently a no op when using ANGLE. It appears
+  that there's a bug in the library which prevents the window contents from
+  refreshing if this is set to anything other than the default value.
+
+## Vulkan Surface Support
+
+Support for creating Vulkan surfaces is configured on by default. To disable
+it change the value of `SDL_VIDEO_VULKAN` to 0 in `SDL_config_windows.h`. You
+must install the [Vulkan SDK](https://www.lunarg.com/vulkan-sdk/) in order to
+use Vulkan graphics in your application.
+
+## Transparent Window Support
+
+SDL uses the Desktop Window Manager (DWM) to create transparent windows. DWM is
+always enabled from Windows 8 and above. Windows 7 only enables DWM with Aero Glass
+theme.
+
+However, it cannot be guaranteed to work on all hardware configurations (an example
+is hybrid GPU systems, such as NVIDIA Optimus laptops).

vendor/sdl-3.2.10/docs/README.md

@@ -0,0 +1,45 @@
+# Simple DirectMedia Layer
+
+https://www.libsdl.org/
+
+Simple DirectMedia Layer is a cross-platform development library designed
+to provide low level access to audio, keyboard, mouse, joystick, and graphics
+hardware. It is used by video playback software, emulators, and popular games
+including Valve's award winning catalog and many Humble Bundle games.
+
+SDL officially supports Windows, macOS, Linux, iOS, Android, Xbox, PlayStation 4/5, Nintendo Switch, and many other platforms.
+
+SDL is written in C, works natively with C++, and there are bindings 
+available for several other languages, including C# and Python.
+
+This library is distributed under the zlib license, which can be found
+in the file "LICENSE.txt".
+
+Information on building SDL with CMake is available in [README-cmake.md](README-cmake.md)
+
+The best way to learn how to use SDL is to check out the header files in
+the "include" subdirectory and the programs in the "examples" subdirectory.
+The header files and test programs are well commented and always up to date.
+
+Information on reporting bugs and contributing is available in [README-contributing.md](README-contributing.md)
+
+More documentation and FAQs are available online at the [wiki](http://wiki.libsdl.org/)
+
+- [Migrating from SDL 2.0](README-migration.md)
+- [main()](README-main-functions.md)
+- [High DPI Support](README-highdpi.md)
+- [Touch](README-touch.md)
+- [Supported platforms](README-platforms.md)
+- [Porting information](README-porting.md)
+
+If you need help with the library, or just want to discuss SDL related
+issues, you can join the [SDL Discourse](https://discourse.libsdl.org/),
+which can be used as a web forum or a mailing list, at your preference.
+
+If you want to report bugs or contribute patches, please submit them to
+[our bug tracker](https://github.com/libsdl-org/SDL/issues)
+
+Enjoy!
+
+
+Sam Lantinga <mailto:slouken@libsdl.org>

vendor/sdl-3.2.10/docs/hello.c

@@ -0,0 +1,68 @@
+/*
+  Copyright (C) 1997-2025 Sam Lantinga <slouken@libsdl.org>
+
+  This software is provided 'as-is', without any express or implied
+  warranty.  In no event will the authors be held liable for any damages
+  arising from the use of this software.
+
+  Permission is granted to anyone to use this software for any purpose,
+  including commercial applications, and to alter it and redistribute it
+  freely.
+*/
+#define SDL_MAIN_USE_CALLBACKS 1  /* use the callbacks instead of main() */
+#include <SDL3/SDL.h>
+#include <SDL3/SDL_main.h>
+
+static SDL_Window *window = NULL;
+static SDL_Renderer *renderer = NULL;
+
+/* This function runs once at startup. */
+SDL_AppResult SDL_AppInit(void **appstate, int argc, char *argv[])
+{
+    /* Create the window */
+    if (!SDL_CreateWindowAndRenderer("Hello World", 800, 600, SDL_WINDOW_FULLSCREEN, &window, &renderer)) {
+        SDL_Log("Couldn't create window and renderer: %s", SDL_GetError());
+        return SDL_APP_FAILURE;
+    }
+    return SDL_APP_CONTINUE;
+}
+
+/* This function runs when a new event (mouse input, keypresses, etc) occurs. */
+SDL_AppResult SDL_AppEvent(void *appstate, SDL_Event *event)
+{
+    if (event->type == SDL_EVENT_KEY_DOWN ||
+        event->type == SDL_EVENT_QUIT) {
+        return SDL_APP_SUCCESS;  /* end the program, reporting success to the OS. */
+    }
+    return SDL_APP_CONTINUE;
+}
+
+/* This function runs once per frame, and is the heart of the program. */
+SDL_AppResult SDL_AppIterate(void *appstate)
+{
+    const char *message = "Hello World!";
+    int w = 0, h = 0;
+    float x, y;
+    const float scale = 4.0f;
+
+    /* Center the message and scale it up */
+    SDL_GetRenderOutputSize(renderer, &w, &h);
+    SDL_SetRenderScale(renderer, scale, scale);
+    x = ((w / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE * SDL_strlen(message)) / 2;
+    y = ((h / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE) / 2;
+
+    /* Draw the message */
+    SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
+    SDL_RenderClear(renderer);
+    SDL_SetRenderDrawColor(renderer, 255, 255, 255, 255);
+    SDL_RenderDebugText(renderer, x, y, message);
+    SDL_RenderPresent(renderer);
+
+    return SDL_APP_CONTINUE;
+}
+
+/* This function runs once at shutdown. */
+void SDL_AppQuit(void *appstate, SDL_AppResult result)
+{
+}
+

vendor/sdl-3.2.10/docs/release_checklist.md

@@ -0,0 +1,52 @@
+# Release checklist
+
+* Run `build-scripts/create-release.py -R libsdl-org/SDL --ref <branch>` to do
+  a dry run creating the release assets. Verify that the archives are correct.
+
+* Tag the release, e.g. `git tag release-3.8.0; git push --tags`
+
+* Run `build-scripts/create-release.py -R libsdl-org/SDL --ref <release-tag>`
+  to have GitHub Actions create release assets. This makes sure the revision
+  string baked into the archives is correct.
+
+* Verify that the source archive REVISION.txt has the correct release tag.
+
+* Sign the source archives and upload everything to libsdl.org
+
+* Create a GitHub release and attach the archives you just generated.
+
+## New feature release
+
+* Update `WhatsNew.txt`
+
+* Bump version number to 3.EVEN.0:
+
+    * `./build-scripts/update-version.sh 3 EVEN 0`
+
+* Do the release
+
+* Immediately create a branch for patch releases, e.g. `git branch release-3.EVEN.x`
+
+* Bump version number from 3.EVEN.0 to 3.(EVEN+1).0
+
+    * `./build-scripts/update-version.sh 3 EVEN+1 0`
+
+* Update the website file include/header.inc.php to reflect the new version
+
+## New bugfix release
+
+* Bump version number from 3.Y.Z to 3.Y.(Z+1) (Y is even)
+
+    * `./build-scripts/update-version.sh 3 Y Z+1`
+
+* Do the release
+
+* Update the website file include/header.inc.php to reflect the new version
+
+## New development prerelease
+
+* Bump version number from 3.Y.Z to 3.Y.(Z+1) (Y is odd)
+
+    * `./build-scripts/update-version.sh 3 Y Z+1`
+
+* Do the release