libs/SDL2/docs/README-dynapi.md

@@ -64,7 +64,7 @@ level of indirection, we can do things like this:
     export SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0
     ./MyGameThatIsStaticallyLinkedToSDL2
 
-And now, this game that is staticallly linked to SDL, can still be overridden 
+And now, this game that is statically linked to SDL, can still be overridden 
 with a newer, or better, SDL. The statically linked one will only be used as 
 far as calling into the jump table in this case. But in cases where no override
 is desired, the statically linked version will provide its own jump table, 

libs/SDL2/docs/README-emscripten.md

@@ -5,7 +5,7 @@ Build:
 
     $ mkdir build
     $ cd build
-    $ emconfigure ../configure --host=asmjs-unknown-emscripten --disable-assembly --disable-threads --enable-cpuinfo=false CFLAGS="-O2"
+    $ emconfigure ../configure --host=asmjs-unknown-emscripten --disable-assembly --disable-threads --disable-cpuinfo CFLAGS="-O2"
     $ emmake make
 
 Or with cmake:
@@ -22,8 +22,6 @@ To build one of the tests:
 
 Uses GLES2 renderer or software
 
-tests: https://dl.dropboxusercontent.com/u/17360362/SDL2-em/index.html
-
 Some other SDL2 libraries can be easily built (assuming SDL2 is installed somewhere):
 
 SDL_mixer (http://www.libsdl.org/projects/SDL_mixer/):

libs/SDL2/docs/README-hg.md

@@ -5,15 +5,12 @@ The latest development version of SDL is available via Mercurial.
 Mercurial allows you to get up-to-the-minute fixes and enhancements;
 as a developer works on a source tree, you can use "hg" to mirror that
 source tree instead of waiting for an official release. Please look
-at the Mercurial website ( http://mercurial.selenic.com/ ) for more
+at the Mercurial website ( https://www.mercurial-scm.org/ ) for more
 information on using hg, where you can also download software for
 Mac OS X, Windows, and Unix systems.
 
     hg clone http://hg.libsdl.org/SDL
 
-If you are building SDL with an IDE, you will need to copy the file
-include/SDL_config.h.default to include/SDL_config.h before building.
-
 If you are building SDL via configure, you will need to run autogen.sh
 before running configure.
 

libs/SDL2/docs/README-ios.md

@@ -8,6 +8,7 @@ Building the Simple DirectMedia Layer for iOS 5.1+
 Requirements: Mac OS X 10.8 or later and the iOS 7+ SDK.
 
 Instructions:
+
 1.  Open SDL.xcodeproj (located in Xcode-iOS/SDL) in Xcode.
 2.  Select your desired target, and hit build.
 
@@ -74,17 +75,17 @@ By default SDL will not use the full pixel density of the screen on
 Retina/high-dpi capable devices. Use the SDL_WINDOW_ALLOW_HIGHDPI flag when
 creating your window to enable high-dpi support.
 
-When high-dpi support is enabled, SDL_GetWindowSize and display mode sizes
+When high-dpi support is enabled, SDL_GetWindowSize() and display mode sizes
 will still be in "screen coordinates" rather than pixels, but the window will
 have a much greater pixel density when the device supports it, and the
-SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize functions (depending on
+SDL_GL_GetDrawableSize() or SDL_GetRendererOutputSize() functions (depending on
 whether raw OpenGL or the SDL_Render API is used) can be queried to determine
 the size in pixels of the drawable screen framebuffer.
 
 Some OpenGL ES functions such as glViewport expect sizes in pixels rather than
 sizes in screen coordinates. When doing 2D rendering with OpenGL ES, an
 orthographic projection matrix using the size in screen coordinates
-(SDL_GetWindowSize) can be used in order to display content at the same scale
+(SDL_GetWindowSize()) can be used in order to display content at the same scale
 no matter whether a Retina device is used or not.
 
 ==============================================================================
@@ -156,7 +157,7 @@ Notes -- Accelerometer as Joystick
 
 SDL for iPhone supports polling the built in accelerometer as a joystick device.  For an example on how to do this, see the accelerometer.c in the demos directory.
 
-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.
+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
@@ -164,7 +165,7 @@ Notes -- OpenGL ES
 
 Your SDL application for iOS uses OpenGL ES for video by default.
 
-OpenGL ES for iOS supports several display pixel formats, such as RGBA8 and RGB565, which provide a 32 bit and 16 bit color buffer respectively. By default, the implementation uses RGB565, but you may use RGBA8 by setting each color component to 8 bits in SDL_GL_SetAttribute.
+OpenGL ES for iOS supports several display pixel formats, such as RGBA8 and RGB565, which provide a 32 bit and 16 bit color buffer respectively. By default, the implementation uses RGB565, but you may use RGBA8 by setting each color component to 8 bits in SDL_GL_SetAttribute().
 
 If your application doesn't use OpenGL's depth buffer, you may find significant performance improvement by setting SDL_GL_DEPTH_SIZE to 0.
 
@@ -172,11 +173,11 @@ Finally, if your application completely redraws the screen each frame, you may f
 
 OpenGL ES on iOS doesn't use the traditional system-framebuffer setup provided in other operating systems. Special care must be taken because of this:
 
-- The drawable Renderbuffer must be bound to the GL_RENDERBUFFER binding point when SDL_GL_SwapWindow is called.
-- The drawable Framebuffer Object must be bound while rendering to the screen and when SDL_GL_SwapWindow is called.
+- The drawable Renderbuffer must be bound to the GL_RENDERBUFFER binding point when SDL_GL_SwapWindow() is called.
+- The drawable Framebuffer Object must be bound while rendering to the screen and when SDL_GL_SwapWindow() is called.
 - If multisample antialiasing (MSAA) is used and glReadPixels is used on the screen, the drawable framebuffer must be resolved to the MSAA resolve framebuffer (via glBlitFramebuffer or glResolveMultisampleFramebufferAPPLE), and the MSAA resolve framebuffer must be bound to the GL_READ_FRAMEBUFFER binding point, before glReadPixels is called.
 
-The above objects can be obtained via SDL_GetWindowWMInfo (in SDL_syswm.h).
+The above objects can be obtained via SDL_GetWindowWMInfo() (in SDL_syswm.h).
 
 ==============================================================================
 Notes -- Keyboard
@@ -219,7 +220,7 @@ Notes -- iPhone SDL limitations
 ==============================================================================
 
 Windows:
-	Full-size, single window applications only.  You cannot create multi-window SDL applications for iPhone OS.  The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow the flag SDL_WINDOW_BORDERLESS).
+	Full-size, single window applications only.  You cannot create multi-window SDL applications for iPhone OS.  The application window will fill the display, though you have the option of turning on or off the menu-bar (pass SDL_CreateWindow() the flag SDL_WINDOW_BORDERLESS).
 
 Textures:
 	The optimal texture formats on iOS are SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_ABGR8888, SDL_PIXELFORMAT_BGR888, and SDL_PIXELFORMAT_RGB24 pixel formats.
@@ -264,3 +265,20 @@ e.g.
     #endif
         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
+
+In order to do that you need to download an older version of Xcode:
+https://developer.apple.com/download/more/?name=Xcode
+
+Open the package contents of the older Xcode and your newer version of Xcode and copy over the folders in Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
+
+Then open the file Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist and add the versions of iOS you want to deploy to the key Root/DefaultProperties/DEPLOYMENT_TARGET_SUGGESTED_VALUES
+
+Open your project and set your deployment target to the desired version of iOS
+
+Finally, remove GameController from the list of frameworks linked by your application and edit the build settings for "Other Linker Flags" and add -weak_framework GameController

libs/SDL2/docs/README-linux.md

@@ -19,14 +19,19 @@ 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
+libgles1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev libibus-1.0-dev \
+fcitx-libs-dev libsamplerate0-dev libsndio-dev
 
-Ubuntu 14.04 can also add "libwayland-dev libmirclient-dev libxkbcommon-dev"
-to that command line for Wayland and Mir support.
+Ubuntu 16.04+ can also add "libwayland-dev libxkbcommon-dev wayland-protocols"
+to that command line for Wayland support.
 
 NOTES:
 - This includes all the audio targets except arts, because Ubuntu pulled the 
   artsc0-dev package, but in theory SDL still supports it.
+- 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 
   configure script to include DirectFB support. Send patches.  :)

libs/SDL2/docs/README-macosx.md

@@ -8,6 +8,9 @@ From the developer's point of view, OS X is a sort of hybrid Mac and
 Unix system, and you have the option of using either traditional
 command line tools or Apple's IDE Xcode.
 
+Command Line Build
+==================
+
 To build SDL using the command line, use the standard configure and make
 process:
 
@@ -21,7 +24,7 @@ the gcc-fat.sh script in build-scripts:
 
     mkdir mybuild
     cd mybuild
-    CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++fat.sh ../configure
+    CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++-fat.sh ../configure
     make
     sudo make install
 
@@ -96,8 +99,8 @@ APP_NAME_bundle: EXE_NAME
 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.in file.
+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.
@@ -111,7 +114,7 @@ install-exec-hook: APP_NAME_bundle
     	cp -r $< /$(DESTDIR)$(prefix)Applications/
 
 This rule takes the Bundle created by the rule from step 3 and installs them
-into $(DESTDIR)$(prefix)/Applications/.
+into "$(DESTDIR)$(prefix)/Applications/".
 
 Again, if you want to install multiple applications, you will have to augment
 the make rule accordingly.
@@ -126,11 +129,16 @@ there are some more things you should do before shipping your product...
    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
+
    instead of those listed by
+
        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
    contains some meta-information about your application (like some copyright
    information, the version of your app, the name of an optional icon file,
@@ -156,8 +164,10 @@ 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
+
 This will create a new folder called Xcode, which you can browse
 normally from the Finder.
 
@@ -227,4 +237,4 @@ following locations:
         Functionality may be added in the future to help this.
 
 
-Known bugs are listed in the file "BUGS"
+Known bugs are listed in the file "BUGS.txt".

libs/SDL2/docs/README-porting.md

@@ -5,7 +5,7 @@ Porting
 
   The first thing you have to do when porting to a new platform, is look at
 include/SDL_platform.h and create an entry there for your operating system.
-The standard format is __PLATFORM__, where PLATFORM is the name of the OS.
+The standard format is "__PLATFORM__", where PLATFORM is the name of the OS.
 Ideally SDL_platform.h will be able to auto-detect the system it's building
 on based on C preprocessor symbols.
 
@@ -13,9 +13,11 @@ There are two basic ways of building SDL at the moment:
 
 1. The "UNIX" way:  ./configure; make; make install
 
-   If you have a GNUish system, then you might try this.  Edit configure.in,
+   If you have a GNUish system, then you might try this.  Edit configure.ac,
    take a look at the large section labelled:
+
 	"Set up the configuration based on the host platform!"
+
    Add a section for your platform, and then re-run autogen.sh and build!
 
 2. Using an IDE:
@@ -23,10 +25,11 @@ There are two basic ways of building SDL at the moment:
    If you're using an IDE or other non-configure build system, you'll probably
    want to create a custom SDL_config.h for your platform.  Edit SDL_config.h,
    add a section for your platform, and create a custom SDL_config_{platform}.h,
-   based on SDL_config.h.minimal and SDL_config.h.in
+   based on SDL_config_minimal.h and SDL_config.h.in
 
    Add the top level include directory to the header search path, and then add
    the following sources to the project:
+
 	src/*.c
 	src/atomic/*.c
 	src/audio/*.c
@@ -37,6 +40,7 @@ There are two basic ways of building SDL at the moment:
 	src/joystick/*.c
 	src/power/*.c
 	src/render/*.c
+	src/render/software/*.c
 	src/stdlib/*.c
 	src/thread/*.c
 	src/timer/*.c

libs/SDL2/docs/README-raspberrypi.md

@@ -23,10 +23,20 @@ Raspbian (other Linux distros may work as well).
 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 
-OpenGL ES 2.x, it usually comes pre installed, but in any case:
+OpenGL ES 2.x, it usually comes pre-installed, but in any case:
     
 sudo apt-get install libraspberrypi0 libraspberrypi-bin libraspberrypi-dev
 
+
+================================================================================
+ 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
 ================================================================================
@@ -37,9 +47,9 @@ 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 Rasbian binary image.
+You'll also need a Raspbian binary image.
 Get it from: http://downloads.raspberrypi.org/raspbian_latest 
-After unzipping, you'll get file with a name like: <date>-wheezy-raspbian.img
+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.
 
     export SYSROOT=/opt/rpi-sysroot
@@ -136,7 +146,7 @@ your app has read access to one of the following:
 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 
 quick workaround is to run your app as root or add yourself to the tty group,
-then re login to the system.
+then re-login to the system.
 
     sudo usermod -aG tty `whoami`
     

libs/SDL2/docs/README-touch.md

@@ -42,14 +42,14 @@ Same as SDL_FINGERDOWN.
 ===========================================================================
 Functions
 ===========================================================================
-SDL provides the ability to access the underlying Finger structures.
+SDL provides the ability to access the underlying SDL_Finger structures.
 These structures should _never_ be modified.
 
 The following functions are included from SDL_touch.h
 
-To get a SDL_TouchID call SDL_GetTouchDevice(index).
+To get a SDL_TouchID call SDL_GetTouchDevice(int index).
 This returns a SDL_TouchID.
-IMPORTANT: If the touch has been removed, or there is no touch with the given ID, SDL_GetTouchID will return 0. Be sure to check for this!
+IMPORTANT: If the touch has been removed, or there is no touch with the given index, SDL_GetTouchDevice() will return 0. Be sure to check for this!
 
 The number of touch devices can be queried with SDL_GetNumTouchDevices().
 
@@ -64,13 +64,13 @@ The most common reason to access SDL_Finger is to query the fingers outside the
 
 
 
-To get a SDL_Finger, call SDL_GetTouchFinger(touchID,index), where touchID is a SDL_TouchID, and index is the requested finger.
+To get a SDL_Finger, call SDL_GetTouchFinger(SDL_TouchID touchID, int index), where touchID is a SDL_TouchID, and index is the requested finger.
 This returns a SDL_Finger *, or NULL if the finger does not exist, or has been removed.
 A SDL_Finger is guaranteed to be persistent for the duration of a touch, but it will be de-allocated as soon as the finger is removed. This occurs when the SDL_FINGERUP event is _added_ to the event queue, and thus _before_ the SDL_FINGERUP event is polled.
 As a result, be very careful to check for NULL return values.
 
 A SDL_Finger has the following fields:
-* x,y,pressure:
+* x, y:
 	The current coordinates of the touch.
 * pressure:
 	The pressure of the touch.

libs/SDL2/docs/README-windows.md

@@ -39,3 +39,7 @@ Known Bugs:
       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

@@ -2,11 +2,8 @@ WinRT
 =====
 
 This port allows SDL applications to run on Microsoft's platforms that require
-use of "Windows Runtime", aka. "WinRT", APIs.  WinRT apps are currently
-full-screen only, and run in what Microsoft sometimes refers to as their
-"Modern" (formerly, "Metro"), environment.  For Windows 8.x, Microsoft may also
-refer to them as "Windows Store" apps, due to them being distributed,
-primarily, via a Microsoft-run online store (of the same name).
+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:
 
@@ -19,15 +16,24 @@ Some of the operating systems that include WinRT, are:
 Requirements
 ------------
 
-* Microsoft Visual C++ (aka Visual Studio), either 2015, 2013, or 2012
+* Microsoft Visual C++ (aka Visual Studio), either 2017, 2015, 2013, or 2012
   - Free, "Community" or "Express" editions may be used, so long as they
     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-targetted apps will run on devices running 8.1
+    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.
@@ -48,7 +54,7 @@ Requirements
 Status
 ------
 
-Here is a rough list of what works, and what doens't:
+Here is a rough list of what works, and what doesn't:
 
 * What works:
   * compilation via Visual C++ 2012 through 2015
@@ -64,12 +70,18 @@ Here is a rough list of what works, and what doens't:
     SDL_GetPerformanceFrequency(), etc.)
   * file I/O via SDL_RWops
   * mouse input  (unsupported on Windows Phone)
-  * audio, via a modified version of SDL's XAudio2 backend
+  * 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
     anything outside of the app is not supported.
   * system path retrieval via SDL's filesystem APIs
   * game controllers.  Support is provided via the SDL_Joystick and
-    SDL_GameController APIs, and is backed by Microsoft's XInput API.
+    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.) 
   * multi-touch input
   * app events.  SDL_APP_WILLENTER* and SDL_APP_DIDENTER* events get sent out as
     appropriate.
@@ -82,7 +94,9 @@ Here is a rough list of what works, and what doens't:
 
 * What partially works:
   * keyboard input.  Most of WinRT's documented virtual keys are supported, as
-    well as many keys with documented hardware scancodes.
+    well as many keys with documented hardware scancodes.  Converting
+    SDL_Scancodes to or from SDL_Keycodes may not work, due to missing APIs
+    (MapVirtualKey()) in Microsoft's Windows Store / UWP APIs.
   * SDLmain.  WinRT uses a different signature for each app's main() function.
     SDL-based apps that use this port must compile in SDL_winrt_main_NonXAML.cpp
     (in `SDL\src\main\winrt\`) directly in order for their C-style main()
@@ -95,8 +109,10 @@ Here is a rough list of what works, and what doens't:
     SDL_CreateSystemCursor() (unsupported on Windows Phone)
   * SDL_WarpMouseInWindow() or SDL_WarpMouseGlobal().  This are not currently
     supported by WinRT itself.
-  * joysticks and game controllers that aren't supported by Microsoft's XInput
-    API.
+  * joysticks and game controllers that either are not supported by
+    Microsoft's XInput API, or are not supported within UWP apps (many
+    controllers that work in Win32, do not work in UWP, due to restrictions in
+    UWP itself).
   * turning off VSync when rendering on Windows Phone.  Attempts to turn VSync
     off on Windows Phone result either in Direct3D not drawing anything, or it
     forcing VSync back on.  As such, SDL_RENDERER_PRESENTVSYNC will always get
@@ -160,7 +176,9 @@ following, at a high-level:
    the linker, and will copy SDL's .dll files to your app's final output.
 4. adjust your app's build settings, at minimum, telling it where to find SDL's
    header files.
-5. add a file that contains a WinRT-appropriate main function.
+5. add files that contains a WinRT-appropriate main function, along with some
+   data to make sure mouse-cursor-hiding (via SDL_ShowCursor(SDL_DISABLE) calls)
+   work properly.
 6. add SDL-specific app code.
 7. build and run your app.
 
@@ -268,39 +286,41 @@ To change these settings:
 10. close the dialog, saving settings, by clicking the "OK" button
 
 
-### 5. Add a WinRT-appropriate main function to the app. ###
+### 5. Add a WinRT-appropriate main function, and a blank-cursor image, to the app. ###
 
-C/C++-based WinRT apps do contain a `main` function that the OS will invoke when 
-the app starts launching. The parameters of WinRT main functions are different 
-than those found on other platforms, Win32 included.  SDL/WinRT provides a 
-platform-appropriate main function that will perform these actions, setup key 
-portions of the app, then invoke a classic, C/C++-style main function (that take 
-in "argc" and "argv" parameters).  The code for this file is contained inside 
-SDL's source distribution, under `src/main/winrt/SDL_winrt_main_NonXAML.cpp`.  
-You'll need to add this file, or a copy of it, to your app's project, and make 
-sure it gets compiled using a Microsoft-specific set of C++ extensions called 
-C++/CX.
+A few files should be included directly in your app's MSVC project, specifically:
+1. a WinRT-appropriate main function (which is different than main() functions on
+   other platforms)
+2. a Win32-style cursor resource, used by SDL_ShowCursor() to hide the mouse cursor
+   (if and when the app needs to do so).  *If this cursor resource is not
+   included, mouse-position reporting may fail if and when the cursor is
+   hidden, due to possible bugs/design-oddities in Windows itself.*
 
-**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.**
-
-To include `SDL_winrt_main_NonXAML.cpp`:
+To include these files for C/C++ projects:
 
 1. right-click on your project (again, in Visual C++'s Solution Explorer), 
    navigate to "Add", then choose "Existing Item...".
-2. open `SDL_winrt_main_NonXAML.cpp`, which is found inside SDL's source 
-   distribution, under `src/main/winrt/`.  Make sure that the open-file dialog 
-   closes, either by double-clicking on the file, or single-clicking on it and 
-   then clicking Add.
-3. right-click on the file (as listed in your project), then click on 
-   "Properties...".
+2. navigate to the directory containing SDL's source code, then into its
+   subdirectory, 'src/main/winrt/'.  Select, then add, the following files:
+   - `SDL_winrt_main_NonXAML.cpp`
+   - `SDL2-WinRTResources.rc`
+   - `SDL2-WinRTResource_BlankCursor.cur`
+3. right-click on the file `SDL_winrt_main_NonXAML.cpp` (as listed in your
+   project), then click on "Properties...".
 4. in the drop-down box next to "Configuration", choose, "All Configurations"
 5. in the drop-down box next to "Platform", choose, "All Platforms"
 6. in the left-hand list, click on "C/C++"
 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 
+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
+main function, and generate SDL2-WinRTResources.res manually by using `rc` via
+the Developer Command Prompt and including it as a <Win32Resource> within the
+first <PropertyGroup> block in your Visual Studio project file.
 
 ### 6. Add app code and assets ###
 
@@ -466,3 +486,62 @@ section.
 
     /nodefaultlib:vccorlibd /nodefaultlib:msvcrtd vccorlibd.lib msvcrtd.lib
 
+
+#### Mouse-motion events fail to get sent, or SDL_GetMouseState() fails to return updated values
+
+This may be caused by a bug in Windows itself, whereby hiding the mouse
+cursor can cause mouse-position reporting to fail.
+
+SDL provides a workaround for this, but it requires that an app links to a
+set of Win32-style cursor image-resource files.  A copy of suitable resource
+files can be found in `src/main/winrt/`.  Adding them to an app's Visual C++
+project file should be sufficient to get the app to use them.
+
+
+#### SDL's Visual Studio project file fails to open, with message, "The system can't find the file specified."
+
+This can be caused for any one of a few reasons, which Visual Studio can
+report, but won't always do so in an up-front manner.
+
+To help determine why this error comes up:
+
+1. open a copy of Visual Studio without opening a project file.  This can be
+   accomplished via Windows' Start Menu, among other means.
+2. show Visual Studio's Output window.  This can be done by going to VS'
+   menu bar, then to View, and then to Output.
+3. try opening the SDL project file directly by going to VS' menu bar, then
+   to File, then to Open, then to Project/Solution.  When a File-Open dialog
+   appears, open the SDL project (such as the one in SDL's source code, in its
+   directory, VisualC-WinRT/UWP_VS2015/).
+4. after attempting to open SDL's Visual Studio project file, additional error
+   information will be output to the Output window.
+
+If Visual Studio reports (via its Output window) that the project:
+
+"could not be loaded because it's missing install components. To fix this launch Visual Studio setup with the following selections:
+Microsoft.VisualStudio.ComponentGroup.UWP.VC"
+
+... then you will need to re-launch Visual Studio's installer, and make sure that
+the workflow for "Universal Windows Platform development" is checked, and that its
+optional component, "C++ Universal Windows Platform tools" is also checked.  While
+you are there, if you are planning on targeting UWP / Windows 10, also make sure
+that you check the optional component, "Windows 10 SDK (10.0.10240.0)".  After
+making sure these items are checked as-appropriate, install them.
+
+Once you install these components, try re-launching Visual Studio, and re-opening
+the SDL project file.  If you still get the error dialog, try using the Output
+window, again, seeing what Visual Studio says about it.
+
+
+#### Game controllers / joysticks aren't working!
+
+Windows only permits certain game controllers and joysticks to work within
+WinRT / UWP apps.  Even if a game controller or joystick works in a Win32
+app, that device is not guaranteed to work inside a WinRT / UWP app.
+
+According to Microsoft, "Xbox compatible controllers" should work inside
+UWP apps, potentially with more working in the future.  This includes, but
+may not be limited to, Microsoft-made Xbox controllers and USB adapters.
+(Source: https://social.msdn.microsoft.com/Forums/en-US/9064838b-e8c3-4c18-8a83-19bf0dfe150d/xinput-fails-to-detect-game-controllers?forum=wpdevelop)
+
+

libs/SDL2/docs/README.md

@@ -54,7 +54,7 @@ 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)
 
 If you want to report bugs or contribute patches, please submit them to
-[bugzilla](http://bugzilla.libsdl.org/)
+[bugzilla](https://bugzilla.libsdl.org/)
 
 Enjoy!
 

libs/SDL2/i686-w64-mingw32/bin/sdl2-config

 #!/bin/sh
 
-prefix=/usr/local/cross-tools/i686-w64-mingw32
+prefix=/opt/local/i686-w64-mingw32
 exec_prefix=${prefix}
 exec_prefix_set=no
 libdir=${exec_prefix}/lib
@@ -39,7 +39,7 @@ while test $# -gt 0; do
       echo $exec_prefix
       ;;
     --version)
-      echo 2.0.4
+      echo 2.0.10
       ;;
     --cflags)
       echo -I${prefix}/include/SDL2  -Dmain=SDL_main
@@ -49,7 +49,7 @@ while test $# -gt 0; do
       ;;
     --static-libs)
 #    --libs|--static-libs)
-      echo -L${exec_prefix}/lib  -lmingw32 -lSDL2main -lSDL2  -mwindows  -Wl,--no-undefined -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -static-libgcc
+      echo -L${exec_prefix}/lib  -lmingw32 -lSDL2main -lSDL2 -mwindows  -Wl,--no-undefined -Wl,--dynamicbase -Wl,--nxcompat -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lsetupapi -lversion -luuid -static-libgcc
       ;;
     *)
       echo "${usage}" 1>&2