43 files changed, 8207 insertions, 0 deletions

diff --git a/src/contrib/SDL-3.2.20/docs/INTRO-androidstudio.md b/src/contrib/SDL-3.2.20/docs/INTRO-androidstudio.md
new file mode 100644
index 0000000..f4d8ecc
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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)
diff --git a/src/contrib/SDL-3.2.20/docs/INTRO-cmake.md b/src/contrib/SDL-3.2.20/docs/INTRO-cmake.md
new file mode 100644
index 0000000..05990e4
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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)
diff --git a/src/contrib/SDL-3.2.20/docs/INTRO-emscripten.md b/src/contrib/SDL-3.2.20/docs/INTRO-emscripten.md
new file mode 100644
index 0000000..a0541c8
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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)
diff --git a/src/contrib/SDL-3.2.20/docs/INTRO-mingw.md b/src/contrib/SDL-3.2.20/docs/INTRO-mingw.md
new file mode 100644
index 0000000..d7c535d
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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
+```
diff --git a/src/contrib/SDL-3.2.20/docs/INTRO-visualstudio.md b/src/contrib/SDL-3.2.20/docs/INTRO-visualstudio.md
new file mode 100644
index 0000000..4017f79
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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!
+
diff --git a/src/contrib/SDL-3.2.20/docs/INTRO-xcode.md b/src/contrib/SDL-3.2.20/docs/INTRO-xcode.md
new file mode 100644
index 0000000..5f0a62a
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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!
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-android.md b/src/contrib/SDL-3.2.20/docs/README-android.md
new file mode 100644
index 0000000..e57ca81
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-bsd.md b/src/contrib/SDL-3.2.20/docs/README-bsd.md
new file mode 100644
index 0000000..d823060
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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)
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-cmake.md b/src/contrib/SDL-3.2.20/docs/README-cmake.md
new file mode 100644
index 0000000..f2e4759
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-contributing.md b/src/contrib/SDL-3.2.20/docs/README-contributing.md
new file mode 100644
index 0000000..02a37bf
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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!
diff --git a/src/contrib/SDL-3.2.20/docs/README-documentation-rules.md b/src/contrib/SDL-3.2.20/docs/README-documentation-rules.md
new file mode 100644
index 0000000..3151de7
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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`.
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-dynapi.md b/src/contrib/SDL-3.2.20/docs/README-dynapi.md
new file mode 100644
index 0000000..9c137db
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-emscripten.md b/src/contrib/SDL-3.2.20/docs/README-emscripten.md
new file mode 100644
index 0000000..2b81468
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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!
+
+
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-gdk.md b/src/contrib/SDL-3.2.20/docs/README-gdk.md
new file mode 100644
index 0000000..acba7bc
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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).
diff --git a/src/contrib/SDL-3.2.20/docs/README-haiku.md b/src/contrib/SDL-3.2.20/docs/README-haiku.md
new file mode 100644
index 0000000..960bc3c
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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).
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-highdpi.md b/src/contrib/SDL-3.2.20/docs/README-highdpi.md
new file mode 100644
index 0000000..dd3a2fa
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/docs/README-highdpi.md
@@ -0,0 +1,40 @@
+
+SDL 3.0 has new support for high DPI displays. Interfaces provided by SDL uses the platform's native coordinates unless otherwise specified.
+
+## 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.
+
+## Numeric example
+
+Given a 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 Windows:
+
+| Value                          | macOS (Default) | macOS (HD) | Windows (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 difference between the approaches taken by macOS and Windows:
+- The Windows and Android coordinate system always deals in physical device pixels, high DPI support is achieved by providing a content scale that tells the developer to draw objects larger. Ignoring this scale factor results in graphics appearing tiny.
+- The macOS and iOS coordinate system always deals in window coordinates, high DPI support is achieved by providing an optional flag for the developer to request more pixels. Omitting this flag results in graphics having low detail.
+- On Linux, X11 uses a similar approach to Windows and Wayland uses a similar approach to macOS.
+
+## Solution
+
+Proper high DPI support takes into account both the content scale and the pixel density.
+
+First, you'd create your window with the `SDL_WINDOW_HIGH_PIXEL_DENSITY` flag, assuming you want the highest detail possible. Then you'd get the window display scale to see how much your UI elements should be enlarged to be readable.
+
+If you're using the SDL 2D renderer, SDL provides the function `SDL_ConvertEventToRenderCoordinates()` to convert mouse coordinates between window coordinates and rendering coordinates, and the more general functions `SDL_RenderCoordinatesFromWindow()` and `SDL_RenderCoordinatesToWindow()` to do other conversion between them.
+
+If you're not using the 2D renderer, you can implement this yourself using `SDL_GetWindowPixelDensity()` as scale factor to convert from window coordinates to pixels.
+
+Finally you'll want to test on both Windows and macOS if possible to make sure your high DPI support works in all environments.
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-ios.md b/src/contrib/SDL-3.2.20/docs/README-ios.md
new file mode 100644
index 0000000..166d182
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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
diff --git a/src/contrib/SDL-3.2.20/docs/README-kmsbsd.md b/src/contrib/SDL-3.2.20/docs/README-kmsbsd.md
new file mode 100644
index 0000000..7604817
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-linux.md b/src/contrib/SDL-3.2.20/docs/README-linux.md
new file mode 100644
index 0000000..3f2d2c0
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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"
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-macos.md b/src/contrib/SDL-3.2.20/docs/README-macos.md
new file mode 100644
index 0000000..e5c75c1
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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_EventEnabled(SDL_EVENT_QUIT)) {
+        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_EventEnabled(SDL_EVENT_DROP_FILE)) {
+        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!
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-main-functions.md b/src/contrib/SDL-3.2.20/docs/README-main-functions.md
new file mode 100644
index 0000000..75b9e2c
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-migration.md b/src/contrib/SDL-3.2.20/docs/README-migration.md
new file mode 100644
index 0000000..deca6d0
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/docs/README-migration.md
@@ -0,0 +1,2295 @@
+# Migrating to SDL 3.0
+
+This guide provides useful information for migrating applications from SDL 2.0 to SDL 3.0.
+
+Details on API changes are organized by SDL 2.0 header below.
+
+The file with your main() function should include <SDL3/SDL_main.h>, as that is no longer included in SDL.h.
+
+Functions that previously returned a negative error code now return bool.
+
+Code that used to look like this:
+```c
+    if (SDL_Function() < 0 || SDL_Function() == -1) {
+        /* Failure... */
+    }
+```
+or
+```c
+    if (SDL_Function() == 0) {
+        /* Success... */
+    }
+```
+or
+```c
+    if (!SDL_Function()) {
+        /* Success... */
+    }
+```
+should be changed to:
+```c
+    if (SDL_Function()) {
+        /* Success... */
+    } else {
+        /* Failure... */
+    }
+```
+This only applies to camel case functions, e.g. `SDL_[A-Z]*`. Lower case functions like SDL_strcmp() and SDL_memcmp() are unchanged, matching their C runtime counterpart.
+
+Many functions and symbols have been renamed. We have provided a handy Python script [rename_symbols.py](https://github.com/libsdl-org/SDL/blob/main/build-scripts/rename_symbols.py) to rename SDL2 functions to their SDL3 counterparts:
+```sh
+rename_symbols.py --all-symbols source_code_path
+```
+
+It's also possible to apply a semantic patch to migrate more easily to SDL3: [SDL_migration.cocci](https://github.com/libsdl-org/SDL/blob/main/build-scripts/SDL_migration.cocci)
+
+SDL headers should now be included as `#include <SDL3/SDL.h>`. Typically that's the only SDL header you'll need in your application unless you are using OpenGL or Vulkan functionality. SDL_image, SDL_mixer, SDL_net, SDL_ttf and SDL_rtf have also their preferred include path changed: for SDL_image, it becomes `#include <SDL3_image/SDL_image.h>`. We have provided a handy Python script [rename_headers.py](https://github.com/libsdl-org/SDL/blob/main/build-scripts/rename_headers.py) to rename SDL2 headers to their SDL3 counterparts:
+```sh
+rename_headers.py source_code_path
+```
+
+Some macros are renamed and/or removed in SDL3. We have provided a handy Python script [rename_macros.py](https://github.com/libsdl-org/SDL/blob/main/build-scripts/rename_macros.py) to replace these, and also add fixme comments on how to further improve the code:
+```sh
+rename_macros.py source_code_path
+```
+
+
+CMake users should use this snippet to include SDL support in their project:
+```cmake
+find_package(SDL3 REQUIRED CONFIG REQUIRED COMPONENTS SDL3)
+target_link_libraries(mygame PRIVATE SDL3::SDL3)
+```
+
+Autotools users should use this snippet to include SDL support in their project:
+```m4
+PKG_CHECK_MODULES([SDL3], [sdl3])
+```
+and then add `$SDL3_CFLAGS` to their project `CFLAGS` and `$SDL3_LIBS` to their project `LDFLAGS`.
+
+Makefile users can use this snippet to include SDL support in their project:
+```make
+CFLAGS += $(shell pkg-config sdl3 --cflags)
+LDFLAGS += $(shell pkg-config sdl3 --libs)
+```
+
+The SDL3test library has been renamed SDL3_test.
+
+The SDLmain library has been removed, it's been entirely replaced by SDL_main.h.
+
+The vi format comments have been removed from source code. Vim users can use the [editorconfig plugin](https://github.com/editorconfig/editorconfig-vim) to automatically set tab spacing for the SDL coding style.
+
+Installed SDL CMake configuration files no longer define `SDL3_PREFIX`, `SDL3_EXEC_PREFIX`, `SDL3_INCLUDE_DIR`, `SDL3_INCLUDE_DIRS`, `SDL3_BINDIR` or `SDL3_LIBDIR`. Users are expected to use [CMake generator expressions](https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#target-dependent-expressions) with `SDL3::SDL3`, `SDL3::SDL3-shared`, `SDL3::SDL3-static` or `SDL3::Headers`.  By no longer defining these CMake variables, using a system SDL3 or using a vendoring SDL3 behave in the same way.
+
+## SDL_atomic.h
+
+The following structures have been renamed:
+- SDL_atomic_t => SDL_AtomicInt
+
+The following functions have been renamed:
+* SDL_AtomicAdd() => SDL_AddAtomicInt()
+* SDL_AtomicCAS() => SDL_CompareAndSwapAtomicInt()
+* SDL_AtomicCASPtr() => SDL_CompareAndSwapAtomicPointer()
+* SDL_AtomicGet() => SDL_GetAtomicInt()
+* SDL_AtomicGetPtr() => SDL_GetAtomicPointer()
+* SDL_AtomicLock() => SDL_LockSpinlock()
+* SDL_AtomicSet() => SDL_SetAtomicInt()
+* SDL_AtomicSetPtr() => SDL_SetAtomicPointer()
+* SDL_AtomicTryLock() => SDL_TryLockSpinlock()
+* SDL_AtomicUnlock() => SDL_UnlockSpinlock()
+
+## SDL_audio.h
+
+The audio subsystem in SDL3 is dramatically different than SDL2. The primary way to play audio is no longer an audio callback; instead you bind SDL_AudioStreams to devices; however, there is still a callback method available if needed.
+
+The SDL 1.2 audio compatibility API has also been removed, as it was a simplified version of the audio callback interface.
+
+SDL3 will not implicitly initialize the audio subsystem on your behalf if you open a device without doing so. Please explicitly call SDL_Init(SDL_INIT_AUDIO) at some point.
+
+SDL2 referred to audio devices that record sound as "capture" devices, and ones that play sound to speakers as "output" devices. In SDL3, we've changed this terminology to be "recording" devices and "playback" devices, which we hope is more clear.
+
+SDL3's audio subsystem offers an enormous amount of power over SDL2, but if you just want a simple migration of your existing code, you can ignore most of it. The simplest migration path from SDL2 looks something like this:
+
+In SDL2, you might have done something like this to play audio...
+
+```c
+    void SDLCALL MyAudioCallback(void *userdata, Uint8 * stream, int len)
+    {
+        /* Calculate a little more audio here, maybe using `userdata`, write it to `stream` */
+    }
+
+    /* ...somewhere near startup... */
+    SDL_AudioSpec my_desired_audio_format;
+    SDL_zero(my_desired_audio_format);
+    my_desired_audio_format.format = AUDIO_S16;
+    my_desired_audio_format.channels = 2;
+    my_desired_audio_format.freq = 44100;
+    my_desired_audio_format.samples = 1024;
+    my_desired_audio_format.callback = MyAudioCallback;
+    my_desired_audio_format.userdata = &my_audio_callback_user_data;
+    SDL_AudioDeviceID my_audio_device = SDL_OpenAudioDevice(NULL, 0, &my_desired_audio_format, NULL, 0);
+    SDL_PauseAudioDevice(my_audio_device, 0);
+```
+
+...in SDL3, you can do this...
+
+```c
+    void SDLCALL MyNewAudioCallback(void *userdata, SDL_AudioStream *stream, int additional_amount, int total_amount)
+    {
+        /* Calculate a little more audio here, maybe using `userdata`, write it to `stream`
+         *
+         * If you want to use the original callback, you could do something like this:
+         */
+        if (additional_amount > 0) {
+            Uint8 *data = SDL_stack_alloc(Uint8, additional_amount);
+            if (data) {
+                MyAudioCallback(userdata, data, additional_amount);
+                SDL_PutAudioStreamData(stream, data, additional_amount);
+                SDL_stack_free(data);
+            }
+        }
+    }
+
+    /* ...somewhere near startup... */
+    const SDL_AudioSpec spec = { SDL_AUDIO_S16, 2, 44100 };
+    SDL_AudioStream *stream = SDL_OpenAudioDeviceStream(SDL_AUDIO_DEVICE_DEFAULT_PLAYBACK, &spec, MyNewAudioCallback, &my_audio_callback_user_data);
+    SDL_ResumeAudioDevice(SDL_GetAudioStreamDevice(stream));
+```
+
+If you used SDL_QueueAudio instead of a callback in SDL2, this is also straightforward.
+
+```c
+    /* ...somewhere near startup... */
+    const SDL_AudioSpec spec = { SDL_AUDIO_S16, 2, 44100 };
+    SDL_AudioStream *stream = SDL_OpenAudioDeviceStream(SDL_AUDIO_DEVICE_DEFAULT_PLAYBACK, &spec, NULL, NULL);
+    SDL_ResumeAudioDevice(SDL_GetAudioStreamDevice(stream));
+
+    /* ...in your main loop... */
+    /* calculate a little more audio into `buf`, add it to `stream` */
+    SDL_PutAudioStreamData(stream, buf, buflen);
+
+```
+
+...these same migration examples apply to audio recording, just using SDL_GetAudioStreamData instead of SDL_PutAudioStreamData.
+
+SDL_AudioInit() and SDL_AudioQuit() have been removed. Instead you can call SDL_InitSubSystem() and SDL_QuitSubSystem() with SDL_INIT_AUDIO, which will properly refcount the subsystems. You can choose a specific audio driver using SDL_AUDIO_DRIVER hint.
+
+The `SDL_AUDIO_ALLOW_*` symbols have been removed; now one may request the format they desire from the audio device, but ultimately SDL_AudioStream will manage the difference. One can use SDL_GetAudioDeviceFormat() to see what the final format is, if any "allowed" changes should be accomodated by the app.
+
+SDL_AudioDeviceID now represents both an open audio device's handle (a "logical" device) and the instance ID that the hardware owns as long as it exists on the system (a "physical" device). The separation between device instances and device indexes is gone, and logical and physical devices are almost entirely interchangeable at the API level.
+
+Devices are opened by physical device instance ID, and a new logical instance ID is generated by the open operation; This allows any device to be opened multiple times, possibly by unrelated pieces of code. SDL will manage the logical devices to provide a single stream of audio to the physical device behind the scenes.
+
+Devices are not opened by an arbitrary string name anymore, but by device instance ID (or magic numbers to request a reasonable default, like a NULL string would do in SDL2). In SDL2, the string was used to open both a standard list of system devices, but also allowed for arbitrary devices, such as hostnames of network sound servers. In SDL3, many of the backends that supported arbitrary device names are obsolete and have been removed; of those that remain, arbitrary devices will be opened with a default device ID and an SDL_hint, so specific end-users can set an environment variable to fit their needs and apps don't have to concern themselves with it.
+
+Many functions that would accept a device index and an `iscapture` parameter now just take an SDL_AudioDeviceID, as they are unique across all devices, instead of separate indices into playback and recording device lists.
+
+Rather than iterating over audio devices using a device index, there are new functions, SDL_GetAudioPlaybackDevices() and SDL_GetAudioRecordingDevices(), to get the current list of devices, and new functions to get information about devices from their instance ID:
+
+```c
+{
+    if (SDL_InitSubSystem(SDL_INIT_AUDIO)) {
+        int i, num_devices;
+        SDL_AudioDeviceID *devices = SDL_GetAudioPlaybackDevices(&num_devices);
+        if (devices) {
+            for (i = 0; i < num_devices; ++i) {
+                SDL_AudioDeviceID instance_id = devices[i];
+                SDL_Log("AudioDevice %" SDL_PRIu32 ": %s", instance_id, SDL_GetAudioDeviceName(instance_id));
+            }
+            SDL_free(devices);
+        }
+        SDL_QuitSubSystem(SDL_INIT_AUDIO);
+    }
+}
+```
+
+SDL_LockAudioDevice() and SDL_UnlockAudioDevice() have been removed, since there is no callback in another thread to protect. SDL's audio subsystem and SDL_AudioStream maintain their own locks internally, so audio streams are safe to use from any thread. If the app assigns a callback to a specific stream, it can use the stream's lock through SDL_LockAudioStream() if necessary.
+
+SDL_PauseAudioDevice() no longer takes a second argument; it always pauses the device. To unpause, use SDL_ResumeAudioDevice().
+
+Audio devices, opened by SDL_OpenAudioDevice(), no longer start in a paused state, as they don't begin processing audio until a stream is bound.
+
+SDL_GetAudioDeviceStatus() has been removed; there is now SDL_AudioDevicePaused().
+
+SDL_QueueAudio(), SDL_DequeueAudio, and SDL_ClearQueuedAudio and SDL_GetQueuedAudioSize() have been removed; an SDL_AudioStream bound to a device provides the exact same functionality.
+
+APIs that use channel counts used to use a Uint8 for the channel; now they use int.
+
+SDL_AudioSpec has been reduced; now it only holds format, channel, and sample rate. SDL_GetSilenceValueForFormat() can provide the information from the SDL_AudioSpec's removed `silence` field. SDL3 now manages the removed `samples` field; apps that want more control over device latency and throughput can force a newly-opened device's sample count with the SDL_HINT_AUDIO_DEVICE_SAMPLE_FRAMES hint, but most apps should not risk messing with the defaults. The other SDL2 SDL_AudioSpec fields aren't relevant anymore.
+
+SDL_GetAudioDeviceSpec() is removed; use SDL_GetAudioDeviceFormat() instead.
+
+SDL_GetDefaultAudioInfo() is removed; SDL_GetAudioDeviceFormat() with SDL_AUDIO_DEVICE_DEFAULT_PLAYBACK or SDL_AUDIO_DEVICE_DEFAULT_RECORDING. There is no replacement for querying the default device name; the string is no longer used to open devices, and SDL3 will migrate between physical devices on the fly if the system default changes, so if you must show this to the user, a generic name like "System default" is recommended.
+
+SDL_MixAudioFormat() and SDL_MIX_MAXVOLUME have been removed in favour of SDL_MixAudio(), which now takes the audio format, and a float volume between 0.0 and 1.0.
+
+SDL_FreeWAV has been removed and calls can be replaced with SDL_free.
+
+SDL_LoadWAV() is a proper function now and no longer a macro (but offers the same functionality otherwise).
+
+SDL_LoadWAV_IO() and SDL_LoadWAV() return an bool now, like most of SDL. They no longer return a pointer to an SDL_AudioSpec.
+
+SDL_AudioCVT interface has been removed, the SDL_AudioStream interface (for audio supplied in pieces) or the new SDL_ConvertAudioSamples() function (for converting a complete audio buffer in one call) can be used instead.
+
+Code that used to look like this:
+```c
+    SDL_AudioCVT cvt;
+    SDL_BuildAudioCVT(&cvt, src_format, src_channels, src_rate, dst_format, dst_channels, dst_rate);
+    cvt.len = src_len;
+    cvt.buf = (Uint8 *) SDL_malloc(src_len * cvt.len_mult);
+    SDL_memcpy(cvt.buf, src_data, src_len);
+    SDL_ConvertAudio(&cvt);
+    do_something(cvt.buf, cvt.len_cvt);
+```
+should be changed to:
+```c
+    Uint8 *dst_data = NULL;
+    int dst_len = 0;
+    const SDL_AudioSpec src_spec = { src_format, src_channels, src_rate };
+    const SDL_AudioSpec dst_spec = { dst_format, dst_channels, dst_rate };
+    if (!SDL_ConvertAudioSamples(&src_spec, src_data, src_len, &dst_spec, &dst_data, &dst_len)) {
+        /* error */
+    }
+    do_something(dst_data, dst_len);
+    SDL_free(dst_data);
+```
+
+AUDIO_U16, AUDIO_U16LSB, AUDIO_U16MSB, and AUDIO_U16SYS have been removed. They were not heavily used, and one could not memset a buffer in this format to silence with a single byte value. Use a different audio format.
+
+If you need to convert U16 audio data to a still-supported format at runtime, the fastest, lossless conversion is to SDL_AUDIO_S16:
+
+```c
+    /* this converts the buffer in-place. The buffer size does not change. */
+    Sint16 *audio_ui16_to_si16(Uint16 *buffer, const size_t num_samples)
+    {
+        size_t i;
+        const Uint16 *src = buffer;
+        Sint16 *dst = (Sint16 *) buffer;
+
+        for (i = 0; i < num_samples; i++) {
+            dst[i] = (Sint16) (src[i] ^ 0x8000);
+        }
+
+        return dst;
+    }
+```
+
+All remaining `AUDIO_*` symbols have been renamed to `SDL_AUDIO_*` for API consistency, but othewise are identical in value and usage.
+
+In SDL2, SDL_AudioStream would convert/resample audio data during input (via SDL_AudioStreamPut). In SDL3, it does this work when requesting audio (via SDL_GetAudioStreamData, which would have been SDL_AudioStreamGet in SDL2). The way you use an AudioStream is roughly the same, just be aware that the workload moved to a different phase.
+
+In SDL2, SDL_AudioStreamAvailable() returns 0 if passed a NULL stream. In SDL3, the equivalent SDL_GetAudioStreamAvailable() call returns -1 and sets an error string, which matches other audiostream APIs' behavior.
+
+In SDL2, SDL_AUDIODEVICEREMOVED events would fire for open devices with the `which` field set to the SDL_AudioDeviceID of the lost device, and in later SDL2 releases, would also fire this event with a `which` field of zero for unopened devices, to signify that the app might want to refresh the available device list. In SDL3, this event works the same, except it won't ever fire with a zero; in this case it'll return the physical device's SDL_AudioDeviceID. Any still-open SDL_AudioDeviceIDs generated from this device with SDL_OpenAudioDevice() will also fire a separate event.
+
+The following functions have been renamed:
+* SDL_AudioStreamAvailable() => SDL_GetAudioStreamAvailable()
+* SDL_AudioStreamClear() => SDL_ClearAudioStream(), returns bool
+* SDL_AudioStreamFlush() => SDL_FlushAudioStream(), returns bool
+* SDL_AudioStreamGet() => SDL_GetAudioStreamData()
+* SDL_AudioStreamPut() => SDL_PutAudioStreamData(), returns bool
+* SDL_FreeAudioStream() => SDL_DestroyAudioStream()
+* SDL_LoadWAV_RW() => SDL_LoadWAV_IO(), returns bool
+* SDL_MixAudioFormat() => SDL_MixAudio(), returns bool
+* SDL_NewAudioStream() => SDL_CreateAudioStream()
+
+
+The following functions have been removed:
+* SDL_GetNumAudioDevices()
+* SDL_GetAudioDeviceSpec()
+* SDL_ConvertAudio()
+* SDL_BuildAudioCVT()
+* SDL_OpenAudio()
+* SDL_CloseAudio()
+* SDL_PauseAudio()
+* SDL_GetAudioStatus()
+* SDL_GetAudioDeviceStatus()
+* SDL_GetDefaultAudioInfo()
+* SDL_LockAudio()
+* SDL_LockAudioDevice()
+* SDL_UnlockAudio()
+* SDL_UnlockAudioDevice()
+* SDL_MixAudio()
+* SDL_QueueAudio()
+* SDL_DequeueAudio()
+* SDL_ClearAudioQueue()
+* SDL_GetQueuedAudioSize()
+
+The following symbols have been renamed:
+* AUDIO_F32 => SDL_AUDIO_F32LE
+* AUDIO_F32LSB => SDL_AUDIO_F32LE
+* AUDIO_F32MSB => SDL_AUDIO_F32BE
+* AUDIO_F32SYS => SDL_AUDIO_F32
+* AUDIO_S16 => SDL_AUDIO_S16LE
+* AUDIO_S16LSB => SDL_AUDIO_S16LE
+* AUDIO_S16MSB => SDL_AUDIO_S16BE
+* AUDIO_S16SYS => SDL_AUDIO_S16
+* AUDIO_S32 => SDL_AUDIO_S32LE
+* AUDIO_S32LSB => SDL_AUDIO_S32LE
+* AUDIO_S32MSB => SDL_AUDIO_S32BE
+* AUDIO_S32SYS => SDL_AUDIO_S32
+* AUDIO_S8 => SDL_AUDIO_S8
+* AUDIO_U8 => SDL_AUDIO_U8
+
+The following symbols have been removed:
+* SDL_MIX_MAXVOLUME - mixer volume is now a float between 0.0 and 1.0
+
+## SDL_cpuinfo.h
+
+The intrinsics headers (mmintrin.h, etc.) have been moved to `<SDL3/SDL_intrin.h>` and are no longer automatically included in SDL.h.
+
+SDL_Has3DNow() has been removed; there is no replacement.
+
+SDL_HasRDTSC() has been removed; there is no replacement. Don't use the RDTSC opcode in modern times, use SDL_GetPerformanceCounter and SDL_GetPerformanceFrequency instead.
+
+SDL_SIMDAlloc(), SDL_SIMDRealloc(), and SDL_SIMDFree() have been removed. You can use SDL_aligned_alloc() and SDL_aligned_free() with SDL_GetSIMDAlignment() to get the same functionality.
+
+The following functions have been renamed:
+* SDL_GetCPUCount() => SDL_GetNumLogicalCPUCores()
+* SDL_SIMDGetAlignment() => SDL_GetSIMDAlignment()
+
+## SDL_endian.h
+
+The following functions have been renamed:
+* SDL_SwapBE16() => SDL_Swap16BE()
+* SDL_SwapBE32() => SDL_Swap32BE()
+* SDL_SwapBE64() => SDL_Swap64BE()
+* SDL_SwapLE16() => SDL_Swap16LE()
+* SDL_SwapLE32() => SDL_Swap32LE()
+* SDL_SwapLE64() => SDL_Swap64LE()
+
+## SDL_error.h
+
+The following functions have been removed:
+* SDL_GetErrorMsg() - Can be implemented as `SDL_strlcpy(errstr, SDL_GetError(), maxlen);`
+
+## SDL_events.h
+
+SDL_PRESSED and SDL_RELEASED have been removed. For the most part you can replace uses of these with true and false respectively. Events which had a field `state` to represent these values have had those fields changed to bool `down`, e.g. `event.key.state` is now `event.key.down`.
+
+The timestamp member of the SDL_Event structure now represents nanoseconds, and is populated with SDL_GetTicksNS()
+
+The timestamp_us member of the sensor events has been renamed sensor_timestamp and now represents nanoseconds. This value is filled in from the hardware, if available, and may not be synchronized with values returned from SDL_GetTicksNS().
+
+You should set the event.common.timestamp field before passing an event to SDL_PushEvent(). If the timestamp is 0 it will be filled in with SDL_GetTicksNS().
+
+Event memory is now managed by SDL, so you should not free the data in SDL_EVENT_DROP_FILE, and if you want to hold onto the text in SDL_EVENT_TEXT_EDITING and SDL_EVENT_TEXT_INPUT events, you should make a copy of it. SDL_TEXTINPUTEVENT_TEXT_SIZE is no longer necessary and has been removed.
+
+Mouse events use floating point values for mouse coordinates and relative motion values. You can get sub-pixel motion depending on the platform and display scaling.
+
+The SDL_DISPLAYEVENT_* events have been moved to top level events, and SDL_DISPLAYEVENT has been removed. In general, handling this change just means checking for the individual events instead of first checking for SDL_DISPLAYEVENT and then checking for display events. You can compare the event >= SDL_EVENT_DISPLAY_FIRST and <= SDL_EVENT_DISPLAY_LAST if you need to see whether it's a display event.
+
+The SDL_WINDOWEVENT_* events have been moved to top level events, and SDL_WINDOWEVENT has been removed. In general, handling this change just means checking for the individual events instead of first checking for SDL_WINDOWEVENT and then checking for window events. You can compare the event >= SDL_EVENT_WINDOW_FIRST and <= SDL_EVENT_WINDOW_LAST if you need to see whether it's a window event.
+
+The SDL_EVENT_WINDOW_RESIZED event is always sent, even in response to SDL_SetWindowSize().
+
+The SDL_EVENT_WINDOW_SIZE_CHANGED event has been removed, and you can use SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED to detect window backbuffer size changes.
+
+The keysym field of key events has been removed to remove one level of indirection, and `sym` has been renamed `key`.
+
+Code that used to look like this:
+```c
+    SDL_Event event;
+    SDL_Keycode key = event.key.keysym.sym;
+    SDL_Keymod mod = event.key.keysym.mod;
+```
+should be changed to:
+```c
+    SDL_Event event;
+    SDL_Keycode key = event.key.key;
+    SDL_Keymod mod = event.key.mod;
+```
+
+The gamepad event structures caxis, cbutton, cdevice, ctouchpad, and csensor have been renamed gaxis, gbutton, gdevice, gtouchpad, and gsensor.
+
+The mouseX and mouseY fields of SDL_MouseWheelEvent have been renamed mouse_x and mouse_y.
+
+The touchId and fingerId fields of SDL_TouchFingerEvent have been renamed touchID and fingerID.
+
+The level field of SDL_JoyBatteryEvent has been split into state and percent.
+
+The iscapture field of SDL_AudioDeviceEvent has been renamed recording.
+
+SDL_QUERY, SDL_IGNORE, SDL_ENABLE, and SDL_DISABLE have been removed. You can use the functions SDL_SetEventEnabled() and SDL_EventEnabled() to set and query event processing state.
+
+SDL_AddEventWatch() now returns false if it fails because it ran out of memory and couldn't add the event watch callback.
+
+SDL_RegisterEvents() now returns 0 if it couldn't allocate any user events.
+
+SDL_EventFilter functions now return bool.
+
+The following symbols have been renamed:
+* SDL_APP_DIDENTERBACKGROUND => SDL_EVENT_DID_ENTER_BACKGROUND
+* SDL_APP_DIDENTERFOREGROUND => SDL_EVENT_DID_ENTER_FOREGROUND
+* SDL_APP_LOWMEMORY => SDL_EVENT_LOW_MEMORY
+* SDL_APP_TERMINATING => SDL_EVENT_TERMINATING
+* SDL_APP_WILLENTERBACKGROUND => SDL_EVENT_WILL_ENTER_BACKGROUND
+* SDL_APP_WILLENTERFOREGROUND => SDL_EVENT_WILL_ENTER_FOREGROUND
+* SDL_AUDIODEVICEADDED => SDL_EVENT_AUDIO_DEVICE_ADDED
+* SDL_AUDIODEVICEREMOVED => SDL_EVENT_AUDIO_DEVICE_REMOVED
+* SDL_CLIPBOARDUPDATE => SDL_EVENT_CLIPBOARD_UPDATE
+* SDL_CONTROLLERAXISMOTION => SDL_EVENT_GAMEPAD_AXIS_MOTION
+* SDL_CONTROLLERBUTTONDOWN => SDL_EVENT_GAMEPAD_BUTTON_DOWN
+* SDL_CONTROLLERBUTTONUP => SDL_EVENT_GAMEPAD_BUTTON_UP
+* SDL_CONTROLLERDEVICEADDED => SDL_EVENT_GAMEPAD_ADDED
+* SDL_CONTROLLERDEVICEREMAPPED => SDL_EVENT_GAMEPAD_REMAPPED
+* SDL_CONTROLLERDEVICEREMOVED => SDL_EVENT_GAMEPAD_REMOVED
+* SDL_CONTROLLERSENSORUPDATE => SDL_EVENT_GAMEPAD_SENSOR_UPDATE
+* SDL_CONTROLLERSTEAMHANDLEUPDATED => SDL_EVENT_GAMEPAD_STEAM_HANDLE_UPDATED
+* SDL_CONTROLLERTOUCHPADDOWN => SDL_EVENT_GAMEPAD_TOUCHPAD_DOWN
+* SDL_CONTROLLERTOUCHPADMOTION => SDL_EVENT_GAMEPAD_TOUCHPAD_MOTION
+* SDL_CONTROLLERTOUCHPADUP => SDL_EVENT_GAMEPAD_TOUCHPAD_UP
+* SDL_DROPBEGIN => SDL_EVENT_DROP_BEGIN
+* SDL_DROPCOMPLETE => SDL_EVENT_DROP_COMPLETE
+* SDL_DROPFILE => SDL_EVENT_DROP_FILE
+* SDL_DROPTEXT => SDL_EVENT_DROP_TEXT
+* SDL_FINGERDOWN => SDL_EVENT_FINGER_DOWN
+* SDL_FINGERMOTION => SDL_EVENT_FINGER_MOTION
+* SDL_FINGERUP => SDL_EVENT_FINGER_UP
+* SDL_FIRSTEVENT => SDL_EVENT_FIRST
+* SDL_JOYAXISMOTION => SDL_EVENT_JOYSTICK_AXIS_MOTION
+* SDL_JOYBALLMOTION => SDL_EVENT_JOYSTICK_BALL_MOTION
+* SDL_JOYBATTERYUPDATED => SDL_EVENT_JOYSTICK_BATTERY_UPDATED
+* SDL_JOYBUTTONDOWN => SDL_EVENT_JOYSTICK_BUTTON_DOWN
+* SDL_JOYBUTTONUP => SDL_EVENT_JOYSTICK_BUTTON_UP
+* SDL_JOYDEVICEADDED => SDL_EVENT_JOYSTICK_ADDED
+* SDL_JOYDEVICEREMOVED => SDL_EVENT_JOYSTICK_REMOVED
+* SDL_JOYHATMOTION => SDL_EVENT_JOYSTICK_HAT_MOTION
+* SDL_KEYDOWN => SDL_EVENT_KEY_DOWN
+* SDL_KEYMAPCHANGED => SDL_EVENT_KEYMAP_CHANGED
+* SDL_KEYUP => SDL_EVENT_KEY_UP
+* SDL_LASTEVENT => SDL_EVENT_LAST
+* SDL_LOCALECHANGED => SDL_EVENT_LOCALE_CHANGED
+* SDL_MOUSEBUTTONDOWN => SDL_EVENT_MOUSE_BUTTON_DOWN
+* SDL_MOUSEBUTTONUP => SDL_EVENT_MOUSE_BUTTON_UP
+* SDL_MOUSEMOTION => SDL_EVENT_MOUSE_MOTION
+* SDL_MOUSEWHEEL => SDL_EVENT_MOUSE_WHEEL
+* SDL_POLLSENTINEL => SDL_EVENT_POLL_SENTINEL
+* SDL_QUIT => SDL_EVENT_QUIT
+* SDL_RENDER_DEVICE_RESET => SDL_EVENT_RENDER_DEVICE_RESET
+* SDL_RENDER_TARGETS_RESET => SDL_EVENT_RENDER_TARGETS_RESET
+* SDL_SENSORUPDATE => SDL_EVENT_SENSOR_UPDATE
+* SDL_TEXTEDITING => SDL_EVENT_TEXT_EDITING
+* SDL_TEXTEDITING_EXT => SDL_EVENT_TEXT_EDITING_EXT
+* SDL_TEXTINPUT => SDL_EVENT_TEXT_INPUT
+* SDL_USEREVENT => SDL_EVENT_USER
+
+The following symbols have been removed:
+* SDL_DROPEVENT_DATA_SIZE - drop event data is dynamically allocated
+* SDL_SYSWMEVENT - you can use SDL_SetWindowsMessageHook() and SDL_SetX11EventHook() to watch and modify system events before SDL sees them.
+* SDL_TEXTEDITINGEVENT_TEXT_SIZE - text editing event data is dynamically allocated
+
+The following structures have been renamed:
+* SDL_ControllerAxisEvent => SDL_GamepadAxisEvent
+* SDL_ControllerButtonEvent => SDL_GamepadButtonEvent
+* SDL_ControllerDeviceEvent => SDL_GamepadDeviceEvent
+* SDL_ControllerSensorEvent => SDL_GamepadSensorEvent
+* SDL_ControllerTouchpadEvent => SDL_GamepadTouchpadEvent
+
+The following functions have been removed:
+* SDL_EventState() - replaced with SDL_SetEventEnabled()
+* SDL_GetEventState() - replaced with SDL_EventEnabled()
+
+The following enums have been renamed:
+* SDL_eventaction => SDL_EventAction
+
+The following functions have been renamed:
+* SDL_DelEventWatch() => SDL_RemoveEventWatch()
+
+## SDL_gamecontroller.h
+
+SDL_gamecontroller.h has been renamed SDL_gamepad.h, and all APIs have been renamed to match.
+
+The SDL_EVENT_GAMEPAD_ADDED event now provides the joystick instance ID in the which member of the cdevice event structure.
+
+The functions SDL_GetGamepads(), SDL_GetGamepadNameForID(), SDL_GetGamepadPathForID(), SDL_GetGamepadPlayerIndexForID(), SDL_GetGamepadGUIDForID(), SDL_GetGamepadVendorForID(), SDL_GetGamepadProductForID(), SDL_GetGamepadProductVersionForID(), and SDL_GetGamepadTypeForID() have been added to directly query the list of available gamepads.
+
+The gamepad face buttons have been renamed from A/B/X/Y to North/South/East/West to indicate that they are positional rather than hardware-specific. You can use SDL_GetGamepadButtonLabel() to get the labels for the face buttons, e.g. A/B/X/Y or Cross/Circle/Square/Triangle. The hint SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS is ignored, and mappings that use this hint are translated correctly into positional buttons. Applications should provide a way for users to swap between South/East as their accept/cancel buttons, as this varies based on region and muscle memory. You can use an approach similar to the following to handle this:
+
+```c
+#define CONFIRM_BUTTON SDL_GAMEPAD_BUTTON_SOUTH
+#define CANCEL_BUTTON SDL_GAMEPAD_BUTTON_EAST
+
+bool flipped_buttons;
+
+void InitMappedButtons(SDL_Gamepad *gamepad)
+{
+    if (!GetFlippedButtonSetting(&flipped_buttons)) {
+        if (SDL_GetGamepadButtonLabel(gamepad, SDL_GAMEPAD_BUTTON_SOUTH) == SDL_GAMEPAD_BUTTON_LABEL_B) {
+            flipped_buttons = true;
+        } else {
+            flipped_buttons = false;
+        }
+    }
+}
+
+SDL_GamepadButton GetMappedButton(SDL_GamepadButton button)
+{
+    if (flipped_buttons) {
+        switch (button) {
+        case SDL_GAMEPAD_BUTTON_SOUTH:
+            return SDL_GAMEPAD_BUTTON_EAST;
+        case SDL_GAMEPAD_BUTTON_EAST:
+            return SDL_GAMEPAD_BUTTON_SOUTH;
+        case SDL_GAMEPAD_BUTTON_WEST:
+            return SDL_GAMEPAD_BUTTON_NORTH;
+        case SDL_GAMEPAD_BUTTON_NORTH:
+            return SDL_GAMEPAD_BUTTON_WEST;
+        default:
+            break;
+        }
+    }
+    return button;
+}
+
+SDL_GamepadButtonLabel GetConfirmActionLabel(SDL_Gamepad *gamepad)
+{
+    return SDL_GetGamepadButtonLabel(gamepad, GetMappedButton(CONFIRM_BUTTON));
+}
+
+SDL_GamepadButtonLabel GetCancelActionLabel(SDL_Gamepad *gamepad)
+{
+    return SDL_GetGamepadButtonLabel(gamepad, GetMappedButton(CANCEL_BUTTON));
+}
+
+void HandleGamepadEvent(SDL_Event *event)
+{
+    if (event->type == SDL_EVENT_GAMEPAD_BUTTON_DOWN) {
+        switch (GetMappedButton(event->gbutton.button)) {
+        case CONFIRM_BUTTON:
+            /* Handle confirm action */
+            break;
+        case CANCEL_BUTTON:
+            /* Handle cancel action */
+            break;
+        default:
+            /* ... */
+            break;
+        }
+    }
+}
+```
+
+SDL_GameControllerGetSensorDataWithTimestamp() has been removed. If you want timestamps for the sensor data, you should use the sensor_timestamp member of SDL_EVENT_GAMEPAD_SENSOR_UPDATE events.
+
+SDL_CONTROLLER_TYPE_VIRTUAL has been removed, so virtual controllers can emulate other gamepad types. If you need to know whether a controller is virtual, you can use SDL_IsJoystickVirtual().
+
+SDL_CONTROLLER_TYPE_AMAZON_LUNA has been removed, and can be replaced with this code:
+```c
+bool SDL_IsJoystickAmazonLunaController(Uint16 vendor_id, Uint16 product_id)
+{
+    return ((vendor_id == 0x1949 && product_id == 0x0419) ||
+            (vendor_id == 0x0171 && product_id == 0x0419));
+}
+```
+
+SDL_CONTROLLER_TYPE_GOOGLE_STADIA has been removed, and can be replaced with this code:
+```c
+bool SDL_IsJoystickGoogleStadiaController(Uint16 vendor_id, Uint16 product_id)
+{
+    return (vendor_id == 0x18d1 && product_id == 0x9400);
+}
+```
+
+SDL_CONTROLLER_TYPE_NVIDIA_SHIELD has been removed, and can be replaced with this code:
+```c
+bool SDL_IsJoystickNVIDIASHIELDController(Uint16 vendor_id, Uint16 product_id)
+{
+    return (vendor_id == 0x0955 && (product_id == 0x7210 || product_id == 0x7214));
+}
+```
+
+The inputType and outputType fields of SDL_GamepadBinding have been renamed input_type and output_type.
+
+SDL_GetGamepadTouchpadFinger() takes a pointer to bool for the finger state instead of a pointer to Uint8.
+
+The following enums have been renamed:
+* SDL_GameControllerAxis => SDL_GamepadAxis
+* SDL_GameControllerBindType => SDL_GamepadBindingType
+* SDL_GameControllerButton => SDL_GamepadButton
+* SDL_GameControllerType => SDL_GamepadType
+
+The following structures have been renamed:
+* SDL_GameController => SDL_Gamepad
+
+The following functions have been renamed:
+* SDL_GameControllerAddMapping() => SDL_AddGamepadMapping()
+* SDL_GameControllerAddMappingsFromFile() => SDL_AddGamepadMappingsFromFile()
+* SDL_GameControllerAddMappingsFromRW() => SDL_AddGamepadMappingsFromIO()
+* SDL_GameControllerClose() => SDL_CloseGamepad()
+* SDL_GameControllerFromInstanceID() => SDL_GetGamepadFromID()
+* SDL_GameControllerFromPlayerIndex() => SDL_GetGamepadFromPlayerIndex()
+* SDL_GameControllerGetAppleSFSymbolsNameForAxis() => SDL_GetGamepadAppleSFSymbolsNameForAxis()
+* SDL_GameControllerGetAppleSFSymbolsNameForButton() => SDL_GetGamepadAppleSFSymbolsNameForButton()
+* SDL_GameControllerGetAttached() => SDL_GamepadConnected()
+* SDL_GameControllerGetAxis() => SDL_GetGamepadAxis()
+* SDL_GameControllerGetAxisFromString() => SDL_GetGamepadAxisFromString()
+* SDL_GameControllerGetButton() => SDL_GetGamepadButton()
+* SDL_GameControllerGetButtonFromString() => SDL_GetGamepadButtonFromString()
+* SDL_GameControllerGetFirmwareVersion() => SDL_GetGamepadFirmwareVersion()
+* SDL_GameControllerGetJoystick() => SDL_GetGamepadJoystick()
+* SDL_GameControllerGetNumTouchpadFingers() => SDL_GetNumGamepadTouchpadFingers()
+* SDL_GameControllerGetNumTouchpads() => SDL_GetNumGamepadTouchpads()
+* SDL_GameControllerGetPlayerIndex() => SDL_GetGamepadPlayerIndex()
+* SDL_GameControllerGetProduct() => SDL_GetGamepadProduct()
+* SDL_GameControllerGetProductVersion() => SDL_GetGamepadProductVersion()
+* SDL_GameControllerGetSensorData() => SDL_GetGamepadSensorData(), returns bool
+* SDL_GameControllerGetSensorDataRate() => SDL_GetGamepadSensorDataRate()
+* SDL_GameControllerGetSerial() => SDL_GetGamepadSerial()
+* SDL_GameControllerGetSteamHandle() => SDL_GetGamepadSteamHandle()
+* SDL_GameControllerGetStringForAxis() => SDL_GetGamepadStringForAxis()
+* SDL_GameControllerGetStringForButton() => SDL_GetGamepadStringForButton()
+* SDL_GameControllerGetTouchpadFinger() => SDL_GetGamepadTouchpadFinger(), returns bool
+* SDL_GameControllerGetType() => SDL_GetGamepadType()
+* SDL_GameControllerGetVendor() => SDL_GetGamepadVendor()
+* SDL_GameControllerHasAxis() => SDL_GamepadHasAxis()
+* SDL_GameControllerHasButton() => SDL_GamepadHasButton()
+* SDL_GameControllerHasSensor() => SDL_GamepadHasSensor()
+* SDL_GameControllerIsSensorEnabled() => SDL_GamepadSensorEnabled()
+* SDL_GameControllerMapping() => SDL_GetGamepadMapping()
+* SDL_GameControllerMappingForGUID() => SDL_GetGamepadMappingForGUID()
+* SDL_GameControllerName() => SDL_GetGamepadName()
+* SDL_GameControllerOpen() => SDL_OpenGamepad()
+* SDL_GameControllerPath() => SDL_GetGamepadPath()
+* SDL_GameControllerRumble() => SDL_RumbleGamepad(), returns bool
+* SDL_GameControllerRumbleTriggers() => SDL_RumbleGamepadTriggers(), returns bool
+* SDL_GameControllerSendEffect() => SDL_SendGamepadEffect(), returns bool
+* SDL_GameControllerSetLED() => SDL_SetGamepadLED(), returns bool
+* SDL_GameControllerSetPlayerIndex() => SDL_SetGamepadPlayerIndex(), returns bool
+* SDL_GameControllerSetSensorEnabled() => SDL_SetGamepadSensorEnabled(), returns bool
+* SDL_GameControllerUpdate() => SDL_UpdateGamepads()
+* SDL_IsGameController() => SDL_IsGamepad()
+
+The following functions have been removed:
+* SDL_GameControllerEventState() - replaced with SDL_SetGamepadEventsEnabled() and SDL_GamepadEventsEnabled()
+* SDL_GameControllerGetBindForAxis() - replaced with SDL_GetGamepadBindings()
+* SDL_GameControllerGetBindForButton() - replaced with SDL_GetGamepadBindings()
+* SDL_GameControllerHasLED() - replaced with SDL_PROP_GAMEPAD_CAP_RGB_LED_BOOLEAN
+* SDL_GameControllerHasRumble() - replaced with SDL_PROP_GAMEPAD_CAP_RUMBLE_BOOLEAN
+* SDL_GameControllerHasRumbleTriggers() - replaced with SDL_PROP_GAMEPAD_CAP_TRIGGER_RUMBLE_BOOLEAN
+* SDL_GameControllerMappingForDeviceIndex() - replaced with SDL_GetGamepadMappingForID()
+* SDL_GameControllerMappingForIndex() - replaced with SDL_GetGamepadMappings()
+* SDL_GameControllerNameForIndex() - replaced with SDL_GetGamepadNameForID()
+* SDL_GameControllerNumMappings() - replaced with SDL_GetGamepadMappings()
+* SDL_GameControllerPathForIndex() - replaced with SDL_GetGamepadPathForID()
+* SDL_GameControllerTypeForIndex() - replaced with SDL_GetGamepadTypeForID()
+
+The following symbols have been renamed:
+* SDL_CONTROLLER_AXIS_INVALID => SDL_GAMEPAD_AXIS_INVALID
+* SDL_CONTROLLER_AXIS_LEFTX => SDL_GAMEPAD_AXIS_LEFTX
+* SDL_CONTROLLER_AXIS_LEFTY => SDL_GAMEPAD_AXIS_LEFTY
+* SDL_CONTROLLER_AXIS_MAX => SDL_GAMEPAD_AXIS_COUNT
+* SDL_CONTROLLER_AXIS_RIGHTX => SDL_GAMEPAD_AXIS_RIGHTX
+* SDL_CONTROLLER_AXIS_RIGHTY => SDL_GAMEPAD_AXIS_RIGHTY
+* SDL_CONTROLLER_AXIS_TRIGGERLEFT => SDL_GAMEPAD_AXIS_LEFT_TRIGGER
+* SDL_CONTROLLER_AXIS_TRIGGERRIGHT => SDL_GAMEPAD_AXIS_RIGHT_TRIGGER
+* SDL_CONTROLLER_BINDTYPE_AXIS => SDL_GAMEPAD_BINDTYPE_AXIS
+* SDL_CONTROLLER_BINDTYPE_BUTTON => SDL_GAMEPAD_BINDTYPE_BUTTON
+* SDL_CONTROLLER_BINDTYPE_HAT => SDL_GAMEPAD_BINDTYPE_HAT
+* SDL_CONTROLLER_BINDTYPE_NONE => SDL_GAMEPAD_BINDTYPE_NONE
+* SDL_CONTROLLER_BUTTON_A => SDL_GAMEPAD_BUTTON_SOUTH
+* SDL_CONTROLLER_BUTTON_B => SDL_GAMEPAD_BUTTON_EAST
+* SDL_CONTROLLER_BUTTON_BACK => SDL_GAMEPAD_BUTTON_BACK
+* SDL_CONTROLLER_BUTTON_DPAD_DOWN => SDL_GAMEPAD_BUTTON_DPAD_DOWN
+* SDL_CONTROLLER_BUTTON_DPAD_LEFT => SDL_GAMEPAD_BUTTON_DPAD_LEFT
+* SDL_CONTROLLER_BUTTON_DPAD_RIGHT => SDL_GAMEPAD_BUTTON_DPAD_RIGHT
+* SDL_CONTROLLER_BUTTON_DPAD_UP => SDL_GAMEPAD_BUTTON_DPAD_UP
+* SDL_CONTROLLER_BUTTON_GUIDE => SDL_GAMEPAD_BUTTON_GUIDE
+* SDL_CONTROLLER_BUTTON_INVALID => SDL_GAMEPAD_BUTTON_INVALID
+* SDL_CONTROLLER_BUTTON_LEFTSHOULDER => SDL_GAMEPAD_BUTTON_LEFT_SHOULDER
+* SDL_CONTROLLER_BUTTON_LEFTSTICK => SDL_GAMEPAD_BUTTON_LEFT_STICK
+* SDL_CONTROLLER_BUTTON_MAX => SDL_GAMEPAD_BUTTON_COUNT
+* SDL_CONTROLLER_BUTTON_MISC1 => SDL_GAMEPAD_BUTTON_MISC1
+* SDL_CONTROLLER_BUTTON_PADDLE1 => SDL_GAMEPAD_BUTTON_RIGHT_PADDLE1
+* SDL_CONTROLLER_BUTTON_PADDLE2 => SDL_GAMEPAD_BUTTON_LEFT_PADDLE1
+* SDL_CONTROLLER_BUTTON_PADDLE3 => SDL_GAMEPAD_BUTTON_RIGHT_PADDLE2
+* SDL_CONTROLLER_BUTTON_PADDLE4 => SDL_GAMEPAD_BUTTON_LEFT_PADDLE2
+* SDL_CONTROLLER_BUTTON_RIGHTSHOULDER => SDL_GAMEPAD_BUTTON_RIGHT_SHOULDER
+* SDL_CONTROLLER_BUTTON_RIGHTSTICK => SDL_GAMEPAD_BUTTON_RIGHT_STICK
+* SDL_CONTROLLER_BUTTON_START => SDL_GAMEPAD_BUTTON_START
+* SDL_CONTROLLER_BUTTON_TOUCHPAD => SDL_GAMEPAD_BUTTON_TOUCHPAD
+* SDL_CONTROLLER_BUTTON_X => SDL_GAMEPAD_BUTTON_WEST
+* SDL_CONTROLLER_BUTTON_Y => SDL_GAMEPAD_BUTTON_NORTH
+* SDL_CONTROLLER_TYPE_NINTENDO_SWITCH_JOYCON_LEFT => SDL_GAMEPAD_TYPE_NINTENDO_SWITCH_JOYCON_LEFT
+* SDL_CONTROLLER_TYPE_NINTENDO_SWITCH_JOYCON_PAIR => SDL_GAMEPAD_TYPE_NINTENDO_SWITCH_JOYCON_PAIR
+* SDL_CONTROLLER_TYPE_NINTENDO_SWITCH_JOYCON_RIGHT => SDL_GAMEPAD_TYPE_NINTENDO_SWITCH_JOYCON_RIGHT
+* SDL_CONTROLLER_TYPE_NINTENDO_SWITCH_PRO => SDL_GAMEPAD_TYPE_NINTENDO_SWITCH_PRO
+* SDL_CONTROLLER_TYPE_PS3 => SDL_GAMEPAD_TYPE_PS3
+* SDL_CONTROLLER_TYPE_PS4 => SDL_GAMEPAD_TYPE_PS4
+* SDL_CONTROLLER_TYPE_PS5 => SDL_GAMEPAD_TYPE_PS5
+* SDL_CONTROLLER_TYPE_UNKNOWN => SDL_GAMEPAD_TYPE_STANDARD
+* SDL_CONTROLLER_TYPE_VIRTUAL => SDL_GAMEPAD_TYPE_VIRTUAL
+* SDL_CONTROLLER_TYPE_XBOX360 => SDL_GAMEPAD_TYPE_XBOX360
+* SDL_CONTROLLER_TYPE_XBOXONE => SDL_GAMEPAD_TYPE_XBOXONE
+
+## SDL_gesture.h
+
+The gesture API has been removed. There is no replacement planned in SDL3.
+However, the SDL2 code has been moved to a single-header library that can
+be dropped into an SDL3 or SDL2 program, to continue to provide this
+functionality to your app and aid migration. That is located in the
+[SDL_gesture GitHub repository](https://github.com/libsdl-org/SDL_gesture).
+
+## SDL_guid.h
+
+SDL_GUIDToString() returns a const pointer to the string representation of a GUID.
+
+The following functions have been renamed:
+* SDL_GUIDFromString() => SDL_StringToGUID()
+
+## SDL_haptic.h
+
+Gamepads with simple rumble capability no longer show up in the SDL haptics interface, instead you should use SDL_RumbleGamepad().
+
+Rather than iterating over haptic devices using device index, there is a new function SDL_GetHaptics() to get the current list of haptic devices, and new functions to get information about haptic devices from their instance ID:
+```c
+{
+    if (SDL_InitSubSystem(SDL_INIT_HAPTIC)) {
+        int i, num_haptics;
+        SDL_HapticID *haptics = SDL_GetHaptics(&num_haptics);
+        if (haptics) {
+            for (i = 0; i < num_haptics; ++i) {
+                SDL_HapticID instance_id = haptics[i];
+                SDL_Log("Haptic %" SDL_PRIu32 ": %s", instance_id, SDL_GetHapticNameForID(instance_id));
+            }
+            SDL_free(haptics);
+        }
+        SDL_QuitSubSystem(SDL_INIT_HAPTIC);
+    }
+}
+```
+
+SDL_GetHapticEffectStatus() now returns bool instead of an int result. You should call SDL_GetHapticFeatures() to make sure effect status is supported before calling this function.
+
+The following functions have been renamed:
+* SDL_HapticClose() => SDL_CloseHaptic()
+* SDL_HapticDestroyEffect() => SDL_DestroyHapticEffect()
+* SDL_HapticGetEffectStatus() => SDL_GetHapticEffectStatus(), returns bool
+* SDL_HapticNewEffect() => SDL_CreateHapticEffect()
+* SDL_HapticNumAxes() => SDL_GetNumHapticAxes()
+* SDL_HapticNumEffects() => SDL_GetMaxHapticEffects()
+* SDL_HapticNumEffectsPlaying() => SDL_GetMaxHapticEffectsPlaying()
+* SDL_HapticOpen() => SDL_OpenHaptic()
+* SDL_HapticOpenFromJoystick() => SDL_OpenHapticFromJoystick()
+* SDL_HapticOpenFromMouse() => SDL_OpenHapticFromMouse()
+* SDL_HapticPause() => SDL_PauseHaptic(), returns bool
+* SDL_HapticQuery() => SDL_GetHapticFeatures()
+* SDL_HapticRumbleInit() => SDL_InitHapticRumble(), returns bool
+* SDL_HapticRumblePlay() => SDL_PlayHapticRumble(), returns bool
+* SDL_HapticRumbleStop() => SDL_StopHapticRumble(), returns bool
+* SDL_HapticRunEffect() => SDL_RunHapticEffect(), returns bool
+* SDL_HapticSetAutocenter() => SDL_SetHapticAutocenter(), returns bool
+* SDL_HapticSetGain() => SDL_SetHapticGain(), returns bool
+* SDL_HapticStopAll() => SDL_StopHapticEffects(), returns bool
+* SDL_HapticStopEffect() => SDL_StopHapticEffect(), returns bool
+* SDL_HapticUnpause() => SDL_ResumeHaptic(), returns bool
+* SDL_HapticUpdateEffect() => SDL_UpdateHapticEffect(), returns bool
+* SDL_JoystickIsHaptic() => SDL_IsJoystickHaptic()
+* SDL_MouseIsHaptic() => SDL_IsMouseHaptic()
+
+The following functions have been removed:
+* SDL_HapticIndex() - replaced with SDL_GetHapticID()
+* SDL_HapticName() - replaced with SDL_GetHapticNameForID()
+* SDL_HapticOpened() - replaced with SDL_GetHapticFromID()
+* SDL_NumHaptics() - replaced with SDL_GetHaptics()
+
+## SDL_hints.h
+
+Calling SDL_GetHint() with the name of the hint being changed from within a hint callback will now return the new value rather than the old value. The old value is still passed as a parameter to the hint callback.
+
+The environment variables SDL_VIDEODRIVER and SDL_AUDIODRIVER have been renamed to SDL_VIDEO_DRIVER and SDL_AUDIO_DRIVER, but the old names are still supported as a fallback.
+
+The environment variables SDL_VIDEO_X11_WMCLASS and SDL_VIDEO_WAYLAND_WMCLASS have been removed and replaced by either using the appindentifier param to SDL_SetAppMetadata() or setting SDL_PROP_APP_METADATA_IDENTIFIER_STRING with SDL_SetAppMetadataProperty()
+
+The environment variable AUDIODEV is used exclusively to specify the audio device for the OSS and NetBSD audio drivers. Its use in the ALSA driver has been replaced with the hint SDL_HINT_AUDIO_ALSA_DEFAULT_DEVICE and in the sndio driver with the environment variable AUDIODEVICE.
+
+The following hints have been renamed:
+* SDL_HINT_ALLOW_TOPMOST => SDL_HINT_WINDOW_ALLOW_TOPMOST
+* SDL_HINT_AUDIODRIVER => SDL_HINT_AUDIO_DRIVER
+* SDL_HINT_DIRECTINPUT_ENABLED => SDL_HINT_JOYSTICK_DIRECTINPUT
+* SDL_HINT_GDK_TEXTINPUT_DEFAULT => SDL_HINT_GDK_TEXTINPUT_DEFAULT_TEXT
+* SDL_HINT_JOYSTICK_GAMECUBE_RUMBLE_BRAKE => SDL_HINT_JOYSTICK_HIDAPI_GAMECUBE_RUMBLE_BRAKE
+* SDL_HINT_JOYSTICK_HIDAPI_PS4_RUMBLE => SDL_HINT_JOYSTICK_ENHANCED_REPORTS
+* SDL_HINT_JOYSTICK_HIDAPI_PS5_RUMBLE => SDL_HINT_JOYSTICK_ENHANCED_REPORTS
+* SDL_HINT_LINUX_DIGITAL_HATS => SDL_HINT_JOYSTICK_LINUX_DIGITAL_HATS
+* SDL_HINT_LINUX_HAT_DEADZONES => SDL_HINT_JOYSTICK_LINUX_HAT_DEADZONES
+* SDL_HINT_LINUX_JOYSTICK_CLASSIC => SDL_HINT_JOYSTICK_LINUX_CLASSIC
+* SDL_HINT_LINUX_JOYSTICK_DEADZONES => SDL_HINT_JOYSTICK_LINUX_DEADZONES
+* SDL_HINT_VIDEODRIVER => SDL_HINT_VIDEO_DRIVER
+* SDL_HINT_VIDEO_WAYLAND_EMULATE_MOUSE_WARP => SDL_HINT_MOUSE_EMULATE_WARP_WITH_RELATIVE
+
+The following hints have been removed:
+* SDL_HINT_ACCELEROMETER_AS_JOYSTICK
+* SDL_HINT_ANDROID_BLOCK_ON_PAUSE_PAUSEAUDIO - the audio will be paused when the application is paused, and SDL_HINT_ANDROID_BLOCK_ON_PAUSE can be used to control that
+* SDL_HINT_AUDIO_DEVICE_APP_NAME - replaced by either using the appname param to SDL_SetAppMetadata() or setting SDL_PROP_APP_METADATA_NAME_STRING with SDL_SetAppMetadataProperty()
+* SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS - gamepad buttons are always positional
+* SDL_HINT_GRAB_KEYBOARD - use SDL_SetWindowKeyboardGrab() instead
+* SDL_HINT_IDLE_TIMER_DISABLED - use SDL_DisableScreenSaver() instead
+* SDL_HINT_IME_INTERNAL_EDITING - replaced with SDL_HINT_IME_IMPLEMENTED_UI
+* SDL_HINT_IME_SHOW_UI - replaced with SDL_HINT_IME_IMPLEMENTED_UI
+* SDL_HINT_IME_SUPPORT_EXTENDED_TEXT - the normal text editing event has extended text
+* SDL_HINT_MOUSE_RELATIVE_MODE_WARP - relative mode is always implemented at the hardware level or reported as unavailable
+* SDL_HINT_MOUSE_RELATIVE_SCALING - mouse coordinates are no longer automatically scaled by the SDL renderer
+* SDL_HINT_PS2_DYNAMIC_VSYNC - use SDL_SetRenderVSync(renderer, -1) instead
+* SDL_HINT_RENDER_BATCHING - Render batching is always enabled, apps should call SDL_FlushRenderer() before calling into a lower-level graphics API.
+* SDL_HINT_RENDER_LOGICAL_SIZE_MODE - the logical size mode is explicitly set with SDL_SetRenderLogicalPresentation()
+* SDL_HINT_RENDER_OPENGL_SHADERS - shaders are always used if they are available
+* SDL_HINT_RENDER_SCALE_QUALITY - textures now default to linear filtering, use SDL_SetTextureScaleMode(texture, SDL_SCALEMODE_NEAREST) if you want nearest pixel mode instead
+* SDL_HINT_THREAD_STACK_SIZE - the stack size can be specified using SDL_CreateThreadWithProperties()
+* SDL_HINT_VIDEO_EXTERNAL_CONTEXT - replaced with SDL_PROP_WINDOW_CREATE_EXTERNAL_GRAPHICS_CONTEXT_BOOLEAN in SDL_CreateWindowWithProperties()
+* SDL_HINT_VIDEO_FOREIGN_WINDOW_OPENGL - replaced with SDL_PROP_WINDOW_CREATE_OPENGL_BOOLEAN in SDL_CreateWindowWithProperties()
+* SDL_HINT_VIDEO_FOREIGN_WINDOW_VULKAN - replaced with SDL_PROP_WINDOW_CREATE_VULKAN_BOOLEAN in SDL_CreateWindowWithProperties()
+* SDL_HINT_VIDEO_HIGHDPI_DISABLED - high DPI support is always enabled
+* SDL_HINT_VIDEO_WINDOW_SHARE_PIXEL_FORMAT - replaced with SDL_PROP_WINDOW_CREATE_WIN32_PIXEL_FORMAT_HWND_POINTER in SDL_CreateWindowWithProperties()
+* SDL_HINT_VIDEO_X11_FORCE_EGL - use SDL_HINT_VIDEO_FORCE_EGL instead
+* SDL_HINT_VIDEO_X11_XINERAMA - Xinerama no longer supported by the X11 backend
+* SDL_HINT_VIDEO_X11_XVIDMODE - Xvidmode no longer supported by the X11 backend
+* SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING - SDL now properly handles the 0x406D1388 Exception if no debugger intercepts it, preventing its propagation.
+* SDL_HINT_WINDOWS_FORCE_MUTEX_CRITICAL_SECTIONS - Slim Reader/Writer Locks are always used if available
+* SDL_HINT_WINDOWS_NO_CLOSE_ON_ALT_F4 - replaced with SDL_HINT_WINDOWS_CLOSE_ON_ALT_F4, defaulting to true
+* SDL_HINT_WINRT_HANDLE_BACK_BUTTON - WinRT support was removed in SDL3.
+* SDL_HINT_WINRT_PRIVACY_POLICY_LABEL - WinRT support was removed in SDL3.
+* SDL_HINT_WINRT_PRIVACY_POLICY_URL - WinRT support was removed in SDL3.
+* SDL_HINT_XINPUT_USE_OLD_JOYSTICK_MAPPING
+
+The following environment variables have been renamed:
+* SDL_AUDIODRIVER => SDL_AUDIO_DRIVER
+* SDL_PATH_DSP => AUDIODEV
+* SDL_VIDEODRIVER => SDL_VIDEO_DRIVER
+
+The following environment variables have been removed:
+* SDL_AUDIO_ALSA_DEBUG - replaced by setting the hint SDL_HINT_LOGGING to "audio=debug"
+* SDL_DISKAUDIODELAY - replaced with the hint SDL_HINT_AUDIO_DISK_TIMESCALE which allows scaling the audio time rather than specifying an absolute delay.
+* SDL_DISKAUDIOFILE - replaced with the hint SDL_HINT_AUDIO_DISK_OUTPUT_FILE
+* SDL_DISKAUDIOFILEIN - replaced with the hint SDL_HINT_AUDIO_DISK_INPUT_FILE
+* SDL_DUMMYAUDIODELAY - replaced with the hint SDL_HINT_AUDIO_DUMMY_TIMESCALE which allows scaling the audio time rather than specifying an absolute delay.
+* SDL_HAPTIC_GAIN_MAX
+* SDL_HIDAPI_DISABLE_LIBUSB - replaced with the hint SDL_HINT_HIDAPI_LIBUSB
+* SDL_HIDAPI_JOYSTICK_DISABLE_UDEV - replaced with the hint SDL_HINT_HIDAPI_UDEV
+* SDL_INPUT_FREEBSD_KEEP_KBD - replaced with the hint SDL_HINT_MUTE_CONSOLE_KEYBOARD
+* SDL_INPUT_LINUX_KEEP_KBD - replaced with the hint SDL_HINT_MUTE_CONSOLE_KEYBOARD
+* VITA_DISABLE_TOUCH_BACK - replaced with the hint SDL_HINT_VITA_ENABLE_BACK_TOUCH
+* VITA_DISABLE_TOUCH_FRONT - replaced with the hint SDL_HINT_VITA_ENABLE_FRONT_TOUCH
+* VITA_MODULE_PATH - replaced with the hint SDL_HINT_VITA_MODULE_PATH
+* VITA_PVR_OGL - replaced with the hint SDL_HINT_VITA_PVR_OPENGL
+* VITA_PVR_SKIP_INIT - replaced with the hint SDL_HINT_VITA_PVR_INIT
+* VITA_RESOLUTION - replaced with the hint SDL_HINT_VITA_RESOLUTION
+
+The following functions have been removed:
+* SDL_ClearHints() - replaced with SDL_ResetHints()
+
+The following functions have been renamed:
+* SDL_DelHintCallback() => SDL_RemoveHintCallback()
+
+## SDL_init.h
+
+On Haiku OS, SDL no longer sets the current working directory to the executable's path during SDL_Init(). If you need this functionality, the fastest solution is to add this code directly after the call to SDL_Init:
+
+```c
+{
+    const char *path = SDL_GetBasePath();
+    if (path) {
+        chdir(path);
+    }
+}
+```
+
+The following symbols have been renamed:
+* SDL_INIT_GAMECONTROLLER => SDL_INIT_GAMEPAD
+
+The following symbols have been removed:
+* SDL_INIT_NOPARACHUTE
+* SDL_INIT_EVERYTHING - you should only initialize the subsystems you are using
+* SDL_INIT_TIMER - no longer needed before calling SDL_AddTimer()
+
+## SDL_joystick.h
+
+SDL_JoystickID has changed from Sint32 to Uint32, with an invalid ID being 0.
+
+Rather than iterating over joysticks using device index, there is a new function SDL_GetJoysticks() to get the current list of joysticks, and new functions to get information about joysticks from their instance ID:
+```c
+{
+    if (SDL_InitSubSystem(SDL_INIT_JOYSTICK)) {
+        int i, num_joysticks;
+        SDL_JoystickID *joysticks = SDL_GetJoysticks(&num_joysticks);
+        if (joysticks) {
+            for (i = 0; i < num_joysticks; ++i) {
+                SDL_JoystickID instance_id = joysticks[i];
+                const char *name = SDL_GetJoystickNameForID(instance_id);
+                const char *path = SDL_GetJoystickPathForID(instance_id);
+
+                SDL_Log("Joystick %" SDL_PRIu32 ": %s%s%s VID 0x%.4x, PID 0x%.4x",
+                        instance_id, name ? name : "Unknown", path ? ", " : "", path ? path : "", SDL_GetJoystickVendorForID(instance_id), SDL_GetJoystickProductForID(instance_id));
+            }
+            SDL_free(joysticks);
+        }
+        SDL_QuitSubSystem(SDL_INIT_JOYSTICK);
+    }
+}
+```
+
+The SDL_EVENT_JOYSTICK_ADDED event now provides the joystick instance ID in the `which` member of the jdevice event structure.
+
+The functions SDL_GetJoysticks(), SDL_GetJoystickNameForID(), SDL_GetJoystickPathForID(), SDL_GetJoystickPlayerIndexForID(), SDL_GetJoystickGUIDForID(), SDL_GetJoystickVendorForID(), SDL_GetJoystickProductForID(), SDL_GetJoystickProductVersionForID(), and SDL_GetJoystickTypeForID() have been added to directly query the list of available joysticks.
+
+SDL_AttachVirtualJoystick() now returns the joystick instance ID instead of a device index, and returns 0 if there was an error.
+
+SDL_VirtualJoystickDesc version should not be set to SDL_VIRTUAL_JOYSTICK_DESC_VERSION, instead the structure should be initialized using SDL_INIT_INTERFACE().
+
+The following functions have been renamed:
+* SDL_JoystickAttachVirtualEx() => SDL_AttachVirtualJoystick()
+* SDL_JoystickClose() => SDL_CloseJoystick()
+* SDL_JoystickDetachVirtual() => SDL_DetachVirtualJoystick(), returns bool
+* SDL_JoystickFromInstanceID() => SDL_GetJoystickFromID()
+* SDL_JoystickFromPlayerIndex() => SDL_GetJoystickFromPlayerIndex()
+* SDL_JoystickGetAttached() => SDL_JoystickConnected()
+* SDL_JoystickGetAxis() => SDL_GetJoystickAxis()
+* SDL_JoystickGetAxisInitialState() => SDL_GetJoystickAxisInitialState()
+* SDL_JoystickGetBall() => SDL_GetJoystickBall(), returns bool
+* SDL_JoystickGetButton() => SDL_GetJoystickButton()
+* SDL_JoystickGetFirmwareVersion() => SDL_GetJoystickFirmwareVersion()
+* SDL_JoystickGetGUID() => SDL_GetJoystickGUID()
+* SDL_JoystickGetGUIDFromString() => SDL_StringToGUID()
+* SDL_JoystickGetHat() => SDL_GetJoystickHat()
+* SDL_JoystickGetPlayerIndex() => SDL_GetJoystickPlayerIndex()
+* SDL_JoystickGetProduct() => SDL_GetJoystickProduct()
+* SDL_JoystickGetProductVersion() => SDL_GetJoystickProductVersion()
+* SDL_JoystickGetSerial() => SDL_GetJoystickSerial()
+* SDL_JoystickGetType() => SDL_GetJoystickType()
+* SDL_JoystickGetVendor() => SDL_GetJoystickVendor()
+* SDL_JoystickInstanceID() => SDL_GetJoystickID()
+* SDL_JoystickIsVirtual() => SDL_IsJoystickVirtual()
+* SDL_JoystickName() => SDL_GetJoystickName()
+* SDL_JoystickNumAxes() => SDL_GetNumJoystickAxes()
+* SDL_JoystickNumBalls() => SDL_GetNumJoystickBalls()
+* SDL_JoystickNumButtons() => SDL_GetNumJoystickButtons()
+* SDL_JoystickNumHats() => SDL_GetNumJoystickHats()
+* SDL_JoystickOpen() => SDL_OpenJoystick()
+* SDL_JoystickPath() => SDL_GetJoystickPath()
+* SDL_JoystickRumble() => SDL_RumbleJoystick(), returns bool
+* SDL_JoystickRumbleTriggers() => SDL_RumbleJoystickTriggers(), returns bool
+* SDL_JoystickSendEffect() => SDL_SendJoystickEffect(), returns bool
+* SDL_JoystickSetLED() => SDL_SetJoystickLED(), returns bool
+* SDL_JoystickSetPlayerIndex() => SDL_SetJoystickPlayerIndex(), returns bool
+* SDL_JoystickSetVirtualAxis() => SDL_SetJoystickVirtualAxis(), returns bool
+* SDL_JoystickSetVirtualButton() => SDL_SetJoystickVirtualButton(), returns bool
+* SDL_JoystickSetVirtualHat() => SDL_SetJoystickVirtualHat(), returns bool
+* SDL_JoystickUpdate() => SDL_UpdateJoysticks()
+
+The following symbols have been renamed:
+* SDL_JOYSTICK_TYPE_GAMECONTROLLER => SDL_JOYSTICK_TYPE_GAMEPAD
+
+The following functions have been removed:
+* SDL_JoystickAttachVirtual() - replaced with SDL_AttachVirtualJoystick()
+* SDL_JoystickCurrentPowerLevel() - replaced with SDL_GetJoystickConnectionState() and SDL_GetJoystickPowerInfo()
+* SDL_JoystickEventState() - replaced with SDL_SetJoystickEventsEnabled() and SDL_JoystickEventsEnabled()
+* SDL_JoystickGetDeviceGUID() - replaced with SDL_GetJoystickGUIDForID()
+* SDL_JoystickGetDeviceInstanceID()
+* SDL_JoystickGetDevicePlayerIndex() - replaced with SDL_GetJoystickPlayerIndexForID()
+* SDL_JoystickGetDeviceProduct() - replaced with SDL_GetJoystickProductForID()
+* SDL_JoystickGetDeviceProductVersion() - replaced with SDL_GetJoystickProductVersionForID()
+* SDL_JoystickGetDeviceType() - replaced with SDL_GetJoystickTypeForID()
+* SDL_JoystickGetDeviceVendor() - replaced with SDL_GetJoystickVendorForID()
+* SDL_JoystickGetGUIDString() - replaced with SDL_GUIDToString()
+* SDL_JoystickHasLED() - replaced with SDL_PROP_JOYSTICK_CAP_RGB_LED_BOOLEAN
+* SDL_JoystickHasRumble() - replaced with SDL_PROP_JOYSTICK_CAP_RUMBLE_BOOLEAN
+* SDL_JoystickHasRumbleTriggers() - replaced with SDL_PROP_JOYSTICK_CAP_TRIGGER_RUMBLE_BOOLEAN
+* SDL_JoystickNameForIndex() - replaced with SDL_GetJoystickNameForID()
+* SDL_JoystickPathForIndex() - replaced with SDL_GetJoystickPathForID()
+* SDL_NumJoysticks() - replaced with SDL_GetJoysticks()
+* SDL_VIRTUAL_JOYSTICK_DESC_VERSION - no longer needed
+
+The following symbols have been removed:
+* SDL_IPHONE_MAX_GFORCE
+* SDL_JOYBALLMOTION
+
+
+The following structures have been renamed:
+* SDL_JoystickGUID => SDL_GUID
+
+## SDL_keyboard.h
+
+Text input is no longer automatically enabled when initializing video, you should call SDL_StartTextInput() when you want to receive text input and call SDL_StopTextInput() when you are done. Starting text input may shown an input method editor (IME) and cause key up/down events to be skipped, so should only be enabled when the application wants text input.
+
+The text input state hase been changed to be window-specific. SDL_StartTextInput(), SDL_StopTextInput(), SDL_TextInputActive(), and SDL_ClearComposition() all now take a window parameter.
+
+SDL_GetDefaultKeyFromScancode(), SDL_GetKeyFromScancode(), and SDL_GetScancodeFromKey() take an SDL_Keymod parameter and use that to provide the correct result based on keyboard modifier state.
+
+SDL_GetKeyboardState() returns a pointer to bool instead of Uint8.
+
+The following functions have been renamed:
+* SDL_IsScreenKeyboardShown() => SDL_ScreenKeyboardShown()
+* SDL_IsTextInputActive() => SDL_TextInputActive()
+
+The following functions have been removed:
+* SDL_IsTextInputShown()
+* SDL_SetTextInputRect() - replaced with SDL_SetTextInputArea()
+
+The following structures have been removed:
+* SDL_Keysym
+
+## SDL_keycode.h
+
+SDL_Keycode is now Uint32 and the SDLK_* constants are now defines instead of an enum, to more clearly reflect that they are a subset of the possible values of an SDL_Keycode.
+
+In addition to the `SDLK_SCANCODE_MASK` bit found on key codes that directly map to scancodes, there is now the
+`SDLK_EXTENDED_MASK` bit used to denote key codes that don't have a corresponding scancode, and aren't a unicode value.
+
+The following symbols have been removed:
+
+* KMOD_RESERVED - No replacement. A bit named "RESERVED" probably shouldn't be used in an app, but if you need it, this was equivalent to KMOD_SCROLL (0x8000) in SDL2.
+* SDLK_WWW
+* SDLK_MAIL
+* SDLK_CALCULATOR
+* SDLK_COMPUTER
+* SDLK_BRIGHTNESSDOWN
+* SDLK_BRIGHTNESSUP
+* SDLK_DISPLAYSWITCH
+* SDLK_KBDILLUMTOGGLE
+* SDLK_KBDILLUMDOWN
+* SDLK_KBDILLUMUP
+* SDLK_APP1
+* SDLK_APP2
+
+
+The following symbols have been renamed:
+* KMOD_ALT => SDL_KMOD_ALT
+* KMOD_CAPS => SDL_KMOD_CAPS
+* KMOD_CTRL => SDL_KMOD_CTRL
+* KMOD_GUI => SDL_KMOD_GUI
+* KMOD_LALT => SDL_KMOD_LALT
+* KMOD_LCTRL => SDL_KMOD_LCTRL
+* KMOD_LGUI => SDL_KMOD_LGUI
+* KMOD_LSHIFT => SDL_KMOD_LSHIFT
+* KMOD_MODE => SDL_KMOD_MODE
+* KMOD_NONE => SDL_KMOD_NONE
+* KMOD_NUM => SDL_KMOD_NUM
+* KMOD_RALT => SDL_KMOD_RALT
+* KMOD_RCTRL => SDL_KMOD_RCTRL
+* KMOD_RGUI => SDL_KMOD_RGUI
+* KMOD_RSHIFT => SDL_KMOD_RSHIFT
+* KMOD_SCROLL => SDL_KMOD_SCROLL
+* KMOD_SHIFT => SDL_KMOD_SHIFT
+* SDLK_AUDIOFASTFORWARD => SDLK_MEDIA_FAST_FORWARD
+* SDLK_AUDIOMUTE => SDLK_MUTE
+* SDLK_AUDIONEXT => SDLK_MEDIA_NEXT_TRACK
+* SDLK_AUDIOPLAY => SDLK_MEDIA_PLAY
+* SDLK_AUDIOPREV => SDLK_MEDIA_PREVIOUS_TRACK
+* SDLK_AUDIOREWIND => SDLK_MEDIA_REWIND
+* SDLK_AUDIOSTOP => SDLK_MEDIA_STOP
+* SDLK_BACKQUOTE => SDLK_GRAVE
+* SDLK_EJECT => SDLK_MEDIA_EJECT
+* SDLK_MEDIASELECT => SDLK_MEDIA_SELECT
+* SDLK_QUOTE => SDLK_APOSTROPHE
+* SDLK_QUOTEDBL => SDLK_DBLAPOSTROPHE
+* SDLK_a => SDLK_A
+* SDLK_b => SDLK_B
+* SDLK_c => SDLK_C
+* SDLK_d => SDLK_D
+* SDLK_e => SDLK_E
+* SDLK_f => SDLK_F
+* SDLK_g => SDLK_G
+* SDLK_h => SDLK_H
+* SDLK_i => SDLK_I
+* SDLK_j => SDLK_J
+* SDLK_k => SDLK_K
+* SDLK_l => SDLK_L
+* SDLK_m => SDLK_M
+* SDLK_n => SDLK_N
+* SDLK_o => SDLK_O
+* SDLK_p => SDLK_P
+* SDLK_q => SDLK_Q
+* SDLK_r => SDLK_R
+* SDLK_s => SDLK_S
+* SDLK_t => SDLK_T
+* SDLK_u => SDLK_U
+* SDLK_v => SDLK_V
+* SDLK_w => SDLK_W
+* SDLK_x => SDLK_X
+* SDLK_y => SDLK_Y
+* SDLK_z => SDLK_Z
+
+## SDL_loadso.h
+
+Shared object handles are now `SDL_SharedObject *`, an opaque type, instead of `void *`. This is just for type-safety and there is no functional difference.
+
+SDL_LoadFunction() now returns `SDL_FunctionPointer` instead of `void *`, and should be cast to the appropriate function type. You can define SDL_FUNCTION_POINTER_IS_VOID_POINTER in your project to restore the previous behavior.
+
+## SDL_log.h
+
+SDL_Log() no longer prints a log prefix by default for SDL_LOG_PRIORITY_INFO and below. The log prefixes can be customized with SDL_SetLogPriorityPrefix().
+
+The following macros have been removed:
+* SDL_MAX_LOG_MESSAGE - there's no message length limit anymore. If you need an artificial limit, this used to be 4096 in SDL versions before 2.0.24.
+
+The following functions have been renamed:
+* SDL_LogGetOutputFunction() => SDL_GetLogOutputFunction()
+* SDL_LogGetPriority() => SDL_GetLogPriority()
+* SDL_LogResetPriorities() => SDL_ResetLogPriorities()
+* SDL_LogSetAllPriority() => SDL_SetLogPriorities()
+* SDL_LogSetOutputFunction() => SDL_SetLogOutputFunction()
+* SDL_LogSetPriority() => SDL_SetLogPriority()
+
+The following symbols have been renamed:
+* SDL_NUM_LOG_PRIORITIES => SDL_LOG_PRIORITY_COUNT
+
+## SDL_main.h
+
+SDL3 doesn't have a static libSDLmain to link against anymore.
+Instead SDL_main.h is now a header-only library **and not included by SDL.h anymore**.
+
+Using it is really simple: Just `#include <SDL3/SDL_main.h>` in the source file with your standard
+`int main(int argc, char* argv[])` function. See docs/README-main-functions.md for details.
+
+Several platform-specific entry point functions have been removed as unnecessary. If for some reason you explicitly need them, here are easy replacements:
+
+```c
+#define SDL_UIKitRunApp(ARGC, ARGV, MAIN_FUNC)  SDL_RunApp(ARGC, ARGV, MAIN_FUNC, NULL)
+#define SDL_GDKRunApp(MAIN_FUNC, RESERVED)  SDL_RunApp(0, NULL, MAIN_FUNC, RESERVED)
+```
+
+The following functions have been removed:
+* SDL_WinRTRunApp() - WinRT support was removed in SDL3.
+
+
+## SDL_messagebox.h
+
+The buttonid field of SDL_MessageBoxButtonData has been renamed buttonID.
+
+The following symbols have been renamed:
+* SDL_MESSAGEBOX_COLOR_MAX => SDL_MESSAGEBOX_COLOR_COUNT
+
+## SDL_metal.h
+
+SDL_Metal_GetDrawableSize() has been removed. SDL_GetWindowSizeInPixels() can be used in its place.
+
+## SDL_mouse.h
+
+SDL_ShowCursor() has been split into three functions: SDL_ShowCursor(), SDL_HideCursor(), and SDL_CursorVisible()
+
+SDL_GetMouseState(), SDL_GetGlobalMouseState(), SDL_GetRelativeMouseState(), SDL_WarpMouseInWindow(), and SDL_WarpMouseGlobal() all use floating point mouse positions, to provide sub-pixel precision on platforms that support it.
+
+SDL_SystemCursor's items from SDL2 have been renamed to match CSS cursor names.
+
+The following functions have been renamed:
+* SDL_FreeCursor() => SDL_DestroyCursor()
+
+The following functions have been removed:
+* SDL_SetRelativeMouseMode() - replaced with SDL_SetWindowRelativeMouseMode()
+* SDL_GetRelativeMouseMode() - replaced with SDL_GetWindowRelativeMouseMode()
+
+The following symbols have been renamed:
+* SDL_BUTTON => SDL_BUTTON_MASK
+* SDL_NUM_SYSTEM_CURSORS => SDL_SYSTEM_CURSOR_COUNT
+* SDL_SYSTEM_CURSOR_ARROW => SDL_SYSTEM_CURSOR_DEFAULT
+* SDL_SYSTEM_CURSOR_HAND => SDL_SYSTEM_CURSOR_POINTER
+* SDL_SYSTEM_CURSOR_IBEAM => SDL_SYSTEM_CURSOR_TEXT
+* SDL_SYSTEM_CURSOR_NO => SDL_SYSTEM_CURSOR_NOT_ALLOWED
+* SDL_SYSTEM_CURSOR_SIZEALL => SDL_SYSTEM_CURSOR_MOVE
+* SDL_SYSTEM_CURSOR_SIZENESW => SDL_SYSTEM_CURSOR_NESW_RESIZE
+* SDL_SYSTEM_CURSOR_SIZENS => SDL_SYSTEM_CURSOR_NS_RESIZE
+* SDL_SYSTEM_CURSOR_SIZENWSE => SDL_SYSTEM_CURSOR_NWSE_RESIZE
+* SDL_SYSTEM_CURSOR_SIZEWE => SDL_SYSTEM_CURSOR_EW_RESIZE
+* SDL_SYSTEM_CURSOR_WAITARROW => SDL_SYSTEM_CURSOR_PROGRESS
+
+## SDL_mutex.h
+
+SDL_MUTEX_MAXWAIT has been removed; it suggested there was a maximum timeout one could outlive, instead of an infinite wait. Instead, pass a -1 to functions that accepted this symbol.
+
+SDL_MUTEX_TIMEDOUT has been removed, the wait functions return true if the operation succeeded or false if they timed out.
+
+SDL_LockMutex(), SDL_UnlockMutex(), SDL_WaitSemaphore(), SDL_SignalSemaphore(), SDL_WaitCondition(), SDL_SignalCondition(), and SDL_BroadcastCondition() now return void; if the object is valid (including being a NULL pointer, which returns immediately), these functions never fail. If the object is invalid or the caller does something illegal, like unlock another thread's mutex, this is considered undefined behavior.
+
+SDL_TryWaitSemaphore(), SDL_WaitSemaphoreTimeout(), and SDL_WaitConditionTimeout() now return true if the operation succeeded or false if they timed out.
+
+The following functions have been renamed:
+* SDL_CondBroadcast() => SDL_BroadcastCondition()
+* SDL_CondSignal() => SDL_SignalCondition()
+* SDL_CondWait() => SDL_WaitCondition()
+* SDL_CondWaitTimeout() => SDL_WaitConditionTimeout(), returns bool
+* SDL_CreateCond() => SDL_CreateCondition()
+* SDL_DestroyCond() => SDL_DestroyCondition()
+* SDL_SemPost() => SDL_SignalSemaphore()
+* SDL_SemTryWait() => SDL_TryWaitSemaphore(), returns bool
+* SDL_SemValue() => SDL_GetSemaphoreValue()
+* SDL_SemWait() => SDL_WaitSemaphore()
+* SDL_SemWaitTimeout() => SDL_WaitSemaphoreTimeout(), returns bool
+
+The following symbols have been renamed:
+* SDL_cond => SDL_Condition
+* SDL_mutex => SDL_Mutex
+* SDL_sem => SDL_Semaphore
+
+## SDL_pixels.h
+
+SDL_PixelFormat has been renamed SDL_PixelFormatDetails and just describes the pixel format, it does not include a palette for indexed pixel types.
+
+SDL_PixelFormatEnum has been renamed SDL_PixelFormat and is used instead of Uint32 for API functions that refer to pixel format by enumerated value.
+
+SDL_MapRGB(), SDL_MapRGBA(), SDL_GetRGB(), and SDL_GetRGBA() take an optional palette parameter for indexed color lookups.
+
+Code that used to look like this:
+```c
+    SDL_GetRGBA(pixel, surface->format, &r, &g, &b, &a);
+```
+should be changed to:
+```c
+    SDL_GetRGBA(pixel, SDL_GetPixelFormatDetails(surface->format), SDL_GetSurfacePalette(surface), &r, &g, &b, &a);
+```
+
+Code that used to look like this:
+```c
+    pixel = SDL_MapRGBA(surface->format, r, g, b, a);
+```
+should be changed to:
+```c
+    pixel = SDL_MapSurfaceRGBA(surface, r, g, b, a);
+```
+
+SDL_CalculateGammaRamp has been removed, because SDL_SetWindowGammaRamp has been removed as well due to poor support in modern operating systems (see [SDL_video.h](#sdl_videoh)).
+
+The following functions have been renamed:
+* SDL_AllocFormat() => SDL_GetPixelFormatDetails()
+* SDL_AllocPalette() => SDL_CreatePalette()
+* SDL_FreePalette() => SDL_DestroyPalette()
+* SDL_MasksToPixelFormatEnum() => SDL_GetPixelFormatForMasks()
+* SDL_PixelFormatEnumToMasks() => SDL_GetMasksForPixelFormat(), returns bool
+
+The following symbols have been renamed:
+* SDL_PIXELFORMAT_BGR444 => SDL_PIXELFORMAT_XBGR4444
+* SDL_PIXELFORMAT_BGR555 => SDL_PIXELFORMAT_XBGR1555
+* SDL_PIXELFORMAT_BGR888 => SDL_PIXELFORMAT_XBGR8888
+* SDL_PIXELFORMAT_RGB444 => SDL_PIXELFORMAT_XRGB4444
+* SDL_PIXELFORMAT_RGB555 => SDL_PIXELFORMAT_XRGB1555
+* SDL_PIXELFORMAT_RGB888 => SDL_PIXELFORMAT_XRGB8888
+
+The following functions have been removed:
+* SDL_FreeFormat()
+* SDL_SetPixelFormatPalette()
+* SDL_CalculateGammaRamp()
+
+The following macros have been removed:
+* SDL_Colour - use SDL_Color instead
+
+The following structures have been renamed:
+* SDL_PixelFormat => SDL_PixelFormatDetails
+
+## SDL_platform.h
+
+The following platform preprocessor macros have been renamed:
+
+| SDL2              | SDL3                      |
+|-------------------|---------------------------|
+| `__3DS__`         | `SDL_PLATFORM_3DS`        |
+| `__AIX__`         | `SDL_PLATFORM_AIX`        |
+| `__ANDROID__`     | `SDL_PLATFORM_ANDROID`    |
+| `__APPLE__`       | `SDL_PLATFORM_APPLE`      |
+| `__BSDI__`        | `SDL_PLATFORM_BSDI`       |
+| `__CYGWIN_`       | `SDL_PLATFORM_CYGWIN`     |
+| `__EMSCRIPTEN__`  | `SDL_PLATFORM_EMSCRIPTEN` |
+| `__FREEBSD__`     | `SDL_PLATFORM_FREEBSD`    |
+| `__GDK__`         | `SDL_PLATFORM_GDK`        |
+| `__HAIKU__`       | `SDL_PLATFORM_HAIKU`      |
+| `__HPUX__`        | `SDL_PLATFORM_HPUX`       |
+| `__IPHONEOS__`    | `SDL_PLATFORM_IOS`        |
+| `__IRIX__`        | `SDL_PLATFORM_IRIX`       |
+| `__LINUX__`       | `SDL_PLATFORM_LINUX`      |
+| `__MACOSX__`      | `SDL_PLATFORM_MACOS`      |
+| `__NETBSD__`      | `SDL_PLATFORM_NETBSD`     |
+| `__OPENBSD__`     | `SDL_PLATFORM_OPENBSD`    |
+| `__OS2__`         | `SDL_PLATFORM_OS2`        |
+| `__OSF__`         | `SDL_PLATFORM_OSF`        |
+| `__PS2__`         | `SDL_PLATFORM_PS2`        |
+| `__PSP__`         | `SDL_PLATFORM_PSP`        |
+| `__QNXNTO__`      | `SDL_PLATFORM_QNXNTO`     |
+| `__RISCOS__`      | `SDL_PLATFORM_RISCOS`     |
+| `__SOLARIS__`     | `SDL_PLATFORM_SOLARIS`    |
+| `__TVOS__`        | `SDL_PLATFORM_TVOS`       |
+| `__unix__`        | `SDL_PLATFORM_UNI`        |
+| `__VITA__`        | `SDL_PLATFORM_VITA`       |
+| `__WIN32__`       | `SDL_PLATFORM_WIN32`      |
+| `__WINGDK__`      | `SDL_PLATFORM_WINGDK`     |
+| `__XBOXONE__`     | `SDL_PLATFORM_XBOXONE`    |
+| `__XBOXSERIES__`  | `SDL_PLATFORM_XBOXSERIES` |
+
+You can use the Python script [rename_macros.py](https://github.com/libsdl-org/SDL/blob/main/build-scripts/rename_macros.py) to automatically rename these in your source code.
+
+A new macro `SDL_PLATFORM_WINDOWS` has been added that is true for all Windows platforms, including Xbox, GDK, etc.
+
+The following platform preprocessor macros have been removed:
+* `__DREAMCAST__`
+* `__NACL__`
+* `__PNACL__`
+* `__WINDOWS__`
+* `__WINRT__`
+
+
+## SDL_quit.h
+
+SDL_quit.h has been completely removed. It only had one symbol in it--SDL_QuitRequested--and if you want it, you can just add this to your app...
+
+```c
+#define SDL_QuitRequested() (SDL_PumpEvents(), (SDL_PeepEvents(NULL,0,SDL_PEEKEVENT,SDL_EVENT_QUIT,SDL_EVENT_QUIT) > 0))
+```
+
+...but this macro is sort of messy, calling two functions in sequence in an expression.
+
+The following macros have been removed:
+* SDL_QuitRequested - call SDL_PumpEvents() then SDL_PeepEvents() directly, instead.
+
+## SDL_rect.h
+
+The following functions have been renamed:
+* SDL_EncloseFPoints() => SDL_GetRectEnclosingPointsFloat()
+* SDL_EnclosePoints() => SDL_GetRectEnclosingPoints()
+* SDL_FRectEmpty() => SDL_RectEmptyFloat()
+* SDL_FRectEquals() => SDL_RectsEqualFloat()
+* SDL_FRectEqualsEpsilon() => SDL_RectsEqualEpsilon()
+* SDL_HasIntersection() => SDL_HasRectIntersection()
+* SDL_HasIntersectionF() => SDL_HasRectIntersectionFloat()
+* SDL_IntersectFRect() => SDL_GetRectIntersectionFloat()
+* SDL_IntersectFRectAndLine() => SDL_GetRectAndLineIntersectionFloat()
+* SDL_IntersectRect() => SDL_GetRectIntersection()
+* SDL_IntersectRectAndLine() => SDL_GetRectAndLineIntersection()
+* SDL_PointInFRect() => SDL_PointInRectFloat()
+* SDL_RectEquals() => SDL_RectsEqual()
+* SDL_UnionFRect() => SDL_GetRectUnionFloat(), returns bool
+* SDL_UnionRect() => SDL_GetRectUnion(), returns bool
+
+## SDL_render.h
+
+The 2D renderer API always uses batching in SDL3. There is no magic to turn
+it on and off; it doesn't matter if you select a specific renderer or try to
+use any hint. This means that all apps that use SDL3's 2D renderer and also
+want to call directly into the platform's lower-layer graphics API _must_ call
+SDL_FlushRenderer() before doing so. This will make sure any pending rendering
+work from SDL is done before the app starts directly drawing.
+
+SDL_GetRenderDriverInfo() has been removed, since most of the information it reported were
+estimates and could not be accurate before creating a renderer. Often times this function
+was used to figure out the index of a driver, so one would call it in a for-loop, looking
+for the driver named "opengl" or whatnot. SDL_GetRenderDriver() has been added for this
+functionality, which returns only the name of the driver.
+
+SDL_CreateRenderer()'s second argument is no longer an integer index, but a
+`const char *` representing a renderer's name; if you were just using a for-loop to find
+which index is the "opengl" or whatnot driver, you can just pass that string directly
+here, now. Passing NULL is the same as passing -1 here in SDL2, to signify you want SDL
+to decide for you.
+
+SDL_CreateRenderer()'s flags parameter has been removed. See specific flags below for how to achieve the same functionality in SDL 3.0.
+
+SDL_CreateWindowAndRenderer() now takes the window title as the first parameter.
+
+SDL_GetRendererInfo() has been removed. The name of a renderer can be retrieved using SDL_GetRendererName(), and the other information is available as properties on the renderer.
+
+Textures are created with SDL_SCALEMODE_LINEAR by default, and use SDL_BLENDMODE_BLEND by default if they are created with a format that has an alpha channel.
+
+SDL_QueryTexture() has been removed. The properties of the texture can be queried using SDL_PROP_TEXTURE_FORMAT_NUMBER, SDL_PROP_TEXTURE_ACCESS_NUMBER, SDL_PROP_TEXTURE_WIDTH_NUMBER, and SDL_PROP_TEXTURE_HEIGHT_NUMBER. A function SDL_GetTextureSize() has been added to get the size of the texture as floating point values.
+
+Mouse and touch events are no longer filtered to change their coordinates, instead you
+can call SDL_ConvertEventToRenderCoordinates() to explicitly map event coordinates into
+the rendering viewport.
+
+SDL_RenderWindowToLogical() and SDL_RenderLogicalToWindow() have been renamed SDL_RenderCoordinatesFromWindow() and SDL_RenderCoordinatesToWindow() and take floating point coordinates in both directions.
+
+The viewport, clipping state, and scale for render targets are now persistent and will remain set whenever they are active.
+
+SDL_Vertex has been changed to use floating point colors, in the range of [0..1] for SDR content.
+
+SDL_RenderReadPixels() returns a surface instead of filling in preallocated memory.
+
+SDL_RenderSetLogicalSize() (now called SDL_SetRenderLogicalPresentation()) in SDL2 would modify the scaling and viewport state. In SDL3, logical presentation maintains its state separately, so the app can use its own viewport and scaling while also setting a logical size.
+
+The following functions have been renamed:
+* SDL_GetRendererOutputSize() => SDL_GetCurrentRenderOutputSize(), returns bool
+* SDL_RenderCopy() => SDL_RenderTexture(), returns bool
+* SDL_RenderCopyEx() => SDL_RenderTextureRotated(), returns bool
+* SDL_RenderCopyExF() => SDL_RenderTextureRotated(), returns bool
+* SDL_RenderCopyF() => SDL_RenderTexture(), returns bool
+* SDL_RenderDrawLine() => SDL_RenderLine(), returns bool
+* SDL_RenderDrawLineF() => SDL_RenderLine(), returns bool
+* SDL_RenderDrawLines() => SDL_RenderLines(), returns bool
+* SDL_RenderDrawLinesF() => SDL_RenderLines(), returns bool
+* SDL_RenderDrawPoint() => SDL_RenderPoint(), returns bool
+* SDL_RenderDrawPointF() => SDL_RenderPoint(), returns bool
+* SDL_RenderDrawPoints() => SDL_RenderPoints(), returns bool
+* SDL_RenderDrawPointsF() => SDL_RenderPoints(), returns bool
+* SDL_RenderDrawRect() => SDL_RenderRect(), returns bool
+* SDL_RenderDrawRectF() => SDL_RenderRect(), returns bool
+* SDL_RenderDrawRects() => SDL_RenderRects(), returns bool
+* SDL_RenderDrawRectsF() => SDL_RenderRects(), returns bool
+* SDL_RenderFillRectF() => SDL_RenderFillRect(), returns bool
+* SDL_RenderFillRectsF() => SDL_RenderFillRects(), returns bool
+* SDL_RenderFlush() => SDL_FlushRenderer(), returns bool
+* SDL_RenderGetClipRect() => SDL_GetRenderClipRect(), returns bool
+* SDL_RenderGetIntegerScale() => SDL_GetRenderIntegerScale()
+* SDL_RenderGetLogicalSize() => SDL_GetRenderLogicalPresentation(), returns bool
+* SDL_RenderGetMetalCommandEncoder() => SDL_GetRenderMetalCommandEncoder()
+* SDL_RenderGetMetalLayer() => SDL_GetRenderMetalLayer()
+* SDL_RenderGetScale() => SDL_GetRenderScale(), returns bool
+* SDL_RenderGetViewport() => SDL_GetRenderViewport(), returns bool
+* SDL_RenderGetWindow() => SDL_GetRenderWindow()
+* SDL_RenderIsClipEnabled() => SDL_RenderClipEnabled()
+* SDL_RenderLogicalToWindow() => SDL_RenderCoordinatesToWindow(), returns bool
+* SDL_RenderSetClipRect() => SDL_SetRenderClipRect(), returns bool
+* SDL_RenderSetLogicalSize() => SDL_SetRenderLogicalPresentation(), returns bool
+* SDL_RenderSetScale() => SDL_SetRenderScale(), returns bool
+* SDL_RenderSetVSync() => SDL_SetRenderVSync(), returns bool
+* SDL_RenderSetViewport() => SDL_SetRenderViewport(), returns bool
+* SDL_RenderWindowToLogical() => SDL_RenderCoordinatesFromWindow(), returns bool
+
+The following functions have been removed:
+* SDL_GL_BindTexture() - use SDL_GetTextureProperties() to get the OpenGL texture ID and bind the texture directly
+* SDL_GL_UnbindTexture() - use SDL_GetTextureProperties() to get the OpenGL texture ID and unbind the texture directly
+* SDL_GetTextureUserData() - use SDL_GetTextureProperties() instead
+* SDL_RenderGetIntegerScale()
+* SDL_RenderSetIntegerScale() - this is now explicit with SDL_LOGICAL_PRESENTATION_INTEGER_SCALE
+* SDL_RenderTargetSupported() - render targets are always supported
+* SDL_SetTextureUserData() - use SDL_GetTextureProperties() instead
+
+The following enums have been renamed:
+* SDL_RendererFlip => SDL_FlipMode - moved to SDL_surface.h
+
+The following symbols have been renamed:
+* SDL_ScaleModeLinear => SDL_SCALEMODE_LINEAR
+* SDL_ScaleModeNearest => SDL_SCALEMODE_NEAREST
+
+The following symbols have been removed:
+* SDL_RENDERER_ACCELERATED - all renderers except `SDL_SOFTWARE_RENDERER` are accelerated
+* SDL_RENDERER_PRESENTVSYNC - replaced with SDL_PROP_RENDERER_CREATE_PRESENT_VSYNC_NUMBER during renderer creation and SDL_PROP_RENDERER_VSYNC_NUMBER after renderer creation
+* SDL_RENDERER_SOFTWARE - you can check whether the name of the renderer is `SDL_SOFTWARE_RENDERER`
+* SDL_RENDERER_TARGETTEXTURE - all renderers support target texture functionality
+* SDL_ScaleModeBest = use SDL_SCALEMODE_LINEAR instead
+
+## SDL_rwops.h
+
+The following symbols have been renamed:
+* RW_SEEK_CUR => SDL_IO_SEEK_CUR
+* RW_SEEK_END => SDL_IO_SEEK_END
+* RW_SEEK_SET => SDL_IO_SEEK_SET
+
+SDL_rwops.h is now named SDL_iostream.h
+
+SDL_RWops is now an opaque structure, and has been renamed to SDL_IOStream. The SDL3 APIs to create an SDL_IOStream (SDL_IOFromFile, etc) are renamed but otherwise still function as they did in SDL2. However, to make a custom SDL_IOStream with app-provided function pointers, call SDL_OpenIO and provide the function pointers through there. To call into an SDL_IOStream's functionality, use the standard APIs (SDL_ReadIO, etc), as the function pointers are internal.
+
+SDL_IOStream is not to be confused with the unrelated standard C++ iostream class!
+
+The RWops function pointers are now in a separate structure called SDL_IOStreamInterface, which is provided to SDL_OpenIO when creating a custom SDL_IOStream implementation. All the functions now take a `void *` userdata argument for their first parameter instead of an SDL_IOStream, since that's now an opaque structure.
+
+SDL_RWread and SDL_RWwrite (and the read and write function pointers) have a different function signature in SDL3, in addition to being renamed.
+
+Previously they looked more like stdio:
+
+```c
+size_t SDL_RWread(SDL_RWops *context, void *ptr, size_t size, size_t maxnum);
+size_t SDL_RWwrite(SDL_RWops *context, const void *ptr, size_t size, size_t maxnum);
+```
+
+But now they look more like POSIX:
+
+```c
+size_t SDL_ReadIO(SDL_IOStream *context, void *ptr, size_t size);
+size_t SDL_WriteIO(SDL_IOStream *context, const void *ptr, size_t size);
+```
+
+Code that used to look like this:
+```c
+size_t custom_read(void *ptr, size_t size, size_t nitems, SDL_RWops *stream)
+{
+    return SDL_RWread(stream, ptr, size, nitems);
+}
+```
+should be changed to:
+```c
+size_t custom_read(void *ptr, size_t size, size_t nitems, SDL_IOStream *stream)
+{
+    if (size > 0 && nitems > 0) {
+        return SDL_ReadIO(stream, ptr, size * nitems) / size;
+    }
+    return 0;
+}
+```
+
+SDL_RWops::type was removed; it wasn't meaningful for app-provided implementations at all, and wasn't much use for SDL's internal implementations, either. If you _have_ to identify the type, you can examine the SDL_IOStream's properties to detect built-in implementations.
+
+SDL_IOStreamInterface::close implementations should clean up their own userdata, but not call SDL_CloseIO on themselves; now the contract is always that SDL_CloseIO is called, which calls `->close` before freeing the opaque object.
+
+SDL_AllocRW(), SDL_FreeRW(), SDL_RWclose() and direct access to the `->close` function pointer have been removed from the API, so there's only one path to manage RWops lifetimes now: SDL_OpenIO() and SDL_CloseIO().
+
+SDL_RWFromFP has been removed from the API, due to issues when the SDL library uses a different C runtime from the application.
+
+You can implement this in your own code easily:
+```c
+#include <stdio.h>
+
+typedef struct IOStreamStdioFPData
+{
+    FILE *fp;
+    bool autoclose;
+} IOStreamStdioFPData;
+
+static Sint64 SDLCALL stdio_seek(void *userdata, Sint64 offset, int whence)
+{
+    FILE *fp = ((IOStreamStdioFPData *) userdata)->fp;
+    int stdiowhence;
+
+    switch (whence) {
+    case SDL_IO_SEEK_SET:
+        stdiowhence = SEEK_SET;
+        break;
+    case SDL_IO_SEEK_CUR:
+        stdiowhence = SEEK_CUR;
+        break;
+    case SDL_IO_SEEK_END:
+        stdiowhence = SEEK_END;
+        break;
+    default:
+        SDL_SetError("Unknown value for 'whence'");
+        return -1;
+    }
+
+    if (fseek(fp, (fseek_off_t)offset, stdiowhence) == 0) {
+        const Sint64 pos = ftell(fp);
+        if (pos < 0) {
+            SDL_SetError("Couldn't get stream offset");
+            return -1;
+        }
+        return pos;
+    }
+    SDL_SetError("Couldn't seek in stream");
+    return -1;
+}
+
+static size_t SDLCALL stdio_read(void *userdata, void *ptr, size_t size, SDL_IOStatus *status)
+{
+    FILE *fp = ((IOStreamStdioFPData *) userdata)->fp;
+    const size_t bytes = fread(ptr, 1, size, fp);
+    if (bytes == 0 && ferror(fp)) {
+        SDL_SetError("Couldn't read stream");
+    }
+    return bytes;
+}
+
+static size_t SDLCALL stdio_write(void *userdata, const void *ptr, size_t size, SDL_IOStatus *status)
+{
+    FILE *fp = ((IOStreamStdioFPData *) userdata)->fp;
+    const size_t bytes = fwrite(ptr, 1, size, fp);
+    if (bytes == 0 && ferror(fp)) {
+        SDL_SetError("Couldn't write stream");
+    }
+    return bytes;
+}
+
+static bool SDLCALL stdio_close(void *userdata)
+{
+    IOStreamStdioData *rwopsdata = (IOStreamStdioData *) userdata;
+    bool status = true;
+    if (rwopsdata->autoclose) {
+        if (fclose(rwopsdata->fp) != 0) {
+            SDL_SetError("Couldn't close stream");
+            status = false;
+        }
+    }
+    return status;
+}
+
+SDL_IOStream *SDL_RWFromFP(FILE *fp, bool autoclose)
+{
+    SDL_IOStreamInterface iface;
+    IOStreamStdioFPData *rwopsdata;
+    SDL_IOStream *rwops;
+
+    rwopsdata = (IOStreamStdioFPData *) SDL_malloc(sizeof (*rwopsdata));
+    if (!rwopsdata) {
+        return NULL;
+    }
+
+    SDL_INIT_INTERFACE(&iface);
+    /* There's no stdio_size because SDL_GetIOSize emulates it the same way we'd do it for stdio anyhow. */
+    iface.seek = stdio_seek;
+    iface.read = stdio_read;
+    iface.write = stdio_write;
+    iface.close = stdio_close;
+
+    rwopsdata->fp = fp;
+    rwopsdata->autoclose = autoclose;
+
+    rwops = SDL_OpenIO(&iface, rwopsdata);
+    if (!rwops) {
+        iface.close(rwopsdata);
+    }
+    return rwops;
+}
+```
+
+The internal `FILE *` is available through a standard SDL_IOStream property, for streams made through SDL_IOFromFile() that use stdio behind the scenes; apps use this pointer at their own risk and should make sure that SDL and the app are using the same C runtime.
+
+On Apple platforms, SDL_RWFromFile (now called SDL_IOFromFile) no longer tries to read from inside the app bundle's resource directory, instead now using the specified path unchanged. One can use SDL_GetBasePath() to find the resource directory on these platforms.
+
+
+The functions SDL_ReadU8(), SDL_ReadU16LE(), SDL_ReadU16BE(), SDL_ReadU32LE(), SDL_ReadU32BE(), SDL_ReadU64LE(), and SDL_ReadU64BE() now return true if the read succeeded and false if it didn't, and store the data in a pointer passed in as a parameter.
+
+The following functions have been renamed:
+* SDL_RWFromConstMem() => SDL_IOFromConstMem()
+* SDL_RWFromFile() => SDL_IOFromFile()
+* SDL_RWFromMem() => SDL_IOFromMem()
+* SDL_RWclose() => SDL_CloseIO(), returns bool
+* SDL_RWread() => SDL_ReadIO()
+* SDL_RWseek() => SDL_SeekIO()
+* SDL_RWsize() => SDL_GetIOSize()
+* SDL_RWtell() => SDL_TellIO()
+* SDL_RWwrite() => SDL_WriteIO()
+* SDL_ReadBE16() => SDL_ReadU16BE()
+* SDL_ReadBE32() => SDL_ReadU32BE()
+* SDL_ReadBE64() => SDL_ReadU64BE()
+* SDL_ReadLE16() => SDL_ReadU16LE()
+* SDL_ReadLE32() => SDL_ReadU32LE()
+* SDL_ReadLE64() => SDL_ReadU64LE()
+* SDL_WriteBE16() => SDL_WriteU16BE()
+* SDL_WriteBE32() => SDL_WriteU32BE()
+* SDL_WriteBE64() => SDL_WriteU64BE()
+* SDL_WriteLE16() => SDL_WriteU16LE()
+* SDL_WriteLE32() => SDL_WriteU32LE()
+* SDL_WriteLE64() => SDL_WriteU64LE()
+
+
+The following structures have been renamed:
+* SDL_RWops => SDL_IOStream
+
+## SDL_scancode.h
+
+The following symbols have been removed:
+* SDL_SCANCODE_WWW
+* SDL_SCANCODE_MAIL
+* SDL_SCANCODE_CALCULATOR
+* SDL_SCANCODE_COMPUTER
+* SDL_SCANCODE_BRIGHTNESSDOWN
+* SDL_SCANCODE_BRIGHTNESSUP
+* SDL_SCANCODE_DISPLAYSWITCH
+* SDL_SCANCODE_KBDILLUMTOGGLE
+* SDL_SCANCODE_KBDILLUMDOWN
+* SDL_SCANCODE_KBDILLUMUP
+* SDL_SCANCODE_APP1
+* SDL_SCANCODE_APP2
+
+The following symbols have been renamed:
+* SDL_NUM_SCANCODES => SDL_SCANCODE_COUNT
+* SDL_SCANCODE_AUDIOFASTFORWARD => SDL_SCANCODE_MEDIA_FAST_FORWARD
+* SDL_SCANCODE_AUDIOMUTE => SDL_SCANCODE_MUTE
+* SDL_SCANCODE_AUDIONEXT => SDL_SCANCODE_MEDIA_NEXT_TRACK
+* SDL_SCANCODE_AUDIOPLAY => SDL_SCANCODE_MEDIA_PLAY
+* SDL_SCANCODE_AUDIOPREV => SDL_SCANCODE_MEDIA_PREVIOUS_TRACK
+* SDL_SCANCODE_AUDIOREWIND => SDL_SCANCODE_MEDIA_REWIND
+* SDL_SCANCODE_AUDIOSTOP => SDL_SCANCODE_MEDIA_STOP
+* SDL_SCANCODE_EJECT => SDL_SCANCODE_MEDIA_EJECT
+* SDL_SCANCODE_MEDIASELECT => SDL_SCANCODE_MEDIA_SELECT
+
+## SDL_sensor.h
+
+SDL_SensorID has changed from Sint32 to Uint32, with an invalid ID being 0.
+
+Rather than iterating over sensors using device index, there is a new function SDL_GetSensors() to get the current list of sensors, and new functions to get information about sensors from their instance ID:
+```c
+{
+    if (SDL_InitSubSystem(SDL_INIT_SENSOR)) {
+        int i, num_sensors;
+        SDL_SensorID *sensors = SDL_GetSensors(&num_sensors);
+        if (sensors) {
+            for (i = 0; i < num_sensors; ++i) {
+                SDL_Log("Sensor %" SDL_PRIu32 ": %s, type %d, platform type %d",
+                        sensors[i],
+                        SDL_GetSensorNameForID(sensors[i]),
+                        SDL_GetSensorTypeForID(sensors[i]),
+                        SDL_GetSensorNonPortableTypeForID(sensors[i]));
+            }
+            SDL_free(sensors);
+        }
+        SDL_QuitSubSystem(SDL_INIT_SENSOR);
+    }
+}
+```
+
+Removed SDL_SensorGetDataWithTimestamp(), if you want timestamps for the sensor data, you should use the sensor_timestamp member of SDL_EVENT_SENSOR_UPDATE events.
+
+
+The following functions have been renamed:
+* SDL_SensorClose() => SDL_CloseSensor()
+* SDL_SensorFromInstanceID() => SDL_GetSensorFromID()
+* SDL_SensorGetData() => SDL_GetSensorData(), returns bool
+* SDL_SensorGetInstanceID() => SDL_GetSensorID()
+* SDL_SensorGetName() => SDL_GetSensorName()
+* SDL_SensorGetNonPortableType() => SDL_GetSensorNonPortableType()
+* SDL_SensorGetType() => SDL_GetSensorType()
+* SDL_SensorOpen() => SDL_OpenSensor()
+* SDL_SensorUpdate() => SDL_UpdateSensors()
+
+The following functions have been removed:
+* SDL_LockSensors()
+* SDL_NumSensors() - replaced with SDL_GetSensors()
+* SDL_SensorGetDeviceInstanceID()
+* SDL_SensorGetDeviceName() - replaced with SDL_GetSensorNameForID()
+* SDL_SensorGetDeviceNonPortableType() - replaced with SDL_GetSensorNonPortableTypeForID()
+* SDL_SensorGetDeviceType() - replaced with SDL_GetSensorTypeForID()
+* SDL_UnlockSensors()
+
+## SDL_shape.h
+
+This header has been removed and a simplified version of this API has been added as SDL_SetWindowShape() in SDL_video.h. See test/testshape.c for an example.
+
+## SDL_stdinc.h
+
+The standard C headers like stdio.h and stdlib.h are no longer included, you should include them directly in your project if you use non-SDL C runtime functions.
+M_PI is no longer defined in SDL_stdinc.h, you can use the new symbols SDL_PI_D (double) and SDL_PI_F (float) instead.
+
+bool is now defined as bool, and is 1 byte instead of the size of an int.
+
+SDL3 attempts to apply consistency to case-insensitive string functions. In SDL2, things like SDL_strcasecmp() would usually only work on English letters, and depending on the user's locale, possibly not even those. In SDL3, consistency is applied:
+
+- Many things that don't care about case-insensitivity, like SDL_strcmp(), continue to work with any null-terminated string of bytes, even if it happens to be malformed UTF-8.
+- SDL_strcasecmp() expects valid UTF-8 strings, and will attempt to support _most_ Unicode characters with a technique known as "case-folding," which is to say it can match 'A' and 'a', and also 'Η' and 'η', but ALSO 'ß' and "ss". This is _probably_ how most apps assumed it worked in SDL2 and won't need any changes.
+- SDL_strncasecmp() works the same, but the third parameter takes _bytes_, as before, so SDL_strlen() can continue to be used with it. If a string hits the limit in the middle of a codepoint, the half-processed bytes of the codepoint will be treated as a collection of U+0xFFFD (REPLACEMENT CHARACTER) codepoints, which you probably don't want.
+- SDL_wcscasecmp() and SDL_wcsncasecmp() work the same way but operate on UTF-16 or UTF-32 encoded strings, depending on what the platform considers "wchar_t" to be. SDL_wcsncasecmp's third parameter is number of wchar_t values, not bytes, but UTF-16 has the same concerns as UTF-8 for variable-length codepoints.
+- SDL_strcasestr() expects valid UTF-8 strings, and will compare codepoints using case-folding.
+- SDL_tolower() and SDL_toupper() continue to only work on single bytes (even though the parameter is an `int`) and _only_ converts low-ASCII English A through Z.
+- SDL_strlwr() and SDL_strupr() operates on individual bytes (not UTF-8 codepoints) and only change low-ASCII English 'A' through 'Z'. These functions do not check the string for valid UTF-8 encoding.
+- The ctype.h replacement SDL_is*() functions (SDL_isalpha, SDL_isdigit, etc) only work on low-ASCII characters and ignore user locale, assuming English. This makes these functions consistent in SDL3, but applications need to be careful to understand their limits.
+
+Please note that the case-folding technique used by SDL3 will not produce correct results for the "Turkish 'I'"; this one letter is a surprisingly hard problem in the Unicode world, and since these functions do not specify the human language in use, we have chosen to ignore this problem.
+
+SDL_strtoll(), SDL_strtoull(), SDL_lltoa(), and SDL_ulltoa() use long long values instead of 64-bit values, to match their C runtime counterparts.
+
+SDL_setenv() is not thread-safe and has been renamed SDL_setenv_unsafe().
+
+The following macros have been removed:
+* SDL_TABLESIZE() - use SDL_arraysize() instead
+
+The following functions have been renamed:
+* SDL_size_add_overflow() => SDL_size_add_check_overflow(), returns bool
+* SDL_size_mul_overflow() => SDL_size_mul_check_overflow(), returns bool
+* SDL_strtokr() => SDL_strtok_r()
+
+The following functions have been removed:
+* SDL_memcpy4()
+
+The following symbols have been renamed:
+* SDL_FALSE => false
+* SDL_TRUE => true
+* SDL_bool => bool
+
+## SDL_surface.h
+
+SDL_Surface has been simplified and internal details are no longer in the public structure.
+
+The `format` member of SDL_Surface is now an enumerated pixel format value. You can get the full details of the pixel format by calling `SDL_GetPixelFormatDetails(surface->format)`. You can get the palette associated with the surface by calling SDL_GetSurfacePalette(). You can get the clip rectangle by calling SDL_GetSurfaceClipRect().
+
+The userdata member of SDL_Surface has been replaced with a more general properties interface, which can be queried with SDL_GetSurfaceProperties()
+
+Indexed format surfaces no longer have a palette by default. Surfaces without a palette will copy the pixels untranslated between surfaces.
+
+Code that used to look like this:
+```c
+    SDL_Surface *surface = SDL_CreateRGBSurfaceWithFormat(0, 32, 32, 8, SDL_PIXELFORMAT_INDEX8);
+    SDL_Palette *palette = surface->format->palette;
+    ...
+```
+should be changed to:
+```c
+    SDL_Surface *surface = SDL_CreateSurface(32, 32, SDL_PIXELFORMAT_INDEX8);
+    SDL_Palette *palette = SDL_CreateSurfacePalette(surface);
+    ...
+```
+
+Removed the unused 'flags' parameter from SDL_ConvertSurface.
+
+SDL_CreateRGBSurface() and SDL_CreateRGBSurfaceWithFormat() have been combined into a new function SDL_CreateSurface().
+SDL_CreateRGBSurfaceFrom() and SDL_CreateRGBSurfaceWithFormatFrom() have been combined into a new function SDL_CreateSurfaceFrom(), and the parameter order has changed for consistency with SDL_CreateSurface().
+
+You can implement the old functions in your own code easily:
+```c
+SDL_Surface *SDL_CreateRGBSurface(Uint32 flags, int width, int height, int depth, Uint32 Rmask, Uint32 Gmask, Uint32 Bmask, Uint32 Amask)
+{
+    return SDL_CreateSurface(width, height,
+            SDL_GetPixelFormatForMasks(depth, Rmask, Gmask, Bmask, Amask));
+}
+
+SDL_Surface *SDL_CreateRGBSurfaceWithFormat(Uint32 flags, int width, int height, int depth, Uint32 format)
+{
+    return SDL_CreateSurface(width, height, format);
+}
+
+SDL_Surface *SDL_CreateRGBSurfaceFrom(void *pixels, int width, int height, int depth, int pitch, Uint32 Rmask, Uint32 Gmask, Uint32 Bmask, Uint32 Amask)
+{
+    return SDL_CreateSurfaceFrom(width, height,
+                                 SDL_GetPixelFormatForMasks(depth, Rmask, Gmask, Bmask, Amask),
+                                 pixels, pitch);
+}
+
+SDL_Surface *SDL_CreateRGBSurfaceWithFormatFrom(void *pixels, int width, int height, int depth, int pitch, Uint32 format)
+{
+    return SDL_CreateSurfaceFrom(width, height, format, pixels, pitch);
+}
+
+```
+
+But if you're migrating your code which uses masks, you probably have a format in mind, possibly one of these:
+```c
+// Various mask (R, G, B, A) and their corresponding format:
+0xFF000000 0x00FF0000 0x0000FF00 0x000000FF => SDL_PIXELFORMAT_RGBA8888
+0x00FF0000 0x0000FF00 0x000000FF 0xFF000000 => SDL_PIXELFORMAT_ARGB8888
+0x0000FF00 0x00FF0000 0xFF000000 0x000000FF => SDL_PIXELFORMAT_BGRA8888
+0x000000FF 0x0000FF00 0x00FF0000 0xFF000000 => SDL_PIXELFORMAT_ABGR8888
+0x0000F800 0x000007E0 0x0000001F 0x00000000 => SDL_PIXELFORMAT_RGB565
+```
+
+SDL_BlitSurface() and SDL_BlitSurfaceScaled() now have a const `dstrect` parameter and do not fill it in with the final destination rectangle.
+
+SDL_BlitSurfaceScaled() and SDL_BlitSurfaceUncheckedScaled() now take a scale parameter.
+
+SDL_PixelFormat is used instead of Uint32 for API functions that refer to pixel format by enumerated value.
+
+SDL_SetSurfaceColorKey() takes an bool to enable and disable colorkey. RLE acceleration isn't controlled by the parameter, you should use SDL_SetSurfaceRLE() to change that separately.
+
+SDL_SetSurfaceRLE() takes an bool to enable and disable RLE acceleration.
+
+The following functions have been renamed:
+* SDL_BlitScaled() => SDL_BlitSurfaceScaled(), returns bool
+* SDL_ConvertSurfaceFormat() => SDL_ConvertSurface()
+* SDL_FillRect() => SDL_FillSurfaceRect(), returns bool
+* SDL_FillRects() => SDL_FillSurfaceRects(), returns bool
+* SDL_FreeSurface() => SDL_DestroySurface()
+* SDL_GetClipRect() => SDL_GetSurfaceClipRect(), returns bool
+* SDL_GetColorKey() => SDL_GetSurfaceColorKey(), returns bool
+* SDL_HasColorKey() => SDL_SurfaceHasColorKey()
+* SDL_HasSurfaceRLE() => SDL_SurfaceHasRLE()
+* SDL_LoadBMP_RW() => SDL_LoadBMP_IO()
+* SDL_LowerBlit() => SDL_BlitSurfaceUnchecked(), returns bool
+* SDL_LowerBlitScaled() => SDL_BlitSurfaceUncheckedScaled(), returns bool
+* SDL_SaveBMP_RW() => SDL_SaveBMP_IO(), returns bool
+* SDL_SetClipRect() => SDL_SetSurfaceClipRect()
+* SDL_SetColorKey() => SDL_SetSurfaceColorKey(), returns bool
+* SDL_UpperBlit() => SDL_BlitSurface(), returns bool
+* SDL_UpperBlitScaled() => SDL_BlitSurfaceScaled(), returns bool
+
+The following symbols have been removed:
+* SDL_SWSURFACE
+
+The following functions have been removed:
+* SDL_FreeFormat()
+* SDL_GetYUVConversionMode()
+* SDL_GetYUVConversionModeForResolution()
+* SDL_SetYUVConversionMode() - use SDL_SetSurfaceColorspace() to set the surface colorspace and SDL_PROP_TEXTURE_CREATE_COLORSPACE_NUMBER with SDL_CreateTextureWithProperties() to set the texture colorspace. The default colorspace for YUV pixel formats is SDL_COLORSPACE_JPEG.
+* SDL_SoftStretch() - use SDL_StretchSurface() with SDL_SCALEMODE_NEAREST
+* SDL_SoftStretchLinear() - use SDL_StretchSurface() with SDL_SCALEMODE_LINEAR
+
+The following symbols have been renamed:
+* SDL_PREALLOC => SDL_SURFACE_PREALLOCATED
+* SDL_SIMD_ALIGNED => SDL_SURFACE_SIMD_ALIGNED
+
+## SDL_system.h
+
+SDL_WindowsMessageHook has changed signatures so the message may be modified and it can block further message processing.
+
+SDL_RequestAndroidPermission is no longer a blocking call; the caller now provides a callback function that fires when a response is available.
+
+SDL_iPhoneSetAnimationCallback() and SDL_iPhoneSetEventPump() have been renamed to SDL_SetiOSAnimationCallback() and SDL_SetiOSEventPump(), respectively. SDL2 has had macros to provide this new name with the old symbol since the introduction of the iPad, but now the correctly-named symbol is the only option.
+
+SDL_IsAndroidTV() has been renamed SDL_IsTV() and is no longer Android-specific; an app running on an Apple TV device will also return true, for example.
+
+The following functions have been removed:
+* SDL_GetWinRTFSPathUNICODE() - WinRT support was removed in SDL3.
+* SDL_GetWinRTFSPathUTF8() - WinRT support was removed in SDL3.
+* SDL_RenderGetD3D11Device() - replaced with the "SDL.renderer.d3d11.device" property
+* SDL_RenderGetD3D12Device() - replaced with the "SDL.renderer.d3d12.device" property
+* SDL_RenderGetD3D9Device() - replaced with the "SDL.renderer.d3d9.device" property
+* SDL_WinRTGetDeviceFamily() - WinRT support was removed in SDL3.
+
+The following functions have been renamed:
+* SDL_AndroidBackButton() => SDL_SendAndroidBackButton()
+* SDL_AndroidGetActivity() => SDL_GetAndroidActivity()
+* SDL_AndroidGetExternalStoragePath() => SDL_GetAndroidExternalStoragePath()
+* SDL_AndroidGetExternalStorageState() => SDL_GetAndroidExternalStorageState()
+* SDL_AndroidGetInternalStoragePath() => SDL_GetAndroidInternalStoragePath()
+* SDL_AndroidGetJNIEnv() => SDL_GetAndroidJNIEnv()
+* SDL_AndroidRequestPermission() => SDL_RequestAndroidPermission(), returns bool
+* SDL_AndroidRequestPermissionCallback() => SDL_RequestAndroidPermissionCallback()
+* SDL_AndroidSendMessage() => SDL_SendAndroidMessage(), returns bool
+* SDL_AndroidShowToast() => SDL_ShowAndroidToast(), returns bool
+* SDL_DXGIGetOutputInfo() => SDL_GetDXGIOutputInfo(), returns bool
+* SDL_Direct3D9GetAdapterIndex() => SDL_GetDirect3D9AdapterIndex()
+* SDL_GDKGetDefaultUser() => SDL_GetGDKDefaultUser(), returns bool
+* SDL_GDKGetTaskQueue() => SDL_GetGDKTaskQueue(), returns bool
+* SDL_IsAndroidTV() => SDL_IsTV()
+* SDL_LinuxSetThreadPriority() => SDL_SetLinuxThreadPriority(), returns bool
+* SDL_LinuxSetThreadPriorityAndPolicy() => SDL_SetLinuxThreadPriorityAndPolicy(), returns bool
+* SDL_OnApplicationDidBecomeActive() => SDL_OnApplicationDidEnterForeground()
+* SDL_OnApplicationWillResignActive() => SDL_OnApplicationWillEnterBackground()
+* SDL_iOSSetAnimationCallback() => SDL_SetiOSAnimationCallback(), returns bool
+* SDL_iOSSetEventPump() => SDL_SetiOSEventPump()
+* SDL_iPhoneSetAnimationCallback() => SDL_SetiOSAnimationCallback(), returns bool
+* SDL_iPhoneSetEventPump() => SDL_SetiOSEventPump()
+
+## SDL_syswm.h
+
+This header has been removed.
+
+The Windows and X11 events are now available via callbacks which you can set with SDL_SetWindowsMessageHook() and SDL_SetX11EventHook().
+
+The information previously available in SDL_GetWindowWMInfo() is now available as window properties, e.g.
+```c
+    SDL_SysWMinfo info;
+    SDL_VERSION(&info.version);
+
+#if defined(__WIN32__)
+    HWND hwnd = NULL;
+    if (SDL_GetWindowWMInfo(window, &info) && info.subsystem == SDL_SYSWM_WINDOWS) {
+        hwnd = info.info.win.window;
+    }
+    if (hwnd) {
+        ...
+    }
+#elif defined(__MACOSX__)
+    NSWindow *nswindow = NULL;
+    if (SDL_GetWindowWMInfo(window, &info) && info.subsystem == SDL_SYSWM_COCOA) {
+        nswindow = (__bridge NSWindow *)info.info.cocoa.window;
+    }
+    if (nswindow) {
+        ...
+    }
+#elif defined(__LINUX__)
+    if (SDL_GetWindowWMInfo(window, &info)) {
+        if (info.subsystem == SDL_SYSWM_X11) {
+            Display *xdisplay = info.info.x11.display;
+            Window xwindow = info.info.x11.window;
+            if (xdisplay && xwindow) {
+                ...
+            }
+        } else if (info.subsystem == SDL_SYSWM_WAYLAND) {
+            struct wl_display *display = info.info.wl.display;
+            struct wl_surface *surface = info.info.wl.surface;
+            if (display && surface) {
+                ...
+            }
+        }
+    }
+#elif defined(__IPHONEOS__)
+    UIWindow *uiwindow = NULL;
+    if (SDL_GetWindowWMInfo(window, &info) && info.subsystem == SDL_SYSWM_UIKIT) {
+        uiwindow = (__bridge UIWindow *)info.info.uikit.window;
+    }
+    if (uiwindow) {
+        GLuint framebuffer = info.info.uikit.framebuffer;
+        GLuint colorbuffer = info.info.uikit.colorbuffer;
+        GLuint resolveFramebuffer = info.info.uikit.resolveFramebuffer;
+        ...
+    }
+#endif
+```
+becomes:
+```c
+#if defined(SDL_PLATFORM_WIN32)
+    HWND hwnd = (HWND)SDL_GetPointerProperty(SDL_GetWindowProperties(window), SDL_PROP_WINDOW_WIN32_HWND_POINTER, NULL);
+    if (hwnd) {
+        ...
+    }
+#elif defined(SDL_PLATFORM_MACOS)
+    NSWindow *nswindow = (__bridge NSWindow *)SDL_GetPointerProperty(SDL_GetWindowProperties(window), SDL_PROP_WINDOW_COCOA_WINDOW_POINTER, NULL);
+    if (nswindow) {
+        ...
+    }
+#elif defined(SDL_PLATFORM_LINUX)
+    if (SDL_strcmp(SDL_GetCurrentVideoDriver(), "x11") == 0) {
+        Display *xdisplay = (Display *)SDL_GetPointerProperty(SDL_GetWindowProperties(window), SDL_PROP_WINDOW_X11_DISPLAY_POINTER, NULL);
+        Window xwindow = (Window)SDL_GetNumberProperty(SDL_GetWindowProperties(window), SDL_PROP_WINDOW_X11_WINDOW_NUMBER, 0);
+        if (xdisplay && xwindow) {
+            ...
+        }
+    } else if (SDL_strcmp(SDL_GetCurrentVideoDriver(), "wayland") == 0) {
+        struct wl_display *display = (struct wl_display *)SDL_GetPointerProperty(SDL_GetWindowProperties(window), SDL_PROP_WINDOW_WAYLAND_DISPLAY_POINTER, NULL);
+        struct wl_surface *surface = (struct wl_surface *)SDL_GetPointerProperty(SDL_GetWindowProperties(window), SDL_PROP_WINDOW_WAYLAND_SURFACE_POINTER, NULL);
+        if (display && surface) {
+            ...
+        }
+    }
+#elif defined(SDL_PLATFORM_IOS)
+    SDL_PropertiesID props = SDL_GetWindowProperties(window);
+    UIWindow *uiwindow = (__bridge UIWindow *)SDL_GetPointerProperty(props, SDL_PROP_WINDOW_UIKIT_WINDOW_POINTER, NULL);
+    if (uiwindow) {
+        GLuint framebuffer = (GLuint)SDL_GetNumberProperty(props, SDL_PROP_WINDOW_UIKIT_OPENGL_FRAMEBUFFER_NUMBER, 0);
+        GLuint colorbuffer = (GLuint)SDL_GetNumberProperty(props, SDL_PROP_WINDOW_UIKIT_OPENGL_RENDERBUFFER_NUMBER, 0);
+        GLuint resolveFramebuffer = (GLuint)SDL_GetNumberProperty(props, SDL_PROP_WINDOW_UIKIT_OPENGL_RESOLVE_FRAMEBUFFER_NUMBER, 0);
+        ...
+    }
+#endif
+```
+
+## SDL_thread.h
+
+SDL_CreateThreadWithStackSize has been replaced with SDL_CreateThreadWithProperties.
+
+SDL_CreateThread and SDL_CreateThreadWithProperties now take beginthread/endthread function pointers on all platforms (ignoring them on most), and have been replaced with macros that hide this detail on all platforms. This works the same as before at the source code level, but the actual function signature that is called in SDL has changed. The library's exported symbol is SDL_CreateThreadRuntime, and looking for "SDL_CreateThread" in the DLL/Shared Library/Dylib will fail. You should not call this directly, but instead always use the macro!
+
+SDL_GetTLS() and SDL_SetTLS() take a pointer to a TLS ID, and will automatically initialize it in a thread-safe way as needed.
+
+The following functions have been renamed:
+* SDL_SetThreadPriority() => SDL_SetCurrentThreadPriority()
+* SDL_TLSCleanup() => SDL_CleanupTLS()
+* SDL_TLSGet() => SDL_GetTLS()
+* SDL_TLSSet() => SDL_SetTLS(), returns bool
+* SDL_ThreadID() => SDL_GetCurrentThreadID()
+
+The following functions have been removed:
+* SDL_TLSCreate() - TLS IDs are automatically allocated as needed.
+
+The following symbols have been renamed:
+* SDL_threadID => SDL_ThreadID
+
+## SDL_timer.h
+
+SDL_GetTicks() now returns a 64-bit value. Instead of using the SDL_TICKS_PASSED macro, you can directly compare tick values, e.g.
+```c
+Uint32 deadline = SDL_GetTicks() + 1000;
+...
+if (SDL_TICKS_PASSED(SDL_GetTicks(), deadline)) {
+    ...
+}
+```
+becomes:
+```c
+Uint64 deadline = SDL_GetTicks() + 1000
+...
+if (SDL_GetTicks() >= deadline) {
+    ...
+}
+```
+
+If you were using this macro for other things besides SDL ticks values, you can define it in your own code as:
+```c
+#define SDL_TICKS_PASSED(A, B)  ((Sint32)((B) - (A)) <= 0)
+```
+
+The callback passed to SDL_AddTimer() has changed parameters to:
+```c
+Uint32 SDLCALL TimerCallback(void *userdata, SDL_TimerID timerID, Uint32 interval);
+````
+
+## SDL_touch.h
+
+SDL_GetTouchName is replaced with SDL_GetTouchDeviceName(), which takes an SDL_TouchID instead of an index.
+
+SDL_TouchID and SDL_FingerID are now Uint64 with 0 being an invalid value.
+
+Rather than iterating over touch devices using an index, there is a new function SDL_GetTouchDevices() to get the available devices.
+
+Rather than iterating over touch fingers using an index, there is a new function SDL_GetTouchFingers() to get the current set of active fingers.
+
+The following functions have been removed:
+* SDL_GetNumTouchDevices() - replaced with SDL_GetTouchDevices()
+* SDL_GetNumTouchFingers() - replaced with SDL_GetTouchFingers()
+* SDL_GetTouchDevice() - replaced with SDL_GetTouchDevices()
+* SDL_GetTouchFinger() - replaced with SDL_GetTouchFingers()
+
+
+## SDL_version.h
+
+SDL_GetRevisionNumber() has been removed from the API, it always returned 0 in SDL 2.0.
+
+SDL_GetVersion() returns the version number, which can be directly compared with another version wrapped with SDL_VERSIONNUM().
+
+The following structures have been removed:
+* SDL_version
+
+The following symbols have been renamed:
+* SDL_COMPILEDVERSION => SDL_VERSION
+* SDL_PATCHLEVEL => SDL_MICRO_VERSION
+
+## SDL_video.h
+
+Several video backends have had their names lower-cased ("kmsdrm", "rpi", "android", "psp", "ps2", "vita"). SDL already does a case-insensitive compare for SDL_HINT_VIDEO_DRIVER tests, but if your app is calling SDL_GetVideoDriver() or SDL_GetCurrentVideoDriver() and doing case-sensitive compares on those strings, please update your code.
+
+SDL_VideoInit() and SDL_VideoQuit() have been removed. Instead you can call SDL_InitSubSystem() and SDL_QuitSubSystem() with SDL_INIT_VIDEO, which will properly refcount the subsystems. You can choose a specific video driver using SDL_HINT_VIDEO_DRIVER.
+
+Rather than iterating over displays using display index, there is a new function SDL_GetDisplays() to get the current list of displays, and functions which used to take a display index now take SDL_DisplayID, with an invalid ID being 0.
+```c
+{
+    if (SDL_InitSubSystem(SDL_INIT_VIDEO)) {
+        int i, num_displays = 0;
+        SDL_DisplayID *displays = SDL_GetDisplays(&num_displays);
+        if (displays) {
+            for (i = 0; i < num_displays; ++i) {
+                SDL_DisplayID instance_id = displays[i];
+                const char *name = SDL_GetDisplayName(instance_id);
+
+                SDL_Log("Display %" SDL_PRIu32 ": %s", instance_id, name ? name : "Unknown");
+            }
+            SDL_free(displays);
+        }
+        SDL_QuitSubSystem(SDL_INIT_VIDEO);
+    }
+}
+```
+
+SDL_CreateWindow() has been simplified and no longer takes a window position. You can use SDL_CreateWindowWithProperties() if you need to set the window position when creating it, e.g.
+```c
+    SDL_PropertiesID props = SDL_CreateProperties();
+    SDL_SetStringProperty(props, SDL_PROP_WINDOW_CREATE_TITLE_STRING, title);
+    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_X_NUMBER, x);
+    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_Y_NUMBER, y);
+    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_WIDTH_NUMBER, width);
+    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_HEIGHT_NUMBER, height);
+    // For window flags you should use separate window creation properties,
+    // but for easier migration from SDL2 you can use the following:
+    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_FLAGS_NUMBER, flags);
+    pWindow = SDL_CreateWindowWithProperties(props);
+    SDL_DestroyProperties(props);
+    if (window) {
+        ...
+    }
+```
+
+The SDL_WINDOWPOS_UNDEFINED_DISPLAY() and SDL_WINDOWPOS_CENTERED_DISPLAY() macros take a display ID instead of display index. The display ID 0 has a special meaning in this case, and is used to indicate the primary display.
+
+The SDL_WINDOW_SHOWN flag has been removed. Windows are shown by default and can be created hidden by using the SDL_WINDOW_HIDDEN flag.
+
+The SDL_WINDOW_SKIP_TASKBAR flag has been replaced by the SDL_WINDOW_UTILITY flag, which has the same functionality.
+
+SDL_DisplayMode now includes the pixel density which can be greater than 1.0 for display modes that have a higher pixel size than the mode size. You should use SDL_GetWindowSizeInPixels() to get the actual pixel size of the window back buffer.
+
+The refresh rate in SDL_DisplayMode is now a float, as well as being represented as a precise fraction with numerator and denominator.
+
+Rather than iterating over display modes using an index, there is a new function SDL_GetFullscreenDisplayModes() to get the list of available fullscreen modes on a display.
+```c
+{
+    SDL_DisplayID display = SDL_GetPrimaryDisplay();
+    int num_modes = 0;
+    SDL_DisplayMode **modes = SDL_GetFullscreenDisplayModes(display, &num_modes);
+    if (modes) {
+        for (i = 0; i < num_modes; ++i) {
+            SDL_DisplayMode *mode = modes[i];
+            SDL_Log("Display %" SDL_PRIu32 " mode %d: %dx%d@%gx %gHz",
+                    display, i, mode->w, mode->h, mode->pixel_density, mode->refresh_rate);
+        }
+        SDL_free(modes);
+    }
+}
+```
+
+SDL_GetDesktopDisplayMode() and SDL_GetCurrentDisplayMode() return pointers to display modes rather than filling in application memory.
+
+Windows now have an explicit fullscreen mode that is set, using SDL_SetWindowFullscreenMode(). The fullscreen mode for a window can be queried with SDL_GetWindowFullscreenMode(), which returns a pointer to the mode, or NULL if the window will be fullscreen desktop. SDL_SetWindowFullscreen() just takes a boolean value, setting the correct fullscreen state based on the selected mode.
+
+SDL_WINDOW_FULLSCREEN_DESKTOP has been removed, and you can call SDL_GetWindowFullscreenMode() to see whether an exclusive fullscreen mode will be used or the borderless fullscreen desktop mode will be used when the window is fullscreen.
+
+SDL_SetWindowBrightness(), SDL_GetWindowBrightness, SDL_SetWindowGammaRamp(), and SDL_GetWindowGammaRamp have been removed from the API, because they interact poorly with modern operating systems and aren't able to limit their effects to the SDL window.
+
+Programs which have access to shaders can implement more robust versions of those functions using custom shader code rendered as a post-process effect.
+
+Removed SDL_GL_CONTEXT_EGL from OpenGL configuration attributes. You can instead use `SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);`
+
+SDL_GL_GetProcAddress() and SDL_EGL_GetProcAddress() now return `SDL_FunctionPointer` instead of `void *`, and should be cast to the appropriate function type. You can define SDL_FUNCTION_POINTER_IS_VOID_POINTER in your project to restore the previous behavior.
+
+SDL_GL_DeleteContext() has been renamed to SDL_GL_DestroyContext to match SDL naming conventions (and glX/EGL!).
+
+SDL_GL_GetSwapInterval() takes the interval as an output parameter and returns true if the function succeeds or false if there was an error.
+
+SDL_GL_GetDrawableSize() has been removed. SDL_GetWindowSizeInPixels() can be used in its place.
+
+The SDL_WINDOW_TOOLTIP and SDL_WINDOW_POPUP_MENU window flags are now supported on Windows, Mac (Cocoa), X11, and Wayland. Creating windows with these flags must happen via the `SDL_CreatePopupWindow()` function. This function requires passing in the handle to a valid parent window for the popup, and the popup window is positioned relative to the parent.
+
+SDL_WindowFlags is used instead of Uint32 for API functions that refer to window flags, and has been extended to 64 bits.
+
+SDL_GetWindowOpacity() directly returns the opacity instead of using an out parameter.
+
+The following functions have been renamed:
+* SDL_GL_DeleteContext() => SDL_GL_DestroyContext(), returns bool
+* SDL_GetClosestDisplayMode() => SDL_GetClosestFullscreenDisplayMode(), returns bool
+* SDL_GetDisplayOrientation() => SDL_GetCurrentDisplayOrientation()
+* SDL_GetPointDisplayIndex() => SDL_GetDisplayForPoint()
+* SDL_GetRectDisplayIndex() => SDL_GetDisplayForRect()
+* SDL_GetWindowDisplayIndex() => SDL_GetDisplayForWindow()
+* SDL_GetWindowDisplayMode() => SDL_GetWindowFullscreenMode()
+* SDL_HasWindowSurface() => SDL_WindowHasSurface()
+* SDL_IsScreenSaverEnabled() => SDL_ScreenSaverEnabled()
+* SDL_SetWindowDisplayMode() => SDL_SetWindowFullscreenMode(), returns bool
+
+The following functions have been removed:
+* SDL_GetDisplayDPI() - not reliable across platforms, approximately replaced by multiplying SDL_GetWindowDisplayScale() times 160 on iPhone and Android, and 96 on other platforms.
+* SDL_GetDisplayMode()
+* SDL_GetNumDisplayModes() - replaced with SDL_GetFullscreenDisplayModes()
+* SDL_GetNumVideoDisplays() - replaced with SDL_GetDisplays()
+* SDL_SetWindowGrab() - use SDL_SetWindowMouseGrab() instead, along with SDL_SetWindowKeyboardGrab() if you also set SDL_HINT_GRAB_KEYBOARD.
+* SDL_GetWindowGrab() - use SDL_GetWindowMouseGrab() instead, along with SDL_GetWindowKeyboardGrab() if you also set SDL_HINT_GRAB_KEYBOARD.
+* SDL_GetWindowData() - use SDL_GetPointerProperty() instead, along with SDL_GetWindowProperties()
+* SDL_SetWindowData() - use SDL_SetPointerProperty() instead, along with SDL_GetWindowProperties()
+* SDL_CreateWindowFrom() - use SDL_CreateWindowWithProperties() with the properties that allow you to wrap an existing window
+* SDL_SetWindowInputFocus() - use SDL_RaiseWindow() instead
+* SDL_SetWindowModalFor() - use SDL_SetWindowParent() with SDL_SetWindowModal() instead
+* SDL_SetWindowBrightness() - use a shader or other in-game effect.
+* SDL_GetWindowBrightness() - use a shader or other in-game effect.
+* SDL_SetWindowGammaRamp() - use a shader or other in-game effect.
+* SDL_GetWindowGammaRamp() - use a shader or other in-game effect.
+
+The SDL_Window id type is named SDL_WindowID
+
+The following environment variables have been removed:
+* SDL_VIDEO_GL_DRIVER - replaced with the hint SDL_HINT_OPENGL_LIBRARY
+* SDL_VIDEO_EGL_DRIVER - replaced with the hint SDL_HINT_EGL_LIBRARY
+
+The following symbols have been renamed:
+* SDL_DISPLAYEVENT_DISCONNECTED => SDL_EVENT_DISPLAY_REMOVED
+* SDL_DISPLAYEVENT_MOVED => SDL_EVENT_DISPLAY_MOVED
+* SDL_DISPLAYEVENT_ORIENTATION => SDL_EVENT_DISPLAY_ORIENTATION
+* SDL_GLattr => SDL_GLAttr
+* SDL_GLcontextFlag => SDL_GLContextFlag
+* SDL_GLcontextReleaseFlag => SDL_GLContextReleaseFlag
+* SDL_GLprofile => SDL_GLProfile
+* SDL_WINDOWEVENT_CLOSE => SDL_EVENT_WINDOW_CLOSE_REQUESTED
+* SDL_WINDOWEVENT_DISPLAY_CHANGED => SDL_EVENT_WINDOW_DISPLAY_CHANGED
+* SDL_WINDOWEVENT_ENTER => SDL_EVENT_WINDOW_MOUSE_ENTER
+* SDL_WINDOWEVENT_EXPOSED => SDL_EVENT_WINDOW_EXPOSED
+* SDL_WINDOWEVENT_FOCUS_GAINED => SDL_EVENT_WINDOW_FOCUS_GAINED
+* SDL_WINDOWEVENT_FOCUS_LOST => SDL_EVENT_WINDOW_FOCUS_LOST
+* SDL_WINDOWEVENT_HIDDEN => SDL_EVENT_WINDOW_HIDDEN
+* SDL_WINDOWEVENT_HIT_TEST => SDL_EVENT_WINDOW_HIT_TEST
+* SDL_WINDOWEVENT_ICCPROF_CHANGED => SDL_EVENT_WINDOW_ICCPROF_CHANGED
+* SDL_WINDOWEVENT_LEAVE => SDL_EVENT_WINDOW_MOUSE_LEAVE
+* SDL_WINDOWEVENT_MAXIMIZED => SDL_EVENT_WINDOW_MAXIMIZED
+* SDL_WINDOWEVENT_MINIMIZED => SDL_EVENT_WINDOW_MINIMIZED
+* SDL_WINDOWEVENT_MOVED => SDL_EVENT_WINDOW_MOVED
+* SDL_WINDOWEVENT_RESIZED => SDL_EVENT_WINDOW_RESIZED
+* SDL_WINDOWEVENT_RESTORED => SDL_EVENT_WINDOW_RESTORED
+* SDL_WINDOWEVENT_SHOWN => SDL_EVENT_WINDOW_SHOWN
+* SDL_WINDOW_ALLOW_HIGHDPI => SDL_WINDOW_HIGH_PIXEL_DENSITY
+* SDL_WINDOW_INPUT_GRABBED => SDL_WINDOW_MOUSE_GRABBED
+
+The following symbols have been removed:
+* SDL_WINDOWEVENT_SIZE_CHANGED - handle the SDL_EVENT_WINDOW_RESIZED and SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED events instead
+* SDL_WINDOWEVENT_TAKE_FOCUS
+
+The following window operations are now considered to be asynchronous requests and should not be assumed to succeed unless
+a corresponding event has been received:
+* SDL_SetWindowSize() (SDL_EVENT_WINDOW_RESIZED)
+* SDL_SetWindowPosition() (SDL_EVENT_WINDOW_MOVED)
+* SDL_MinimizeWindow() (SDL_EVENT_WINDOW_MINIMIZED)
+* SDL_MaximizeWindow() (SDL_EVENT_WINDOW_MAXIMIZED)
+* SDL_RestoreWindow() (SDL_EVENT_WINDOW_RESTORED)
+* SDL_SetWindowFullscreen() (SDL_EVENT_WINDOW_ENTER_FULLSCREEN / SDL_EVENT_WINDOW_LEAVE_FULLSCREEN)
+
+If it is required that operations be applied immediately after one of the preceding calls, the `SDL_SyncWindow()` function
+will attempt to wait until all pending window operations have completed. The `SDL_HINT_VIDEO_SYNC_WINDOW_OPERATIONS` hint
+can also be set to automatically synchronize after all calls to an asynchronous window operation, mimicking the behavior
+of SDL 2. Be aware that synchronizing can potentially block for long periods of time, as it may have to wait for window
+animations to complete. Also note that windowing systems can deny or not precisely obey these requests (e.g. windows may
+not be allowed to be larger than the usable desktop space or placed offscreen), so a corresponding event may never arrive
+or not contain the expected values.
+
+## SDL_vulkan.h
+
+SDL_Vulkan_GetInstanceExtensions() no longer takes a window parameter, and no longer makes the app allocate query/allocate space for the result, instead returning a static const internal string.
+
+SDL_Vulkan_GetVkGetInstanceProcAddr() now returns `SDL_FunctionPointer` instead of `void *`, and should be cast to PFN_vkGetInstanceProcAddr.
+
+SDL_Vulkan_CreateSurface() now takes a VkAllocationCallbacks pointer as its third parameter. If you don't have an allocator to supply, pass a NULL here to use the system default allocator (SDL2 always used the system default allocator here).
+
+SDL_Vulkan_GetDrawableSize() has been removed. SDL_GetWindowSizeInPixels() can be used in its place.
+
+SDL_vulkanInstance and SDL_vulkanSurface have been removed. They were for compatibility with Tizen, who had built their own Vulkan interface into SDL2, but these apps will need changes for the SDL3 API if they are upgraded anyhow.
diff --git a/src/contrib/SDL-3.2.20/docs/README-n3ds.md b/src/contrib/SDL-3.2.20/docs/README-n3ds.md
new file mode 100644
index 0000000..8f95473
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-ngage.md b/src/contrib/SDL-3.2.20/docs/README-ngage.md
new file mode 100644
index 0000000..84192b0
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-platforms.md b/src/contrib/SDL-3.2.20/docs/README-platforms.md
new file mode 100644
index 0000000..46a054a
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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-n3ds.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
diff --git a/src/contrib/SDL-3.2.20/docs/README-porting.md b/src/contrib/SDL-3.2.20/docs/README-porting.md
new file mode 100644
index 0000000..ada1d67
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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)
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-ps2.md b/src/contrib/SDL-3.2.20/docs/README-ps2.md
new file mode 100644
index 0000000..d358565
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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
diff --git a/src/contrib/SDL-3.2.20/docs/README-ps4.md b/src/contrib/SDL-3.2.20/docs/README-ps4.md
new file mode 100644
index 0000000..29b5a93
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-ps5.md b/src/contrib/SDL-3.2.20/docs/README-ps5.md
new file mode 100644
index 0000000..55470d4
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-psp.md b/src/contrib/SDL-3.2.20/docs/README-psp.md
new file mode 100644
index 0000000..65d2af2
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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
diff --git a/src/contrib/SDL-3.2.20/docs/README-riscos.md b/src/contrib/SDL-3.2.20/docs/README-riscos.md
new file mode 100644
index 0000000..5af80a7
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-steamos.md b/src/contrib/SDL-3.2.20/docs/README-steamos.md
new file mode 100644
index 0000000..0feab9a
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-strings.md b/src/contrib/SDL-3.2.20/docs/README-strings.md
new file mode 100644
index 0000000..ea86b8d
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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).
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-switch.md b/src/contrib/SDL-3.2.20/docs/README-switch.md
new file mode 100644
index 0000000..16b7acd
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-touch.md b/src/contrib/SDL-3.2.20/docs/README-touch.md
new file mode 100644
index 0000000..05edc2c
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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)
diff --git a/src/contrib/SDL-3.2.20/docs/README-versions.md b/src/contrib/SDL-3.2.20/docs/README-versions.md
new file mode 100644
index 0000000..6c2d920
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/docs/README-versions.md
@@ -0,0 +1,48 @@
+# Versioning
+
+## Since 3.2.0
+
+SDL follows an "odd/even" versioning policy, similar to GLib, GTK, Flatpak
+and older versions of the Linux kernel:
+
+* If the minor version (second part) and the patch version (third part) is
+    divisible by 2 (for example 3.2.6, 3.4.0), 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 may add small changes
+        to the ABI, so newer patch versions are backwards-compatible but
+        not fully forwards-compatible. For example, programs built against
+        SDL 3.2.0 should work fine with SDL 3.2.8, but programs built against
+        SDL 3.2.8 may not work with 3.2.0.
+
+    * The minor version increases when significant changes are made that
+        require longer development or testing time, e.g. major new functionality,
+        or revamping support for a platform. Newer minor versions are
+        backwards-compatible, but not fully forwards-compatible. For example,
+        programs built against SDL 3.2.x should work fine with SDL 3.4.x,
+        but programs built against SDL 3.4.x may not work with 3.2.x.
+
+* If the minor version (second part) or patch version (third part) is not
+    divisible by 2 (for example 3.2.9, 3.3.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.
+
+    * Prereleases are backwards-compatible with older stable branches.
+        For example, programs built against SDL 3.2.x should work fine with
+        SDL 3.3.x, but programs built against SDL 3.3.x may not work with 3.2.x.
+
+    * Prereleases are not guaranteed to be backwards-compatible with each other.
+        For example, new API or ABI added in 3.3.0 might be removed or changed in
+        3.3.1. If this would be a problem for you, please do not use prereleases.
+
+    * Only use a prerelease if you can guarantee that you will promptly upgrade
+        to the stable release that follows it. For example, do not use 3.3.x
+        unless you will be able to upgrade to 3.4.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 only package stable releases, and not prereleases.
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-vita.md b/src/contrib/SDL-3.2.20/docs/README-vita.md
new file mode 100644
index 0000000..8d7e70b
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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.
diff --git a/src/contrib/SDL-3.2.20/docs/README-wayland.md b/src/contrib/SDL-3.2.20/docs/README-wayland.md
new file mode 100644
index 0000000..75a9b90
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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;
+}
+```
+
diff --git a/src/contrib/SDL-3.2.20/docs/README-windows.md b/src/contrib/SDL-3.2.20/docs/README-windows.md
new file mode 100644
index 0000000..1e6d464
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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).
diff --git a/src/contrib/SDL-3.2.20/docs/README.md b/src/contrib/SDL-3.2.20/docs/README.md
new file mode 100644
index 0000000..d0f5a54
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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>
diff --git a/src/contrib/SDL-3.2.20/docs/doxyfile b/src/contrib/SDL-3.2.20/docs/doxyfile
new file mode 100644
index 0000000..c8891d8
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/docs/doxyfile
@@ -0,0 +1,1564 @@
+# Doxyfile 1.5.9
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project
+#
+# All text after a hash (#) is considered a comment and will be ignored
+# The format is:
+#       TAG = value [value, ...]
+# For lists items can also be appended using:
+#       TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (" ")
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file 
+# that follow. The default is UTF-8 which is also the encoding used for all 
+# text before the first occurrence of this tag. Doxygen uses libiconv (or the 
+# iconv built into libc) for the transcoding. See 
+# http://www.gnu.org/software/libiconv for the list of possible encodings.
+
+DOXYFILE_ENCODING      = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded 
+# by quotes) that should identify the project.
+
+PROJECT_NAME           = SDL
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number. 
+# This could be handy for archiving the generated documentation or 
+# if some version control system is used.
+
+PROJECT_NUMBER         = 3.0
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) 
+# base path where the generated documentation will be put. 
+# If a relative path is entered, it will be relative to the location 
+# where doxygen was started. If left blank the current directory will be used.
+
+OUTPUT_DIRECTORY       = ./output
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 
+# 4096 sub-directories (in 2 levels) under the output directory of each output 
+# format and will distribute the generated files over these directories. 
+# Enabling this option can be useful when feeding doxygen a huge amount of 
+# source files, where putting all generated files in the same directory would 
+# otherwise cause performance problems for the file system.
+
+CREATE_SUBDIRS         = YES
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all 
+# documentation generated by doxygen is written. Doxygen will use this 
+# information to generate all constant output in the proper language. 
+# The default language is English, other supported languages are: 
+# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, 
+# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German, 
+# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English 
+# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian, 
+# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrilic, Slovak, 
+# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.
+
+OUTPUT_LANGUAGE        = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will 
+# include brief member descriptions after the members that are listed in 
+# the file and class documentation (similar to JavaDoc). 
+# Set to NO to disable this.
+
+BRIEF_MEMBER_DESC      = YES
+
+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend 
+# the brief description of a member or function before the detailed description. 
+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the 
+# brief descriptions will be completely suppressed.
+
+REPEAT_BRIEF           = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator 
+# that is used to form the text in various listings. Each string 
+# in this list, if found as the leading text of the brief description, will be 
+# stripped from the text and the result after processing the whole list, is 
+# used as the annotated text. Otherwise, the brief description is used as-is. 
+# If left blank, the following values are used ("$name" is automatically 
+# replaced with the name of the entity): "The $name class" "The $name widget" 
+# "The $name file" "is" "provides" "specifies" "contains" 
+# "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF       = "The $name class" \
+                         "The $name widget" \
+                         "The $name file" \
+                         is \
+                         provides \
+                         specifies \
+                         contains \
+                         represents \
+                         a \
+                         an \
+                         the
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then 
+# Doxygen will generate a detailed section even if there is only a brief 
+# description.
+
+ALWAYS_DETAILED_SEC    = YES
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all 
+# inherited members of a class in the documentation of that class as if those 
+# members were ordinary class members. Constructors, destructors and assignment 
+# operators of the base classes will not be shown.
+
+INLINE_INHERITED_MEMB  = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full 
+# path before files name in the file list and in the header files. If set 
+# to NO the shortest path that makes the file name unique will be used.
+
+FULL_PATH_NAMES        = YES
+
+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag 
+# can be used to strip a user-defined part of the path. Stripping is 
+# only done if one of the specified strings matches the left-hand part of 
+# the path. The tag can be used to show relative paths in the file list. 
+# If left blank the directory from which doxygen is run is used as the 
+# path to strip.
+
+STRIP_FROM_PATH        =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of 
+# the path mentioned in the documentation of a class, which tells 
+# the reader which header file to include in order to use a class. 
+# If left blank only the name of the header file containing the class 
+# definition is used. Otherwise one should specify the include paths that 
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH    = 
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter 
+# (but less readable) file names. This can be useful is your file systems 
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES            = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen 
+# will interpret the first line (until the first dot) of a JavaDoc-style 
+# comment as the brief description. If set to NO, the JavaDoc 
+# comments will behave just like regular Qt-style comments 
+# (thus requiring an explicit @brief command for a brief description.)
+
+JAVADOC_AUTOBRIEF      = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then Doxygen will 
+# interpret the first line (until the first dot) of a Qt-style 
+# comment as the brief description. If set to NO, the comments 
+# will behave just like regular Qt-style comments (thus requiring 
+# an explicit \brief command for a brief description.)
+
+QT_AUTOBRIEF           = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen 
+# treat a multi-line C++ special comment block (i.e. a block of //! or /// 
+# comments) as a brief description. This used to be the default behaviour. 
+# The new default is to treat a multi-line C++ comment block as a detailed 
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented 
+# member inherits the documentation from any documented member that it 
+# re-implements.
+
+INHERIT_DOCS           = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce 
+# a new page for each member. If set to NO, the documentation of a member will 
+# be part of the file/class/namespace that contains it.
+
+SEPARATE_MEMBER_PAGES  = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. 
+# Doxygen uses this value to replace tabs by spaces in code fragments.
+
+TAB_SIZE               = 8
+
+# This tag can be used to specify a number of aliases that acts 
+# as commands in the documentation. An alias has the form "name=value". 
+# For example adding "sideeffect=\par Side Effects:\n" will allow you to 
+# put the command \sideeffect (or @sideeffect) in the documentation, which 
+# will result in a user-defined paragraph with heading "Side Effects:". 
+# You can put \n's in the value part of an alias to insert newlines.
+
+ALIASES                = "defined=\"\def\"" \
+                         "discussion=\"\par Discussion:\n\""
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C 
+# sources only. Doxygen will then generate output that is more tailored for C. 
+# For instance, some of the names that are used will be different. The list 
+# of all members will be omitted, etc.
+
+OPTIMIZE_OUTPUT_FOR_C  = YES
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java 
+# sources only. Doxygen will then generate output that is more tailored for 
+# Java. For instance, namespaces will be presented as packages, qualified 
+# scopes will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA   = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran 
+# sources only. Doxygen will then generate output that is more tailored for 
+# Fortran.
+
+OPTIMIZE_FOR_FORTRAN   = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL 
+# sources. Doxygen will then generate output that is tailored for 
+# VHDL.
+
+OPTIMIZE_OUTPUT_VHDL   = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it parses. 
+# With this tag you can assign which parser to use for a given extension. 
+# Doxygen has a built-in mapping, but you can override or extend it using this tag. 
+# The format is ext=language, where ext is a file extension, and language is one of 
+# the parsers supported by doxygen: IDL, Java, Javascript, C#, C, C++, D, PHP, 
+# Objective-C, Python, Fortran, VHDL, C, C++. For instance to make doxygen treat 
+# .inc files as Fortran files (default is PHP), and .f files as C (default is Fortran), 
+# use: inc=Fortran f=C. Note that for custom extensions you also need to set
+# FILE_PATTERNS otherwise the files are not read by doxygen.
+
+EXTENSION_MAPPING      = 
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want 
+# to include (a tag file for) the STL sources as input, then you should 
+# set this tag to YES in order to let doxygen match functions declarations and 
+# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. 
+# func(std::string) {}). This also make the inheritance and collaboration 
+# diagrams that involve STL classes more complete and accurate.
+
+BUILTIN_STL_SUPPORT    = YES
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to 
+# enable parsing support.
+
+CPP_CLI_SUPPORT        = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only. 
+# Doxygen will parse them like normal C++ but will assume all classes use public 
+# instead of private inheritance when no explicit protection keyword is present.
+
+SIP_SUPPORT            = NO
+
+# For Microsoft's IDL there are propget and propput attributes to indicate getter 
+# and setter methods for a property. Setting this option to YES (the default) 
+# will make doxygen to replace the get and set methods by a property in the 
+# documentation. This will only work if the methods are indeed getting or 
+# setting a simple type. If this is not the case, or you want to show the 
+# methods anyway, you should set this option to NO.
+
+IDL_PROPERTY_SUPPORT   = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC 
+# tag is set to YES, then doxygen will reuse the documentation of the first 
+# member in the group (if any) for the other members of the group. By default 
+# all members of a group must be documented explicitly.
+
+DISTRIBUTE_GROUP_DOC   = NO
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of 
+# the same type (for instance a group of public functions) to be put as a 
+# subgroup of that type (e.g. under the Public Functions section). Set it to 
+# NO to prevent subgrouping. Alternatively, this can be done per class using 
+# the \nosubgrouping command.
+
+SUBGROUPING            = YES
+
+# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum 
+# is documented as struct, union, or enum with the name of the typedef. So 
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct 
+# with name TypeT. When disabled the typedef will appear as a member of a file, 
+# namespace, or class. And the struct will be named TypeS. This can typically 
+# be useful for C code in case the coding convention dictates that all compound 
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+
+TYPEDEF_HIDES_STRUCT   = YES
+
+# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to 
+# determine which symbols to keep in memory and which to flush to disk. 
+# When the cache is full, less often used symbols will be written to disk. 
+# For small to medium size projects (<1000 input files) the default value is 
+# probably good enough. For larger projects a too small cache size can cause 
+# doxygen to be busy swapping symbols to and from disk most of the time 
+# causing a significant performance penality. 
+# If the system has enough physical memory increasing the cache will improve the 
+# performance by keeping more symbols in memory. Note that the value works on 
+# a logarithmic scale so increasing the size by one will rougly double the 
+# memory usage. The cache size is given by this formula: 
+# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0, 
+# corresponding to a cache size of 2^16 = 65536 symbols
+
+SYMBOL_CACHE_SIZE      = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in 
+# documentation are documented, even if no documentation was available. 
+# Private class members and static file members will be hidden unless 
+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+EXTRACT_ALL            = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class 
+# will be included in the documentation.
+
+EXTRACT_PRIVATE        = YES
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file 
+# will be included in the documentation.
+
+EXTRACT_STATIC         = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) 
+# defined locally in source files will be included in the documentation. 
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES  = YES
+
+# This flag is only useful for Objective-C code. When set to YES local 
+# methods, which are defined in the implementation section but not in 
+# the interface are included in the documentation. 
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS  = YES
+
+# If this flag is set to YES, the members of anonymous namespaces will be 
+# extracted and appear in the documentation as a namespace called 
+# 'anonymous_namespace{file}', where file will be replaced with the base 
+# name of the file that contains the anonymous namespace. By default 
+# anonymous namespace are hidden.
+
+EXTRACT_ANON_NSPACES   = YES
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all 
+# undocumented members of documented classes, files or namespaces. 
+# If set to NO (the default) these members will be included in the 
+# various overviews, but no documentation section is generated. 
+# This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_MEMBERS     = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all 
+# undocumented classes that are normally visible in the class hierarchy. 
+# If set to NO (the default) these classes will be included in the various 
+# overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_CLASSES     = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all 
+# friend (class|struct|union) declarations. 
+# If set to NO (the default) these declarations will be included in the 
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS  = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any 
+# documentation blocks found inside the body of a function. 
+# If set to NO (the default) these blocks will be appended to the 
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS      = NO
+
+# The INTERNAL_DOCS tag determines if documentation 
+# that is typed after a \internal command is included. If the tag is set 
+# to NO (the default) then the documentation will be excluded. 
+# Set it to YES to include the internal documentation.
+
+INTERNAL_DOCS          = YES
+
+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate 
+# file names in lower-case letters. If set to YES upper-case letters are also 
+# allowed. This is useful if you have classes or files whose names only differ 
+# in case and if your file system supports case sensitive file names. Windows 
+# and Mac users are advised to set this option to NO.
+
+CASE_SENSE_NAMES       = NO
+
+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen 
+# will show members with their full class and namespace scopes in the 
+# documentation. If set to YES the scope will be hidden.
+
+HIDE_SCOPE_NAMES       = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen 
+# will put a list of the files that are included by a file in the documentation 
+# of that file.
+
+SHOW_INCLUDE_FILES     = YES
+
+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] 
+# is inserted in the documentation for inline members.
+
+INLINE_INFO            = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen 
+# will sort the (detailed) documentation of file and class members 
+# alphabetically by member name. If set to NO the members will appear in 
+# declaration order.
+
+SORT_MEMBER_DOCS       = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the 
+# brief documentation of file, namespace and class members alphabetically 
+# by member name. If set to NO (the default) the members will appear in 
+# declaration order.
+
+SORT_BRIEF_DOCS        = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the 
+# hierarchy of group names into alphabetical order. If set to NO (the default) 
+# the group names will appear in their defined order.
+
+SORT_GROUP_NAMES       = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be 
+# sorted by fully-qualified names, including namespaces. If set to 
+# NO (the default), the class list will be sorted only by class name, 
+# not including the namespace part. 
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. 
+# Note: This option applies only to the class list, not to the 
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME     = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or 
+# disable (NO) the todo list. This list is created by putting \todo 
+# commands in the documentation.
+
+GENERATE_TODOLIST      = YES
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or 
+# disable (NO) the test list. This list is created by putting \test 
+# commands in the documentation.
+
+GENERATE_TESTLIST      = YES
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or 
+# disable (NO) the bug list. This list is created by putting \bug 
+# commands in the documentation.
+
+GENERATE_BUGLIST       = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or 
+# disable (NO) the deprecated list. This list is created by putting 
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional 
+# documentation sections, marked by \if sectionname ... \endif.
+
+ENABLED_SECTIONS       = 
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines 
+# the initial value of a variable or define consists of for it to appear in 
+# the documentation. If the initializer consists of more lines than specified 
+# here it will be hidden. Use a value of 0 to hide initializers completely. 
+# The appearance of the initializer of individual variables and defines in the 
+# documentation can be controlled using \showinitializer or \hideinitializer 
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES  = 30
+
+# If the sources in your project are distributed over multiple directories 
+# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy 
+# in the documentation. The default is NO.
+
+SHOW_DIRECTORIES       = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. 
+# This will remove the Files entry from the Quick Index and from the 
+# Folder Tree View (if specified). The default is YES.
+
+SHOW_FILES             = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the 
+# Namespaces page.  This will remove the Namespaces entry from the Quick Index 
+# and from the Folder Tree View (if specified). The default is YES.
+
+SHOW_NAMESPACES        = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that 
+# doxygen should invoke to get the current version for each file (typically from 
+# the version control system). Doxygen will invoke the program by executing (via 
+# popen()) the command <command> <input-file>, where <command> is the value of 
+# the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file 
+# provided by doxygen. Whatever the program writes to standard output 
+# is used as the file version. See the manual for examples.
+
+FILE_VERSION_FILTER    = 
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed by 
+# doxygen. The layout file controls the global structure of the generated output files 
+# in an output format independent way. The create the layout file that represents 
+# doxygen's defaults, run doxygen with the -l option. You can optionally specify a 
+# file name after the option, if omitted DoxygenLayout.xml will be used as the name 
+# of the layout file.
+
+LAYOUT_FILE            = 
+
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated 
+# by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+QUIET                  = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are 
+# generated by doxygen. Possible values are YES and NO. If left blank 
+# NO is used.
+
+WARNINGS               = YES
+
+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings 
+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will 
+# automatically be disabled.
+
+WARN_IF_UNDOCUMENTED   = YES
+
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for 
+# potential errors in the documentation, such as not documenting some 
+# parameters in a documented function, or documenting parameters that 
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR      = YES
+
+# This WARN_NO_PARAMDOC option can be abled to get warnings for 
+# functions that are documented, but have no documentation for their parameters 
+# or return value. If set to NO (the default) doxygen will only warn about 
+# wrong or incomplete parameter documentation, but not about the absence of 
+# documentation.
+
+WARN_NO_PARAMDOC       = YES
+
+# The WARN_FORMAT tag determines the format of the warning messages that 
+# doxygen can produce. The string should contain the $file, $line, and $text 
+# tags, which will be replaced by the file and line number from which the 
+# warning originated and the warning text. Optionally the format may contain 
+# $version, which will be replaced by the version of the file (if it could 
+# be obtained via FILE_VERSION_FILTER)
+
+WARN_FORMAT            = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning 
+# and error messages should be written. If left blank the output is written 
+# to stderr.
+
+WARN_LOGFILE           = ./doxygen_warn.txt
+
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag can be used to specify the files and/or directories that contain 
+# documented source files. You may enter file names like "myfile.cpp" or 
+# directories like "/usr/src/myproject". Separate the files or directories 
+# with spaces.
+
+INPUT                  = . ../include
+
+# This tag can be used to specify the character encoding of the source files 
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is 
+# also the default input encoding. Doxygen uses libiconv (or the iconv built 
+# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for 
+# the list of possible encodings.
+
+INPUT_ENCODING         = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the 
+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
+# and *.h) to filter out the source-files in the directories. If left 
+# blank the following patterns are tested: 
+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx 
+# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
+
+FILE_PATTERNS          = *.c \
+                         *.cc \
+                         *.cxx \
+                         *.cpp \
+                         *.c++ \
+                         *.d \
+                         *.java \
+                         *.ii \
+                         *.ixx \
+                         *.ipp \
+                         *.i++ \
+                         *.inl \
+                         *.h \
+                         *.hh \
+                         *.hxx \
+                         *.hpp \
+                         *.h++ \
+                         *.idl \
+                         *.odl \
+                         *.cs \
+                         *.php \
+                         *.php3 \
+                         *.inc \
+                         *.m \
+                         *.mm \
+                         *.dox \
+                         *.py \
+                         *.f90 \
+                         *.f \
+                         *.vhd \
+                         *.vhdl \
+                         *.h.in \
+                         *.h.default \
+                         *.md
+
+# The RECURSIVE tag can be used to turn specify whether or not subdirectories 
+# should be searched for input files as well. Possible values are YES and NO. 
+# If left blank NO is used.
+
+RECURSIVE              = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should 
+# excluded from the INPUT source files. This way you can easily exclude a 
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+EXCLUDE                = \
+    ../include/SDL3/SDL_egl.h \
+    ../include/SDL3/SDL_opengl.h \
+    ../include/SDL3/SDL_opengl_glext.h \
+    ../include/SDL3/SDL_opengles.h \
+    ../include/SDL3/SDL_opengles2.h \
+    ../include/SDL3/SDL_opengles2_gl2.h \
+    ../include/SDL3/SDL_opengles2_gl2ext.h \
+    ../include/SDL3/SDL_opengles2_gl2platform.h \
+    ../include/SDL3/SDL_opengles2_khrplatform.h \
+    ../include/build_config \
+    ./release_checklist.md \
+
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or 
+# directories that are symbolic links (a Unix filesystem feature) are excluded 
+# from the input.
+
+EXCLUDE_SYMLINKS       = NO
+
+# If the value of the INPUT tag contains directories, you can use the 
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude 
+# certain files from those directories. Note that the wildcards are matched 
+# against the file with absolute path, so to exclude all test directories 
+# for example use the pattern */test/*
+
+EXCLUDE_PATTERNS       =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names 
+# (namespaces, classes, functions, etc.) that should be excluded from the 
+# output. The symbol name can be a fully qualified name, a word, or if the 
+# wildcard * is used, a substring. Examples: ANamespace, AClass, 
+# AClass::ANamespace, ANamespace::*Test
+
+EXCLUDE_SYMBOLS        = 
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or 
+# directories that contain example code fragments that are included (see 
+# the \include command).
+
+EXAMPLE_PATH           =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the 
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
+# and *.h) to filter out the source-files in the directories. If left 
+# blank all files are included.
+
+EXAMPLE_PATTERNS       = *
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be 
+# searched for input files to be used with the \include or \dontinclude 
+# commands irrespective of the value of the RECURSIVE tag. 
+# Possible values are YES and NO. If left blank NO is used.
+
+EXAMPLE_RECURSIVE      = YES
+
+# The IMAGE_PATH tag can be used to specify one or more files or 
+# directories that contain image that are included in the documentation (see 
+# the \image command).
+
+IMAGE_PATH             = 
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should 
+# invoke to filter for each input file. Doxygen will invoke the filter program 
+# by executing (via popen()) the command <filter> <input-file>, where <filter> 
+# is the value of the INPUT_FILTER tag, and <input-file> is the name of an 
+# input file. Doxygen will then use the output that the filter program writes 
+# to standard output.  If FILTER_PATTERNS is specified, this tag will be 
+# ignored.
+
+INPUT_FILTER           = 
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern 
+# basis.  Doxygen will compare the file name with each pattern and apply the 
+# filter if there is a match.  The filters are a list of the form: 
+# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further 
+# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER 
+# is applied to all files.
+
+FILTER_PATTERNS        = 
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using 
+# INPUT_FILTER) will be used to filter the input files when producing source 
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+FILTER_SOURCE_FILES    = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will 
+# be generated. Documented entities will be cross-referenced with these sources. 
+# Note: To get rid of all source code in the generated output, make sure also 
+# VERBATIM_HEADERS is set to NO.
+
+SOURCE_BROWSER         = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body 
+# of functions and classes directly in the documentation.
+
+INLINE_SOURCES         = YES
+
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct 
+# doxygen to hide any special comment blocks from generated source code 
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS    = NO
+
+# If the REFERENCED_BY_RELATION tag is set to YES 
+# then for each documented function all documented 
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES 
+# then for each documented function all documented entities 
+# called/used by that function will be listed.
+
+REFERENCES_RELATION    = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) 
+# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from 
+# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will 
+# link to the source code.  Otherwise they will link to the documentation.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code 
+# will point to the HTML generated by the htags(1) tool instead of doxygen 
+# built-in source browser. The htags tool is part of GNU's global source 
+# tagging system (see http://www.gnu.org/software/global/global.html). You 
+# will need version 4.8.6 or higher.
+
+USE_HTAGS              = NO
+
+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen 
+# will generate a verbatim copy of the header file for each class for 
+# which an include is specified. Set to NO to disable this.
+
+VERBATIM_HEADERS       = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index 
+# of all compounds will be generated. Enable this if the project 
+# contains a lot of classes, structs, unions or interfaces.
+
+ALPHABETICAL_INDEX     = YES
+
+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then 
+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns 
+# in which this list will be split (can be a number in the range [1..20])
+
+COLS_IN_ALPHA_INDEX    = 5
+
+# In case all classes in a project start with a common prefix, all 
+# classes will be put under the same header in the alphabetical index. 
+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that 
+# should be ignored while generating the index headers.
+
+IGNORE_PREFIX          = SDL_ \
+                         SDL
+
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will 
+# generate HTML output.
+
+GENERATE_HTML          = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `html' will be used as the default path.
+
+HTML_OUTPUT            = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for 
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank 
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION    = .html
+
+# The HTML_HEADER tag can be used to specify a personal HTML header for 
+# each generated HTML page. If it is left blank doxygen will generate a 
+# standard header.
+
+HTML_HEADER            = 
+
+# The HTML_FOOTER tag can be used to specify a personal HTML footer for 
+# each generated HTML page. If it is left blank doxygen will generate a 
+# standard footer.
+
+HTML_FOOTER            = 
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading 
+# style sheet that is used by each HTML page. It can be used to 
+# fine-tune the look of the HTML output. If the tag is left blank doxygen 
+# will generate a default style sheet. Note that doxygen will try to copy 
+# the style sheet file to the HTML output directory, so don't put your own 
+# stylesheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET        = 
+
+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, 
+# files or namespaces will be aligned in HTML using tables. If set to 
+# NO a bullet list will be used.
+
+HTML_ALIGN_MEMBERS     = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML 
+# documentation will contain sections that can be hidden and shown after the 
+# page has loaded. For this to work a browser that supports 
+# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox 
+# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
+
+HTML_DYNAMIC_SECTIONS  = YES
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files 
+# will be generated that can be used as input for Apple's Xcode 3 
+# integrated development environment, introduced with OSX 10.5 (Leopard). 
+# To create a documentation set, doxygen will generate a Makefile in the 
+# HTML output directory. Running make will produce the docset in that 
+# directory and running "make install" will install the docset in 
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find 
+# it at startup. 
+# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html for more information.
+
+GENERATE_DOCSET        = NO
+
+# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the 
+# feed. A documentation feed provides an umbrella under which multiple 
+# documentation sets from a single provider (such as a company or product suite) 
+# can be grouped.
+
+DOCSET_FEEDNAME        = "SDL 3.0 Doxygen"
+
+# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that 
+# should uniquely identify the documentation set bundle. This should be a 
+# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen 
+# will append .docset to the name.
+
+DOCSET_BUNDLE_ID       = org.libsdl.sdl30
+
+# If the GENERATE_HTMLHELP tag is set to YES, additional index files 
+# will be generated that can be used as input for tools like the 
+# Microsoft HTML help workshop to generate a compiled HTML help file (.chm) 
+# of the generated HTML documentation.
+
+GENERATE_HTMLHELP      = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can 
+# be used to specify the file name of the resulting .chm file. You 
+# can add a path in front of the file if the result should not be 
+# written to the html output directory.
+
+CHM_FILE               = ./sdl30.chm
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can 
+# be used to specify the location (absolute path including file name) of 
+# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run 
+# the HTML help compiler on the generated index.hhp.
+
+HHC_LOCATION           = 
+
+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag 
+# controls if a separate .chi index file is generated (YES) or that 
+# it should be included in the master .chm file (NO).
+
+GENERATE_CHI           = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING 
+# is used to encode HtmlHelp index (hhk), content (hhc) and project file 
+# content.
+
+CHM_INDEX_ENCODING     = 
+
+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag 
+# controls whether a binary table of contents is generated (YES) or a 
+# normal table of contents (NO) in the .chm file.
+
+BINARY_TOC             = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members 
+# to the contents of the HTML help documentation and to the tree view.
+
+TOC_EXPAND             = YES
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and QHP_VIRTUAL_FOLDER 
+# are set, an additional index file will be generated that can be used as input for 
+# Qt's qhelpgenerator to generate a Qt Compressed Help (.qch) of the generated 
+# HTML documentation.
+
+GENERATE_QHP           = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can 
+# be used to specify the file name of the resulting .qch file. 
+# The path specified is relative to the HTML output folder.
+
+QCH_FILE               = 
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating 
+# Qt Help Project output. For more information please see 
+# http://doc.trolltech.com/qthelpproject.html#namespace
+
+QHP_NAMESPACE          = 
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating 
+# Qt Help Project output. For more information please see 
+# http://doc.trolltech.com/qthelpproject.html#virtual-folders
+
+QHP_VIRTUAL_FOLDER     = doc
+
+# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to add. 
+# For more information please see 
+# http://doc.trolltech.com/qthelpproject.html#custom-filters
+
+QHP_CUST_FILTER_NAME   = 
+
+# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the custom filter to add.For more information please see 
+# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">Qt Help Project / Custom Filters</a>.
+
+QHP_CUST_FILTER_ATTRS  = 
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this project's 
+# filter section matches. 
+# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">Qt Help Project / Filter Attributes</a>.
+
+QHP_SECT_FILTER_ATTRS  = 
+
+# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can 
+# be used to specify the location of Qt's qhelpgenerator. 
+# If non-empty doxygen will try to run qhelpgenerator on the generated 
+# .qhp file.
+
+QHG_LOCATION           = 
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at 
+# top of each HTML page. The value NO (the default) enables the index and 
+# the value YES disables it.
+
+DISABLE_INDEX          = NO
+
+# This tag can be used to set the number of enum values (range [1..20]) 
+# that doxygen will group on one line in the generated HTML documentation.
+
+ENUM_VALUES_PER_LINE   = 1
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index 
+# structure should be generated to display hierarchical information. 
+# If the tag value is set to FRAME, a side panel will be generated 
+# containing a tree-like index structure (just like the one that 
+# is generated for HTML Help). For this to work a browser that supports 
+# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, 
+# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are 
+# probably better off using the HTML help feature. Other possible values 
+# for this tag are: HIERARCHIES, which will generate the Groups, Directories, 
+# and Class Hierarchy pages using a tree view instead of an ordered list; 
+# ALL, which combines the behavior of FRAME and HIERARCHIES; and NONE, which 
+# disables this behavior completely. For backwards compatibility with previous 
+# releases of Doxygen, the values YES and NO are equivalent to FRAME and NONE 
+# respectively.
+
+GENERATE_TREEVIEW      = ALL
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be 
+# used to set the initial width (in pixels) of the frame in which the tree 
+# is shown.
+
+TREEVIEW_WIDTH         = 250
+
+# Use this tag to change the font size of Latex formulas included 
+# as images in the HTML documentation. The default is 10. Note that 
+# when you change the font size after a successful doxygen run you need 
+# to manually remove any form_*.png images from the HTML output directory 
+# to force them to be regenerated.
+
+FORMULA_FONTSIZE       = 10
+
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will 
+# generate Latex output.
+
+GENERATE_LATEX         = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `latex' will be used as the default path.
+
+LATEX_OUTPUT           = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be 
+# invoked. If left blank `latex' will be used as the default command name.
+
+LATEX_CMD_NAME         = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to 
+# generate index for LaTeX. If left blank `makeindex' will be used as the 
+# default command name.
+
+MAKEINDEX_CMD_NAME     = makeindex
+
+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact 
+# LaTeX documents. This may be useful for small projects and may help to 
+# save some trees in general.
+
+COMPACT_LATEX          = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used 
+# by the printer. Possible values are: a4, a4wide, letter, legal and 
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE             = a4wide
+
+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
+# packages that should be included in the LaTeX output.
+
+EXTRA_PACKAGES         = 
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for 
+# the generated latex document. The header should contain everything until 
+# the first chapter. If it is left blank doxygen will generate a 
+# standard header. Notice: only use this tag if you know what you are doing!
+
+LATEX_HEADER           = 
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated 
+# is prepared for conversion to pdf (using ps2pdf). The pdf file will 
+# contain links (just like the HTML output) instead of page references 
+# This makes the output suitable for online browsing using a pdf viewer.
+
+PDF_HYPERLINKS         = YES
+
+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of 
+# plain latex in the generated Makefile. Set this option to YES to get a 
+# higher quality PDF documentation.
+
+USE_PDFLATEX           = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. 
+# command to the generated LaTeX files. This will instruct LaTeX to keep 
+# running if errors occur, instead of asking the user for help. 
+# This option is also used when generating formulas in HTML.
+
+LATEX_BATCHMODE        = NO
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not 
+# include the index chapters (such as File Index, Compound Index, etc.) 
+# in the output.
+
+LATEX_HIDE_INDICES     = NO
+
+# If LATEX_SOURCE_CODE is set to YES then doxygen will include
+# source code with syntax highlighting in the LaTeX output.
+# Note that which sources are shown also depends on other settings
+# such as SOURCE_BROWSER.
+
+LATEX_SOURCE_CODE      = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output 
+# The RTF output is optimized for Word 97 and may not look very pretty with 
+# other RTF readers or editors.
+
+GENERATE_RTF           = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `rtf' will be used as the default path.
+
+RTF_OUTPUT             = rtf
+
+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact 
+# RTF documents. This may be useful for small projects and may help to 
+# save some trees in general.
+
+COMPACT_RTF            = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated 
+# will contain hyperlink fields. The RTF file will 
+# contain links (just like the HTML output) instead of page references. 
+# This makes the output suitable for online browsing using WORD or other 
+# programs which support those fields. 
+# Note: wordpad (write) and others do not support links.
+
+RTF_HYPERLINKS         = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's 
+# config file, i.e. a series of assignments. You only have to provide 
+# replacements, missing definitions are set to their default value.
+
+RTF_STYLESHEET_FILE    = 
+
+# Set optional variables used in the generation of an rtf document. 
+# Syntax is similar to doxygen's config file.
+
+RTF_EXTENSIONS_FILE    = 
+
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will 
+# generate man pages
+
+GENERATE_MAN           = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `man' will be used as the default path.
+
+MAN_OUTPUT             = man
+
+# The MAN_EXTENSION tag determines the extension that is added to 
+# the generated man pages (default is the subroutine's section .3)
+
+MAN_EXTENSION          = .3
+
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output, 
+# then it will generate one additional man file for each entity 
+# documented in the real man page(s). These additional files 
+# only source the real man page, but without them the man command 
+# would be unable to find the correct page. The default is NO.
+
+MAN_LINKS              = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES Doxygen will 
+# generate an XML file that captures the structure of 
+# the code including all documentation.
+
+GENERATE_XML           = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. 
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 
+# put in front of it. If left blank `xml' will be used as the default path.
+
+XML_OUTPUT             = xml
+
+# The XML_SCHEMA tag can be used to specify an XML schema, 
+# which can be used by a validating XML parser to check the 
+# syntax of the XML files.
+
+XML_SCHEMA             = 
+
+# The XML_DTD tag can be used to specify an XML DTD, 
+# which can be used by a validating XML parser to check the 
+# syntax of the XML files.
+
+XML_DTD                = 
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will 
+# dump the program listings (including syntax highlighting 
+# and cross-referencing information) to the XML output. Note that 
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING     = YES
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will 
+# generate an AutoGen Definitions (see autogen.sf.net) file 
+# that captures the structure of the code including all 
+# documentation. Note that this feature is still experimental 
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF   = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will 
+# generate a Perl module file that captures the structure of 
+# the code including all documentation. Note that this 
+# feature is still experimental and incomplete at the 
+# moment.
+
+GENERATE_PERLMOD       = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate 
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able 
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX          = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be 
+# nicely formatted so it can be parsed by a human reader.  This is useful 
+# if you want to understand what is going on.  On the other hand, if this 
+# tag is set to NO the size of the Perl module output will be much smaller 
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY         = YES
+
+# The names of the make variables in the generated doxyrules.make file 
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. 
+# This is useful so different doxyrules.make files included by the same 
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX = 
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor   
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will 
+# evaluate all C-preprocessor directives found in the sources and include 
+# files.
+
+ENABLE_PREPROCESSING   = YES
+
+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro 
+# names in the source code. If set to NO (the default) only conditional 
+# compilation will be performed. Macro expansion can be done in a controlled 
+# way by setting EXPAND_ONLY_PREDEF to YES.
+
+MACRO_EXPANSION        = YES
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES 
+# then the macro expansion is limited to the macros specified with the 
+# PREDEFINED and EXPAND_AS_DEFINED tags.
+
+EXPAND_ONLY_PREDEF     = YES
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files 
+# in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+SEARCH_INCLUDES        = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that 
+# contain include files that are not input files but should be processed by 
+# the preprocessor.
+
+INCLUDE_PATH           =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard 
+# patterns (like *.h and *.hpp) to filter out the header-files in the 
+# directories. If left blank, the patterns specified with FILE_PATTERNS will 
+# be used.
+
+INCLUDE_FILE_PATTERNS  = 
+
+# The PREDEFINED tag can be used to specify one or more macro names that 
+# are defined before the preprocessor is started (similar to the -D option of 
+# gcc). The argument of the tag is a list of macros of the form: name 
+# or name=definition (no spaces). If the definition and the = are 
+# omitted =1 is assumed. To prevent a macro definition from being 
+# undefined via #undef or recursively expanded use the := operator 
+# instead of the = operator.
+
+PREDEFINED             = DOXYGEN_SHOULD_IGNORE_THIS=1 \
+                         SDL_DECLSPEC= \
+                         SDL_DECLSPEC_TEMP= \
+                         SDLCALL= \
+                         _WIN32=1
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then 
+# this tag can be used to specify a list of macro names that should be expanded. 
+# The macro definition that is found in the sources will be used. 
+# Use the PREDEFINED tag if you want to use a different macro definition.
+
+EXPAND_AS_DEFINED      = 
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then 
+# doxygen's preprocessor will remove all function-like macros that are alone 
+# on a line, have an all uppercase name, and do not end with a semicolon. Such 
+# function macros are typically used for boiler-plate code, and will confuse 
+# the parser if not removed.
+
+SKIP_FUNCTION_MACROS   = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references   
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles. 
+# Optionally an initial location of the external documentation 
+# can be added for each tagfile. The format of a tag file without 
+# this location is as follows: 
+#   TAGFILES = file1 file2 ... 
+# Adding location for the tag files is done as follows: 
+#   TAGFILES = file1=loc1 "file2 = loc2" ... 
+# where "loc1" and "loc2" can be relative or absolute paths or 
+# URLs. If a location is present for each tag, the installdox tool 
+# does not have to be run to correct the links. 
+# Note that each tag file must have a unique name 
+# (where the name does NOT include the path) 
+# If a tag file is not located in the directory in which doxygen 
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES               = 
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create 
+# a tag file that is based on the input files it reads.
+
+GENERATE_TAGFILE       = ./SDL.tag
+
+# If the ALLEXTERNALS tag is set to YES all external classes will be listed 
+# in the class index. If set to NO only the inherited external classes 
+# will be listed.
+
+ALLEXTERNALS           = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed 
+# in the modules index. If set to NO, only the current project's groups will 
+# be listed.
+
+EXTERNAL_GROUPS        = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script 
+# interpreter (i.e. the result of `which perl').
+
+PERL_PATH              = c:\Perl\bin\perl.exe
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool   
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will 
+# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base 
+# or super classes. Setting the tag to NO turns the diagrams off. Note that 
+# this option is superseded by the HAVE_DOT option below. This is only a 
+# fallback. It is recommended to install and use dot, since it yields more 
+# powerful graphs.
+
+CLASS_DIAGRAMS         = YES
+
+# You can define message sequence charts within doxygen comments using the \msc 
+# command. Doxygen will then run the mscgen tool (see 
+# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the 
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where 
+# the mscgen tool resides. If left empty the tool is assumed to be found in the 
+# default search path.
+
+MSCGEN_PATH            = 
+
+# If set to YES, the inheritance and collaboration graphs will hide 
+# inheritance and usage relations if the target is undocumented 
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS   = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is 
+# available from the path. This tool is part of Graphviz, a graph visualization 
+# toolkit from AT&T and Lucent Bell Labs. The other options in this section 
+# have no effect if this option is set to NO (the default)
+
+HAVE_DOT               = YES
+
+# By default doxygen will write a font called FreeSans.ttf to the output 
+# directory and reference it in all dot files that doxygen generates. This 
+# font does not include all possible unicode characters however, so when you need 
+# these (or just want a differently looking font) you can specify the font name 
+# using DOT_FONTNAME. You need need to make sure dot is able to find the font, 
+# which can be done by putting it in a standard location or by setting the 
+# DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory 
+# containing the font.
+
+DOT_FONTNAME           = FreeSans
+
+# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs. 
+# The default size is 10pt.
+
+DOT_FONTSIZE           = 10
+
+# By default doxygen will tell dot to use the output directory to look for the 
+# FreeSans.ttf font (which doxygen will put there itself). If you specify a 
+# different font using DOT_FONTNAME you can set the path where dot 
+# can find it using this tag.
+
+DOT_FONTPATH           = 
+
+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen 
+# will generate a graph for each documented class showing the direct and 
+# indirect inheritance relations. Setting this tag to YES will force the 
+# the CLASS_DIAGRAMS tag to NO.
+
+CLASS_GRAPH            = YES
+
+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen 
+# will generate a graph for each documented class showing the direct and 
+# indirect implementation dependencies (inheritance, containment, and 
+# class references variables) of the class with other documented classes.
+
+COLLABORATION_GRAPH    = YES
+
+# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen 
+# will generate a graph for groups, showing the direct groups dependencies
+
+GROUP_GRAPHS           = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and 
+# collaboration diagrams in a style similar to the OMG's Unified Modeling 
+# Language.
+
+UML_LOOK               = NO
+
+# If set to YES, the inheritance and collaboration graphs will show the 
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS     = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT 
+# tags are set to YES then doxygen will generate a graph for each documented 
+# file showing the direct and indirect include dependencies of the file with 
+# other documented files.
+
+INCLUDE_GRAPH          = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and 
+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each 
+# documented header file showing the documented files that directly or 
+# indirectly include this file.
+
+INCLUDED_BY_GRAPH      = YES
+
+# If the CALL_GRAPH and HAVE_DOT options are set to YES then 
+# doxygen will generate a call dependency graph for every global function 
+# or class method. Note that enabling this option will significantly increase 
+# the time of a run. So in most cases it will be better to enable call graphs 
+# for selected functions only using the \callgraph command.
+
+CALL_GRAPH             = NO
+
+# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then 
+# doxygen will generate a caller dependency graph for every global function 
+# or class method. Note that enabling this option will significantly increase 
+# the time of a run. So in most cases it will be better to enable caller 
+# graphs for selected functions only using the \callergraph command.
+
+CALLER_GRAPH           = NO
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen 
+# will graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY    = YES
+
+# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES 
+# then doxygen will show the dependencies a directory has on other directories 
+# in a graphical way. The dependency relations are determined by the #include 
+# relations between the files in the directories.
+
+DIRECTORY_GRAPH        = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images 
+# generated by dot. Possible values are png, jpg, or gif 
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT       = png
+
+# The tag DOT_PATH can be used to specify the path where the dot tool can be 
+# found. If left blank, it is assumed the dot tool can be found in the path.
+
+DOT_PATH               = 
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that 
+# contain dot files that are included in the documentation (see the 
+# \dotfile command).
+
+DOTFILE_DIRS           = 
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of 
+# nodes that will be shown in the graph. If the number of nodes in a graph 
+# becomes larger than this value, doxygen will truncate the graph, which is 
+# visualized by representing a node as a red box. Note that doxygen if the 
+# number of direct children of the root node in a graph is already larger than 
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note 
+# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+
+DOT_GRAPH_MAX_NODES    = 60
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the 
+# graphs generated by dot. A depth value of 3 means that only nodes reachable 
+# from the root by following a path via at most 3 edges will be shown. Nodes 
+# that lay further from the root node will be omitted. Note that setting this 
+# option to 1 or 2 may greatly reduce the computation time needed for large 
+# code bases. Also note that the size of a graph can be further restricted by 
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+
+MAX_DOT_GRAPH_DEPTH    = 2
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent 
+# background. This is disabled by default, because dot on Windows does not 
+# seem to support this out of the box. Warning: Depending on the platform used, 
+# enabling this option may lead to badly anti-aliased labels on the edges of 
+# a graph (i.e. they become hard to read).
+
+DOT_TRANSPARENT        = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output 
+# files in one run (i.e. multiple -o and -T options on the command line). This 
+# makes dot run faster, but since only newer versions of dot (>1.8.10) 
+# support this, this feature is disabled by default.
+
+DOT_MULTI_TARGETS      = YES
+
+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will 
+# generate a legend page explaining the meaning of the various boxes and 
+# arrows in the dot generated graphs.
+
+GENERATE_LEGEND        = YES
+
+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will 
+# remove the intermediate dot files that are used to generate 
+# the various graphs.
+
+DOT_CLEANUP            = YES
+
+#---------------------------------------------------------------------------
+# Options related to the search engine
+#---------------------------------------------------------------------------
+
+# The SEARCHENGINE tag specifies whether or not a search engine should be 
+# used. If set to NO the values of all tags below this one will be ignored.
+
+SEARCHENGINE           = NO
diff --git a/src/contrib/SDL-3.2.20/docs/hello.c b/src/contrib/SDL-3.2.20/docs/hello.c
new file mode 100644
index 0000000..a825ea1
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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)
+{
+}
+
diff --git a/src/contrib/SDL-3.2.20/docs/release_checklist.md b/src/contrib/SDL-3.2.20/docs/release_checklist.md
new file mode 100644
index 0000000..56fb23d
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/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