alphatau 0.1.0

data/ext/alphatau/native/sdl/docs/README-linux.md

@@ -0,0 +1,90 @@
+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 
+default configuration parameters.
+
+
+================================================================================
+Build Dependencies
+================================================================================
+    
+Ubuntu 13.04, all available features enabled:
+
+sudo apt-get install build-essential mercurial make cmake autoconf automake \
+libtool libasound2-dev libpulse-dev libaudio-dev libx11-dev libxext-dev \
+libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxxf86vm-dev \
+libxss-dev libgl1-mesa-dev libesd0-dev libdbus-1-dev libudev-dev \
+libgles1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev libibus-1.0-dev \
+fcitx-libs-dev libsamplerate0-dev libsndio-dev
+
+Ubuntu 16.04+ can also add "libwayland-dev libxkbcommon-dev wayland-protocols"
+to that command line for Wayland support.
+
+Ubuntu 16.10 can also add "libmirclient-dev libxkbcommon-dev" to that command
+line for Mir 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.  :)
+
+
+================================================================================
+Joystick does not work
+================================================================================
+
+If you compiled or are using a version of SDL with udev support (and you should!)
+there's a few issues that may cause SDL to fail to detect your joystick. To
+debug this, start by installing the evtest utility. On Ubuntu/Debian:
+
+    sudo apt-get install evtest
+    
+Then run:
+    
+    sudo evtest
+    
+You'll hopefully see your joystick listed along with a name like "/dev/input/eventXX"
+Now run:
+    
+    cat /dev/input/event/XX
+
+If you get a permission error, you need to set a udev rule to change the mode of
+your device (see below)    
+    
+Also, try:
+    
+    sudo udevadm info --query=all --name=input/eventXX
+    
+If you see a line stating ID_INPUT_JOYSTICK=1, great, if you don't see it,
+you need to set up an udev rule to force this variable.
+
+A combined rule for the Saitek Pro Flight Rudder Pedals to fix both issues looks 
+like:
+    
+   SUBSYSTEM=="input", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
+   SUBSYSTEM=="input", ATTRS{idProduct}=="0764", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
+   
+You can set up similar rules for your device by changing the values listed in
+idProduct and idVendor. To obtain these values, try:
+    
+    sudo udevadm info -a --name=input/eventXX | grep idVendor
+    sudo udevadm info -a --name=input/eventXX | grep idProduct
+    
+If multiple values come up for each of these, the one you want is the first one of each.    
+
+On other systems which ship with an older udev (such as CentOS), you may need
+to set up a rule such as:
+    
+    SUBSYSTEM=="input", ENV{ID_CLASS}=="joystick", ENV{ID_INPUT_JOYSTICK}="1"
+

data/ext/alphatau/native/sdl/docs/README-macosx.md

@@ -0,0 +1,240 @@
+Mac OS X
+==============================================================================
+
+These instructions are for people using Apple's Mac OS X (pronounced
+"ten").
+
+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:
+
+    ./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:
+
+    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
+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.
+
+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;
+    }
+    
+    - (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;
+    }
+
+==============================================================================
+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
+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
+"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.in file.
+
+If your project builds more than one application, you will have to do a bit
+more. For each of your target applications, you need a separate rule.
+
+If you want the created bundles to be installed, you may want to add this
+rule to your Makefile.am:
+
+    install-exec-hook: APP_NAME_bundle
+    	rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
+    	mkdir -p $(DESTDIR)$(prefix)/Applications/
+    	cp -r $< /$(DESTDIR)$(prefix)Applications/
+
+This rule takes the Bundle created by the rule from step 3 and installs them
+into "$(DESTDIR)$(prefix)/Applications/".
+
+Again, if you want to install multiple applications, you will have to augment
+the make rule accordingly.
+
+
+But beware! That is only part of the story! With the above, you end up with
+a bare bone .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 
+   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
+
+   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,
+   and other things). Part of that information is displayed by the Finder
+   when you click on the .app, or if you look at the "Get Info" window.
+   More information about Info.plist files can be found on Apple's homepage.
+
+
+As a final remark, let me add that I use some of the techniques (and some
+variations of them) in Exult and ScummVM; both are available in source on
+the net, so feel free to take a peek at them for inspiration!
+
+
+==============================================================================
+Using the Simple DirectMedia Layer with Xcode
+==============================================================================
+
+These instructions are for using Apple's Xcode IDE to build SDL applications.
+
+- First steps
+
+The first thing to do is to unpack the Xcode.tar.gz archive in the
+top level SDL directory (where the Xcode.tar.gz archive resides).
+Because Stuffit Expander will unpack the archive into a subdirectory,
+you should unpack the archive manually from the command line:
+
+    cd [path_to_SDL_source]
+    tar zxf Xcode.tar.gz
+
+This will create a new folder called Xcode, which you can browse
+normally from the Finder.
+
+- Building the Framework
+
+The SDL Library is packaged as a framework bundle, an organized
+relocatable folder hierarchy of executable code, interface headers,
+and additional resources. For practical purposes, you can think of a 
+framework as a more user and system-friendly shared library, whose library
+file behaves more or less like a standard UNIX shared library.
+
+To build the framework, simply open the framework project and build it. 
+By default, the framework bundle "SDL.framework" is installed in 
+/Library/Frameworks. Therefore, the testers and project stationary expect
+it to be located there. However, it will function the same in any of the
+following locations:
+
+    ~/Library/Frameworks
+    /Local/Library/Frameworks
+    /System/Library/Frameworks
+
+- Build Options
+    There are two "Build Styles" (See the "Targets" tab) for SDL.
+    "Deployment" should be used if you aren't tweaking the SDL library.
+    "Development" should be used to debug SDL apps or the library itself.
+
+- Building the Testers
+    Open the SDLTest project and build away!
+
+- Using the Project Stationary
+    Copy the stationary to the indicated folders to access it from
+    the "New Project" and "Add target" menus. What could be easier?
+
+- Setting up a new project by hand
+    Some of you won't want to use the Stationary so I'll give some tips:
+    * 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".

data/ext/alphatau/native/sdl/docs/README-nacl.md

@@ -0,0 +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
+

data/ext/alphatau/native/sdl/docs/README-pandora.md

@@ -0,0 +1,17 @@
+Pandora 
+=====================================================================
+
+( http://openpandora.org/ )
+- A pandora specific video driver was written to allow SDL 2.0 with OpenGL ES
+support to work on the pandora under the framebuffer. This driver do not have
+input support for now, so if you use it you will have to add your own control code.
+The video driver name is "pandora" so if you have problem running it from
+the framebuffer, try to set the following variable before starting your application :
+"export SDL_VIDEODRIVER=pandora"
+
+- OpenGL ES support was added to the x11 driver, so it's working like the normal
+x11 driver one with OpenGLX support, with SDL input event's etc..
+
+
+David Carré (Cpasjuste)
+cpasjuste@gmail.com