From 03f8528315fa46c95991a34f3325d7b33ae5538c Mon Sep 17 00:00:00 2001
From: Edward Rudd <urkle@outoforder.cc>
Date: Sat, 02 May 2020 21:48:36 +0000
Subject: [PATCH] Update source to SDL2 2.0.12

---
 source/docs/README-nacl.md |  206 +++++++++++++++++++++++++-------------------------
 1 files changed, 103 insertions(+), 103 deletions(-)

diff --git a/source/docs/README-nacl.md b/source/docs/README-nacl.md
index 4c9432b..53ada33 100644
--- a/source/docs/README-nacl.md
+++ b/source/docs/README-nacl.md
@@ -1,103 +1,103 @@
-Native Client
-================================================================================
-
-Requirements: 
-
-* 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 
-platforms. This does not mean it won't work with the other toolchains!
-
-================================================================================
-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 
-you dump them into the SDK path, which is inconvenient).
-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),
-hiding the asynchronous nature of the browser behind the scenes...which is not the
-same as making it disappear!
-
-
-================================================================================
-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 
-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).
-
-================================================================================
-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, 
-                      unsigned long mountflags, const void *data);
-    int umount(const char *target);
-    
-    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 
-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
-
-To be able to save into the directory "/save/" (like backup of game) :
-
-    mount("", "/save", "html5fs", 0, "type=PERSISTENT");
-
-And add to manifest.json :
-
-    "permissions": [
-        "unlimitedStorage"
-    ]
-
-================================================================================
-TODO - Known Issues
-================================================================================
-* Testing of all systems with a real application (something other than SDL's tests)
-* Key events don't seem to work properly
-
+Native Client
+================================================================================
+
+Requirements: 
+
+* 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 
+platforms. This does not mean it won't work with the other toolchains!
+
+================================================================================
+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 
+you dump them into the SDK path, which is inconvenient).
+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),
+hiding the asynchronous nature of the browser behind the scenes...which is not the
+same as making it disappear!
+
+
+================================================================================
+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 
+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).
+
+================================================================================
+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, 
+                      unsigned long mountflags, const void *data);
+    int umount(const char *target);
+    
+    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 
+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
+
+To be able to save into the directory "/save/" (like backup of game) :
+
+    mount("", "/save", "html5fs", 0, "type=PERSISTENT");
+
+And add to manifest.json :
+
+    "permissions": [
+        "unlimitedStorage"
+    ]
+
+================================================================================
+TODO - Known Issues
+================================================================================
+* Testing of all systems with a real application (something other than SDL's tests)
+* Key events don't seem to work properly
+

--
Gitblit v1.9.3