libs/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.
-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:
+1. Open SDL.xcodeproj (located in Xcode/SDL) in Xcode.
+2. Select your desired target, and hit build.
 
-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
 ==============================================================================
 
@@ -140,18 +111,17 @@ e.g.
             return 1;
         }
     }
-    
+
     int main(int argc, char *argv[])
     {
         SDL_SetEventFilter(HandleAppEvents, NULL);
-    
+
         ... run your main loop
-    
+
         return 0;
     }
 
-    
-==============================================================================
+
 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
 ==============================================================================
 
@@ -210,12 +185,44 @@ Once your application is installed its directory tree looks like:
             Preferences/
         tmp/
 
-When your SDL based iPhone application starts up, it sets the working directory to the main bundle (MySDLApp Home/MySDLApp.app), where your application resources are stored.  You cannot write to this directory.  Instead, I advise you to write document files to "../Documents/" and preferences to "../Library/Preferences".  
+When your SDL based iPhone application starts up, it sets the working directory to the main bundle (MySDLApp Home/MySDLApp.app), where your application resources are stored.  You cannot write to this directory.  Instead, I advise you to write document files to "../Documents/" and preferences to "../Library/Preferences".
 
 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,8 +235,24 @@ 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
 ==============================================================================
-Game Center 
+
+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:
@@ -245,15 +268,15 @@ e.g.
     {
         ... do event handling, frame logic and rendering ...
     }
-    
+
     int main(int argc, char *argv[])
     {
         ... initialize game ...
-    
+
     #if __IPHONEOS__
         // 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_iPhoneSetAnimationCallback(window, 1, ShowFrame, NULL);
@@ -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

libs/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.

libs/SDL2/docs/README-linux.md

@@ -3,85 +3,94 @@ 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
-at runtime, and you won't get a missing library error, at least with the 
+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 13.04, all available features enabled:
+--------------------------------------------------------------------------------
+
+Ubuntu 18.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
+
+Ubuntu 22.04+ can also add `libpipewire-0.3-dev libdecor-0-dev` to that command line.
 
-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
+Fedora 35, all available features enabled:
 
-Ubuntu 16.04+ can also add "libwayland-dev libxkbcommon-dev wayland-protocols"
-to that command line for Wayland support.
+    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
   have this library installed.
 - DirectFB isn't included because the configure script (currently) fails to find
-  it at all. You can do "sudo apt-get install libdirectfb-dev" and fix the 
+  it at all. You can do "sudo apt-get install libdirectfb-dev" and fix the
   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
 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)    
-    
+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 
+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"
-   
+
+    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.    
+
+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"
 

libs/SDL2/docs/README-macosx.md → libs/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
-    make
-    sudo make install
+```bash
+mkdir build
+cd build
+../configure
+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:
+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
+```
 
-    mkdir mybuild
-    cd mybuild
-    CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++-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
+You can also build SDL as a Universal library (a single binary for both
+64-bit Intel and ARM architectures), by using the build-scripts/clang-fat.sh
+script.
+
+```bash
+mkdir build
+cd build
+CC=$PWD/../build-scripts/clang-fat.sh ../configure
+make
+sudo make install
+```
+
+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:
-
-- 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
-  file with the app. To solve these issues, put the following code in your 
-  NSApplicationDelegate implementation:
-
-
-    - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
-    {
-        if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
-            SDL_Event event;
-            event.type = SDL_QUIT;
-            SDL_PushEvent(&event);
-        }
-    
-        return NSTerminateCancel;
+
+# Caveats for using SDL with Mac OS X
+
+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
+file with the app. To solve these issues, put the following code in your
+NSApplicationDelegate implementation:
+
+
+```objc
+- (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
+{
+    if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
+        SDL_Event event;
+        event.type = SDL_QUIT;
+        SDL_PushEvent(&event);
     }
-    
-    - (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
-    {
-        if (SDL_GetEventState(SDL_DROPFILE) == SDL_ENABLE) {
-            SDL_Event event;
-            event.type = SDL_DROPFILE;
-            event.drop.file = SDL_strdup([filename UTF8String]);
-            return (SDL_PushEvent(&event) > 0);
-        }
-    
-        return NO;
+
+    return NSTerminateCancel;
+}
+
+- (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
+{
+    if (SDL_GetEventState(SDL_DROPFILE) == SDL_ENABLE) {
+        SDL_Event event;
+        event.type = SDL_DROPFILE;
+        event.drop.file = SDL_strdup([filename UTF8String]);
+        return (SDL_PushEvent(&event) > 0);
     }
 
-==============================================================================
-Using the Simple DirectMedia Layer with a traditional Makefile
-==============================================================================
+    return NO;
+}
+```
+
+# 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:
 
-    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.
+```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.
@@ -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:
 
-    install-exec-hook: APP_NAME_bundle
-    	rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
-    	mkdir -p $(DESTDIR)$(prefix)/Applications/
-    	cp -r $< /$(DESTDIR)$(prefix)Applications/
+```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
 
-       sdl-config --static-libs
+   ```bash
+   sdl-config --static-libs
+   ```
 
    instead of those listed by
 
-       sdl-config --libs
+   ```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,93 +168,118 @@ 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:
 
-    cd [path_to_SDL_source]
-    tar zxf Xcode.tar.gz
+```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,
-and additional resources. For practical purposes, you can think of a 
+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 
+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:
-    * 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
-    * 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
-
-- 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
-        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!
-        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.
-
-
-Known bugs are listed in the file "BUGS.txt".
+* ~/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. 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.
+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!
+

libs/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.
+-   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_SemWait`, `SDL_CondWait`, `SDL_WaitThread`). To avoid starving other threads, `SDL_SemTryWait` and `SDL_SemWaitTimeout` will yield if they fail to acquire the semaphore, see https://github.com/libsdl-org/SDL/pull/6776 for more information.

libs/SDL2/docs/README-nacl.md

 Native Client
 ================================================================================
 
-Requirements: 
+Requirements:
 
-* Native Client SDK (https://developer.chrome.com/native-client), 
+* Native Client SDK (https://developer.chrome.com/native-client),
   (tested with Pepper version 33 or higher).
 
 The SDL backend for Chrome's Native Client has been tested only with the PNaCl
-toolchain, which generates binaries designed to run on ARM and x86_32/64 
+toolchain, which generates binaries designed to run on ARM and x86_32/64
 platforms. This does not mean it won't work with the other toolchains!
 
 ================================================================================
@@ -17,15 +17,15 @@ Building SDL for NaCl
 Set up the right environment variables (see naclbuild.sh), then configure SDL with:
 
     configure --host=pnacl --prefix some/install/destination
-    
-Then "make". 
 
-As an example of how to create a deployable app a Makefile project is provided 
-in test/nacl/Makefile, which includes some monkey patching of the common.mk file 
-provided by NaCl, without which linking properly to SDL won't work (the search 
-path can't be modified externally, so the linker won't find SDL's binaries unless 
+Then "make".
+
+As an example of how to create a deployable app a Makefile project is provided
+in test/nacl/Makefile, which includes some monkey patching of the common.mk file
+provided by NaCl, without which linking properly to SDL won't work (the search
+path can't be modified externally, so the linker won't find SDL's binaries unless
 you dump them into the SDK path, which is inconvenient).
-Also provided in test/nacl is the required support file, such as index.html, 
+Also provided in test/nacl is the required support file, such as index.html,
 manifest.json, etc.
 SDL apps for NaCl run on a worker thread using the ppapi_simple infrastructure.
 This allows for blocking calls on all the relevant systems (OpenGL ES, filesystem),
@@ -38,20 +38,20 @@ Running tests
 ================================================================================
 
 Due to the nature of NaCl programs, building and running SDL tests is not as
-straightforward as one would hope. The script naclbuild.sh in build-scripts 
-automates the process and should serve as a guide for users of SDL trying to build 
+straightforward as one would hope. The script naclbuild.sh in build-scripts
+automates the process and should serve as a guide for users of SDL trying to build
 their own applications.
 
 Basic usage:
-    
+
     ./naclbuild.sh path/to/pepper/toolchain (i.e. ~/naclsdk/pepper_35)
-    
+
 This will build testgles2.c by default.
 
 If you want to build a different test, for example testrendercopyex.c:
-    
+
     SOURCES=~/sdl/SDL/test/testrendercopyex.c ./naclbuild.sh ~/naclsdk/pepper_35
-    
+
 Once the build finishes, you have to serve the contents with a web server (the
 script will give you instructions on how to do that with Python).
 
@@ -60,28 +60,28 @@ RWops and nacl_io
 ================================================================================
 
 SDL_RWops work transparently with nacl_io. Two functions control the mount points:
-    
-    int mount(const char* source, const char* target, 
-                      const char* filesystemtype, 
+
+    int mount(const char* source, const char* target,
+                      const char* filesystemtype,
                       unsigned long mountflags, const void *data);
     int umount(const char *target);
-    
-    For convenience, SDL will by default mount an httpfs tree at / before calling 
+
+    For convenience, SDL will by default mount an httpfs tree at / before calling
 the app's main function. Such setting can be overridden by calling:
-    
+
     umount("/");
 
 And then mounting a different filesystem at /
 
 It's important to consider that the asynchronous nature of file operations on a
 browser is hidden from the application, effectively providing the developer with
-a set of blocking file operations just like you get in a regular desktop 
-environment, which eases the job of porting to Native Client, but also introduces 
-a set of challenges of its own, in particular when big file sizes and slow 
+a set of blocking file operations just like you get in a regular desktop
+environment, which eases the job of porting to Native Client, but also introduces
+a set of challenges of its own, in particular when big file sizes and slow
 connections are involved.
 
 For more information on how nacl_io and mount points work, see:
-    
+
     https://developer.chrome.com/native-client/devguide/coding/nacl_io
     https://src.chromium.org/chrome/trunk/src/native_client_sdk/src/libraries/nacl_io/nacl_io.h
 

libs/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.

libs/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 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.

libs/SDL2/docs/README-pandora.md

-Pandora 
+Pandora
 =====================================================================
 
 ( http://openpandora.org/ )

libs/SDL2/docs/README-ps2.md

+PS2
+======
+SDL2 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 SDL2 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
+```
+
+## Hints
+The PS2 port has a special Hint for having a dynamic VSYNC. The Hint is `SDL_HINT_PS2_DYNAMIC_VSYNC`.
+If you enabled the dynamic vsync having as well `SDL_RENDERER_PRESENTVSYNC` enabled, then if the app is not able to run at 60 FPS, automatically the `vsync` will be disabled having a better performance, instead of droping FPS to 30.
+
+## 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 conection 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 everytime 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

libs/SDL2/docs/README-psp.md

 PSP
 ======
-SDL port for the Sony PSP contributed by 
-   Captian Lex 
+SDL2 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 for the PSP, make sure psp-config is in the path and run:
-   make -f Makefile.psp
+## Building
+To build SDL2 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://psp-dev.org/doku.php?id=tutorial:hello_world)
 
-To Do
-------
-PSP Screen Keyboard
+## To Do
+- PSP Screen Keyboard
+- Dialogs

libs/SDL2/docs/README-raspberrypi.md

 Raspberry Pi
-================================================================================
+============
 
 Requirements:
 
 Raspbian (other Linux distros may work as well).
 
-================================================================================
- Features
-================================================================================
+Features
+--------
 
 * Works without X11
 * Hardware accelerated OpenGL ES 2.x
@@ -16,30 +15,28 @@ Raspbian (other Linux distros may work as well).
 * Hotplugging of input devices via UDEV
 
 
-================================================================================
- Raspbian Build Dependencies
-================================================================================
+Raspbian Build Dependencies
+---------------------------
 
 sudo apt-get install libudev-dev libasound2-dev libdbus-1-dev
 
-You also need the VideoCore binary stuff that ships in /opt/vc for EGL and 
+You also need the VideoCore binary stuff that ships in /opt/vc for EGL and
 OpenGL ES 2.x, it usually comes pre-installed, but in any case:
-    
+
 sudo apt-get install libraspberrypi0 libraspberrypi-bin libraspberrypi-dev
 
 
-================================================================================
- NEON
-================================================================================
+NEON
+----
 
 If your Pi has NEON support, make sure you add -mfpu=neon to your CFLAGS so
 that SDL will select some otherwise-disabled highly-optimized code. The
 original Pi units don't have NEON, the Pi2 probably does, and the Pi3
 definitely does.
 
-================================================================================
- Cross compiling from x86 Linux
-================================================================================
+
+Cross compiling from x86 Linux
+------------------------------
 
 To cross compile SDL for Raspbian from your desktop machine, you'll need a
 Raspbian system root and the cross compilation tools. We'll assume these tools
@@ -48,7 +45,7 @@ will be placed in /opt/rpi-tools
     sudo git clone --depth 1 https://github.com/raspberrypi/tools /opt/rpi-tools
 
 You'll also need a Raspbian binary image.
-Get it from: http://downloads.raspberrypi.org/raspbian_latest 
+Get it from: http://downloads.raspberrypi.org/raspbian_latest
 After unzipping, you'll get file with a name like: "<date>-wheezy-raspbian.img"
 Let's assume the sysroot will be built in /opt/rpi-sysroot.
 
@@ -66,14 +63,14 @@ Now, before chrooting into the ARM sysroot, you'll need to apply a workaround,
 edit $SYSROOT/etc/ld.so.preload and comment out all lines in it.
 
     sudo chroot $SYSROOT
-    apt-get install libudev-dev libasound2-dev libdbus-1-dev libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxxf86vm-dev libxss-dev
+    apt-get install libudev-dev libasound2-dev libdbus-1-dev libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxi-dev libxss-dev
     exit
     sudo umount $SYSROOT/dev
     sudo umount $SYSROOT/proc
     sudo umount $SYSROOT/sys
     sudo umount /mnt
-    
-There's one more fix required, as the libdl.so symlink uses an absolute path 
+
+There's one more fix required, as the libdl.so symlink uses an absolute path
 which doesn't quite work in our setup.
 
     sudo rm -rf $SYSROOT/usr/lib/arm-linux-gnueabihf/libdl.so
@@ -89,14 +86,13 @@ The final step is compiling SDL itself.
     make install
 
 To be able to deploy this to /usr/local in the Raspbian system you need to fix up a few paths:
-    
+
     perl -w -pi -e "s#$PWD/rpi-sdl2-installed#/usr/local#g;" ./rpi-sdl2-installed/lib/libSDL2.la ./rpi-sdl2-installed/lib/pkgconfig/sdl2.pc ./rpi-sdl2-installed/bin/sdl2-config
-    
-================================================================================
- Apps don't work or poor video/audio performance
-================================================================================
 
-If you get sound problems, buffer underruns, etc, run "sudo rpi-update" to 
+Apps don't work or poor video/audio performance
+-----------------------------------------------
+
+If you get sound problems, buffer underruns, etc, run "sudo rpi-update" to
 update the RPi's firmware. Note that doing so will fix these problems, but it
 will also render the CMA - Dynamic Memory Split functionality useless.
 
@@ -105,38 +101,35 @@ low in general, specially if a 1080p TV is hooked up.
 
 See here how to configure this setting: http://elinux.org/RPiconfig
 
-Using a fixed gpu_mem=128 is the best option (specially if you updated the 
+Using a fixed gpu_mem=128 is the best option (specially if you updated the
 firmware, using CMA probably won't work, at least it's the current case).
 
-================================================================================
- No input
-================================================================================
+No input
+--------
 
 Make sure you belong to the "input" group.
 
     sudo usermod -aG input `whoami`
 
-================================================================================
- No HDMI Audio
-================================================================================
+No HDMI Audio
+-------------
 
 If you notice that ALSA works but there's no audio over HDMI, try adding:
-    
+
     hdmi_drive=2
-    
+
 to your config.txt file and reboot.
 
 Reference: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=5062
 
-================================================================================
- Text Input API support
-================================================================================
+Text Input API support
+----------------------
 
 The Text Input API is supported, with translation of scan codes done via the
 kernel symbol tables. For this to work, SDL needs access to a valid console.
 If you notice there's no SDL_TEXTINPUT message being emitted, double check that
 your app has read access to one of the following:
-    
+
 * /proc/self/fd/0
 * /dev/tty
 * /dev/tty[0...6]
@@ -144,29 +137,29 @@ your app has read access to one of the following:
 * /dev/console
 
 This is usually not a problem if you run from the physical terminal (as opposed
-to running from a pseudo terminal, such as via SSH). If running from a PTS, a 
+to running from a pseudo terminal, such as via SSH). If running from a PTS, a
 quick workaround is to run your app as root or add yourself to the tty group,
 then re-login to the system.
 
     sudo usermod -aG tty `whoami`
-    
+
 The keyboard layout used by SDL is the same as the one the kernel uses.
 To configure the layout on Raspbian:
-    
+
     sudo dpkg-reconfigure keyboard-configuration
-    
+
 To configure the locale, which controls which keys are interpreted as letters,
 this determining the CAPS LOCK behavior:
 
     sudo dpkg-reconfigure locales
 
-================================================================================
- OpenGL problems
-================================================================================
 
-If you have desktop OpenGL headers installed at build time in your RPi or cross 
-compilation environment, support for it will be built in. However, the chipset 
-does not actually have support for it, which causes issues in certain SDL apps 
+OpenGL problems
+---------------
+
+If you have desktop OpenGL headers installed at build time in your RPi or cross
+compilation environment, support for it will be built in. However, the chipset
+does not actually have support for it, which causes issues in certain SDL apps
 since the presence of OpenGL support supersedes the ES/ES2 variants.
 The workaround is to disable OpenGL at configuration time:
 
@@ -177,12 +170,11 @@ environment variable:
 
     export SDL_RENDER_DRIVER=opengles2
 
-================================================================================
- Notes
-================================================================================
+Notes
+-----
 
 * When launching apps remotely (via SSH), SDL can prevent local keystrokes from
   leaking into the console only if it has root privileges. Launching apps locally
   does not suffer from this issue.
-  
+
 

libs/SDL2/docs/README-riscos.md

+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, SDL2 for RISC OS only supports compiling with GCCSDK under Linux. Both the autoconf and CMake build systems are supported.
+
+The following commands can be used to build SDL2 for RISC OS using autoconf:
+
+    ./configure --host=arm-unknown-riscos --prefix=$GCCSDK_INSTALL_ENV --disable-gcc-atomics
+    make
+    make install
+
+The following commands can be used to build SDL2 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 -DSDL_GCC_ATOMICS=OFF
+    cmake --build build-riscos
+    cmake --build build-riscos --target install
+
+
+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.
+
+GCC atomics are currently broken on some platforms, meaning it's currently necessary to compile with `--disable-gcc-atomics` using autotools or `-DSDL_GCC_ATOMICS=OFF` using CMake.
+
+The joystick, locale and power APIs are not yet implemented.

libs/SDL2/docs/README-touch.md

@@ -8,7 +8,7 @@ The linux touch system is currently based off event streams, and proc/bus/device
 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: 
+iPhone:
 Works out of box.
 
 Windows:

libs/SDL2/docs/README-versions.md

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

libs/SDL2/docs/README-visualc.md

+Using SDL with Microsoft Visual C++
+===================================
+
+### by Lion Kimbro with additions by James Turk
+
+You can either use the precompiled libraries from the [SDL](https://www.libsdl.org/download.php) web site, or you can build SDL
+yourself.
+
+### Building SDL
+
+0. To build SDL, your machine must, at a minimum, have the DirectX9.0c SDK installed. It may or may not be retrievable from
+the [Microsoft](https://www.microsoft.com) website, so you might need to locate it [online](https://duckduckgo.com/?q=directx9.0c+sdk+download&t=h_&ia=web).
+_Editor's note: I've been able to successfully build SDL using Visual Studio 2019 **without** the DX9.0c SDK_
+
+1. Open the Visual Studio solution file at `./VisualC/SDL.sln`.
+
+2. Your IDE will likely prompt you to upgrade this solution file to whatever later version of the IDE you're using. In the `Retarget Projects` dialog,
+all of the affected project files should be checked allowing you to use the latest `Windows SDK Version` you have installed, along with
+the `Platform Toolset`.
+
+If you choose *NOT* to upgrade to use the latest `Windows SDK Version` or `Platform Toolset`, then you'll need the `Visual Studio 2010 Platform Toolset`.
+
+3. Build the `.dll` and `.lib` files by right clicking on each project in turn (Projects are listed in the _Workspace_
+panel in the _FileView_ tab), and selecting `Build`.
+
+You may get a few warnings, but you should not get any errors.
+
+Later, we will refer to the following `.lib` and `.dll` files that have just been generated:
+
+-   `./VisualC/Win32/Debug/SDL2.dll` or `./VisualC/Win32/Release/SDL2.dll`
+-   `./VisualC/Win32/Debug/SDL2.lib` or `./VisualC/Win32/Release/SDL2.lib`
+-   `./VisualC/Win32/Debug/SDL2main.lib` or `./VisualC/Win32/Release/SDL2main.lib`
+
+_Note for the `x64` versions, just replace `Win32` in the path with `x64`_
+
+### Creating a Project with SDL
+
+- Create a project as a `Win32 Application`.
+
+- Create a C++ file for your project.
+
+- Set the C runtime to `Multi-threaded DLL` in the menu:
+`Project|Settings|C/C++                  tab|Code Generation|Runtime Library `.
+
+- Add the SDL `include` directory to your list of includes in the menu:
+`Project|Settings|C/C++ tab|Preprocessor|Additional include directories `
+
+*VC7 Specific: Instead of doing this, I find it easier to add the
+include and library directories to the list that VC7 keeps. Do this by
+selecting Tools|Options|Projects|VC++ Directories and under the "Show
+Directories For:" dropbox select "Include Files", and click the "New
+Directory Icon" and add the [SDLROOT]\\include directory (e.g. If you
+installed to c:\\SDL\\ add c:\\SDL\\include). Proceed to change the
+dropbox selection to "Library Files" and add [SDLROOT]\\lib.*
+
+The "include directory" I am referring to is the `./include` folder.
+
+Now we're going to use the files that we had created earlier in the *Build SDL* step.
+
+Copy the following file into your Project directory:
+
+-   `SDL2.dll`
+
+Add the following files to your project (It is not necessary to copy them to your project directory):
+
+-   `SDL2.lib`
+-   `SDL2main.lib`
+
+To add them to your project, right click on your project, and select
+`Add files to project`.
+
+**Instead of adding the files to your project, it is more desirable to add them to the linker options: Project|Properties|Linker|Command Line
+and type the names of the libraries to link with in the "Additional Options:" box. Note: This must be done for each build configuration
+(e.g. Release,Debug).**
+
+### Hello SDL2
+
+Here's a sample SDL snippet to verify everything is setup in your IDE:
+
+```
+    #include "SDL.h"
+
+    int main( int argc, char* argv[] )
+    {
+        const int WIDTH = 640;
+        const int HEIGHT = 480;
+        SDL_Window* window = NULL;
+        SDL_Renderer* renderer = NULL;
+
+        SDL_Init(SDL_INIT_VIDEO);
+        window = SDL_CreateWindow("SDL2 Test", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, WIDTH, HEIGHT, SDL_WINDOW_SHOWN);
+        renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);
+
+        SDL_DestroyRenderer(renderer);
+        SDL_DestroyWindow(window);
+        SDL_Quit();
+        return 0;
+    }
+ ```
+
+### That's it!
+
+I hope that this document has helped you get through the most difficult part of using the SDL: installing it.
+Suggestions for improvements should be posted to the [Github Issues](https://github.com/libsdl-org/SDL/issues).
+
+### Credits
+
+Thanks to [Paulus Esterhazy](mailto:pesterhazy@gmx.net), for the work on VC++ port.
+
+This document was originally called "VisualC.txt", and was written by [Sam Lantinga](mailto:slouken@libsdl.org).
+
+Later, it was converted to HTML and expanded into the document that you see today by [Lion Kimbro](mailto:snowlion@sprynet.com).
+
+Minor Fixes and Visual C++ 7 Information (In Green) was added by [James Turk](mailto:james@conceptofzero.net)

libs/SDL2/docs/README-vita.md

+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:
+```
+   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_setenv("VITA_RESOLUTION", "720", 1);` and `SDL_setenv("VITA_RESOLUTION", "1080", 1);`
+* 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_setenv("VITA_PVR_OGL", "1", 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_setenv("VITA_DISABLE_TOUCH_FRONT", "1", 1);` and `SDL_setenv("VITA_DISABLE_TOUCH_BACK", "1", 1);`
+* Support for L2/R2/R3/R3 buttons, haptic feedback and gamepad led only available on PSTV, or when using external ds4 gamepad on vita.

libs/SDL2/docs/README-windows.md

-Windows
-================================================================================
-
-================================================================================
-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 
+# Windows
+
+## 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
+
+
+## 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.
+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)
-    
+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). 
+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).
+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.
+
+- 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.
+

libs/SDL2/docs/README-winrt.md

@@ -5,49 +5,23 @@ This port allows SDL applications to run on Microsoft's platforms that require
 use of "Windows Runtime", aka. "WinRT", APIs.  Microsoft may, in some cases,
 refer to them as either "Windows Store", or for Windows 10, "UWP" apps.
 
-Some of the operating systems that include WinRT, are:
-
-* Windows 10, via its Universal Windows Platform (UWP) APIs
-* Windows 8.x
-* Windows RT 8.x (aka. Windows 8.x for ARM processors)
-* Windows Phone 8.x
+In the past, SDL has supported Windows RT 8.x, Windows Phone, etc, but in
+modern times this port is focused on UWP apps, which run on Windows 10,
+and modern Xbox consoles.
 
 
 Requirements
 ------------
 
-* Microsoft Visual C++ (aka Visual Studio), either 2017, 2015, 2013, or 2012
+* Microsoft Visual C++ (aka Visual Studio) 2019.
   - Free, "Community" or "Express" editions may be used, so long as they
-    include  support for either "Windows Store" or "Windows Phone" apps.
+    include support for either "Windows Store" or "Windows Phone" apps.
     "Express" versions marked as supporting "Windows Desktop" development
     typically do not include support for creating WinRT apps, to note.
     (The "Community" editions of Visual C++ do, however, support both
     desktop/Win32 and WinRT development).
-  - Visual Studio 2017 can be used, however it is recommended that you install
-    the Visual C++ 2015 build tools.  These build tools can be installed
-    using VS 2017's installer.  Be sure to also install the workload for
-    "Universal Windows Platform development", its optional component, the
-    "C++ Universal Windows Platform tools", and for UWP / Windows 10
-    development, the "Windows 10 SDK (10.0.10240.0)".  Please note that
-    targeting UWP / Windows 10 apps from development machine(s) running
-    earlier versions of Windows, such as Windows 7, is not always supported
-    by Visual Studio, and you may get error(s) when attempting to do so.
-  - Visual C++ 2012 can only build apps that target versions 8.0 of Windows,
-    or  Windows Phone.  8.0-targeted apps will run on devices running 8.1
-    editions of Windows, however they will not be able to take advantage of
-    8.1-specific features.
-  - Visual C++ 2013 cannot create app projects that target Windows 8.0.
-    Visual C++ 2013 Update 4, can create app projects for Windows Phone 8.0,
-    Windows Phone 8.1, and Windows 8.1, but not Windows 8.0.  An optional
-    Visual Studio add-in, "Tools for Maintaining Store apps for Windows 8",
-    allows Visual C++ 2013 to load and build Windows 8.0 projects that were
-    created with Visual C++ 2012, so long as Visual C++ 2012 is installed
-    on the same machine.  More details on targeting different versions of
-    Windows can found at the following web pages:
-      - [Develop apps by using Visual Studio 2013](http://msdn.microsoft.com/en-us/library/windows/apps/br211384.aspx)
-      - [To add the Tools for Maintaining Store apps for Windows 8](http://msdn.microsoft.com/en-us/library/windows/apps/dn263114.aspx#AddMaintenanceTools)
 * A valid Microsoft account - This requirement is not imposed by SDL, but
-  rather by Microsoft's Visual C++ toolchain.  This is required to launch or 
+  rather by Microsoft's Visual C++ toolchain.  This is required to launch or
   debug apps.
 
 
@@ -57,7 +31,7 @@ Status
 Here is a rough list of what works, and what doesn't:
 
 * What works:
-  * compilation via Visual C++ 2012 through 2015
+  * compilation via Visual C++ 2019.
   * compile-time platform detection for SDL programs.  The C/C++ #define,
     `__WINRT__`, will be set to 1 (by SDL) when compiling for WinRT.
   * GPU-accelerated 2D rendering, via SDL_Renderer.
@@ -70,8 +44,8 @@ Here is a rough list of what works, and what doesn't:
     SDL_GetPerformanceFrequency(), etc.)
   * file I/O via SDL_RWops
   * mouse input  (unsupported on Windows Phone)
-  * audio, via SDL's WASAPI backend (if you want to record, your app must 
-    have "Microphone" capabilities enabled in its manifest, and the user must 
+  * audio, via SDL's WASAPI backend (if you want to record, your app must
+    have "Microphone" capabilities enabled in its manifest, and the user must
     not have blocked access. Otherwise, capture devices will fail to work,
     presenting as a device disconnect shortly after opening it.)
   * .DLL file loading.  Libraries *MUST* be packaged inside applications.  Loading
@@ -81,7 +55,7 @@ Here is a rough list of what works, and what doesn't:
     SDL_GameController APIs, and is backed by Microsoft's XInput API.  Please
     note, however, that Windows limits game-controller support in UWP apps to,
     "Xbox compatible controllers" (many controllers that work in Win32 apps,
-    do not work in UWP, due to restrictions in UWP itself.) 
+    do not work in UWP, due to restrictions in UWP itself.)
   * multi-touch input
   * app events.  SDL_APP_WILLENTER* and SDL_APP_DIDENTER* events get sent out as
     appropriate.
@@ -225,7 +199,7 @@ libraries such that, when the app is built:
 
 1. each library gets built for the appropriate CPU architecture(s) and WinRT
    platform(s).
-2. each library's output, such as .dll files, get copied to the app's build 
+2. each library's output, such as .dll files, get copied to the app's build
    output.
 
 To set this up for SDL/WinRT, you'll need to run through the following steps:
@@ -234,13 +208,8 @@ To set this up for SDL/WinRT, you'll need to run through the following steps:
    "Solution Explorer")
 2. right click on your app's solution.
 3. navigate to "Add", then to "Existing Project..."
-4. find SDL/WinRT's Visual C++ project file and open it.  Different project
-   files exist for different WinRT platforms.  All of them are in SDL's
-   source distribution, in the following directories:
-    * `VisualC-WinRT/UWP_VS2015/`        - for Windows 10 / UWP apps
-    * `VisualC-WinRT/WinPhone81_VS2013/` - for Windows Phone 8.1 apps
-    * `VisualC-WinRT/WinRT80_VS2012/`    - for Windows 8.0 apps
-    * `VisualC-WinRT/WinRT81_VS2013/`    - for Windows 8.1 apps
+4. find SDL/WinRT's Visual C++ project file and open it, in the `VisualC-WinRT`
+   directory.
 5. once the project has been added, right-click on your app's project and
    select, "References..."
 6. click on the button titled, "Add New Reference..."
@@ -276,12 +245,12 @@ To change these settings:
 7. edit the "Additional Include Directories" setting, and add a path to SDL's
    "include" directory
 8. **Optional: to enable compilation of C code:** change the setting for
-   "Consume Windows Runtime Extension" from "Yes (/ZW)" to "No".  If you're 
-   working with a completely C++ based project, this step can usually be 
+   "Consume Windows Runtime Extension" from "Yes (/ZW)" to "No".  If you're
+   working with a completely C++ based project, this step can usually be
    omitted.
-9. **Optional: to disable precompiled headers (which can produce 
-   'stdafx.h'-related build errors, if setup incorrectly:** in the left-hand 
-   list, select "Precompiled Headers", then change the setting for "Precompiled 
+9. **Optional: to disable precompiled headers (which can produce
+   'stdafx.h'-related build errors, if setup incorrectly:** in the left-hand
+   list, select "Precompiled Headers", then change the setting for "Precompiled
    Header" from "Use (/Yu)" to "Not Using Precompiled Headers".
 10. close the dialog, saving settings, by clicking the "OK" button
 
@@ -298,7 +267,7 @@ A few files should be included directly in your app's MSVC project, specifically
 
 To include these files for C/C++ projects:
 
-1. right-click on your project (again, in Visual C++'s Solution Explorer), 
+1. right-click on your project (again, in Visual C++'s Solution Explorer),
    navigate to "Add", then choose "Existing Item...".
 2. navigate to the directory containing SDL's source code, then into its
    subdirectory, 'src/main/winrt/'.  Select, then add, the following files:
@@ -313,8 +282,8 @@ To include these files for C/C++ projects:
 7. change the setting for "Consume Windows Runtime Extension" to "Yes (/ZW)".
 8. click the OK button.  This will close the dialog.
 
-**NOTE: C++/CX compilation is currently required in at least one file of your 
-app's project.  This is to make sure that Visual C++'s linker builds a 'Windows 
+**NOTE: C++/CX compilation is currently required in at least one file of your
+app's project.  This is to make sure that Visual C++'s linker builds a 'Windows
 Metadata' file (.winmd) for your app.  Not doing so can lead to build errors.**
 
 For non-C++ projects, you will need to call SDL_WinRTRunApp from your language's
@@ -324,104 +293,107 @@ first <PropertyGroup> block in your Visual Studio project file.
 
 ### 6. Add app code and assets ###
 
-At this point, you can add in SDL-specific source code.  Be sure to include a 
-C-style main function (ie: `int main(int argc, char *argv[])`).  From there you 
-should be able to create a single `SDL_Window` (WinRT apps can only have one 
-window, at present), as well as an `SDL_Renderer`.  Direct3D will be used to 
-draw content.  Events are received via SDL's usual event functions 
-(`SDL_PollEvent`, etc.)  If you have a set of existing source files and assets, 
-you can start adding them to the project now.  If not, or if you would like to 
-make sure that you're setup correctly, some short and simple sample code is 
+At this point, you can add in SDL-specific source code.  Be sure to include a
+C-style main function (ie: `int main(int argc, char *argv[])`).  From there you
+should be able to create a single `SDL_Window` (WinRT apps can only have one
+window, at present), as well as an `SDL_Renderer`.  Direct3D will be used to
+draw content.  Events are received via SDL's usual event functions
+(`SDL_PollEvent`, etc.)  If you have a set of existing source files and assets,
+you can start adding them to the project now.  If not, or if you would like to
+make sure that you're setup correctly, some short and simple sample code is
 provided below.
 
 
 #### 6.A. ... when creating a new app ####
 
-If you are creating a new app (rather than porting an existing SDL-based app), 
-or if you would just like a simple app to test SDL/WinRT with before trying to 
-get existing code working, some working SDL/WinRT code is provided below.  To 
+If you are creating a new app (rather than porting an existing SDL-based app),
+or if you would just like a simple app to test SDL/WinRT with before trying to
+get existing code working, some working SDL/WinRT code is provided below.  To
 set this up:
 
 1. right click on your app's project
 2. select Add, then New Item.  An "Add New Item" dialog will show up.
 3. from the left-hand list, choose "Visual C++"
 4. from the middle/main list, choose "C++ File (.cpp)"
-5. near the bottom of the dialog, next to "Name:", type in a name for your 
+5. near the bottom of the dialog, next to "Name:", type in a name for your
 source file, such as, "main.cpp".
-6. click on the Add button.  This will close the dialog, add the new file to 
+6. click on the Add button.  This will close the dialog, add the new file to
 your project, and open the file in Visual C++'s text editor.
 7. Copy and paste the following code into the new file, then save it.
 
+```c
+#include <SDL.h>
+
+int main(int argc, char **argv)
+{
+    SDL_DisplayMode mode;
+    SDL_Window * window = NULL;
+    SDL_Renderer * renderer = NULL;
+    SDL_Event evt;
+    SDL_bool keep_going = SDL_TRUE;
+
+    if (SDL_Init(SDL_INIT_VIDEO) != 0) {
+        return 1;
+    } else if (SDL_GetCurrentDisplayMode(0, &mode) != 0) {
+        return 1;
+    } else if (SDL_CreateWindowAndRenderer(mode.w, mode.h, SDL_WINDOW_FULLSCREEN, &window, &renderer) != 0) {
+        return 1;
+    }
 
-    #include <SDL.h>
-    
-    int main(int argc, char **argv)
-    {
-        SDL_DisplayMode mode;
-        SDL_Window * window = NULL;
-        SDL_Renderer * renderer = NULL;
-        SDL_Event evt;
-    
-        if (SDL_Init(SDL_INIT_VIDEO) != 0) {
-            return 1;
-        }
-    
-        if (SDL_GetCurrentDisplayMode(0, &mode) != 0) {
-            return 1;
-        }
-    
-        if (SDL_CreateWindowAndRenderer(mode.w, mode.h, SDL_WINDOW_FULLSCREEN, &window, &renderer) != 0) {
-            return 1;
-        }
-    
-        while (1) {
-            while (SDL_PollEvent(&evt)) {
+    while (keep_going) {
+        while (SDL_PollEvent(&evt)) {
+            if ((evt.type == SDL_KEYDOWN) && (evt.key.keysym.sym == SDLK_ESCAPE)) {
+                keep_going = SDL_FALSE;
             }
-    
-            SDL_SetRenderDrawColor(renderer, 0, 255, 0, 255);
-            SDL_RenderClear(renderer);
-            SDL_RenderPresent(renderer);
         }
+
+        SDL_SetRenderDrawColor(renderer, 0, 255, 0, 255);
+        SDL_RenderClear(renderer);
+        SDL_RenderPresent(renderer);
     }
 
+    SDL_Quit();
+    return 0;
+}
+```
 
 #### 6.B. Adding code and assets ####
 
-If you have existing code and assets that you'd like to add, you should be able 
+If you have existing code and assets that you'd like to add, you should be able
 to add them now.  The process for adding a set of files is as such.
 
 1. right click on the app's project
 2. select Add, then click on "New Item..."
-3. open any source, header, or asset files as appropriate.  Support for C and 
+3. open any source, header, or asset files as appropriate.  Support for C and
 C++ is available.
 
-Do note that WinRT only supports a subset of the APIs that are available to 
-Win32-based apps.  Many portions of the Win32 API and the C runtime are not 
+Do note that WinRT only supports a subset of the APIs that are available to
+Win32-based apps.  Many portions of the Win32 API and the C runtime are not
 available.
 
-A list of unsupported C APIs can be found at 
+A list of unsupported C APIs can be found at
 <http://msdn.microsoft.com/en-us/library/windows/apps/jj606124.aspx>
 
-General information on using the C runtime in WinRT can be found at 
+General information on using the C runtime in WinRT can be found at
 <https://msdn.microsoft.com/en-us/library/hh972425.aspx>
 
-A list of supported Win32 APIs for WinRT apps can be found at 
-<http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx>.  To note, 
-the list of supported Win32 APIs for Windows Phone 8.0 is different.  
-That list can be found at 
+A list of supported Win32 APIs for WinRT apps can be found at
+<http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx>.  To note,
+the list of supported Win32 APIs for Windows Phone 8.0 is different.
+That list can be found at
 <http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj662956(v=vs.105).aspx>
 
 
 ### 7. Build and run your app ###
 
-Your app project should now be setup, and you should be ready to build your app.  
-To run it on the local machine, open the Debug menu and choose "Start 
-Debugging".  This will build your app, then run your app full-screen.  To switch 
-out of your app, press the Windows key.  Alternatively, you can choose to run 
-your app in a window.  To do this, before building and running your app, find 
-the drop-down menu in Visual C++'s toolbar that says, "Local Machine".  Expand 
-this by clicking on the arrow on the right side of the list, then click on 
-Simulator.  Once you do that, any time you build and run the app, the app will 
+Your app project should now be setup, and you should be ready to build your app.
+To run it on the local machine, open the Debug menu and choose "Start
+Debugging".  This will build your app, then run your app full-screen.  To switch
+out of your app, press the Windows key.  Alternatively, you can choose to run
+your app in a window.  To do this, before building and running your app, find
+the drop-down menu in Visual C++'s toolbar that says, "Local Machine".  Expand
+this by clicking on the arrow on the right side of the list, then click on
+Simulator.  Once you do that, any time you build and run the app, the app will
 launch in window, rather than full-screen.
 
 
@@ -434,37 +406,37 @@ Windows 8.x that ran primarily on ARM-based tablet computers.
 
 To build and run the app on ARM-based, "Windows RT" devices, you'll need to:
 
-- install Microsoft's "Remote Debugger" on the device.  Visual C++ installs and 
+- install Microsoft's "Remote Debugger" on the device.  Visual C++ installs and
   debugs ARM-based apps via IP networks.
-- change a few options on the development machine, both to make sure it builds 
-  for ARM (rather than x86 or x64), and to make sure it knows how to find the 
+- change a few options on the development machine, both to make sure it builds
+  for ARM (rather than x86 or x64), and to make sure it knows how to find the
   Windows RT device (on the network).
 
-Microsoft's Remote Debugger can be found at 
-<https://msdn.microsoft.com/en-us/library/hh441469.aspx>.  Please note 
-that separate versions of this debugger exist for different versions of Visual 
+Microsoft's Remote Debugger can be found at
+<https://msdn.microsoft.com/en-us/library/hh441469.aspx>.  Please note
+that separate versions of this debugger exist for different versions of Visual
 C++, one each for MSVC 2015, 2013, and 2012.
 
 To setup Visual C++ to launch your app on an ARM device:
 
-1. make sure the Remote Debugger is running on your ARM device, and that it's on 
+1. make sure the Remote Debugger is running on your ARM device, and that it's on
    the same IP network as your development machine.
-2. from Visual C++'s toolbar, find a drop-down menu that says, "Win32".  Click 
+2. from Visual C++'s toolbar, find a drop-down menu that says, "Win32".  Click
    it, then change the value to "ARM".
-3. make sure Visual C++ knows the hostname or IP address of the ARM device.  To 
+3. make sure Visual C++ knows the hostname or IP address of the ARM device.  To
    do this:
     1. open the app project's properties
     2. select "Debugging"
-    3. next to "Machine Name", enter the hostname or IP address of the ARM 
+    3. next to "Machine Name", enter the hostname or IP address of the ARM
        device
     4. if, and only if, you've turned off authentication in the Remote Debugger,
        then change the setting for "Require Authentication" to No
     5. click "OK"
-4. build and run the app (from Visual C++).  The first time you do this, a 
-   prompt will show up on the ARM device, asking for a Microsoft Account.  You 
-   do, unfortunately, need to log in here, and will need to follow the 
-   subsequent registration steps in order to launch the app.  After you do so, 
-   if the app didn't already launch, try relaunching it again from within Visual 
+4. build and run the app (from Visual C++).  The first time you do this, a
+   prompt will show up on the ARM device, asking for a Microsoft Account.  You
+   do, unfortunately, need to log in here, and will need to follow the
+   subsequent registration steps in order to launch the app.  After you do so,
+   if the app didn't already launch, try relaunching it again from within Visual
    C++.
 
 

libs/SDL2/docs/README.md

-Simple DirectMedia Layer {#mainpage}
-========================
+# Simple DirectMedia Layer
 
-                                  (SDL)
-
-                                Version 2.0
-
----
-http://www.libsdl.org/
+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
@@ -14,14 +8,14 @@ hardware via OpenGL and Direct3D. 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, Mac OS X, Linux, iOS, and Android.
+SDL officially supports Windows, macOS, Linux, iOS, and Android.
 Support for other platforms may be found in the source code.
 
 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 "COPYING.txt".
+in the file "LICENSE.txt".
 
 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 "test" subdirectory.
@@ -34,30 +28,36 @@ More documentation and FAQs are available online at [the wiki](http://wiki.libsd
 - [DirectFB](README-directfb.md)
 - [DynAPI](README-dynapi.md)
 - [Emscripten](README-emscripten.md)
+- [GDK](README-gdk.md)
 - [Gesture](README-gesture.md)
-- [Mercurial](README-hg.md)
+- [Git](README-git.md)
 - [iOS](README-ios.md)
 - [Linux](README-linux.md)
-- [OS X](README-macosx.md)
+- [macOS](README-macos.md)
+- [OS/2](README-os2.md)
 - [Native Client](README-nacl.md)
 - [Pandora](README-pandora.md)
 - [Supported Platforms](README-platforms.md)
 - [Porting information](README-porting.md)
 - [PSP](README-psp.md)
+- [PS2](README-ps2.md)
 - [Raspberry Pi](README-raspberrypi.md)
 - [Touch](README-touch.md)
+- [Versions](README-versions.md)
 - [WinCE](README-wince.md)
 - [Windows](README-windows.md)
 - [WinRT](README-winrt.md)
+- [PSVita](README-vita.md)
+- [Nokia N-Gage](README-ngage.md)
 
 If you need help with the library, or just want to discuss SDL related
-issues, you can join the [developers mailing list](http://www.libsdl.org/mailing-list.php)
+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
-[bugzilla](https://bugzilla.libsdl.org/)
+[our bug tracker](https://github.com/libsdl-org/SDL/issues)
 
 Enjoy!
 
 
 Sam Lantinga <mailto:slouken@libsdl.org>
-