SDL 2.0.12 -> 2.26.5

3rdp/win32.release/sdl2/BUGS.txt

 
-Bugs are now managed in the SDL bug tracker, here:
+Bugs are now managed in the SDL issue tracker, here:
 
-    https://bugzilla.libsdl.org/
+    https://github.com/libsdl-org/SDL/issues
 
 You may report bugs there, and search to see if a given issue has already
  been reported, discussed, and maybe even fixed.
@@ -11,6 +11,6 @@ You may also find help at the SDL forums/mailing list:
 
     https://discourse.libsdl.org/
 
-Bug reports are welcome here, but we really appreciate if you use Bugzilla, as
- bugs discussed on the mailing list may be forgotten or missed.
+Bug reports are welcome here, but we really appreciate if you use the issue
+ tracker, as bugs discussed on the mailing list may be forgotten or missed.
 

3rdp/win32.release/sdl2/cmake/sdl2-config-version.cmake

+# based on the files generated by CMake's write_basic_package_version_file
+
+# SDL2 CMake version configuration file:
+# This file is meant to be placed in a cmake subfolder of SDL2-devel-2.x.y-VC
+
+if(NOT EXISTS "${CMAKE_CURRENT_LIST_DIR}/../include/SDL_version.h")
+    message(AUTHOR_WARNING "Could not find SDL_version.h. This script is meant to be placed in the root of SDL2-devel-2.x.y-VC")
+    return()
+endif()
+
+file(READ "${CMAKE_CURRENT_LIST_DIR}/../include/SDL_version.h" _sdl_version_h)
+string(REGEX MATCH "#define[ \t]+SDL_MAJOR_VERSION[ \t]+([0-9]+)" _sdl_major_re "${_sdl_version_h}")
+set(_sdl_major "${CMAKE_MATCH_1}")
+string(REGEX MATCH "#define[ \t]+SDL_MINOR_VERSION[ \t]+([0-9]+)" _sdl_minor_re "${_sdl_version_h}")
+set(_sdl_minor "${CMAKE_MATCH_1}")
+string(REGEX MATCH "#define[ \t]+SDL_PATCHLEVEL[ \t]+([0-9]+)" _sdl_patch_re "${_sdl_version_h}")
+set(_sdl_patch "${CMAKE_MATCH_1}")
+if(_sdl_major_re AND _sdl_minor_re AND _sdl_patch_re)
+    set(PACKAGE_VERSION "${_sdl_major}.${_sdl_minor}.${_sdl_patch}")
+else()
+    message(AUTHOR_WARNING "Could not extract version from SDL_version.h.")
+    return()
+endif()
+
+if(PACKAGE_FIND_VERSION_RANGE)
+    # Package version must be in the requested version range
+    if ((PACKAGE_FIND_VERSION_RANGE_MIN STREQUAL "INCLUDE" AND PACKAGE_VERSION VERSION_LESS PACKAGE_FIND_VERSION_MIN)
+        OR ((PACKAGE_FIND_VERSION_RANGE_MAX STREQUAL "INCLUDE" AND PACKAGE_VERSION VERSION_GREATER PACKAGE_FIND_VERSION_MAX)
+        OR (PACKAGE_FIND_VERSION_RANGE_MAX STREQUAL "EXCLUDE" AND PACKAGE_VERSION VERSION_GREATER_EQUAL PACKAGE_FIND_VERSION_MAX)))
+        set(PACKAGE_VERSION_COMPATIBLE FALSE)
+    else()
+        set(PACKAGE_VERSION_COMPATIBLE TRUE)
+    endif()
+else()
+    if(PACKAGE_VERSION VERSION_LESS PACKAGE_FIND_VERSION)
+        set(PACKAGE_VERSION_COMPATIBLE FALSE)
+    else()
+        set(PACKAGE_VERSION_COMPATIBLE TRUE)
+        if(PACKAGE_FIND_VERSION STREQUAL PACKAGE_VERSION)
+            set(PACKAGE_VERSION_EXACT TRUE)
+        endif()
+    endif()
+endif()
+
+# if the using project doesn't have CMAKE_SIZEOF_VOID_P set, fail.
+if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "")
+    set(PACKAGE_VERSION_UNSUITABLE TRUE)
+endif()
+
+# check that the installed version has the same 32/64bit-ness as the one which is currently searching:
+if(NOT (CMAKE_SIZEOF_VOID_P STREQUAL "8" OR CMAKE_SIZEOF_VOID_P STREQUAL "4"))
+    set(PACKAGE_VERSION "${PACKAGE_VERSION} (32+64bit)")
+    set(PACKAGE_VERSION_UNSUITABLE TRUE)
+endif()

3rdp/win32.release/sdl2/cmake/sdl2-config.cmake

+# SDL2 CMake configuration file:
+# This file is meant to be placed in a cmake subfolder of SDL2-devel-2.x.y-VC
+
+cmake_minimum_required(VERSION 3.0)
+
+include(FeatureSummary)
+set_package_properties(SDL2 PROPERTIES
+    URL "https://www.libsdl.org/"
+    DESCRIPTION "low level access to audio, keyboard, mouse, joystick, and graphics hardware"
+)
+
+# Copied from `configure_package_config_file`
+macro(set_and_check _var _file)
+    set(${_var} "${_file}")
+    if(NOT EXISTS "${_file}")
+        message(FATAL_ERROR "File or directory ${_file} referenced by variable ${_var} does not exist !")
+    endif()
+endmacro()
+
+# Copied from `configure_package_config_file`
+macro(check_required_components _NAME)
+    foreach(comp ${${_NAME}_FIND_COMPONENTS})
+        if(NOT ${_NAME}_${comp}_FOUND)
+            if(${_NAME}_FIND_REQUIRED_${comp})
+                set(${_NAME}_FOUND FALSE)
+            endif()
+        endif()
+    endforeach()
+endmacro()
+
+set(SDL2_FOUND TRUE)
+
+if(CMAKE_SIZEOF_VOID_P STREQUAL "4")
+    set(_sdl_arch_subdir "x86")
+elseif(CMAKE_SIZEOF_VOID_P STREQUAL "8")
+    set(_sdl_arch_subdir "x64")
+else()
+    set(SDL2_FOUND FALSE)
+    return()
+endif()
+
+# For compatibility with autotools sdl2-config.cmake, provide SDL2_* variables.
+
+set_and_check(SDL2_PREFIX       "${CMAKE_CURRENT_LIST_DIR}/..")
+set_and_check(SDL2_EXEC_PREFIX  "${CMAKE_CURRENT_LIST_DIR}/..")
+set_and_check(SDL2_INCLUDE_DIR  "${SDL2_PREFIX}/include")
+set(SDL2_INCLUDE_DIRS           "${SDL2_INCLUDE_DIR}")
+set_and_check(SDL2_BINDIR       "${SDL2_PREFIX}/lib/${_sdl_arch_subdir}")
+set_and_check(SDL2_LIBDIR       "${SDL2_PREFIX}/lib/${_sdl_arch_subdir}")
+
+set(SDL2_LIBRARIES      SDL2::SDL2main SDL2::SDL2)
+set(SDL2MAIN_LIBRARY    SDL2::SDL2main)
+set(SDL2TEST_LIBRARY    SDL2::SDL2test)
+
+
+# All targets are created, even when some might not be requested though COMPONENTS.
+# This is done for compatibility with CMake generated SDL2-target.cmake files.
+
+set(_sdl2_library     "${SDL2_LIBDIR}/SDL2.lib")
+set(_sdl2_dll_library "${SDL2_BINDIR}/SDL2.dll")
+if(EXISTS "${_sdl2_library}" AND EXISTS "${_sdl2_dll_library}")
+    if(NOT TARGET SDL2::SDL2)
+        add_library(SDL2::SDL2 SHARED IMPORTED)
+        set_target_properties(SDL2::SDL2
+            PROPERTIES
+                INTERFACE_INCLUDE_DIRECTORIES "${SDL2_INCLUDE_DIRS}"
+                IMPORTED_IMPLIB "${_sdl2_library}"
+                IMPORTED_LOCATION "${_sdl2_dll_library}"
+                COMPATIBLE_INTERFACE_BOOL "SDL2_SHARED"
+                INTERFACE_SDL2_SHARED "ON"
+        )
+    endif()
+    set(SDL2_SDL2_FOUND TRUE)
+else()
+    set(SDL2_SDL2_FOUND FALSE)
+endif()
+unset(_sdl2_library)
+unset(_sdl2_dll_library)
+
+set(_sdl2main_library "${SDL2_LIBDIR}/SDL2main.lib")
+if(EXISTS "${_sdl2main_library}")
+    if(NOT TARGET SDL2::SDL2main)
+        add_library(SDL2::SDL2main STATIC IMPORTED)
+        set_target_properties(SDL2::SDL2main
+        PROPERTIES
+            IMPORTED_LOCATION "${_sdl2main_library}"
+        )
+    endif()
+    set(SDL2_SDL2main_FOUND TRUE)
+else()
+    set(SDL2_SDL2_FOUND FALSE)
+endif()
+unset(_sdl2main_library)
+
+set(_sdl2test_library "${SDL2_LIBDIR}/SDL2test.lib")
+if(EXISTS "${_sdl2test_library}")
+    if(NOT TARGET SDL2::SDL2test)
+        add_library(SDL2::SDL2test STATIC IMPORTED)
+        set_target_properties(SDL2::SDL2test
+            PROPERTIES
+                INTERFACE_INCLUDE_DIRECTORIES "${SDL2_INCLUDE_DIRS}"
+                IMPORTED_LOCATION "${_sdl2test_library}"
+        )
+    endif()
+    set(SDL2_SDL2test_FOUND TRUE)
+else()
+    set(SDL2_SDL2_FOUND FALSE)
+endif()
+unset(_sdl2test_library)
+
+check_required_components(SDL2)

3rdp/win32.release/sdl2/docs/CONTRIBUTING.md

+# 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)
+-   [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, as such 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.
+
+## 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/

3rdp/win32.release/sdl2/docs/README-android.md

@@ -10,11 +10,10 @@ If you are using the older ant build process, it is no longer officially
 supported, but you can use the "android-project-ant" directory as a template.
 
 
-================================================================================
 Requirements
 ================================================================================
 
-Android SDK (version 26 or later)
+Android SDK (version 31 or later)
 https://developer.android.com/sdk/index.html
 
 Android NDK r15c or later
@@ -23,7 +22,6 @@ https://developer.android.com/tools/sdk/ndk/index.html
 Minimum API level supported by SDL: 16 (Android 4.1)
 
 
-================================================================================
 How the port works
 ================================================================================
 
@@ -42,7 +40,6 @@ dispatches to native functions implemented in the SDL library:
 src/core/android/SDL_android.c
 
 
-================================================================================
 Building an app
 ================================================================================
 
@@ -120,7 +117,6 @@ Here's an explanation of the files in the Android project, so you can customize
         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.
 
 
-================================================================================
 Customizing your application name
 ================================================================================
 
@@ -151,7 +147,6 @@ Then replace "SDLActivity" in AndroidManifest.xml with the name of your
 class, .e.g. "MyGame"
 
 
-================================================================================
 Customizing your application icon
 ================================================================================
 
@@ -160,7 +155,6 @@ the drawable directories under the res directory. There are several directories
 for different screen sizes.
 
 
-================================================================================
 Loading assets
 ================================================================================
 
@@ -189,7 +183,6 @@ disable this behaviour, see for example:
 http://ponystyle.com/blog/2010/03/26/dealing-with-asset-compression-in-android-apps/
 
 
-================================================================================
 Pause / Resume behaviour
 ================================================================================
 
@@ -205,12 +198,39 @@ app can continue to operate as it was.
 
 However, there's a chance (on older hardware, or on systems under heavy load),
 where the GL context can not be restored. In that case you have to listen for
-a specific message, (which is not yet implemented!) and restore your textures
-manually or quit the app (which is actually the kind of behaviour you'll see
-under iOS, if the OS can not restore your GL context it will just kill your app)
+a specific message (SDL_RENDER_DEVICE_RESET) and restore your textures
+manually or quit the app.
 
+You should not use the SDL renderer API while the app going in background:
+- SDL_APP_WILLENTERBACKGROUND:
+    after you read this message, GL context gets backed-up and you should not
+    use the SDL renderer API.
 
+    When this event is received, you have to set the render target to NULL, if you're using it.
+    (eg call SDL_SetRenderTarget(renderer, NULL))
+
+- SDL_APP_DIDENTERFOREGROUND:
+   GL context is restored, and the SDL renderer API is available (unless you
+   receive SDL_RENDER_DEVICE_RESET).
+
+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
 ================================================================================
 
@@ -226,7 +246,16 @@ 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
 ================================================================================
 
@@ -239,7 +268,6 @@ For more information go here:
 	https://developer.android.com/ndk/guides/cpp-support
 
 
-================================================================================
 Using the emulator
 ================================================================================
 
@@ -252,7 +280,6 @@ Notice that this software emulator is incredibly slow and needs a lot of disk sp
 Using a real device works better.
 
 
-================================================================================
 Troubleshooting
 ================================================================================
 
@@ -332,7 +359,6 @@ If you need to build without optimization turned on, you can create a file calle
     APP_OPTIM := debug
 
 
-================================================================================
 Memory debugging
 ================================================================================
 
@@ -384,7 +410,6 @@ When you're done instrumenting with valgrind, you can disable the wrapper:
     adb shell setprop wrap.org.libsdl.app ""
 
 
-================================================================================
 Graphics debugging
 ================================================================================
 
@@ -398,7 +423,6 @@ The Tegra Graphics Debugger is available from NVidia here:
 https://developer.nvidia.com/tegra-graphics-debugger
 
 
-================================================================================
 Why is API level 16 the minimum required?
 ================================================================================
 
@@ -408,7 +432,6 @@ about 99% of the Android devices accessing Google Play support API level 16 or
 higher (January 2018).
 
 
-================================================================================
 A note regarding the use of the "dirty rectangles" rendering technique
 ================================================================================
 
@@ -427,7 +450,6 @@ screen each frame.
 Reference: http://www.khronos.org/registry/egl/specs/EGLTechNote0001.html
 
 
-================================================================================
 Ending your application
 ================================================================================
 
@@ -445,7 +467,6 @@ Don't call exit() as it stops the activity badly.
 NB: "Back button" can be handled as a SDL_KEYDOWN/UP events, with Keycode
 SDLK_AC_BACK, for any purpose.
 
-================================================================================
 Known issues
 ================================================================================
 

3rdp/win32.release/sdl2/docs/README-cmake.md

-CMake
-================================================================================
+# CMake
+
 (www.cmake.org)
 
 SDL's build system was traditionally based on autotools. Over time, this
 approach has suffered from several issues across the different supported 
 platforms.
-To solve these problems, a new build system based on CMake is under development.
-It works in parallel to the legacy system, so users can experiment with it
-without complication.
-While still experimental, the build system should be usable on the following
-platforms:
+To solve these problems, a new build system based on CMake was introduced.
+It is developed in parallel to the legacy autotools build system, so users 
+can experiment with it without complication.
+
+The CMake build system is supported on the following platforms:
 
 * FreeBSD
 * Linux
-* VS.NET 2010
+* Microsoft Visual C
 * MinGW and Msys
 * macOS, iOS, and tvOS, with support for XCode
+* Android
+* Emscripten
+* RiscOS
+* Playstation Vita
 
+## Building SDL
 
-================================================================================
-Usage
-================================================================================
-
-Assuming the source for SDL is located at ~/sdl
-
+Assuming the source for SDL is located at `~/sdl`
+```sh
 cd ~
 mkdir build
 cd build
-    cmake ../sdl
+cmake ~/sdl
+cmake --build .
+```
+
+This will build the static and dynamic versions of SDL in the `~/build` directory.
+Installation can be done using:
+
+```sh
+cmake --install .        # '--install' requires CMake 3.15, or newer
+```
+
+## Including SDL in your project
+
+SDL can be included in your project in 2 major ways:
+- using a system SDL library, provided by your (*nix) 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.0)
+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)
+    add_subdirectory(vendored/sdl EXCLUDE_FROM_ALL)
+else()
+    # 1. Look for a SDL2 package, 2. look for the SDL2 component and 3. fail if none can be found
+    find_package(SDL2 REQUIRED CONFIG REQUIRED COMPONENTS SDL2)
     
-This will build the static and dynamic versions of SDL in the ~/build directory.
+    # 1. Look for a SDL2 package, 2. Look for the SDL2maincomponent and 3. DO NOT fail when SDL2main is not available 
+    find_package(SDL2 REQUIRED CONFIG COMPONENTS SDL2main)
+endif()
 
+# Create your game executable target as usual 
+add_executable(mygame WIN32 mygame.c)
 
-================================================================================
-Usage, iOS/tvOS
-================================================================================
+# SDL2::SDL2main may or may not be available. It is e.g. required by Windows GUI applications  
+if(TARGET SDL2::SDL2main)
+    # It has an implicit dependency on SDL2 functions, so it MUST be added before SDL2::SDL2 (or SDL2::SDL2-static)
+    target_link_libraries(mygame PRIVATE SDL2::SDL2main)
+endif()
+
+# Link to the actual SDL2 library. SDL2::SDL2 is the shared SDL library, SDL2::SDL2-static is the static SDL libarary.
+target_link_libraries(mygame PRIVATE SDL2::SDL2)
+```
+
+### 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                                                                                |
+|----------------|--------------------------------------------------------------------------------------------|
+| SDL2           | The SDL2 shared library, available through the `SDL2::SDL2` target [^SDL_TARGET_EXCEPTION] |
+| SDL2-static    | The SDL2 static library, available through the `SDL2::SDL2-static` target                  |
+| SDL2main       | The SDL2main static library, available through the `SDL2::SDL2main` target                 |
+| SDL2test       | The SDL2test static library, available through the `SDL2::SDL2test` target                 |
+
+### Using a vendored SDL
+
+This only requires a copy of SDL in a subdirectory.
+
+## CMake configuration options for platforms
+
+### iOS/tvOS
 
 CMake 3.14+ natively includes support for iOS and tvOS.  SDL binaries may be built
 using Xcode or Make, possibly among other build-systems.
@@ -53,32 +115,49 @@ To use, set the following CMake variables when running CMake's configuration sta
 - `CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures>` (example: "arm64;armv7s;x86_64")
 
 
-### Examples (for iOS/tvOS):
+#### Examples
 
 - for iOS-Simulator, using the latest, installed SDK:
 
-    `cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64`
+    ```bash
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
+    ```
 
 - for iOS-Device, using the latest, installed SDK, 64-bit only
 
-    `cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64`
+    ```bash
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64
+    ```
 
 - for iOS-Device, using the latest, installed SDK, mixed 32/64 bit
 
-    `cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"`
+    ```cmake
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"
+    ```
 
 - for iOS-Device, using a specific SDK revision (iOS 12.4, in this example):
 
-    `cmake ~/sdl -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64`
+    ```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 ~/sdl -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64`
+    ```cmake
+    cmake ~/sdl -DSDL_TESTS=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
+    ```
 
 - for tvOS-Simulator, using the latest, installed SDK:
 
-    `cmake ~/sdl -DCMAKE_SYSTEM_NAME=tvOS -DCMAKE_OSX_SYSROOT=appletvsimulator -DCMAKE_OSX_ARCHITECTURES=x86_64`
+    ```cmake
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=tvOS -DCMAKE_OSX_SYSROOT=appletvsimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
+    ```
 
 - for tvOS-Device, using the latest, installed SDK:
 
-    `cmake ~/sdl -DCMAKE_SYSTEM_NAME=tvOS -DCMAKE_OSX_SYSROOT=appletvos -DCMAKE_OSX_ARCHITECTURES=arm64`
+    ```cmake
+    cmake ~/sdl -DCMAKE_SYSTEM_NAME=tvOS -DCMAKE_OSX_SYSROOT=appletvos -DCMAKE_OSX_ARCHITECTURES=arm64`
+    ```
+
+
+[^SDL_TARGET_EXCEPTION]: `SDL2::SDL2` can be an ALIAS to a static `SDL2::SDL2-static` target for multiple reasons.

3rdp/win32.release/sdl2/docs/README-directfb.md

@@ -15,29 +15,34 @@ What you need:
 * Kernel-Framebuffer support: required: vesafb, radeonfb .... 
 * Mesa 7.0.x	   - optional for OpenGL
 
-/etc/directfbrc
-
-This file should contain the following lines to make
+The `/etc/directfbrc` file should contain the following lines to make
 your joystick work and avoid crashes:
-------------------------
+
+```
 disable-module=joystick
 disable-module=cle266
 disable-module=cyber5k
 no-linux-input-grab
-------------------------
+```
 
 To disable to use x11 backend when DISPLAY variable is found use
 
+```
 export SDL_DIRECTFB_X11_CHECK=0
+```
 
 To disable the use of linux input devices, i.e. multimice/multikeyboard support,
 use
 
+```
 export SDL_DIRECTFB_LINUX_INPUT=0
+```
 
 To use hardware accelerated YUV-overlays for YUV-textures, use:
 
+```
 export SDL_DIRECTFB_YUV_DIRECT=1
+```
 
 This is disabled by default. It will only support one 
 YUV texture, namely the first. Every other YUV texture will be
@@ -45,7 +50,9 @@ rendered in software.
 
 In addition, you may use (directfb-1.2.x)
 
+```
 export SDL_DIRECTFB_YUV_UNDERLAY=1
+```
 
 to make the YUV texture an underlay. This will make the cursor to
 be shown.
@@ -54,14 +61,18 @@ Simple Window Manager
 =====================
 
 The driver has support for a very, very basic window manager you may
-want to use when running with "wm=default". Use
+want to use when running with `wm=default`. Use
 
+```
 export SDL_DIRECTFB_WM=1
+```
 
 to enable basic window borders. In order to have the window title rendered,
 you need to have the following font installed:
 
+```
 /usr/share/fonts/truetype/freefont/FreeSans.ttf
+```
 
 OpenGL Support
 ==============
@@ -71,21 +82,25 @@ works at least on all directfb supported platforms.
 
 As of this writing 20100802 you need to pull Mesa from git and do the following:
 
-------------------------
+```
 git clone git://anongit.freedesktop.org/git/mesa/mesa
 cd mesa 
 git checkout 2c9fdaf7292423c157fc79b5ce43f0f199dd753a
-------------------------
+```
+
+Edit `configs/linux-directfb` so that the Directories-section looks like this:
 
-Edit configs/linux-directfb so that the Directories-section looks like
-------------------------
+```
 # Directories
 SRC_DIRS     = mesa glu 
 GLU_DIRS     = sgi
 DRIVER_DIRS  = directfb
 PROGRAM_DIRS = 
-------------------------
+```
 
+Then do the following:
+
+```
 make linux-directfb
 make
 
@@ -95,13 +110,14 @@ sudo make install INSTALL_DIR=/usr/local/dfb_GL
 cd src/mesa/drivers/directfb
 make
 sudo make install INSTALL_DIR=/usr/local/dfb_GL
-------------------------
+```
 
 To run the SDL - testprograms:
 
+```
 export SDL_VIDEODRIVER=directfb
 export LD_LIBRARY_PATH=/usr/local/dfb_GL/lib
 export LD_PRELOAD=/usr/local/dfb_GL/libGL.so.7
 
 ./testgl
-
+```

3rdp/win32.release/sdl2/docs/README-dynapi.md

-Dynamic API
-================================================================================
-Originally posted by Ryan at:
-  https://plus.google.com/103391075724026391227/posts/TB8UfnDYu4U
+# Dynamic API
+
+Originally posted on Ryan's Google+ account.
 
 Background:
 
@@ -35,10 +34,12 @@ 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
 UInt32 SDL_Init(Uint32 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.
@@ -47,22 +48,26 @@ 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
 Uint32 SDL_Init_DEFAULT(Uint32 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. 
+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 SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0
 ./MyGameThatIsStaticallyLinkedToSDL2
+```
 
 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 
@@ -94,7 +99,9 @@ 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. 
@@ -116,6 +123,7 @@ 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 

3rdp/win32.release/sdl2/docs/README-emscripten.md

-Emscripten
-================================================================================
+# Emscripten
+
+(This documentation is not very robust; we will update and expand this later.)
+
+## A quick note about audio
+
+Modern web browsers will not permit web pages to produce sound before the
+user has interacted with them; 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.
+
+To solve this, most browsers will refuse to let a web app use the audio
+subsystem at all before the user has interacted with (clicked on) the page
+in a meaningful way. SDL-based apps also have to deal with this problem; if
+the user hasn't interacted with the page, SDL_OpenAudioDevice will fail.
+
+There are two reasonable ways to deal with this: 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, the user can
+reasonably opt-in to listening, and you never get access denied to the audio
+device.
+
+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.
+
+
+## Building SDL/emscripten
+
+SDL currently requires at least Emscripten 2.0.32 to build. Newer versions
+are likely to work, as well.
+
 
 Build:
 

3rdp/win32.release/sdl2/docs/README-gdk.md

+GDK
+=====
+
+This port allows SDL applications to run via Microsoft's Game Development Kit (GDK).
+
+Windows (GDK) and  Xbox One/Xbox Series (GDKX) are supported. Although most of the Xbox code is included in the public SDL source code, NDA access is required for a small number of source files. If you have access to GDKX, these required Xbox files are posted on the GDK forums [here](https://forums.xboxlive.com/questions/130003/).
+
+
+Requirements
+------------
+
+* Microsoft Visual Studio 2022 (in theory, it should also work in 2017 or 2019, but this has not been tested)
+* Microsoft GDK June 2022 or newer (public release [here](https://github.com/microsoft/GDK/releases/tag/June_2022))
+* 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 identifiers used by the GDK test programs in the included solution will 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 `__GDK__` is `#define`d on every GDK platform, and the  `__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 (you should link against SDL2main.lib, as in Windows x64). If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
+  * 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_GDKGetTaskQueue`, if needed. When done with the queue, be sure to use `XTaskQueueCloseHandle` to decrement the reference count (otherwise it will cause a resource leak).
+  
+* 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:
+
+* SDL2 (DLL) - This is the typical SDL2.dll, but for Gaming.Desktop.x64.
+* SDL2main (lib) - This contains a drop-in implementation of `WinMain` that is used as the entry point for GDK programs.
+* 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/testsprite2 - 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 SDL2 and SDL2main for GDK ###
+
+Open `VisualC-GDK/SDL.sln` in Visual Studio, you need to build the SDL2 and SDL2main targets for the Gaming.Desktop.x64 platform (Release is recommended). You will need to copy/keep track of the `SDL2.dll`, `XCurl.dll` (which is output by Gaming.Desktop.x64), `SDL2.lib`, and `SDL2main.lib` output files for your game project.
+
+*Alternatively*, you could setup your solution file to instead reference the SDL2/SDL2main project file targets from the SDL source, and add those projects as a dependency. This would mean that SDL2 and SDL2main would both 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 SDL2.lib and SDL2main.lib are
+* Under Linker > Input > Additional Dependencies, you need the following:
+  * `SDL2.lib`
+  * `SDL2main.lib` (unless not using)
+  * `xgameruntime.lib`
+  * `../Microsoft.Xbox.Services.141.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 "SDL_main.h"` and declare a standard main function. If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
+
+### 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 SDL2.dll
+* "$(Console_GRDKExtLibRoot)Xbox.Services.API.C\DesignTime\CommonConfiguration\Neutral\Lib\Release\Microsoft.Xbox.Services.141.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.
+
+
+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).

3rdp/win32.release/sdl2/docs/README-git.md

+git
+=========
+
+The latest development version of SDL is available via git.
+Git allows you to get up-to-the-minute fixes and enhancements;
+as a developer works on a source tree, you can use "git" to mirror that
+source tree instead of waiting for an official release. Please look
+at the Git website ( https://git-scm.com/ ) for more
+information on using git, where you can also download software for
+macOS, Windows, and Unix systems.
+
+    git clone https://github.com/libsdl-org/SDL
+
+If you are building SDL via configure, you will need to run autogen.sh
+before running configure.
+
+There is a web interface to the Git repository at:
+	http://github.com/libsdl-org/SDL/
+

3rdp/win32.release/sdl2/docs/README-hg.md

-Mercurial
-=========
+We are no longer hosted in Mercurial. Please see README-git.md for details.
 
-The latest development version of SDL is available via Mercurial.
-Mercurial allows you to get up-to-the-minute fixes and enhancements;
-as a developer works on a source tree, you can use "hg" to mirror that
-source tree instead of waiting for an official release. Please look
-at the Mercurial website ( https://www.mercurial-scm.org/ ) for more
-information on using hg, where you can also download software for
-Mac OS X, Windows, and Unix systems.
-
-    hg clone http://hg.libsdl.org/SDL
-
-If you are building SDL via configure, you will need to run autogen.sh
-before running configure.
-
-There is a web interface to the subversion repository at:
-	http://hg.libsdl.org/SDL/
-
-There is an RSS feed available at that URL, for those that want to
-track commits in real time.
+Thanks!
 

3rdp/win32.release/sdl2/docs/README-ios.md

 iOS
 ======
 
-==============================================================================
-Building the Simple DirectMedia Layer for iOS 5.1+
+Building the Simple DirectMedia Layer for iOS 9.0+
 ==============================================================================
 
-Requirements: Mac OS X 10.8 or later and the iOS 7+ SDK.
+Requirements: Mac OS X 10.9 or later and the iOS 9.0 or newer SDK.
 
 Instructions:
 
-1.  Open SDL.xcodeproj (located in Xcode-iOS/SDL) in Xcode.
+1. Open SDL.xcodeproj (located in Xcode/SDL) in Xcode.
 2. Select your desired target, and hit build.
 
-There are three build targets:
-- libSDL.a:
-	Build SDL as a statically linked library
-- testsdl:
-	Build a test program (there are known test failures which are fine)
-- Template:
-	Package a project template together with the SDL for iPhone static libraries and copies of the SDL headers.  The template includes proper references to the SDL library and headers, skeleton code for a basic SDL program, and placeholder graphics for the application icon and startup screen.
-
-
-==============================================================================
-Build SDL for iOS from the command line
-==============================================================================
-
-1. cd (PATH WHERE THE SDL CODE IS)/build-scripts
-2. ./iosbuild.sh
 
-If everything goes fine, you should see a build/ios directory, inside there's
-two directories "lib" and "include". 
-"include" contains a copy of the SDL headers that you'll need for your project,
-make sure to configure XCode to look for headers there.
-"lib" contains find two files, libSDL2.a and libSDL2main.a, you have to add both 
-to your XCode project. These libraries contain three architectures in them,
-armv6 for legacy devices, armv7, and i386 (for the simulator).
-By default, iosbuild.sh will autodetect the SDK version you have installed using 
-xcodebuild -showsdks, and build for iOS >= 3.0, you can override this behaviour 
-by setting the MIN_OS_VERSION variable, ie:
-
-MIN_OS_VERSION=4.2 ./iosbuild.sh
-
-==============================================================================
 Using the Simple DirectMedia Layer for iOS
 ==============================================================================
 
-FIXME: This needs to be updated for the latest methods
+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 SDL2.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. In the main view, expand SDL -> Library Source -> main -> uikit and drag SDL_uikit_main.c into your game files
+9. Add the source files that you would normally have for an SDL program, making sure to have #include "SDL.h" at the top of the file containing your main() function.
+10. Add any assets that your application needs.
+11. Enjoy!
 
-Here is the easiest method:
-1.  Build the SDL library (libSDL2.a) and the iPhone SDL Application template.
-2.  Install the iPhone SDL Application template by copying it to one of Xcode's template directories.  I recommend creating a directory called "SDL" in "/Developer/Platforms/iOS.platform/Developer/Library/Xcode/Project Templates/" and placing it there.
-3.  Start a new project using the template.  The project should be immediately ready for use with SDL.
 
-Here is a more manual method:
-1.  Create a new iOS view based application.
-2.  Build the SDL static library (libSDL2.a) for iOS and include them in your project.  Xcode will ignore the library that is not currently of the correct architecture, hence your app will work both on iOS and in the iOS Simulator.
-3.  Include the SDL header files in your project.
-4.  Remove the ApplicationDelegate.h and ApplicationDelegate.m files -- SDL for iOS provides its own UIApplicationDelegate.  Remove MainWindow.xib -- SDL for iOS produces its user interface programmatically.
-5.  Delete the contents of main.m and program your app as a regular SDL program instead.  You may replace main.m with your own main.c, but you must tell Xcode not to use the project prefix file, as it includes Objective-C code.
+TODO: Add information regarding App Store requirements such as icons, etc.
+
 
-==============================================================================
 Notes -- Retina / High-DPI and window sizes
 ==============================================================================
 
@@ -88,7 +59,7 @@ orthographic projection matrix using the size in screen coordinates
 (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
 ==============================================================================
 
@@ -151,7 +122,6 @@ e.g.
     }
 
     
-==============================================================================
 Notes -- Accelerometer as Joystick
 ==============================================================================
 
@@ -159,7 +129,7 @@ SDL for iPhone supports polling the built in accelerometer as a joystick device.
 
 The main thing to note when using the accelerometer with SDL is that while the iPhone natively reports accelerometer as floating point values in units of g-force, SDL_JoystickGetAxis() reports joystick values as signed integers.  Hence, in order to convert between the two, some clamping and scaling is necessary on the part of the iPhone SDL joystick driver.  To convert SDL_JoystickGetAxis() reported values BACK to units of g-force, simply multiply the values by SDL_IPHONE_MAX_GFORCE / 0x7FFF.
 
-==============================================================================
+
 Notes -- OpenGL ES
 ==============================================================================
 
@@ -179,7 +149,7 @@ OpenGL ES on iOS doesn't use the traditional system-framebuffer setup provided i
 
 The above objects can be obtained via SDL_GetWindowWMInfo() (in SDL_syswm.h).
 
-==============================================================================
+
 Notes -- Keyboard
 ==============================================================================
 
@@ -195,7 +165,12 @@ SDL_bool SDL_IsTextInputActive()
 	-- 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
+
+
 Notes -- Reading and Writing files
 ==============================================================================
 
@@ -215,7 +190,39 @@ When your SDL based iPhone application starts up, it sets the working directory
 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 SDL2.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 SDL2.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. This means that iOS apps which used the statically-linked libSDL2.lib and now link with the xcframwork will need to define their own main() to call SDL_UIKitRunApp(), like this:
+
+#ifndef SDL_MAIN_HANDLED
+#ifdef main
+#undef main
+#endif
+
+int
+main(int argc, char *argv[])
+{
+	return SDL_UIKitRunApp(argc, argv, SDL_main);
+}
+#endif /* !SDL_MAIN_HANDLED */
+
+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
 ==============================================================================
 
@@ -228,7 +235,23 @@ Textures:
 Loading Shared Objects:
 	This is disabled by default since it seems to break the terms of the iOS SDK agreement for iOS versions prior to iOS 8. It can be re-enabled in SDL_config_iphoneos.h.
 
+
+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 
 ==============================================================================
 
@@ -266,11 +289,11 @@ e.g.
         return 0;
     }
 
-==============================================================================
+
 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 6.1
+SDL supports deploying to older versions of iOS than are supported by the latest version of Xcode, all the way back to iOS 8.0
 
 In order to do that you need to download an older version of Xcode:
 https://developer.apple.com/download/more/?name=Xcode

3rdp/win32.release/sdl2/docs/README-kmsbsd.md

+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.
+
+
+SDL2 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.

3rdp/win32.release/sdl2/docs/README-linux.md

@@ -3,31 +3,41 @@ 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 Xinerama support and the target
-system does not have the Xinerama libraries installed, it will be disabled
+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:
 
-Ubuntu 13.04, all available features enabled:
+    sudo apt-get install build-essential git make autoconf automake libtool \
+    pkg-config cmake ninja-build gnome-desktop-testing libasound2-dev libpulse-dev \
+    libaudio-dev libjack-dev libsndio-dev libsamplerate0-dev libx11-dev libxext-dev \
+    libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev libxss-dev libwayland-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 fcitx-libs-dev
 
-sudo apt-get install build-essential mercurial make cmake autoconf automake \
-libtool libasound2-dev libpulse-dev libaudio-dev libx11-dev libxext-dev \
-libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxxf86vm-dev \
-libxss-dev libgl1-mesa-dev libesd0-dev libdbus-1-dev libudev-dev \
-libgles1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev libibus-1.0-dev \
-fcitx-libs-dev libsamplerate0-dev libsndio-dev
+Ubuntu 22.04+ can also add `libpipewire-0.3-dev libdecor-0-dev` to that command line.
 
-Ubuntu 16.04+ can also add "libwayland-dev libxkbcommon-dev wayland-protocols"
-to that command line for Wayland support.
+Fedora 35, all available features enabled:
+
+    sudo yum install gcc git-core make cmake autoconf automake libtool \
+    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 fcitx-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 \
+    libsamplerate-devel pipewire-jack-audio-connection-kit-devel \
 
 NOTES:
-- This includes all the audio targets except arts, because Ubuntu pulled the 
-  artsc0-dev package, but in theory SDL still supports it.
+- This includes all the audio targets except arts and esd, because Ubuntu
+  (and/or Debian) pulled their packages, but in theory SDL still supports them.
+  The sndio audio target is also unavailable on Fedora.
 - libsamplerate0-dev lets SDL optionally link to libresamplerate at runtime
   for higher-quality audio resampling. SDL will work without it if the library
   is missing, so it's safe to build in support even if the end user doesn't
@@ -37,9 +47,8 @@ NOTES:
   configure script to include DirectFB support. Send patches.  :)
 
 
-================================================================================
 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

3rdp/win32.release/sdl2/docs/README-macosx.md → 3rdp/win32.release/sdl2/docs/README-macos.md

-Mac OS X
-==============================================================================
+# Mac OS X (aka macOS).
 
 These instructions are for people using Apple's Mac OS X (pronounced
-"ten").
+"ten"), which in newer versions is just referred to as "macOS".
 
-From the developer's point of view, OS X is a sort of hybrid Mac and
+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
-==================
+# Command Line Build
 
 To build SDL using the command line, use the standard configure and make
 process:
 
-    ./configure
+```bash
+mkdir build
+cd build
+../configure
 make
 sudo make install
+```
+
+CMake is also known to work, although it continues to be a work in progress:
+
+```bash
+mkdir build
+cd build
+cmake -DCMAKE_BUILD_TYPE=Release ..
+make
+sudo make install
+```
+
 
 You can also build SDL as a Universal library (a single binary for both
-32-bit and 64-bit Intel architectures), on Mac OS X 10.7 and newer, by using
-the gcc-fat.sh script in build-scripts:
+64-bit Intel and ARM architectures), by using the build-scripts/clang-fat.sh
+script.
 
-    mkdir mybuild
-    cd mybuild
-    CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++-fat.sh ../configure
+```bash
+mkdir build
+cd build
+CC=$PWD/../build-scripts/clang-fat.sh ../configure
 make
 sudo make install
+```
 
-This script builds SDL with 10.5 ABI compatibility on i386 and 10.6
-ABI compatibility on x86_64 architectures.  For best compatibility you
+This script builds SDL with 10.9 ABI compatibility on 64-bit Intel and 11.0
+ABI compatibility on ARM64 architectures.  For best compatibility you
 should compile your application the same way.
 
-Please note that building SDL requires at least Xcode 4.6 and the 10.7 SDK
-(even if you target back to 10.5 systems). PowerPC support for Mac OS X has
-been officially dropped as of SDL 2.0.2.
+Please note that building SDL requires at least Xcode 6 and the 10.9 SDK.
+PowerPC support for macOS has been officially dropped as of SDL 2.0.2.
+32-bit Intel and macOS 10.8 runtime support has been officially dropped as
+of SDL 2.24.0.
 
 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 Mac OS X
-==============================================================================
 
-Some things you have to be aware of when using SDL on Mac OS X:
+# Caveats for using SDL with Mac OS X
 
-- If you register your own NSApplicationDelegate (using [NSApp setDelegate:]),
+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_DROPFILE when you request to open a
@@ -53,6 +66,7 @@ Some things you have to be aware of when using SDL on Mac OS X:
 NSApplicationDelegate implementation:
 
 
+```objc
 - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
 {
     if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
@@ -75,32 +89,33 @@ Some things you have to be aware of when using SDL on Mac OS X:
     
     return NO;
 }
+```
 
-==============================================================================
-Using the Simple DirectMedia Layer with a traditional Makefile
-==============================================================================
+# Using the Simple DirectMedia Layer with a traditional Makefile
 
 An existing autoconf/automake build system for your SDL app has good chances
-to work almost unchanged on OS X. However, to produce a "real" Mac OS X binary
+to work almost unchanged on macOS. 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 basically is a fancy folder with a name like
+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.
+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.
@@ -108,10 +123,12 @@ 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/".
@@ -119,27 +136,30 @@ 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 bare bone .app bundle, which is double clickable from the Finder. But
+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) The bundle right now probably is dynamically linked against SDL. That 
+1. The bundle right now probably is dynamically linked against SDL. That
    means that when you copy it to another computer, *it will not run*,
    unless you also install SDL on that other computer. A good solution
    for this dilemma is to static link against SDL. On OS X, you can
    achieve that by linking against the libraries listed by
 
+   ```bash
    sdl-config --static-libs
+   ```
 
    instead of those listed by
 
+   ```bash
    sdl-config --libs
+   ```
 
    Depending on how exactly SDL is integrated into your build systems, the
    way to achieve that varies, so I won't describe it here in detail
 
-2) Add an 'Info.plist' to your application. That is a special XML file which
+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
@@ -148,30 +168,31 @@ there are some more things you should do before shipping your product...
 
 
 As a final remark, let me add that I use some of the techniques (and some
-variations of them) in Exult and ScummVM; both are available in source on
+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
-==============================================================================
+# Using the Simple DirectMedia Layer with Xcode
 
 These instructions are for using Apple's Xcode IDE to build SDL applications.
 
-- First steps
+## 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
+## Building the Framework
 
 The SDL Library is packaged as a framework bundle, an organized
 relocatable folder hierarchy of executable code, interface headers,
@@ -185,50 +206,71 @@ By default, the framework bundle "SDL.framework" is installed in
 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
+* ~/Library/Frameworks
+* /Local/Library/Frameworks
+* /System/Library/Frameworks
+
+## Build Options
 
-- 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
+## Building the Testers
+
 Open the SDLTest project and build away!
 
-- Using the Project Stationary
+## 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
+## Setting up a new project by hand
+
 Some of you won't want to use the Stationary so I'll give some tips:
-    * Create a new "Cocoa Application"
-    * Add src/main/macosx/SDLMain.m , .h and .nib to your project
-    * Remove "main.c" from your project
-    * Remove "MainMenu.nib" from your project
-    * Add "$(HOME)/Library/Frameworks/SDL.framework/Headers" to include path
-    * Add "$(HOME)/Library/Frameworks" to the frameworks search path
+
+(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"
-    * Set the "Main Nib File" under "Application Settings" to "SDLMain.nib"
 * Add your files
 * Clean and build
 
-- Building from command line
-    Use pbxbuild in the same directory as your .pbproj file
+## Building from command line
+
+Use `xcode-build` in the same directory as your .pbxproj file
+
+## Running your app
 
-- 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.
+Executables" panel of the target settings.
+    
+# Implementation Notes
 
-- Implementation Notes
 Some things that may be of interest about how it all works...
-    * Working directory
-        As defined in the SDL_main.m file, the working directory of your SDL app
-        is by default set to its parent. You may wish to change this to better
-        suit your needs.
-    * You have a Cocoa App!
+
+## 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. SDL2 does 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 finger, 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.
@@ -236,5 +278,8 @@ following locations:
 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!
 
-Known bugs are listed in the file "BUGS.txt".

3rdp/win32.release/sdl2/docs/README-n3ds.md

+# 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.
+-   SDL2main should be used to ensure ROMFS is enabled.
+-   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.

3rdp/win32.release/sdl2/docs/README-ngage.md

+Nokia N-Gage
+============
+
+SDL2 port for Symbian S60v1 and v2 with a main focus on the Nokia N-Gage
+(Classic and QD) by [Michael Fitzmayer](https://github.com/mupfdev).
+
+Compiling
+---------
+
+SDL is part of the [N-Gage SDK.](https://github.com/ngagesdk) project.
+The library is included in the
+[toolchain](https://github.com/ngagesdk/ngage-toolchain) as a
+sub-module.
+
+A complete example project based on SDL2 can be found in the GitHub
+account of the SDK: [Wordle](https://github.com/ngagesdk/wordle).
+
+Current level of implementation
+-------------------------------
+
+The video driver currently provides full screen video support with
+keyboard input.
+
+At the moment only the software renderer works.
+
+Audio is not yet implemented.
+
+Acknowledgements
+----------------
+
+Thanks to Hannu Viitala, Kimmo Kinnunen and Markus Mertama for the
+valuable insight into Symbian programming.  Without the SDL 1.2 port
+which was specially developed for CDoom (Doom for the Nokia 9210), this
+adaptation would not have been possible.
+
+I would like to thank my friends
+[Razvan](https://twitter.com/bewarerazvan) and [Dan
+Whelan](https://danwhelan.ie/), for their continuous support.  Without
+you and the [N-Gage community](https://discord.gg/dbUzqJ26vs), I would
+have lost my patience long ago.
+
+Last but not least, I would like to thank the development team of
+[EKA2L1](https://12z1.com/) (an experimental Symbian OS emulator). Your
+patience and support in troubleshooting helped me a lot.

3rdp/win32.release/sdl2/docs/README-os2.md

+Simple DirectMedia Layer 2 for OS/2 & eComStation
+================================================================================
+SDL port for OS/2, authored by Andrey Vasilkin <digi@os2.snc.ru>, 2016
+
+
+OpenGL and audio capture not supported by this port.
+
+Additional optional environment variables:
+
+SDL_AUDIO_SHARE
+  Values: 0 or 1, default is 0
+  Initializes the device as shareable or exclusively acquired.
+
+SDL_VIDEODRIVER
+  Values: DIVE or VMAN, default is DIVE
+  Use video subsystem: Direct interface video extensions (DIVE) or
+  Video Manager (VMAN).
+
+You may significantly increase video output speed with OS4 kernel and patched
+files vman.dll and dive.dll or with latest versions of ACPI support and video
+driver Panorama.
+
+Latest versions of OS/4 kernel:
+  http://gus.biysk.ru/os4/
+ (Info: https://www.os2world.com/wiki/index.php/Phoenix_OS/4)
+
+Patched files vman.dll and dive.dll:
+  http://gus.biysk.ru/os4/test/pached_dll/PATCHED_DLL.RAR
+
+
+Compiling:
+----------
+
+Open Watcom 1.9 or newer is tested. For the new Open Watcom V2 fork, see:
+https://github.com/open-watcom/ and https://open-watcom.github.io
+WATCOM environment variable must to be set to the Open Watcom install
+directory. To compile, run: wmake -f Makefile.os2
+
+
+Installing:
+-----------
+
+- eComStation:
+
+  If you have previously installed SDL2, make a Backup copy of SDL2.dll
+  located in D:\ecs\dll (where D: is disk on which installed eComStation).
+  Stop all programs running with SDL2. Copy SDL2.dll to D:\ecs\dll
+
+- OS/2:
+
+  Copy SDL2.dll to any directory on your LIBPATH.  If you have a previous
+  version installed, close all SDL2 applications before replacing the old
+  copy.  Also make sure that any other older versions of DLLs are removed
+  from your system.
+
+
+Joysticks in SDL2:
+------------------
+
+The joystick code in SDL2 is a direct forward-port from the SDL-1.2 version.
+Here is the original documentation from SDL-1.2:
+
+The Joystick detection only works for standard joysticks (2 buttons, 2 axes
+and the like). Therefore, if you use a non-standard joystick, you should
+specify its features in the SDL_OS2_JOYSTICK environment variable in a batch
+file or CONFIG.SYS, so SDL applications can provide full capability to your
+device. The syntax is:
+
+SET SDL_OS2_JOYSTICK=[JOYSTICK_NAME] [AXES] [BUTTONS] [HATS] [BALLS]
+
+So, it you have a Gravis GamePad with 4 axes, 2 buttons, 2 hats and 0 balls,
+the line should be:
+
+SET SDL_OS2_JOYSTICK=Gravis_GamePad 4 2 2 0
+
+If you want to add spaces in your joystick name, just surround it with
+quotes or double-quotes:
+
+SET SDL_OS2_JOYSTICK='Gravis GamePad' 4 2 2 0
+
+or
+
+SET SDL_OS2_JOYSTICK="Gravis GamePad" 4 2 2 0
+
+   Note however that Balls and Hats are not supported under OS/2, and the
+value will be ignored... but it is wise to define these correctly because
+in the future those can be supported.
+
+   Also the number of buttons is limited to 2 when using two joysticks,
+4 when using one joystick with 4 axes, 6 when using a joystick with 3 axes
+and 8 when using a joystick with 2 axes. Notice however these are limitations
+of the Joystick Port hardware, not OS/2.