Finish importing full OP contents

advanced_topics/binary_serialization_api.rst

@@ -307,21 +307,21 @@ This field is padded to 4 bytes.
 15: image
 ~~~~~~~~~
 
-+---------------------+-------+-----------+------------------------------------------------------+
-| Offset              | Len   | Type      | Description                                          |
-+=====================+=======+===========+======================================================+
-| 4                   | 4     | Integer   | Format (see FORMAT\_\* in \\"Image\\":class\_image   |
-+---------------------+-------+-----------+------------------------------------------------------+
-| 8                   | 4     | Integer   | Mip-Maps (0 means no mip-maps).                      |
-+---------------------+-------+-----------+------------------------------------------------------+
-| 12                  | 4     | Integer   | Width (Pixels)                                       |
-+---------------------+-------+-----------+------------------------------------------------------+
-| 16                  | 4     | Integer   | Height (Pixels)                                      |
-+---------------------+-------+-----------+------------------------------------------------------+
-| 20                  | 4     | Integer   | Data Length                                          |
-+---------------------+-------+-----------+------------------------------------------------------+
-| 24..24+DataLength   | 1     | Byte      | Image Data                                           |
-+---------------------+-------+-----------+------------------------------------------------------+
++---------------------+-------+-----------+--------------------------------------------------+
+| Offset              | Len   | Type      | Description                                      |
++=====================+=======+===========+==================================================+
+| 4                   | 4     | Integer   | Format (see FORMAT\_\* in "Image":class\_image   |
++---------------------+-------+-----------+--------------------------------------------------+
+| 8                   | 4     | Integer   | Mip-Maps (0 means no mip-maps).                  |
++---------------------+-------+-----------+--------------------------------------------------+
+| 12                  | 4     | Integer   | Width (Pixels)                                   |
++---------------------+-------+-----------+--------------------------------------------------+
+| 16                  | 4     | Integer   | Height (Pixels)                                  |
++---------------------+-------+-----------+--------------------------------------------------+
+| 20                  | 4     | Integer   | Data Length                                      |
++---------------------+-------+-----------+--------------------------------------------------+
+| 24..24+DataLength   | 1     | Byte      | Image Data                                       |
++---------------------+-------+-----------+--------------------------------------------------+
 
 This field is padded to 4 bytes.
 
@@ -386,7 +386,7 @@ Every name string is is padded to 4 bytes.
 | 4        | 4     | Integer   | val&0x7FFFFFFF = elements, val&0x80000000 = shared (bool)   |
 +----------+-------+-----------+---------------------------------------------------------------------+
 
-| Then what follows is, for amount of \\"elements\\", pairs of key and
+| Then what follows is, for amount of "elements", pairs of key and
   value, one after the other, using
 | this same format.
 
@@ -399,8 +399,8 @@ Every name string is is padded to 4 bytes.
 | 4        | 4     | Integer   | val&0x7FFFFFFF = elements, val&0x80000000 = shared (bool)   |
 +----------+-------+-----------+---------------------------------------------------------------------+
 
-| Then what follows is, for amount of \\"elements\\", values one after
-  the other, using
+| Then what follows is, for amount of "elements", values one after the
+  other, using
 | this same format.
 
 22: byte array

advanced_topics/command_line_tutorial.rst

@@ -100,7 +100,7 @@ that is headless (server build, no video) is ideal for this.
 
 ::
 
-    user@host:~/newgame$ godot -export \"Linux X11\" /var/builds/project
+    user@host:~/newgame$ godot -export "Linux X11" /var/builds/project
     user@host:~/newgame$ godot -export Android /var/builds/project.apk
 
 The platform names recognized by the ``-export`` switch are the same as
@@ -122,17 +122,14 @@ Running a script
 
 Here is a simple example of how it works:
 
-| <pre class=\\"python\\">
-| #sayhello.gd
-| extends SceneTree
+.. code:: python
 
-| func \_init():
-| print(\\"Hello!\\")
-| quit()
+    #sayhello.gd
+    extends SceneTree
 
-.. raw:: html
-
-   </pre>
+    func _init():
+        print("Hello!")
+        quit()
 
 And how to run it:
 

advanced_topics/compiling_for_android.rst

@@ -30,8 +30,8 @@ Setting Up SCons
   Android NDK.
 
 To set those environment variables on Windows, press Windows+R, type
-\\"control system\\", then click on **Advanced system settings** in the
-left pane, then click on **Environment variables** on the window that
+"control system", then click on **Advanced system settings** in the left
+pane, then click on **Environment variables** on the window that
 appears.
 
 To set those environment variables on Linux, use
@@ -78,8 +78,8 @@ platform, for each build type (release, debug, etc), it must be
 replaced.
 
 **Note**: The file inside libs/armeabi must be renamed to
-**\\"libgodot\_android.so\\"**, or else unsatisfied link error will
-happen at runtime.
+**"libgodot\_android.so"**, or else unsatisfied link error will happen
+at runtime.
 
 If you also want to include support for x86 Android, add the following
 compile flag: ``x86=yes`` , then copy/symlink the resulting folder to
@@ -102,8 +102,8 @@ the current numbers, then set the following environment variables:
 
 ::
 
-    NDK_TOOLCHAIN  (by default set to \"arm-eabi-4.4.0\")
-    NDK_TARGET (by default set to \"arm-linux-androideabi-4.8\")
+    NDK_TOOLCHAIN  (by default set to "arm-eabi-4.4.0")
+    NDK_TARGET (by default set to "arm-linux-androideabi-4.8")
 
 Building the APK
 ----------------

advanced_topics/compiling_for_ios.rst

@@ -40,5 +40,5 @@ Run
 | To run on a device or simulator, follow these instructions:
   [[Exporting for iOS]].
 | Replace or add your executable to the Xcode project, and change the
-  \\"executable name\\" property on Info.plist accordingly if you use an
+  "executable name" property on Info.plist accordingly if you use an
   alternative build.

advanced_topics/compiling_for_linux.rst

@@ -41,9 +41,9 @@ Start a terminal, go to the root dir of the engine source code and type:
     user@host:~/godot$ scons platform=x11
 
 If all goes well, the resulting binary executable will be placed in the
-\\"bin\\" subdirectory. This executable file contains the whole engine
-and runs without any dependencies. Executing it will bring up the
-project manager.
+"bin" subdirectory. This executable file contains the whole engine and
+runs without any dependencies. Executing it will bring up the project
+manager.
 
 Building export templates
 -------------------------

advanced_topics/compiling_for_osx.rst

@@ -21,9 +21,9 @@ Start a terminal, go to the root dir of the engine source code and type:
     user@host:~/godot$ scons platform=osx
 
 If all goes well, the resulting binary executable will be placed in the
-\\"bin\\" subdirectory. This executable file contains the whole engine
-and runs without any dependencies. Executing it will bring up the
-project manager. There is a .app template to put the binary into in
+"bin" subdirectory. This executable file contains the whole engine and
+runs without any dependencies. Executing it will bring up the project
+manager. There is a .app template to put the binary into in
 tools/Godot.app.
 
 Cross-compiling
@@ -31,9 +31,8 @@ Cross-compiling
 
 It is possible to compile for OS X in a Linux environment (and maybe
 also in Windows with Cygwin). For that you will need
-\\\ `OSXCross\\ <https://github.com/tpoechtrager/osxcross>`__ for being
-able to use OS X as target. First, follow the instructions to install
-it:
+`OSXCross <https://github.com/tpoechtrager/osxcross>`__ for being able
+to use OS X as target. First, follow the instructions to install it:
 
 # Clone the OSXCross repository
 (https://github.com/tpoechtrager/osxcross) somewhere in your machine (or

advanced_topics/compiling_for_universal_windows_apps.rst

@@ -1,32 +1,31 @@
 Compiling for Universal Windows Apps
 ====================================
 
-This page documents the current state of the \\"winrt\\" platform, used
-to support \\"Windows Store Apps\\" for Windows 8.1, and Windows Phone
-8.1 apps using Microsoft's new \\"Universal\\" APIs.
+This page documents the current state of the "winrt" platform, used to
+support "Windows Store Apps" for Windows 8.1, and Windows Phone 8.1 apps
+using Microsoft's new "Universal" APIs.
 
 Requirements
 ------------
 
 -  Windows 8
 -  SCons (see [[Compiling for Windows]] for more details)
--  Visual Studio 2013 for Windows (but *not* \\"for Windows Desktop\\").
-   Tested on \\"Microsoft Visual Studio Express 2013 for Windows Version
-   12.0.31101.00 Update 4\\".
+-  Visual Studio 2013 for Windows (but *not* "for Windows Desktop").
+   Tested on "Microsoft Visual Studio Express 2013 for Windows Version
+   12.0.31101.00 Update 4".
 
 Compiling
 ---------
 
 The platform can compile binaries for both Windows 8.1 and Windows Phone
-8.1. The architecture is decided by the environment variable
-\\"PLATFORM\\".
+8.1. The architecture is decided by the environment variable "PLATFORM".
 
 Windows 8.1
 ~~~~~~~~~~~
 
-\* Open a \\"VS 2013 x64 Cross Tools Command Prompt\\"
+\* Open a "VS 2013 x64 Cross Tools Command Prompt"
 
-\* The value of environment variable \\"PLATFORM\\" should be \\"x64\\"
+\* The value of environment variable "PLATFORM" should be "x64"
 
 \* Run scons with platform=winrt from the root of the source tree
 
@@ -35,15 +34,15 @@ Windows 8.1
     C:\\godot_source> scons platform=winrt
 
 -  You should get an executable file inside bin/ named according to your
-   build options, for the architecture \\"x64\\", for example
-   \\"godot.winrt.tools.x64.exe\\".
+   build options, for the architecture "x64", for example
+   "godot.winrt.tools.x64.exe".
 
 Windows Phone 8.1
 ~~~~~~~~~~~~~~~~~
 
-\* Open a \\"Visual Studio 2012 ARM Phone Tools Command Prompt\\"
+\* Open a "Visual Studio 2012 ARM Phone Tools Command Prompt"
 
-\* The value of environment variable \\"PLATFORM\\" should be \\"arm\\"
+\* The value of environment variable "PLATFORM" should be "arm"
 
 \* Run scons with platform=winrt from the root of the source tree
 
@@ -52,26 +51,26 @@ Windows Phone 8.1
     C:\\godot_source> scons platform=winrt
 
 -  You should get an executable file inside bin/ named according to your
-   build options, for the architecture \\"arm\\", for example
-   \\"godot.winrt.tools.arm.exe\\".
+   build options, for the architecture "arm", for example
+   "godot.winrt.tools.arm.exe".
 
 Running
 -------
 
-On Visual studio, create a new project using any of the \\"Unversal
-App\\" templates found under Visual C++ -> Store Apps -> Universal Apps.
-\\"Blank App\\" should be fine.
+On Visual studio, create a new project using any of the "Unversal App"
+templates found under Visual C++ -> Store Apps -> Universal Apps. "Blank
+App" should be fine.
 
-On the \\"Solution Explorer\\" box, you should have 3 sections,
-\\"App.Windows (Windows 8.1)\\", \\"App.WindowsPhone (Windows Phone
-8.1)\\" and \\"App.Shared\\". You need to add files to each section:
+On the "Solution Explorer" box, you should have 3 sections, "App.Windows
+(Windows 8.1)", "App.WindowsPhone (Windows Phone 8.1)" and "App.Shared".
+You need to add files to each section:
 
 App.Shared
 ~~~~~~~~~~
 
--  Add a folder named \\"game\\" containing your game content (can be
-   individual files or your data.pck). Remember to set the \\"Content\\"
-   property of each file to \\"True\\", otherwise your files won't get
+-  Add a folder named "game" containing your game content (can be
+   individual files or your data.pck). Remember to set the "Content"
+   property of each file to "True", otherwise your files won't get
    included in the package.
 
 App.Windows
@@ -79,13 +78,13 @@ App.Windows
 
 \* Add your windows executable, and all the .dll files found on
 platform/winrt/x64/bin on the godot source. Remember to also set the
-\\"Content\\" property.
+"Content" property.
 
-\* Find the file \\"Package.appxmanifest\\". Right click on it and
-select \\"Open with...\\" then \\"XML (Text) Editor\\" from the list.
+\* Find the file "Package.appxmanifest". Right click on it and select
+"Open with..." then "XML (Text) Editor" from the list.
 
-\* Find the \\"Application\\" section, and add (or modify) the
-\\"Executable\\" property with the name of your .exe. Example:
+\* Find the "Application" section, and add (or modify) the "Executable"
+property with the name of your .exe. Example:
 
 ::
 
@@ -94,23 +93,21 @@ App.WindowsPhone
 
 -  Repeat all the steps from App.Windows, using your arm executable and
    the dlls found in platform/winrt/arm/bin. Remember to set the
-   \\"Content\\" property for all the files.
+   "Content" property for all the files.
 
-Use the green \\"Play\\" button on the top to run. The drop down menu
-next to it should let you choose the project (App.Windows or
-App.WindowsPhone) and the device (\\"Local Machine\\", \\"Device\\" for
-an attached phone, etc).
+Use the green "Play" button on the top to run. The drop down menu next
+to it should let you choose the project (App.Windows or
+App.WindowsPhone) and the device ("Local Machine", "Device" for an
+attached phone, etc).
 
 Angle
 -----
 
 ANGLE precompiled binaries are provided on platform/winrt/x64 and
-platform/winrt/arm. They are built from MSOpenTech's \\"future-dev\\"
-branch, found here:
-\\\ `https://github.com/MSOpenTech/angle\\ <https://github.com/MSOpenTech/angle>`__.
-The visual studio 'solutions' used are found on
-\\"projects/winrt/windows/angle.sln\\" and
-\\"projects/winrt/windowsphone/angle.sln\\".
+platform/winrt/arm. They are built from MSOpenTech's "future-dev"
+branch, found here: https://github.com/MSOpenTech/angle. The visual
+studio 'solutions' used are found on "projects/winrt/windows/angle.sln"
+and "projects/winrt/windowsphone/angle.sln".
 
 What's missing
 --------------
@@ -131,18 +128,17 @@ Packages
 This is what we know:
 
 -  App packages are documented here:
-   \\\ `http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464929.aspx\\ <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464929.aspx>`__
--  There are 2 command line tools that might be useful, \\\ `App
-   Packager\\ <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh446767.aspx>`__
+   http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464929.aspx
+-  There are 2 command line tools that might be useful, `App
+   Packager <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh446767.aspx>`__
    and
-   \\\ `SignTool\\ <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/ff551778.aspx>`__.
--  There are a bunch of tools on \\"powershell\\" that deal with
-   packages that might be relevant:
-   \\\ `http://technet.microsoft.com/library/dn448373.aspx\\ <http://technet.microsoft.com/library/dn448373.aspx>`__
--  When running a Windows 8.1 app on \\"Local Machine\\" from Visual
-   studio, the app seems to run from an uncompressed directory on the
-   filesystem in an arbitrary location (ie. outside of the proper
-   directory where Apps are installed), but there is some special
-   registry entry made for it, so we know it's possible to skip the
-   packaging step to run locally (in the case of very big games this can
-   be useful).
+   `SignTool <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/ff551778.aspx>`__.
+-  There are a bunch of tools on "powershell" that deal with packages
+   that might be relevant:
+   http://technet.microsoft.com/library/dn448373.aspx
+-  When running a Windows 8.1 app on "Local Machine" from Visual studio,
+   the app seems to run from an uncompressed directory on the filesystem
+   in an arbitrary location (ie. outside of the proper directory where
+   Apps are installed), but there is some special registry entry made
+   for it, so we know it's possible to skip the packaging step to run
+   locally (in the case of very big games this can be useful).

advanced_topics/compiling_for_windows.rst

@@ -6,27 +6,25 @@ Requirements
 
 For compiling under Windows, the following is required:
 
--  \\\ `Visual C++\\ <http://www.microsoft.com/visualstudio>`__, Visual
-   C++ Express compiler or Visual Studio Community (recommended) at
-   least the 2010 version (10.0) up to 2015 (14.0). **Make sure you get
-   a version that can compile for C++, Desktop**.
--  \\\ `Python 2.7+\\ <http://www.python.org/getit/releases/2.7/>`__
-   (3.0 is untested as of now). Using the 32-bits installer is
-   recommended.
--  \\\ `Pywin32 Python
-   Extension\\ <http://sourceforge.net/projects/pywin32>`__ for parallel
+-  `Visual C++ <http://www.microsoft.com/visualstudio>`__, Visual C++
+   Express compiler or Visual Studio Community (recommended) at least
+   the 2010 version (10.0) up to 2015 (14.0). **Make sure you get a
+   version that can compile for C++, Desktop**.
+-  `Python 2.7+ <http://www.python.org/getit/releases/2.7/>`__ (3.0 is
+   untested as of now). Using the 32-bits installer is recommended.
+-  `Pywin32 Python
+   Extension <http://sourceforge.net/projects/pywin32>`__ for parallel
    builds (which increase the build speed by a great factor).
--  \\\ `SCons\\ <http://www.scons.org>`__ build system.
+-  `SCons <http://www.scons.org>`__ build system.
 
 Setting up SCons
 ----------------
 
 Python adds the interpreter (python.exe) to the path. It usually
 installs in C:\\\\Python (or C:\\\\Python[Version]). SCons installs
-inside the python install and provides a .bat file called
-\\"scons.bat\\". The location of this file can be added to the path or
-it can simply be copied to C:\\\\Python together with the interpreter
-executable.
+inside the python install and provides a .bat file called "scons.bat".
+The location of this file can be added to the path or it can simply be
+copied to C:\\\\Python together with the interpreter executable.
 
 Compiling
 ---------
@@ -64,7 +62,7 @@ build it seems to be by running:
 
 ::
 
-    \"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\vcvarsall.bat\" && c:\\python27\\scons p=windows
+    "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\vcvarsall.bat" && c:\\python27\\scons p=windows
 
 (or however your VS and Scons are installed)
 
@@ -91,8 +89,8 @@ following env variables:
 
 ::
 
-    export MINGW32_PREFIX=\"/path/to/i586-mingw32msvc-\"
-    export MINGW64_PREFIX=\"/path/to/i686-w64-mingw32-\"
+    export MINGW32_PREFIX="/path/to/i586-mingw32msvc-"
+    export MINGW64_PREFIX="/path/to/i686-w64-mingw32-"
 
 To make sure you are doing things correctly, executing the following in
 the shell should result in a working compiler:

advanced_topics/core_types.rst

@@ -31,7 +31,7 @@ directly to wchar\_t.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/typedefs.h\\ <https://github.com/okamstudio/godot/blob/master/core/typedefs.h>`__
+-  `core/typedefs.h <https://github.com/okamstudio/godot/blob/master/core/typedefs.h>`__
 
 Memory model
 ------------
@@ -128,8 +128,8 @@ locked until they go out of scope.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/os/memory.h\\ <https://github.com/okamstudio/godot/blob/master/core/os/memory.h>`__
--  \\\ `core/dvector.h\\ <https://github.com/okamstudio/godot/blob/master/core/dvector.h>`__
+-  `core/os/memory.h <https://github.com/okamstudio/godot/blob/master/core/os/memory.h>`__
+-  `core/dvector.h <https://github.com/okamstudio/godot/blob/master/core/dvector.h>`__
 
 Containers
 ----------
@@ -162,10 +162,10 @@ The Vector<> class also has a few nice features:
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/vector.h\\ <https://github.com/okamstudio/godot/blob/master/core/vector.h>`__
--  \\\ `core/list.h\\ <https://github.com/okamstudio/godot/blob/master/core/list.h>`__
--  \\\ `core/set.h\\ <https://github.com/okamstudio/godot/blob/master/core/set.h>`__
--  \\\ `core/map.h\\ <https://github.com/okamstudio/godot/blob/master/core/map.h>`__
+-  `core/vector.h <https://github.com/okamstudio/godot/blob/master/core/vector.h>`__
+-  `core/list.h <https://github.com/okamstudio/godot/blob/master/core/list.h>`__
+-  `core/set.h <https://github.com/okamstudio/godot/blob/master/core/set.h>`__
+-  `core/map.h <https://github.com/okamstudio/godot/blob/master/core/map.h>`__
 
 String
 ------
@@ -178,7 +178,7 @@ conversion and visualization.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/ustring.h\\ <https://github.com/okamstudio/godot/blob/master/core/ustring.h>`__
+-  `core/ustring.h <https://github.com/okamstudio/godot/blob/master/core/ustring.h>`__
 
 StringName
 ----------
@@ -193,7 +193,7 @@ StringName
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/string\_db.h\\ <https://github.com/okamstudio/godot/blob/master/core/string_db.h>`__
+-  `core/string\_db.h <https://github.com/okamstudio/godot/blob/master/core/string_db.h>`__
 
 Math types
 ----------
@@ -204,7 +204,7 @@ directory, they are basically just that.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/math\\ <https://github.com/okamstudio/godot/blob/master/core/math>`__
+-  `core/math <https://github.com/okamstudio/godot/blob/master/core/math>`__
 
 NodePath
 --------
@@ -215,7 +215,7 @@ referencing them fast.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/path\_db.h\\ <https://github.com/okamstudio/godot/blob/master/core/path_db.h>`__
+-  `core/path\_db.h <https://github.com/okamstudio/godot/blob/master/core/path_db.h>`__
 
 RID
 ---
@@ -228,4 +228,4 @@ referenced data.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/rid.h\\ <https://github.com/okamstudio/godot/blob/master/core/rid.h>`__
+-  `core/rid.h <https://github.com/okamstudio/godot/blob/master/core/rid.h>`__

advanced_topics/creating_android_modules.rst

@@ -64,29 +64,23 @@ In the config.py for the module, some extra functions are provided for
 convenience. First, it's often wise to detect if android is being built
 and only enable building in this case:
 
-| <pre class=\\"python\\">
-| def can\_build(plat):
-| return plat==\\"android\\"
+.. code:: python
 
-.. raw:: html
-
-   </pre>
+    def can_build(plat):
+        return plat=="android"
 
 If more than one platform can be built (typical if implementing the
 module also for iOS), check manually for Android in the configure
 functions:
 
-| <pre class=\\"python\\">
-| def can\_build(plat):
-| return plat\\"android\\" or plat\\"iphone\\"
-
-| def configure(env):
-| if env['platform'] == 'android':
-| #androd specific code
+.. code:: python
 
-.. raw:: html
+    def can_build(plat):
+        return plat=="android" or plat=="iphone"
 
-   </pre>
+    def configure(env):
+        if env['platform'] == 'android':
+             #androd specific code
 
 Java singleton
 --------------
@@ -95,56 +89,51 @@ An android module will usually have a singleton class that will load it,
 this class inherits from ``Godot.SingletonBase``. A singleton object
 template follows:
 
-| <pre class=\\"java\\">
-| //namespace is wrong, will eventually change
-| package com.android.godot;
+.. code:: java
 
-public class MySingleton extends Godot.SingletonBase {
+    //namespace is wrong, will eventually change
+    package com.android.godot;
 
-| public int myFunction(String p\_str) {
-| // a function to bind
-| }
+    public class MySingleton extends Godot.SingletonBase {
 
-static public Godot.SingletonBase initialize(Activity p\_activity) {
 
-| return new MySingleton(p\_activity);
-| }
+        public int myFunction(String p_str) {
+              // a function to bind
+        }
 
-| public MySingleton(Activity p\_activity) {
-| //register class name and functions to bind
-| registerClass(\\"MySingleton\\", new String[]{\\"myFunction\\"});
+        static public Godot.SingletonBase initialize(Activity p_activity) {
 
-| // you might want to try initializing your singleton here, but android
-| // threads are weird and this runs in another thread, so you usually
-  have to do
-| activity.runOnUiThread(new Runnable() {
-| public void run() {
-| //useful way to get config info from engine.cfg
-| String key = GodotLib.getGlobal(\\"plugin/api\_key\\");
-| SDK.initializeHere();
-| }
-| });
+                    return new MySingleton(p_activity);
+        } 
 
-}
+        public MySingleton(Activity p_activity) {
+              //register class name and functions to bind
+              registerClass("MySingleton", new String[]{"myFunction"});
 
-// forwarded callbacks you can reimplement, as SDKs often need them
+              // you might want to try initializing your singleton here, but android
+              // threads are weird and this runs in another thread, so you usually have to do
+              activity.runOnUiThread(new Runnable() {
+                   public void run() {
+                        //useful way to get config info from engine.cfg
+                        String key = GodotLib.getGlobal("plugin/api_key");
+                        SDK.initializeHere();
+                   }
+              });
 
-protected void onMainActivityResult(int requestCode, int resultCode,
-Intent data) {}
+        }
 
-| protected void onMainPause() {}
-| protected void onMainResume() {}
-| protected void onMainDestroy() {}
+         // forwarded callbacks you can reimplement, as SDKs often need them
 
-| protected void onGLDrawFrame(GL10 gl) {}
-| protected void onGLSurfaceChanged(GL10 gl, int width, int height) {}
-  // singletons will always miss first onGLSurfaceChanged call
+         protected void onMainActivityResult(int requestCode, int resultCode, Intent data) {}
 
-}
+         protected void onMainPause() {}
+         protected void onMainResume() {}
+         protected void onMainDestroy() {}
 
-.. raw:: html
+         protected void onGLDrawFrame(GL10 gl) {}
+         protected void onGLSurfaceChanged(GL10 gl, int width, int height) {} // singletons will always miss first onGLSurfaceChanged call
 
-   </pre>
+    }
 
 Calling back to Godot from Java is a little more difficult. The instance
 ID of the script must be known first, this is obtained by calling
@@ -154,30 +143,23 @@ passed to Java.
 From Java, use the calldeferred function to communicate back with Godot.
 Java will most likely run in a separate thread, so calls are deferred:
 
-<pre class=\\"java\\">GodotLib.calldeferred(, \\"\\", new
-Object[]{param1,param2,etc});
+.. code:: java
 
-.. raw:: html
-
-   </pre>
+    GodotLib.calldeferred(, "", new Object[]{param1,param2,etc});
 
 Add this singleton to the build of the project by adding the following
 to config.py:
 
-| <pre class=\\"python\\">
-| def can\_build(plat):
-| return plat\\"android\\" or plat\\"iphone\\"
-
-| def configure(env):
-| if env['platform'] == 'android':
-| # will copy this to the java folder
-| env.android\_module\_file(\\"MySingleton.java\\")
-| #env.android\_module\_file(\\"MySingleton2.java\\") call again for
-  more files
+.. code:: python
 
-.. raw:: html
+    def can_build(plat):
+        return plat=="android" or plat=="iphone"
 
-   </pre>
+    def configure(env):
+        if env['platform'] == 'android':
+            # will copy this to the java folder
+            env.android_module_file("MySingleton.java")
+            #env.android_module_file("MySingleton2.java") call again for more files
 
 AndroidManifest
 ---------------
@@ -189,19 +171,16 @@ maybe other functionalities are needed.
 Create the custom chunk of android manifest and put it inside the
 module, add it like this:
 
-| <pre class=\\"python\\">
-| def can\_build(plat):
-| return plat\\"android\\" or plat\\"iphone\\"
+.. code:: python
 
-| def configure(env):
-| if env['platform'] == 'android':
-| # will copy this to the java folder
-| env.android\_module\_file(\\"MySingleton.java\\")
-| env.android\_module\_manifest(\\"AndroidManifestChunk.xml\\")
+    def can_build(plat):
+        return plat=="android" or plat=="iphone"
 
-.. raw:: html
-
-   </pre>
+    def configure(env):
+        if env['platform'] == 'android':
+            # will copy this to the java folder
+            env.android_module_file("MySingleton.java") 
+            env.android_module_manifest("AndroidManifestChunk.xml")
 
 SDK library
 -----------
@@ -210,20 +189,17 @@ So, finally it's time to add the SDK library. The library can come in
 two flavors, a JAR file or an Android project for ant. JAR is the
 easiest to integrate, just put it in the module directory and add it:
 
-| <pre class=\\"python\\">
-| def can\_build(plat):
-| return plat\\"android\\" or plat\\"iphone\\"
-
-| def configure(env):
-| if env['platform'] == 'android':
-| # will copy this to the java folder
-| env.android\_module\_file(\\"MySingleton.java\\")
-| env.android\_module\_manifest(\\"AndroidManifestChunk.xml\\")
-| env.android\_module\_library(\\"MyLibrary-3.1.jar\\")
+.. code:: python
 
-.. raw:: html
+    def can_build(plat):
+        return plat=="android" or plat=="iphone"
 
-   </pre>
+    def configure(env):
+        if env['platform'] == 'android':
+            # will copy this to the java folder
+            env.android_module_file("MySingleton.java") 
+            env.android_module_manifest("AndroidManifestChunk.xml")
+            env.android_module_library("MyLibrary-3.1.jar")
 
 SDK project
 -----------
@@ -238,24 +214,21 @@ the project folder inside the module directory and configure it:
 As of this writing, godot uses minsdk 10 and target sdk 15. If this ever
 changes, should be reflected in the manifest template:
 
-\\\ `https://github.com/okamstudio/godot/blob/master/platform/android/AndroidManifest.xml.template\\ <https://github.com/okamstudio/godot/blob/master/platform/android/AndroidManifest.xml.template>`__
+https://github.com/okamstudio/godot/blob/master/platform/android/AndroidManifest.xml.template
 
 Then, add the module folder to the project:
 
-| <pre class=\\"python\\">
-| def can\_build(plat):
-| return plat\\"android\\" or plat\\"iphone\\"
+.. code:: python
 
-| def configure(env):
-| if env['platform'] == 'android':
-| # will copy this to the java folder
-| env.android\_module\_file(\\"MySingleton.java\\")
-| env.android\_module\_manifest(\\"AndroidManifestChunk.xml\\")
-| env.android\_module\_source(\\"sdk-1.2\\",\\"\\")
+    def can_build(plat):
+        return plat=="android" or plat=="iphone"
 
-.. raw:: html
-
-   </pre>
+    def configure(env):
+        if env['platform'] == 'android':
+            # will copy this to the java folder
+            env.android_module_file("MySingleton.java") 
+            env.android_module_manifest("AndroidManifestChunk.xml")
+            env.android_module_source("sdk-1.2","")
 
 Building
 --------
@@ -299,7 +272,7 @@ the following line to engine.cfg:
 
     [android]
 
-    modules=\"com/android/godot/MySingleton\"
+    modules="com/android/godot/MySingleton"
 
 More than one singleton module can be enable by separating with comma:
 
@@ -307,22 +280,19 @@ More than one singleton module can be enable by separating with comma:
 
     [android]
 
-    modules=\"com/android/godot/MySingleton,com/android/godot/MyOtherSingleton\"
+    modules="com/android/godot/MySingleton,com/android/godot/MyOtherSingleton"
 
 Then just request the singleton Java object from Globals like this:
 
-| <pre class=\\"python\\">
-| #in any file
-
-var singleton=null
+.. code:: python
 
-| func \_init():
-| singleton = Globals.get\_singleton(\\"MySingleton\\")
-| print( singleton.myFunction(\\"Hello\\") )
+    #in any file
 
-.. raw:: html
+    var singleton=null
 
-   </pre>
+    func _init():
+        singleton = Globals.get_singleton("MySingleton")
+        print( singleton.myFunction("Hello") )
 
 Troubleshooting
 ---------------
@@ -350,5 +320,5 @@ Future
     class = JavaClassWrapper.wrap()
 
 This is most likely not functional yet, if you want to test it and help
-us make it work, contact us through the \\\ `developer mailing
-list\\ <https://groups.google.com/forum/#!forum/godot-engine>`__.
+us make it work, contact us through the `developer mailing
+list <https://groups.google.com/forum/#!forum/godot-engine>`__.

advanced_topics/cross-compiling_for_ios_on_linux.rst

@@ -11,10 +11,10 @@ Disclaimer
 While it is possible to compile for iOS on a Linux environment, Apple is
 very restrictive about the tools to be used (specially hardware-wise),
 allowing pretty much only their products to be used for development. So
-this is **not official**. However, a \\\ `statement from Apple in
-2010\\ <http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html>`__
-says they relaxed some of the \\\ `App Store review
-guidelines\\ <https://developer.apple.com/app-store/review/guidelines/>`__
+this is **not official**. However, a `statement from Apple in
+2010 <http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html>`__
+says they relaxed some of the `App Store review
+guidelines <https://developer.apple.com/app-store/review/guidelines/>`__
 to allow any tool to be used, as long as the resulting binary do not
 download any code, which means it should be OK to use the procedure
 described here and cross-compiling the binary.
@@ -22,21 +22,21 @@ described here and cross-compiling the binary.
 Requirements
 ------------
 
--  \\\ `**XCode with the iOS
-   SDK**\\ <https://developer.apple.com/xcode/download>`__ (a dmg image)
--  \\\ `**Clang >=3.5**\\ <http://clang.llvm.org>`__ for your
-   development machine installed and in the ``PATH``. It needs to be
-   version >= 3.5 to target ``arm64`` architecture.
--  \\\ `**Fuse**\\ <http://fuse.sourceforge.net>`__ for mounting and
-   umounting the dmg image.
--  \\\ `**darling-dmg**\\ <https://github.com/darlinghq/darling-dmg>`__,
-   which needs to be built from source. The procedure for that is
-   explained below.
+-  `**XCode with the iOS
+   SDK** <https://developer.apple.com/xcode/download>`__ (a dmg image)
+-  `**Clang >=3.5** <http://clang.llvm.org>`__ for your development
+   machine installed and in the ``PATH``. It needs to be version >= 3.5
+   to target ``arm64`` architecture.
+-  `**Fuse** <http://fuse.sourceforge.net>`__ for mounting and umounting
+   the dmg image.
+-  `**darling-dmg** <https://github.com/darlinghq/darling-dmg>`__, which
+   needs to be built from source. The procedure for that is explained
+   below.
 
    -  For building darling-dmg, you'll need the development packages of
       the following libraries: **fuse, icu, openssl, zlib, bzip2**.
 
--  \\\ `**cctools-port**\\ <https://github.com/tpoechtrager/cctools-port>`__
+-  `**cctools-port** <https://github.com/tpoechtrager/cctools-port>`__
    for the needed build tools. The procedure for building is quite
    peculiar and is described below.
 
@@ -138,8 +138,8 @@ way, with some additional arguments to provide the correct paths:
 
 ::
 
-    $ scons -j 4 platform=iphone bits=32 target=release_debug IPHONESDK=\"/path/to/iPhoneSDK\" IPHONEPATH=\"/path/to/iostoolchain\" ios_triple=\"arm-apple-darwin11-\"
-    $ scons -j 4 platform=iphone bits=64 target=release_debug IPHONESDK=\"/path/to/iPhoneSDK\" IPHONEPATH=\"/path/to/iostoolchain\" ios_triple=\"arm-apple-darwin11-\"
+    $ scons -j 4 platform=iphone bits=32 target=release_debug IPHONESDK="/path/to/iPhoneSDK" IPHONEPATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"
+    $ scons -j 4 platform=iphone bits=64 target=release_debug IPHONESDK="/path/to/iPhoneSDK" IPHONEPATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"
 
 Producing fat binaries
 ~~~~~~~~~~~~~~~~~~~~~~

advanced_topics/custom_modules_in_c++.rst

@@ -38,9 +38,9 @@ To create a new module, the first step is creating a directory inside
 modules. If you want to maintain the module separately, you can checkout
 a different VCS into modules and use it.
 
-The example module will be called \\"sumator\\", and is placed inside
-the Godot source tree (C:\\\\godot refers to wherever the Godot sources
-are located):
+The example module will be called "sumator", and is placed inside the
+Godot source tree (C:\\\\godot refers to wherever the Godot sources are
+located):
 
 ::
 
@@ -51,71 +51,65 @@ are located):
 
 Inside we will create a simple sumator class:
 
-| <pre class=\\"cpp\\">
-| /\* sumator.h \*/
-| #ifndef SUMATOR\_H
-| #define SUMATOR\_H
+.. code:: cpp
 
-#include "reference.h&quot;
+    /* sumator.h */
+    #ifndef SUMATOR_H
+    #define SUMATOR_H
 
-| class Sumator : public Reference {
-| OBJ\_TYPE(Sumator,Reference);
+    #include "reference.h"
 
-int count;
+    class Sumator : public Reference {
+        OBJ_TYPE(Sumator,Reference);
 
-| protected:
-| static void \_bind\_methods();
-| public:
+        int count;
 
-| void add(int value);
-| void reset();
-| int get\_total() const;
+    protected:
+        static void _bind_methods();
+    public:
 
-| Sumator();
-| };
+        void add(int value);
+        void reset();
+        int get_total() const;
 
-#endif
+        Sumator();
+    };
 
-.. raw:: html
-
-   </pre>
+    #endif
 
 And then the cpp file.
 
-| <pre class=\\"cpp\\">
-| /\* sumator.cpp \*/
-
-#include "sumator.h&quot;
+.. code:: cpp
 
-void Sumator::add(int value) {
+    /* sumator.cpp */
 
-| count+=value;
-| }
+    #include "sumator.h"
 
-void Sumator::reset() {
+    void Sumator::add(int value) {
 
-| count=0;
-| }
+        count+=value;
+    }
 
-int Sumator::get\_total() const {
+    void Sumator::reset() {
 
-| return count;
-| }
+        count=0;
+    }
 
-void Sumator::\_bind\_methods() {
+    int Sumator::get_total() const {
 
-| ObjectTypeDB::bind\_method("add&quot;,&Sumator::add);
-| ObjectTypeDB::bind\_method("reset&quot;,&Sumator::reset);
-| ObjectTypeDB::bind\_method("get\_total&quot;,&Sumator::get\_total);
-| }
+        return count;
+    }
 
-| Sumator::Sumator() {
-| count=0;
-| }
+    void Sumator::_bind_methods() {
 
-.. raw:: html
+        ObjectTypeDB::bind_method("add",&Sumator::add);
+        ObjectTypeDB::bind_method("reset",&Sumator::reset);
+        ObjectTypeDB::bind_method("get_total",&Sumator::get_total);
+    }
 
-   </pre>
+    Sumator::Sumator() {
+        count=0;
+    }
 
 Then, the new class needs to be registered somehow, so two more files
 need to be created:
@@ -127,69 +121,53 @@ need to be created:
 
 With the following contents
 
-| <pre class=\\"cpp\\">
-| /\* register\_types.h \*/
-
-| void register\_sumator\_types();
-| void unregister\_sumator\_types();
-| /\* yes, the word in the middle must be the same as the module folder
-  name \*/
+.. code:: cpp
 
-.. raw:: html
+    /* register_types.h */
 
-   </pre>
+    void register_sumator_types();
+    void unregister_sumator_types();
+    /* yes, the word in the middle must be the same as the module folder name */
 
-| <pre class=\\"cpp\\">
-| /\* register\_types.cpp \*/
+.. code:: cpp
 
-| #include "register\_types.h&quot;
-| #include "object\_type\_db.h&quot;
-| #include "sumator.h&quot;
+    /* register_types.cpp */
 
-void register\_sumator\_types() {
+    #include "register_types.h"
+    #include "object_type_db.h"
+    #include "sumator.h"
 
-| ObjectTypeDB::register\_type&lt;Sumator&gt;();
-| }
+    void register_sumator_types() {
 
-| void unregister\_sumator\_types() {
-| //nothing to do here
-| }
+            ObjectTypeDB::register_type<Sumator>();
+    }
 
-.. raw:: html
-
-   </pre>
+    void unregister_sumator_types() {
+       //nothing to do here
+    }
 
 Next, we need to create a SCsub so the build system compiles this
 module:
 
-<pre class=\\"python\\">
-
-#. SCsub
-   Import('env')
+.. code:: python
 
-env.add\_source\_files(env.modules\_sources,"\*.cpp&quot;) # just add
-all cpp files to the build
+    # SCsub
+    Import('env')
 
-.. raw:: html
-
-   </pre>
+    env.add_source_files(env.modules_sources,"*.cpp") # just add all cpp files to the build
 
 And finally, the configuration file for the module, this is a simple
 python script that must be named 'config.py'
 
-<pre class=\\"python\\">
-
-#. config.py
+.. code:: python
 
-| def can\_build(platform):
-| return True
+    # config.py
 
-| def configure(env):
-| pass
+    def can_build(platform):
+        return True  
 
-.. raw:: html
-
-   </pre>
+    def configure(env):
+        pass
 
 The module is asked if it's ok to build for the specific platform (in
 this case, True means it will build for every platform).
@@ -221,17 +199,14 @@ Using the module
 Using your newly created module is very easy, from any script you can
 do:
 
-| <pre class=\\"python\\">
-| var s = Sumator.new()
-| s.add(10)
-| s.add(20)
-| s.add(30)
-| print( s.get\_total() )
-| s.reset()
-
-.. raw:: html
+.. code:: python
 
-   </pre>
+    var s = Sumator.new()
+    s.add(10)
+    s.add(20)
+    s.add(30)
+    print( s.get_total() )
+    s.reset()
 
 And the output will be ``60``.
 
@@ -250,7 +225,7 @@ some surprises.
 
 -  If you inherit from [[API:Node]] (or any derived node type, such as
    Sprite), your new class will appear in the editor, in the inheritance
-   tree in the \\"Add Node\\" dialog.
+   tree in the "Add Node" dialog.
 -  If you inherit from [[API:Resource]], it will appear int the resource
    list, and all the exposed properties can be serialized when
    saved/loaded.

advanced_topics/introduction_to_the_buildsystem.rst

@@ -4,12 +4,12 @@ Introduction to the buildsystem
 Scons
 -----
 
-Godot uses \\\ `Scons\\ <http://www.scons.org>`__ to build. We love it,
-we are not changing it for anything else. We are not even sure other
-build systems are up to the task of building Godot. We constantly get
-requests to move the build system to CMake, or Visual Studio, but this
-is not going to happen. There are many reasons why we have chosen SCons
-over other alternatives and are listed as follows:
+Godot uses `Scons <http://www.scons.org>`__ to build. We love it, we are
+not changing it for anything else. We are not even sure other build
+systems are up to the task of building Godot. We constantly get requests
+to move the build system to CMake, or Visual Studio, but this is not
+going to happen. There are many reasons why we have chosen SCons over
+other alternatives and are listed as follows:
 
 -  Godot can be compiled for a dozen different platforms. All PC
    platforms, all mobile platforms, many consoles, and many web-based
@@ -149,9 +149,9 @@ Target controls optimization and debug flags. Each mode means:
 
     scons platform= target=debug/release_debug/release
 
-This flag appends \\".debug\\" suffix (for debug), or \\".tools\\" (for
-debug with tools enables). When optimization is enabled (release) it
-appends the \\".opt\\" suffix.
+This flag appends ".debug" suffix (for debug), or ".tools" (for debug
+with tools enables). When optimization is enabled (release) it appends
+the ".opt" suffix.
 
 Bits
 ----
@@ -171,8 +171,8 @@ else.
 
     scons platform= bits=default/32/64
 
-This flag appends \\".32\\" or \\".64\\" suffixes to resulting binaries
-when relevant.
+This flag appends ".32" or ".64" suffixes to resulting binaries when
+relevant.
 
 Export templates
 ----------------

advanced_topics/object_class.rst

@@ -6,33 +6,26 @@ inherit directly or indirectly from it. Objects provide reflection and
 editable properties, and declaring them is a matter of using a single
 macro like this.
 
-| <pre class=\\"cpp\\">
-| class CustomObject : public Object {
+.. code:: cpp
 
-| OBJ\_TYPE(CustomObject,Object); // this required to inherit
-| };
+    class CustomObject : public Object {
 
-.. raw:: html
-
-   </pre>
+        OBJ_TYPE(CustomObject,Object); // this required to inherit
+    };
 
 This makes objects gain a lot of functionality, like for example
 
-| <pre class=\\"cpp\\">
-| obj = memnew(CustomObject);
-| print\_line("Object Type: ",obj->get\_type()); //print object type
-
-obj2 = obj->cast\_to&lt;OtherType&gt;(); // converting between types,
-this also works without RTTI enabled.
+.. code:: cpp
 
-.. raw:: html
+    obj = memnew(CustomObject);
+    print_line("Object Type: ",obj->get_type()); //print object type
 
-   </pre>
+    obj2 = obj->cast_to<OtherType>(); // converting between types, this also works without RTTI enabled.
 
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/object.h\\ <https://github.com/okamstudio/godot/blob/master/core/object.h>`__
+-  `core/object.h <https://github.com/okamstudio/godot/blob/master/core/object.h>`__
 
 Registering an Object
 ---------------------
@@ -43,22 +36,18 @@ their methods properties and integer constants.
 
 Classes are registered by calling:
 
-<pre class=\\"cpp\\">ObjectTypeDB::register\_type()
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    ObjectTypeDB::register_type()
 
 Registering it will allow the type to be instanced by scripts, code, or
 creating them again when deserializing.
 
 Registering as virtual is the same but it can't be instanced.
 
-<pre class=\\"cpp\\">ObjectTypeDB::register\_virtual\_type()
+.. code:: cpp
 
-.. raw:: html
-
-   </pre>
+    ObjectTypeDB::register_virtual_type()
 
 Object derived classes can override a static function
 ``static void _bind_methods()``, when one class is registered, this
@@ -70,25 +59,18 @@ virtual automatically.
 Inside ``_bind_methods``, there are a couple of things that can be done.
 Registering functions is one:
 
-<pre
-class=\\"cpp\\">ObjectTypeDB::register\_method(\_MD (\\"methodname\\",\\"arg1name\\",\\"arg2name\\"),&MyCustethod);
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    ObjectTypeDB::register_method(_MD("methodname","arg1name","arg2name"),&MyCustethod);
 
 Default values for arguments can be passed in reverse order:
 
-<pre
-class=\\"cpp\\">ObjectTypeDB::register\_method(\_MD (\\"methodname\\",\\"arg1name\\",\\"arg2name\\"),&MyCustomType::method,DEFVAL (-1));
-//default argument for arg2name
+.. code:: cpp
 
-.. raw:: html
+    ObjectTypeDB::register_method(_MD("methodname","arg1name","arg2name"),&MyCustomType::method,DEFVAL(-1)); //default argument for arg2name
 
-   </pre>
-
-``_MD`` is a macro that convers \\"methodname\\" to a stringname for
-more efficiency. Argument names are used for instrospection, but when
+``_MD`` is a macro that convers "methodname" to a stringname for more
+efficiency. Argument names are used for instrospection, but when
 compiling on release, the macro ignores them, so the strings are unused
 and optimized away.
 
@@ -101,42 +83,33 @@ string passing the name can be passed for brevity.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/object\_type\_db.h\\ <https://github.com/okamstudio/godot/blob/master/core/object_type_db.h>`__
+-  `core/object\_type\_db.h <https://github.com/okamstudio/godot/blob/master/core/object_type_db.h>`__
 
 Constants
 ---------
 
 Classes often have enums such as:
 
-| <pre class=\\"cpp\\">
-| enum SomeMode {
-| MODE\_FIRST,
-| MODE\_SECOND
-| };
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    enum SomeMode {
+       MODE_FIRST,
+       MODE_SECOND
+    };
 
 For these to work when binding to methods, the enum must be declared
 convertible to int, for this a macro is provided:
 
-<pre class=\\"cpp\\">VARIANT\_ENUM\_CAST( MyClass::SomeMode); // now
-functions that take SomeMode can be bound.
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    VARIANT_ENUM_CAST( MyClass::SomeMode); // now functions that take SomeMode can be bound.
 
 The constants can also be bound inside ``_bind_methods``, by using:
 
-| <pre class=\\"cpp\\">
-| BIND\_CONSTANT( MODE\_FIRST );
-| BIND\_CONSTANT( MODE\_SECOND );
+.. code:: cpp
 
-.. raw:: html
-
-   </pre>
+    BIND_CONSTANT( MODE_FIRST );
+    BIND_CONSTANT( MODE_SECOND );
 
 Properties (set/get)
 --------------------
@@ -149,34 +122,25 @@ Objects export properties, properties are useful for the following:
 Properties are usually defined by the PropertyInfo() class. Usually
 constructed as:
 
-<pre
-class=\\"cpp\\">PropertyInfo(type,name,hint,hint\_string,usage\_flags)
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    PropertyInfo(type,name,hint,hint_string,usage_flags)
 
 For example:
 
-<pre
-class=\\"cpp\\">PropertyInfo(Variant::INT,\\"amount\\",PROPERTY\_HINT\_RANGE,\\"0,49,1\\",PROPERTY\_USAGE\_EDITOR)
+.. code:: cpp
 
-.. raw:: html
+    PropertyInfo(Variant::INT,"amount",PROPERTY_HINT_RANGE,"0,49,1",PROPERTY_USAGE_EDITOR)
 
-   </pre>
-
-This is an integer property, named \\"amount\\", hint is a range, range
-goes from 0 to 49 in steps of 1 (integers). It is only usable for the
-editor (edit value visually) but wont be serialized.
+This is an integer property, named "amount", hint is a range, range goes
+from 0 to 49 in steps of 1 (integers). It is only usable for the editor
+(edit value visually) but wont be serialized.
 
 or
 
-<pre
-class=\\"cpp\\">PropertyInfo(Variant::STRING,\\"modes\\",PROPERTY\_HINT\_ENUM,\\"Enabled,Disabled,Turbo\\")
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    PropertyInfo(Variant::STRING,"modes",PROPERTY_HINT_ENUM,"Enabled,Disabled,Turbo")
 
 This is a string property, can take any string but the editor will only
 allow the defined hint ones. Since no hint flags were specified, the
@@ -188,19 +152,15 @@ check.
 Properties can also work like C# properties and be accessed from script
 using indexing, but ths usage is generally discouraged, as using
 functions is preferred for legibility. Many properties are also bound
-with categories, such as \\"animation/frame\\" which also make indexing
+with categories, such as "animation/frame" which also make indexing
 imposssible unless using operator [].
 
 From ``_bind_methods()``, properties can be created and bound as long as
 a set/get functions exist. Example:
 
-<pre class=\\"cpp\\">ADD\_PROPERTY(
-PropertyInfo(Variant::INT,\\"amount\\"), \_SCS (\\"set\_amount\\"),
-\_SCS (\\"get\_amount\\") )
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    ADD_PROPERTY( PropertyInfo(Variant::INT,"amount"), _SCS("set_amount"), _SCS("get_amount") )
 
 This creates the property using the setter and the getter. ``_SCS`` is a
 macro that creates a StringName efficiently.
@@ -216,17 +176,11 @@ they are NOT virtual, DO NOT make them virtual, they are called for
 every override and the previous ones are not invalidated (multilevel
 call).
 
-| <pre class=\\"cpp\\">
-| void \_get\_property\_info(List \*r\_props); //return list of
-  propertes
-| bool \_get(const StringName& p\_property, Variany& r\_value) const;
-  //return true if property was found
-| bool \_set(const StringName& p\_property, const Variany& p\_value);
-  //return true if property was found
+.. code:: cpp
 
-.. raw:: html
-
-   </pre>
+    void _get_property_info(List *r_props); //return list of propertes
+    bool _get(const StringName& p_property, Variany& r_value) const; //return true if property was found
+    bool _set(const StringName& p_property, const Variany& p_value); //return true if property was found
 
 This is also a little less efficient since ``p_property`` must be
 compared against the desired names in serial order.
@@ -237,15 +191,12 @@ Dynamic casting
 Godot provides dynamic casting between Object Derived classes, for
 example:
 
-| <pre class=\\"cpp\\">
-| void somefunc(Object \*some\_obj) {
-
-| Button \* button = some\_obj->cast\_to&lt;Button&gt;();
-| }
+.. code:: cpp
 
-.. raw:: html
+    void somefunc(Object *some_obj) {
 
-   </pre>
+         Button * button = some_obj->cast_to<Button>();
+    }
 
 If cast fails, NULL is returned. This system uses RTTI, but it also
 works fine (although a bit slower) when RTTI is disabled. This is useful
@@ -258,14 +209,11 @@ Signals
 Objects can have a set of signals defined (similar to Delegates in other
 languages). Connecting to them is rather easy:
 
-| <pre class=\\"cpp\\">
-| obj->connect(,target\_instance,target\_method)
-| //for example
-| obj->connect(\\"enter\_tree\\",this,\\"\_node\_entered\_tree\\")
+.. code:: cpp
 
-.. raw:: html
-
-   </pre>
+    obj->connect(,target_instance,target_method)
+    //for example
+    obj->connect("enter_tree",this,"_node_entered_tree")
 
 The method ``_node_entered_tree`` must be registered to the class using
 ``ObjectTypeDB::register_method`` (explained before).
@@ -273,11 +221,9 @@ The method ``_node_entered_tree`` must be registered to the class using
 Adding signals to a class is done in ``_bind_methods``, using the
 ``ADD_SIGNAL`` macro, for example:
 
-<pre class=\\"cpp\\">ADD\_SIGNAL( MethodInfo(\\"been\_killed\\") )
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    ADD_SIGNAL( MethodInfo("been_killed") )
 
 References
 ----------
@@ -286,16 +232,13 @@ Reference inherits from Object and holds a reference count. It is the
 base for reference counted object types. Declaring them must be done
 using Ref<> template. For example.
 
-| <pre class=\\"cpp\\">
-| class MyReference: public Reference {
-| OBJ\_TYPE( MyReference ,Reference);
-| };
-
-Ref myref = memnew( MyReference );
+.. code:: cpp
 
-.. raw:: html
+    class MyReference: public Reference {
+        OBJ_TYPE( MyReference ,Reference);
+    };
 
-   </pre>
+    Ref myref = memnew( MyReference );
 
 ``myref`` is reference counted. It will be freed when no more Ref<>
 templates point to it.
@@ -303,7 +246,7 @@ templates point to it.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/reference.h\\ <https://github.com/okamstudio/godot/blob/master/core/reference.h>`__
+-  `core/reference.h <https://github.com/okamstudio/godot/blob/master/core/reference.h>`__
 
 Resources:
 ----------
@@ -319,19 +262,16 @@ Resources without a path are fine too.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/resource.h\\ <https://github.com/okamstudio/godot/blob/master/core/resource.h>`__
+-  `core/resource.h <https://github.com/okamstudio/godot/blob/master/core/resource.h>`__
 
 Resource loading
 ----------------
 
 Resources can be loaded with the ResourceLoader API, like this:
 
-<pre class=\\"cpp\\">Ref res =
-ResourceLoader::load(\\"res://someresource.res\\")
+.. code:: cpp
 
-.. raw:: html
-
-   </pre>
+    Ref res = ResourceLoader::load("res://someresource.res")
 
 If a reference to that resource has been loaded previously and is in
 memory, the resource loader will return that reference. This means that
@@ -343,27 +283,23 @@ the same time.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/io/resource\_loader.h\\ <https://github.com/okamstudio/godot/blob/master/core/io/resource_loader.h>`__
+-  `core/io/resource\_loader.h <https://github.com/okamstudio/godot/blob/master/core/io/resource_loader.h>`__
 
 Resource saving
 ---------------
 
 Saving a resource can be done with the resource saver API:
 
-<pre
-class=\\"cpp\\">ResourceSaver::save(\\"res://someresource.res\\",instance)
-
-.. raw:: html
+.. code:: cpp
 
-   </pre>
+    ResourceSaver::save("res://someresource.res",instance)
 
 Instance will be saved. Sub resources that have a path to a file will be
 saved as a reference to that resource. Sub resources without a path will
 be bundled with the saved resource and assigned sub-IDs, like
-\\"res://somereource.res::1\\". This also helps to cache them when
-loaded.
+"res://somereource.res::1". This also helps to cache them when loaded.
 
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/io/resource\_saver.h\\ <https://github.com/okamstudio/godot/blob/master/core/io/resource_saver.h>`__
+-  `core/io/resource\_saver.h <https://github.com/okamstudio/godot/blob/master/core/io/resource_saver.h>`__

advanced_topics/services_for_ios.rst

@@ -23,29 +23,24 @@ locally (no internet connection, API incorrectly configured, etc). If
 the error value is 'OK', a response event will be produced and added to
 the 'pending events' queue. Example:
 
-| <pre class=\\"python\\">
-| func on\_purchase\_pressed():
-| var result = InAppStore.purchase( { \\\ `product\_id\\ <>`__
-  \\"my\_product\\" } )
-| if result == OK:
-| animation.play(\\"busy\\") # show the \\"waiting for response\\"
-  animation
-| else:
-| show\_error()
-
-| # put this on a 1 second timer or something
-| func check\_events():
-| while InAppStore.get\_pending\_event\_count() > 0:
-| var event = InAppStore.pop\_pending\_event()
-| if event.type  \\"purchase\\":
-              if event.result  \\\ `ok\\ <>`__
-| show\_success(event.product\_id)
-| else:
-| show\_error()
-
-.. raw:: html
-
-   </pre>
+.. code:: python
+
+    func on_purchase_pressed():
+        var result = InAppStore.purchase( { "product_id": "my_product" } )
+        if result == OK:
+            animation.play("busy") # show the "waiting for response" animation
+        else:
+            show_error()
+
+    # put this on a 1 second timer or something
+    func check_events():
+        while InAppStore.get_pending_event_count() > 0:
+            var event = InAppStore.pop_pending_event()
+            if event.type == "purchase":
+                if event.result == "ok":
+                    show_success(event.product_id)
+                else:
+                    show_error()
 
 Remember that when a call returns OK, the API will *always* produce an
 event through the pending\_event interface, even if it's an error, or a
@@ -66,9 +61,9 @@ Store Kit
 
 Implemented in platform/iphone/in\_app\_store.mm
 
-The Store Kit API is accessible through the \\"InAppStore\\" singleton
-(will always be available from gdscript). It is initialized
-automatically. It has 2 methods for purchasing:
+The Store Kit API is accessible through the "InAppStore" singleton (will
+always be available from gdscript). It is initialized automatically. It
+has 2 methods for purchasing:
 
 -  ``Error purchase(Variant p_params);``
 -  ``Error request_product_info(Variant p_params);``
@@ -93,7 +88,7 @@ string with your product id. Example:
 
 ::
 
-    var result = InAppStore.purchase( { \"product_id\": \"my_product\" } )
+    var result = InAppStore.purchase( { "product_id": "my_product" } )
 
 Response event
 ^^^^^^^^^^^^^^
@@ -105,9 +100,9 @@ On error:
 ::
 
     {
-      \"type\": \"purchase\",
-      \"result\": \"error\",
-      \"product_id\": \"the product id requested\"
+      "type": "purchase",
+      "result": "error",
+      "product_id": "the product id requested"
     }
 
 On success:
@@ -115,9 +110,9 @@ On success:
 ::
 
     {
-      \"type\": \"purchase\",
-      \"result\": \"ok\",
-      \"product_id\": \"the product id requested\"
+      "type": "purchase",
+      "result": "ok",
+      "product_id": "the product id requested"
     }
 
 request\_product\_info
@@ -133,7 +128,7 @@ string array with a list of product ids. Example:
 
 ::
 
-    var result = InAppStore.request_product_info( { \"product_ids\": [\"my_product1\", \"my_product2\"] } )
+    var result = InAppStore.request_product_info( { "product_ids": ["my_product1", "my_product2"] } )
 
 Response event
 ^^^^^^^^^^^^^^
@@ -143,14 +138,14 @@ The response event will be a dictionary with the following fields:
 ::
 
     {
-      \"type\": \"product_info\",
-      \"result\": \"ok\",
-      \"invalid_ids\": [ list of requested ids that were invalid ],
-      \"ids\": [ list of ids that were valid ],
-      \"titles\": [ list of valid product titles (corresponds with list of valid ids) ],
-      \"descriptions\": [ list of valid product descriptions ] ,
-      \"prices\": [ list of valid product prices ],
-      \"localized_prices\": [ list of valid product localized prices ],
+      "type": "product_info",
+      "result": "ok",
+      "invalid_ids": [ list of requested ids that were invalid ],
+      "ids": [ list of ids that were valid ],
+      "titles": [ list of valid product titles (corresponds with list of valid ids) ],
+      "descriptions": [ list of valid product descriptions ] ,
+      "prices": [ list of valid product prices ],
+      "localized_prices": [ list of valid product localized prices ],
     }
 
 Game Center
@@ -158,8 +153,8 @@ Game Center
 
 Implemented in platform/iphone/game\_center.mm
 
-The Game Center API is available through the \\"GameCenter\\" singleton.
-It has 6 methods:
+The Game Center API is available through the "GameCenter" singleton. It
+has 6 methods:
 
 -  ``Error post_score(Variant p_score);``
 -  ``Erroraward_achievement(Variant p_params);``
@@ -187,7 +182,7 @@ Example:
 
 ::
 
-    var result = GameCenter.post_score( { \"value\": 100, \"category\": \"my_leaderboard\", } )
+    var result = GameCenter.post_score( { "value": 100, "category": "my_leaderboard", } )
 
 Response event
 ^^^^^^^^^^^^^^
@@ -199,10 +194,10 @@ On error:
 ::
 
     {
-      \"type\": \"post_score\",
-      \"result\": \"error\",
-      \"error_code\": the value from NSError::code,
-      \"error_description\": the value from NSError::localizedDescription,
+      "type": "post_score",
+      "result": "error",
+      "error_code": the value from NSError::code,
+      "error_description": the value from NSError::localizedDescription,
     }
 
 On success:
@@ -210,8 +205,8 @@ On success:
 ::
 
     {
-      \"type\": \"post_score\",
-      \"result\": \"ok\",
+      "type": "post_score",
+      "result": "ok",
     }
 
 award\_achievement
@@ -234,7 +229,7 @@ Example:
 
 ::
 
-    var result = award_achievement( { \"name\": \"hard_mode_completed\", \"progress\": 6.1 } )
+    var result = award_achievement( { "name": "hard_mode_completed", "progress": 6.1 } )
 
 Response event
 ^^^^^^^^^^^^^^
@@ -246,9 +241,9 @@ On error:
 ::
 
     {
-      \"type\": \"award_achievement\",
-      \"result\": \"error\",
-      \"error_code\": the error code taken from NSError::code,
+      "type": "award_achievement",
+      "result": "error",
+      "error_code": the error code taken from NSError::code,
     }
 
 On success:
@@ -256,8 +251,8 @@ On success:
 ::
 
     {
-      \"type\": \"award_achievement\",
-      \"result\": \"ok\",
+      "type": "award_achievement",
+      "result": "ok",
     }
 
 reset\_achievements
@@ -275,9 +270,9 @@ On error:
 ::
 
     {
-      \"type\": \"reset_achievements\",
-      \"result\": \"error\",
-      \"error_code\": the value from NSError::code
+      "type": "reset_achievements",
+      "result": "error",
+      "error_code": the value from NSError::code
     }
 
 On success:
@@ -285,8 +280,8 @@ On success:
 ::
 
     {
-      \"type\": \"reset_achievements\",
-      \"result\": \"ok\",
+      "type": "reset_achievements",
+      "result": "ok",
     }
 
 request\_achievements
@@ -305,9 +300,9 @@ On error:
 ::
 
     {
-      \"type\": \"achievements\",
-      \"result\": \"error\",
-      \"error_code\": the value from NSError::code
+      "type": "achievements",
+      "result": "error",
+      "error_code": the value from NSError::code
     }
 
 On success:
@@ -315,10 +310,10 @@ On success:
 ::
 
     {
-      \"type\": \"achievements\",
-      \"result\": \"ok\",
-      \"names\": [ list of the name of each achievement ],
-      \"progress\": [ list of the progress made on each achievement ]
+      "type": "achievements",
+      "result": "ok",
+      "names": [ list of the name of each achievement ],
+      "progress": [ list of the progress made on each achievement ]
     }
 
 request\_achievement\_descriptions
@@ -337,9 +332,9 @@ On error:
 ::
 
     {
-      \"type\": \"achievement_descriptions\",
-      \"result\": \"error\",
-      \"error_code\": the value from NSError::code
+      "type": "achievement_descriptions",
+      "result": "error",
+      "error_code": the value from NSError::code
     }
 
 On success:
@@ -347,15 +342,15 @@ On success:
 ::
 
     {
-      \"type\": \"achievement_descriptions\",
-      \"result\": \"ok\",
-      \"names\": [ list of the name of each achievement ],
-      \"titles\": [ list of the title of each achievement ]
-      \"unachieved_descriptions\": [ list of the description of each achievement when it is unachieved ]
-      \"achieved_descriptions\": [ list of the description of each achievement when it is achieved ]
-      \"maximum_points\": [ list of the points earned by completing each achievement ]
-      \"hidden\": [ list of booleans indicating whether each achievement is initially visible ]
-      \"replayable\": [ list of booleans indicating whether each achievement can be earned more than once ]
+      "type": "achievement_descriptions",
+      "result": "ok",
+      "names": [ list of the name of each achievement ],
+      "titles": [ list of the title of each achievement ]
+      "unachieved_descriptions": [ list of the description of each achievement when it is unachieved ]
+      "achieved_descriptions": [ list of the description of each achievement when it is achieved ]
+      "maximum_points": [ list of the points earned by completing each achievement ]
+      "hidden": [ list of booleans indicating whether each achievement is initially visible ]
+      "replayable": [ list of booleans indicating whether each achievement can be earned more than once ]
     }
 
 show\_game\_center
@@ -370,19 +365,19 @@ Parameters
 Takes a Dictionary as a parameter, with 2 fields:
 
 -  ``view`` (string) (optional) the name of the view to present. Accepts
-   \\"default\\", \\"leaderboards\\", \\"achievements\\", or
-   \\"challenges\\". Defaults to \\"default\\".
+   "default", "leaderboards", "achievements", or "challenges". Defaults
+   to "default".
 -  ``leaderboard_name`` (string) (optional) the name of the leaderboard
-   to present. Only used when \\"view\\" is \\"leaderboards\\" (or
-   \\"default\\" is configured to show leaderboards). If not specified,
-   Game Center will display the aggregate leaderboard.
+   to present. Only used when "view" is "leaderboards" (or "default" is
+   configured to show leaderboards). If not specified, Game Center will
+   display the aggregate leaderboard.
 
 Examples:
 
 ::
 
-    var result = show_game_center( { \"view\": \"leaderboards\", \"leaderboard_name\": \"best_time_leaderboard\" } )
-    var result = show_game_center( { \"view\": \"achievements\" } )
+    var result = show_game_center( { "view": "leaderboards", "leaderboard_name": "best_time_leaderboard" } )
+    var result = show_game_center( { "view": "achievements" } )
 
 Response event
 ^^^^^^^^^^^^^^
@@ -394,41 +389,37 @@ On close:
 ::
 
     {
-      \"type\": \"show_game_center\",
-      \"result\": \"ok\",
+      "type": "show_game_center",
+      "result": "ok",
     }
 
 Multi-platform games
 --------------------
 
 When working on a multi-platform game, you won't always have the
-\\"GameCenter\\" singleton available (for example when running on PC or
+"GameCenter" singleton available (for example when running on PC or
 Android). Because the gdscript compiler looks up the singletons at
 compile time, you can't just query the singletons to see and use what
 you need inside a conditional block, you need to also define them as
 valid identifiers (local variable or class member). This is an example
 of how to work around this in a class:
 
-| <pre class=\\"python\\">
-| var GameCenter = null # define it as a class member
+.. code:: python
 
-| func post\_score(p\_score):
-| if GameCenter == null:
-| return
-| GameCenter.post\_score( { \\\ `value\\ <>`__ p\_score,
-  \\\ `category\\ <>`__ \\"my\_leaderboard\\" } )
+    var GameCenter = null # define it as a class member
 
-| func check\_events():
-| while GameCenter.get\_pending\_event\_count() > 0:
-| # do something with events here
-| pass
+    func post_score(p_score):
+        if GameCenter == null:
+            return
+        GameCenter.post_score( { "value": p_score, "category": "my_leaderboard" } )
 
-| func \_ready():
-| # check if the singleton exists
-| if Globals.has\_singleton(\\"GameCenter\\"):
-| GameCenter = Globals.get\_singleton(\\"GameCenter\\")
-| # connect your timer here to the \\"check\_events\\" function
+    func check_events():
+        while GameCenter.get_pending_event_count() > 0:
+            # do something with events here
+            pass
 
-.. raw:: html
-
-   </pre>
+    func _ready():
+        # check if the singleton exists
+        if Globals.has_singleton("GameCenter"):
+            GameCenter = Globals.get_singleton("GameCenter")
+            # connect your timer here to the "check_events" function

advanced_topics/variant_class.rst

@@ -35,7 +35,7 @@ of c++ with little effort. Become a friend of Variant today.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/variant.h\\ <https://github.com/okamstudio/godot/blob/master/core/variant.h>`__
+-  `core/variant.h <https://github.com/okamstudio/godot/blob/master/core/variant.h>`__
 
 Dictionary and Array
 --------------------
@@ -56,5 +56,5 @@ desired.
 References:
 ~~~~~~~~~~~
 
--  \\\ `core/dictionary.h\\ <https://github.com/okamstudio/godot/blob/master/core/dictionary.h>`__
--  \\\ `core/array.h\\ <https://github.com/okamstudio/godot/blob/master/core/array.h>`__
+-  `core/dictionary.h <https://github.com/okamstudio/godot/blob/master/core/dictionary.h>`__
+-  `core/array.h <https://github.com/okamstudio/godot/blob/master/core/array.h>`__

asset_pipeline/export.rst

@@ -0,0 +1,17 @@
+Export
+======
+
+.. toctree::
+   :maxdepth: 1
+   :name: export
+
+   exporting_projects
+   one-click_deploy
+   exporting_images
+   exporting_for_pc
+   exporting_for_android
+   exporting_for_ios
+.. exporting_for_bb10
+.. exporting_for_nacl
+.. exporting_for_html5
+.. exporting_for_consoles

asset_pipeline/exporting_for_android.rst

@@ -0,0 +1,63 @@
+Exporting for Android
+=====================
+
+Exporting for android has much less requirements than compiling Godot
+for it. As follows are the steps to setup the SDK and the engine.
+
+Download the Android SDK
+------------------------
+
+Download and install the Android SDK from
+http://developer.android.com/sdk/index.html
+
+Download the Java 6 or OpenJDK6
+-------------------------------
+
+Download and install Java 6 or OpenJDK 6, Android needs this version and
+it seems that jarsigner (what is used to sign APKs) from greater
+versions do not work.
+
+Create a debug.keystore
+-----------------------
+
+Android needs a debug keystore file to install to devices and distribute
+non-release APKs. If you have used the SDK before and have built
+projects, ant or eclipse probably generated one for you (In Linux and
+OSX, you can find it in the ~/.android folder).
+
+If you can't find it or need to generate one, the keytool command from
+the JDK can be used for this purpose:
+
+keytool -keyalg RSA -genkeypair -alias androiddebugkey -keypass android
+-keystore debug.keystore -storepass android -dname "CN=Android
+Debug,O=Android,C=US" -validity 9999
+
+Make sure you have adb
+----------------------
+
+ADB is the command line tool used to communicate with Android devices.
+It's installed with the SDK, but you may need to install one (any) of
+the Android API levels for it to be installed in the SDK directory.
+
+Setting it up in Godot
+----------------------
+
+Enter the Editor Settings screen. This screens contains the editor
+settings for the user account in the computer (It's independent from the
+project).
+
+.. image:: /img/editorsettings.png
+
+Scroll down to the section where the Android settings are located:
+
+.. image:: /img/androidsdk.png
+
+In that screen, the path to 3 files needs to be set:
+
+-  The *adb* executable (adb.exe on Windows)
+-  The *jarsigner* executable (from JDK6)
+-  The debug *keystore*
+
+Once that is configured, everything is ready to export to Android!
+
+

asset_pipeline/exporting_for_ios.rst

@@ -0,0 +1,76 @@
+Exporting for iOS
+=================
+
+Exporting for iOS is done manually at the moment. These are the steps to
+load your game in an XCode project, where you can deploy to a device,
+publish, etc.
+
+Requirements
+------------
+
+-  Download XCode for iOS
+-  Download the export templates:
+   http://www.godotengine.org/projects/godot-engine/documents
+-  Since there is no automatic deployer yet, unzip export\_templates.tpz
+   manually and extract GodotiOSXCode.zip from it.
+
+The zip contains an XCode project, godot\_ios.xcodeproj, an empty
+data.pck file and the engine executable. Open the project, and modify
+the game name, icon, organization, provisioning signing certificate
+identities (??), etc.
+
+Add your project data
+---------------------
+
+Using the Godot editor, [[Exporting\_for\_pc\|export your project for
+Windows]], to obtain the data.pck file. Replace the empty data.pck in
+the XCode project with the new one, and run/archive.
+
+If you want to test your scenes on the iOS device as you edit them, you
+can add your game directory to the project (instead of data.pck), and
+add a property "godot\_path" to Info.plist, with the name of your
+directory as its value.
+
+.. image:: /img/godot_path.png
+
+Alternatively you can add all the files from your game directly, with
+"engine.cfg" at the root.
+
+Loading files from a host
+-------------------------
+
+Sometimes your game becomes too big and deploying to the device takes
+too long every time you run. In that case you can deploy only the engine
+executable, and serve the game files from your computer.
+
+Setting up the file host
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+On your PC, open the editor, and click the righ-most icon on the
+top-center group of icons, and select "Enable File Server". The icon
+turns red. Your PC will open a port and accept connections to serve
+files from your project's directory (so enable your local firewall
+accordingly).
+
+.. image:: /img/rfs_server.png
+
+Setting up the game
+~~~~~~~~~~~~~~~~~~~
+
+On XCode, click on your app name (top left, next to the "Stop" button),
+and select "Edit Scheme". Go to the "Arguments" tab, and add 2
+arguments, "-rfs" and the IP of your PC.
+
+.. image:: /img/edit_scheme.png
+
+When you run, your device will connect to the host and open the files
+remotely. Note that the directory with the game data ("platformer") is
+no longer added to the project, only the engine executable.
+
+Services for iOS
+----------------
+
+Special iOS services can be used in Godot. Check out the [[Services for
+iOS]] page.
+
+

asset_pipeline/exporting_for_pc.rst

@@ -0,0 +1,15 @@
+Exporting for PC
+================
+
+The simplest way to distribute a game for PC is to copy the executables
+(godot.exe on windows, godot on the rest), zip the folder and send it to
+someone else. However, this is often not desired.
+
+Godot offers a more elegant approach for PC distribution when using the
+export system. When exporting for PC (Linux, Windows, Mac), the exporter
+takes all the project files and creates a "data.pck" file. This file is
+bundled with a specially optimized binary that is smaller, faster and
+lacks tools and debugger.
+
+Optionally, the files can be bundled inside the executable, though this
+does not always works properly.

asset_pipeline/exporting_images.rst

@@ -0,0 +1,67 @@
+Exporting images
+================
+
+It is often desired to do an operation to all or a group of images upon
+export. Godot provides some tools for this. Examples of such operations
+are:
+
+-  Converting all images from a lossless format to a lossy one (ie: png
+   -> web) for greater compression.
+-  Shrinking all images to half the size, to create a low resolution
+   build for smaller screens.
+-  Create an atlas for a group of images and crop them, for higher
+   performance and less memory usage.
+
+Image Export Options
+--------------------
+
+In the `Export Dialog <export>`__, go to the Images tab:
+
+.. image:: /img/exportimages.png
+
+In this dialog the image extensions for conversion can be selected, and
+operations can be performed that apply to all images (except those in
+groups -next section for that-):
+
+-  **Convert Image Format**: Probably the most useful operation is to
+   convert to Lossy (WebP) to save disk space. For lossy, a Quality bar
+   can set the quality/vs size ratio.
+-  **Shrink**: This allows to shrink all images by a given amount. It's
+   useful to export a game to half or less resolution for special
+   devices.
+-  **Compress Formats**: Allows to select which image exensions to
+   convert.
+
+On export, Godot will perform the desired operation. The first export
+might be really slow, but subsequent exports will be fast, as the
+converted images will be cached.
+
+Image Group Export Options
+--------------------------
+
+This section is similar to the previous one, except it can operate on a
+selected group of images. When a image is in a group, the settings from
+the global export options are overridden by the ones from the group. An
+image can only be in one group at the same time. So if the image is in
+another group different to the current one being edited, it will not be
+selectable.
+
+.. image:: /img/imagegroup.png
+
+Atlas
+~~~~~
+
+As a plus, an atlas can be created from a group. When this mode is
+active, a button to preview the resulting atlas becomes available. Make
+sure that atlases don't become too big, as some hardware will not
+support textures bigger than 2048x2048 pixels. If this happens, just
+create another atlas.
+
+The atlas can be useful to speed up drawing of some scenes, as state
+changes are minimized when drawing from it (through unlike other
+engines, Godot is designed so state changes do not affect it as much).
+Textures added to an atlas get cropped (empty spaces around the image
+are removed), so this is another reason to use them (save space). If
+unsure, though, just leave that option disabled.
+
+

asset_pipeline/exporting_projects.rst

@@ -0,0 +1,127 @@
+Exporting projects
+==================
+
+Why Exporting?
+--------------
+
+Originally, Godot did not have any means to export projects. The
+developers would compile the proper binaries and build the packages for
+each platform manually.
+
+When more developers (and even non-programmers) started using it, and
+when our company started taking more projects at the same time, it
+became evident that this was a bottleneck.
+
+On PC
+~~~~~
+
+Distributing a game project on PC with Godot is rather easy. Just drop
+the godot.exe (or godot) binary together in the same place as the
+engine.cfg file, zip it and you are done. This can be taken advantage to
+make custom installers.
+
+It sounds simple, but there are probably a few reasons why the developer
+may not want to do this. The first one is that it may not be desirable
+to distribute loads of files. Some developers may not like curious users
+peeking at how the game was made, others may just find it inelegant,
+etc.
+
+Another reason is that, for distribution, the developer might use a
+specially compiled binary, which is smaller in size, more optimized and
+does not include tools inside (like the editor, debugger, etc).
+
+Finally, Godot has a simple but efficient system for creating DLCs as
+extra package files.
+
+On Mobile
+~~~~~~~~~
+
+The same scenario in mobile is a little worse. To distribute a project
+in those devices, a binary for each of those platforms is built, then
+added to a native project together with the game data.
+
+This can be troublesome because it means that the developer must be
+familiarized with the SDK of each platform before even being able to
+export. In other words, while learning each SDK is always encouraged, it
+can be frustrating to be forced to do it at an undesired time.
+
+There is also another problem with this approach, which is the fact that
+different devices prefer some data in different formats to run. The main
+example of this is texture compression. All PC hardware uses S3TC (BC)
+compression and that has been standardized for more than a decade, but
+mobile devices use different formats for texture compression, such as
+PVRCT (iOS) or ETC (Android)
+
+Export Dialog
+-------------
+
+After many attempts at different export workflows, the current one has
+worked the best. At the time of this writing, not all platforms are
+supported yet, but that will change soon.
+
+To open the export dialog, just click the "Export" Button:
+
+.. image:: /img/export.png
+
+The dialog will open, showing all the supported export platforms:
+
+.. image:: /img/export_dialog.png
+
+The default options are often enough to export, so tweaking them is not
+necessary until it's needed. However, many platforms require additional
+tools (SDKs) to be installed to be able to export. Additionally, Godot
+needs exports templates installed to create packages. The export dialog
+will complain when something is missing and will not allow the user to
+export for that platform until he or she resolves it:
+
+.. image:: /img/export_error.png
+
+At that time, the user is expected to come back to the wiki and follow
+instructions on how to properly set up that platform.
+
+Export Templates
+~~~~~~~~~~~~~~~~
+
+Apart from setting up the platform, the export templates must be
+installed to be able to export projects. They can be downloaded as a
+.tpz (a renamed .zip) file from the wiki.
+
+Once downloaded, they can be installed using the "Install Export
+Templates" option in the editor:
+
+.. image:: /img/exptemp.png
+
+Export Mode
+~~~~~~~~~~~
+
+When exporting, Godot makes a list of all the files to export and then
+creates the package. There are 3 different modes for exporting:
+
+-  Export every single file in the project
+-  Export only resources (+custom filter), this is default.
+-  Export only selected resources (+custom filter)
+
+.. image:: /img/expres.png
+
+-  **Export every single file** - This mode exports every single file in
+   the project. This is good to test if something is being forgotten,
+   but developers often have a lot of unrelated stuff around in the dev
+   dir, which makes it a bad idea.
+
+-  **Export only resources** - Only resources are exported. For most
+   projects, this is enough. However many developers like to use custom
+   datafiles in their games. To compensate for this, filters can be
+   added for extra extensions (like, *.txt,*.csv, etc).
+
+-  **Export only selected resources** - Only select resources from a
+   list are exported. This is probably overkill for most projects, but
+   in some cases it is justified (usually huge projects). This mode
+   offers total control of what is exported. Individual resources can be
+   selected and dependency detection is performed to ensure that
+   everything needed is added. As a plus, this mode allows to
+   "Bundle" scenes and dependencies into a single file, which is
+   *really* useful for games distributed on optical media.
+
+.. image:: /img/expselected.png
+
+

asset_pipeline/general.rst

@@ -4,5 +4,5 @@ General
 .. toctree::
    :maxdepth: 1
    :name: general
-   
+
    managing_image_files

asset_pipeline/import.rst

@@ -0,0 +1,14 @@
+Import
+======
+
+.. toctree::
+   :maxdepth: 1
+   :name: import
+
+   import_process
+   importing_textures
+   importing_3d_meshes
+   importing_3d_scenes
+   importing_fonts
+   importing_audio_samples
+   importing_translations

asset_pipeline/import_process.rst

@@ -0,0 +1,166 @@
+Import process
+==============
+
+What is it for?
+---------------
+
+When Godot was created, it was probably after several failed and not so
+failed engine attempts (well, each attempt failed a little less.. and so
+on). One of the most difficult areas of creating game engines is
+managing the import process. That means, getting the assets that artists
+make into the game, in a way that functions optimally.
+
+Artists use certain tools and formats, and programmers would rather have
+their data into a different format. This is because artists put their
+focus on creating assets with the best quality possible, while
+programmers have to make sure they actually run at decent speed (or run
+at all), use a certain amount of memory, and don't take ages loading
+from disk.
+
+One would think that just writing a converter/importer would be enough,
+but this is not all there is to it. The same way programmers iterate
+several times over their code, artists keep making changes to their
+assets. This generates some bottleneck, because *someone* has to keep
+re-importing that artwork right? And importing assets is often something
+that has to be agreed by both parties, as the programmer needs to decide
+how the artwork is imported and the artists needs to see how it looks.
+
+The goal to establishing an import process is that both can agree on how
+the rules under which the assets are going to be imported the first
+time, and the system will apply those rules automatically each time the
+asset is re-imported.
+
+Godot does not do the re-import process automatically, though. It gives
+the team the option to do it at any time ( a red icon on the top right
+of the screen, allows the ability to do it at any desired time).
+
+Does it always work?
+--------------------
+
+The aim of the import system is that it works well enough for most
+common cases and projects. What is there has been tested and seems to
+cover most needs.
+
+However, as mentioned before, this is on of the most difficult areas of
+writing a game engine. It may happen often (specially on large projects,
+ports, or projects with unusual requirement) that what is provided is
+not enough. It's easy to say that the engine is open source and that the
+programmer should make their own if they don't like what is there, but
+that would be making a huge disservice to the users and not the right
+attitude. Because of that, we made sure to provide as many tools and
+helpers as possible to support a custom import process, for example:
+
+-  Access to the internals of almost all data structures is provided to
+   the scripting and C++ API, as well as saving and loading in all
+   supported file formats.
+-  Some importers (like the 3D asset importer) support scripts to modify
+   the data being imported.
+-  Support for creating custom import plugins is also provided, even for
+   replacing the existing ones.
+-  If all else fails, Godot supports for adding custom resource loaders,
+   to load data in alternative formats, without intermediate conversion.
+
+Both the import system and the custom tools provided will improve over
+time as more use cases are revealed to us.
+
+Importing assets
+----------------
+
+Source asset location
+~~~~~~~~~~~~~~~~~~~~~
+
+To begin, it is a good idea to define where the original assets created
+by the artists (before they are imported) will be located. Normally,
+Godot does not mind much about the location, but if the project has
+several developers, it is a good idea to understand the simple rule for
+it to work for everyone.
+
+First of all, it would be really good for this location to **not** be
+inside the project path (where engine.cfg is located, or any
+sub-folder). Godot expects regular resources in there, and may consider
+many of the files used as source art as regular resources. This would
+lead to it bundling all of them when the project is exported, something
+which is undesired.
+
+Now that it is clear that this location must be outside the project
+folder, the rule that Godot uses to reference external assets can be
+explained. When an asset is imported, the engine stores a relative path
+from the project path to the asset (In windows, this works as long as
+they are on the same drive, otherwise an absolute path is stored). This
+ensures that the same asset can be re-imported in another computer.
+
+The usual approach to this, when using a VCS such as Subversion,
+Perforce or GIT, is to create the project in a subfolder, so both it and
+the source assets can be commited to a same repository. For example:
+
+Repository layout:
+
+::
+
+    source_assets/sfx/explosion.wav
+    source_assets/sfx/crash.wav
+    source_assets/fonts/myfont.ttf
+    source_assets/translation/strings.csv
+    source_assets/art/niceart.psd
+    game/engine.cfg
+
+In the above example, artists, musican, translators, etc. can work in
+the source\_assets/ folder, then import the assets to the game/ folder.
+When the repository is updated, anyone can re-import the assets if they
+changed.
+
+Import dialogs
+~~~~~~~~~~~~~~
+
+Godot provides for importing several types of assets, all of them can be
+accessed from the import dialog:
+
+.. image:: /img/import.png
+
+Each of the dialog shares a similar function, a source file (or several
+of them) must be provided, as well as a target destination inside the
+project folders. Once imported, Godot saves this information as metadata
+in the imported asset itself.
+
+.. image:: /img/importdialogs.png
+
+More information about each specific type of asset can be found in
+specific sections, such as `Importing Textures <import_textures>`__.
+
+Tracking changes and re-importing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Godot tracks changes in the source assets constantly. If at least one
+asset has been found to be modified (md5 is different than when it was
+imported), a small red indicator will appear in the top right corner of
+the screen.
+
+.. image:: /img/changes.png
+
+| From that moment onward, the user can choose to re-import at any given
+  time by clicking on the red-icon. When this action is done, a dialog
+  will pop-up showing which resources can be re-imported (all selected
+  by default).
+| Accepting that dialog will immediately re-import the resources and
+  will update any of them currently in use in the editor (like a
+  texture, model or audio file).
+
+.. image:: /img/changed.png
+
+Manually re-importing
+~~~~~~~~~~~~~~~~~~~~~
+
+The re-import process is automatic, but it may be desired at some point
+to change the settings of an already imported file, so it can be
+re-imported differently. For this, the Import Settings window is
+provided.
+
+.. image:: /img/isettings.png
+
+This screen allows the user to re-open the corresponding import-window
+to re-import that asset again, with the ability to change any of the
+settings.
+
+.. image:: /img/reimported.png
+
+

asset_pipeline/importing_3d_meshes.rst

@@ -0,0 +1,60 @@
+Importing 3D meshes
+===================
+
+Introduction
+------------
+
+Godot supports a flexible and powerful [[3D Scene importer]], that
+allows for full scene importing. For a lot of artists and developers
+this is more than enough. However, many do not like this workflow as
+much and prefer to import individual 3D Meshes and build the scenes
+inside the Godot 3D editor themselves. (Note that for more advanced
+features such as skeletal animation, there is no option to the 3D Scene
+Importer).
+
+The 3D mesh import workflow is simple and works using the OBJ file
+format. The imported meshes result in a .msh binary file which the user
+can put into a [[API:MeshInstance]], which in turn can be placed
+somewhere in the edited scene.
+
+Importing
+---------
+
+Importing is done through the Import 3D Mesh menu:
+
+.. image:: /img/mesh_import.png
+
+Which opens the Mesh import window:
+
+.. image:: /img/mesh_dialog.png
+
+This dialog allows the import of one more more OBJ files into a target
+path. OBJ files are converted to .msh files. Files are imported without
+any material on them, material has to be added by the user (see the
+[[Fixed materials]] tutorial). If the external OBJ file is changed it
+will be re-imported, while keeping the newly assigned material.
+
+Options
+-------
+
+A few options are present. Normals is needed for regular shading, while
+Tangents is needed if you plan to use normal-mapping on the material. In
+general, OBJ files describe how to be shaded very well, but an option to
+force smooth shading is available.
+
+Finally, there is an option to weld vertices. Given OBJ files are
+text-based, it is common to find some of these with vertices that do not
+mach, which results in strange shading. The weld vertices option merges
+vertices that are too close to keep proper smooth shading.
+
+Usage
+-----
+
+Mesh resources (what this importer imports) are used inside MeshInstance
+nodes. Simply set them to the Mesh property of them.
+
+.. image:: /img/3dmesh_instance.png
+
+And that is it.
+
+

asset_pipeline/importing_3d_scenes.rst

@@ -0,0 +1,411 @@
+Importing 3D scenes
+===================
+
+Introduction
+------------
+
+Most game engines just import 3D objects, which may contain skeletons or
+animations and then all further work is done in the engine UI, like
+object placement, full scene animations, etc. In Godot, given the node
+system is very similar to how 3D DCC (Such as Maya, 3DS Max or Blender)
+tools work, full 3D scenes can be imported in all their glory.
+Additionally, by using a simple language tag system, it is possible to
+specify that objects are imported as several things, such as collidable,
+rooms and portals, vehicles and wheels, LOD distances, billboards, etc.
+
+This allows for some interesting features:
+
+-  Importing simple scenes, rigged objects, animations, etc.
+-  Importing full scenes. Entire scenarios can be created and updated in
+   the 3D DCC and imported to Godot each time they change, then only
+   little editing is needed from the engine side.
+-  Full cutscenes can be imported, including multiple character
+   animation, lighting, camera motion, etc.
+-  Scenes can be further edited and scripted in the engine, where
+   shaders and environment effects can be added, enemies can be
+   instanced, etc. The importer will update geometry changes if the
+   source scene changes but keep the local changes too (in real-time
+   while using the Godot editor!)
+-  Textures can be all batch-imported and updated when the source scene
+   changes.
+
+This is achieved by using a very simple language tag that will be
+explained in detail later.
+
+Exporting DAE files
+-------------------
+
+Why not FBX?
+~~~~~~~~~~~~
+
+Most game engines use the FBX format for importing 3D scenes, which is
+definitely one of the most standardized in the industry. However, this
+format requires the use of a closed library from Autodesk which is
+distributed with a more restrictive licensing terms than Godot. The plan
+is, sometime in the future, to implement an external conversion binary,
+but meanwhile FBX is not really supported.
+
+Exporting DAE files from Maya and 3DS Max
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Autodesk added built-in collada support to Maya and 3DS Max, but It's
+really broken and should not be used. The best way to export this format
+is by using the
+`OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`__
+plugins. They work really well, although they are not always up-to date
+with the latest version of the software.
+
+Exporting DAE files from Blender
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+| Blender also has built-in collada support, but It's really broken and
+  should not be used either.
+| Godot provides a `Python
+  Plugin <https://github.com/okamstudio/godot/tree/master/tools/export/blender25>`__
+  that will do a much better job at exporting the scenes.
+
+The import process
+------------------
+
+Import process begins with the 3D scene import menu:
+
+.. image:: /img/3dimp_menu.png
+
+That opens what is probably the biggest of all the import dialogs:
+
+| p=. |image1|
+| Many options exist in there, so each section will be explained as
+  follows:
+
+Source & target paths
+---------------------
+
+| To import, two options are needed. The first is a source .dae file
+  (.dae stands for Collada. More import formats will eventually added,
+  but Collada is the most complete open format as of this writing).
+| A target folder needs to be provided, so the importer can import the
+  scene there. The imported scene will have the same filename as the
+  source one, except for the .scn extension, so make sure you pick good
+  names when you export!
+
+The textures will be copied and converted. Textures in 3D applications
+are usually just PNG or JPG files. Godot will convert them to video
+memory texture compression format (s3tc, pvrtc, ericsson, etc) by
+default to improve performance and save resources.
+
+Since the original textures, 3d file and textues are usually not needed,
+it's recommended you keep them outside the project. For some hints on
+how to do this the best way, you can check the [[Version control &
+Project organization]] tutorial.
+
+Two options for textures are provided. They can be copied to the same
+place as the scene, or they can be copied to a common path (configurable
+in the project settings). If you choose this, make sure no two textures
+are names the same.
+
+3D rigging tips
+---------------
+
+Before going into the options, here are some tips for making sure your
+rigs import properly
+
+-  Only up to 4 weights are imported per vertex, if a vertex depends of
+   more than 4 bones, only the 4 most important bones (the one with the
+   most weight) will be imported. For most models this usually works
+   fine, but just keep it in mind.
+-  Do not use non-uniform scale in bone animation, as this will likely
+   not import properly. Try to accomplish the same effect with more
+   bones.
+-  When exporting from Blender, make sure that objects modified by a
+   skeleton are children of it. Many objects can be modified by a single
+   skeleton, but they all should be direct children.
+-  The same way, when using Blender, make sure that the relative
+   transform of children nodes to the skeleton is zero (no rotation, no
+   translation, no scale. All zero and scale at 1.0). The position of
+   both objects (the little orange dot) should be at the same place.
+
+3D import options
+-----------------
+
+This section contains many options to change the way import workflow
+works. Some (like HDR) will be better explained in other sections, but
+in general a pattern can be visible in the options and that is, many of
+the options end with "-something". For example:
+
+-  Remove Nodes (-noimp)
+-  Set Alpha in Materials (-alpha)
+-  Create Collisions (-col).
+
+This means that the object names in the 3D DCC need to have those
+options appended at the end for the importer to tell what they are. When
+imported, Godot will convert them to what they are meant to be.
+
+**Note:** Maya users must use “\_" (underscore) instead of "-" (minus).
+
+Here is an example of how a scene in the 3D dcc looks (using blender),
+and how it is imported to Godot:
+
+.. image:: /img/3dimp_blender.png
+
+Notice that:
+
+-  The camera was imported normally.
+-  A Room was created (-room).
+-  A Portal was created (-portal).
+-  The Mesh got static collision added (-col).
+-  The Light was not imported (-noimp).
+
+Options in detail
+-----------------
+
+Following is a list of most import options and what they do in more
+detail.
+
+Remove nodes (-noimp)
+^^^^^^^^^^^^^^^^^^^^^
+
+Node names that have this at the end will be removed at import time, mo
+matter their type. Erasing them afterwards is most of the times
+pointless because the will be restored if the source scene changes.
+
+Import animations
+^^^^^^^^^^^^^^^^^
+
+Some scene formats (.dae) support one or more animations. If this is
+checked, an `AnimationPlayer <class_animationplayer>`__ node will be
+created, containing the animations.
+
+Compress geometry
+^^^^^^^^^^^^^^^^^
+
+This option (disabled [STRIKEOUT:or more like, always enabled] at the
+moment at the time of writing this) will compress geometry so it takes
+less space and renders faster (at the cost of less precision).
+
+Force generation of tangent arrays
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The importer detects when you have used a normalmap texture, or when the
+source file contains tangent/binormal information. These arrays are
+needed for normalmapping to work, and most exporters know what they do
+when they export this. However, it might be possible to run into source
+scenes that do not have this information which, as a result, make
+normal-mapping not work. If you notice that normal-maps do not work when
+importing the scene, turn this on!
+
+SRGB -> linear of diffuse textures
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When rendering using HDR (High Dynamic Range) it might be desirable to
+use linear-space textures to achieve a more real-life lighting.
+Otherwise, colors may saturate and contrast too much when exposure
+changes. This option must be used together with the SRGB option in
+`WorldEnvironment <class_worldenvironment>`__. The texture import
+options also have the option to do this conversion, but if this one is
+turned on, conversion will always be done to diffuse textures (usually
+what is desired). For more information, read the [[HDR]].
+
+Set alpha in materials (-alpha)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When working with most 3D dccs, its pretty obvious when a texture is
+transparent and has opacity and this rarely affects the workflow or
+final rendering. However, when dealing with real-time rendering,
+materials with alpha blending are usually less optimal to draw, so they
+must be explicitly marked as such.
+
+Originally Godot detected this based on whether if the source texture
+had an alpha channel, but most image manipulation apps like Photoshop or
+Gimp will export this channel anyway even if not used. Code was added
+later to check manually if there really was any transparency in the
+texture, but artists will anyway and very often lay uvmaps into opaque
+parts of a texture and leave unused areas (where no UV exists)
+transparent, making this detection worthless.
+
+Finally, it was decided that it's best to import everything as opaque
+and leave artists to fix materials that need transparency when it's
+obvious that they are not looking right (see the [Fixed Ma
+
+As a helper, since every 3D dcc allows naming the materials and keeping
+their name upon export, the (-alpha) modifier in their name will hint
+the 3D scene importer in Godot that this material will use the alpha
+channel for transparency.
+
+Set vert. color in materials (-vcol)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most 3D DCCs support vertex color painting. This is generally applied as
+multiplication or screen blending. However, it is also often the case
+that your exporter will export this information as all 1s, or export it
+as something else and you will not realize it. Since most of the cases
+this option is not desired, just add this to any material to confirm
+that vertex colors are desired.
+
+Create collisions (-col, -colonly)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These will only work for Mesh nodes, If the "-col" option is detected, a
+child static collision node will be added, using the same geometry as
+the mesh.
+
+However, it is often the case that the visual geometry is too complex or
+too un-smooth for collisions, which end up not working well. To solve
+this, the "-colonly" modifier exists, which will remove the mesh upon
+import and create a `StaticBody <class_staticbody>`__ collision instead.
+This helps the visual mesh and actual collision to be separated.
+
+Create rooms (-room)
+^^^^^^^^^^^^^^^^^^^^
+
+This is used to create a room. As a general rule, any node that is a
+child of this node will be considered inside the room (including
+portals). For more information about rooms/portals, look at the
+[[Portals and Rooms]] tutorial.
+
+There are two ways in which this modifier can be used. The first is
+using a Dummy/Empty node in the 3D app with the "-room" tag. For this to
+work, the "interior" of the room must be closed (geometry of the
+childrens should contain walls, roof, floor, etc and the only holes to
+the outside should be covered with portals). The importer will then
+create a simplified version of the geometry for the room.
+
+The second way is to use the "-room" modifier on a mesh node. This will
+use the mesh as the base for the BSP tree that contains the room bounds.
+Make sure that the mesh shape is **closed**, all normals **point
+outside** and that the geometry is **not self-intersecting**, otherwise
+the bounds may be computed wrong (BSP Trees are too picky and difficult
+to work with, which is why they are barely used anymore..).
+
+Anyway, the room will need portals, which are described next.
+
+Create portals (-portal)
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Portals are the view to look outside a room. They are always some flat
+shape on the surface of a room. If the portal is left alone, it is used
+to activate occlusion when looking inside<->outside the room. Again,
+more information on the [[Portals and Rooms]] tutorial.
+
+Basically, the conditions to make and import a portal from the 3D DCC
+are:
+
+-  It should be a child of a room.
+-  It should lay on the surface of the room (this doesn't need to be
+   super exact, just make it as close as you can by eye and Godot will
+   adjust it)
+-  It must be a flat, convex shape, any flat and convex shape is ok, no
+   matter the axis or size.
+-  Normals for the flat shape faces must **all point towards the
+   OUTSIDE** of the room.
+
+Here is how it usually looks:
+
+.. image:: /img/3dimp_portal.png
+
+To connect to rooms, simply make two identical portals for both rooms
+and place them overlapped. This does not need to be perfectly exact,
+again, as Godot will fix it.
+
+[..]
+^^^^
+
+The rest of the tags in this section should be rather obvious, or will
+be documented/changed in the future.
+
+Double-sidedness
+----------------
+
+| Collada and other formats support specifying the double-sidedness of
+  the geometry (in other words, when not double-sided, back-faces are
+  not drawn). Godot supports this option per Material, not per Geometry.
+| When exporting from 3D DCCs that work with per-object double-sidedness
+  (such as Blender of Maya), make sure that the double sided objects do
+  not share a material with the single sided ones or the importer will
+  not be able to discern.
+
+Animation options
+-----------------
+
+| Some things to keep in mind when importing animations. 3D DCCs allow
+  animating with curves for every x,y,z component, doing IK constraints
+  and other stuff. When imported for real-time, animations are sampled
+  (at small intervals) so all this information is lost. Sampled
+  animations are fast to process, but can use considerable amounts of
+  memory.
+| Because of this, the "Optimize" option exists but, in some cases, this
+  option might get to break an animation, so make it sure to disable if
+  you see this.
+
+Some animations are meant to be cycled (like walk animations) if this is
+the case, animation names that end in "-cycle" or "-loop" are
+automatically set to loop.
+
+Import script
+-------------
+
+Creating a script to parse the imported scene is actually really simple.
+This is great for post processing, changing materials, doing funny stuff
+with the geometry, etc.
+
+Create a script that basically looks like this:
+
+::
+
+    tool #needed so it runs in editor
+    extends EditorScenePostImport
+
+    func post_import(scene):
+      #do your stuff here
+      pass # scene contains the imported scene starting from the root node
+
+The post-import function takes the imported scene as parameter (the
+parameter is actually the root node of the scene).
+
+Update logic
+------------
+
+Other types of resources (like samples, meshes, fonts, images, etc.) are
+re-imported entirely when changed and user changes are not kept.
+
+Because of 3D Scenes can be really complex, they use a different update
+strategy. The user might have done local changes to take advantage of
+the engine features and it would be really frustrating if everything is
+lost on re-import because the source asset changed.
+
+This led to the implementation of a special update strategy. The idea
+behind is that the user will not lose anything he or she did, and only
+added data or data that can't be edited inside Godot will be updated.
+
+It works like this:
+
+Strategy
+^^^^^^^^
+
+Upon changes on the source asset (ie: .dae), and on re-import, the
+editor will remember the way the scene originally was, and will track
+your local changes like renaming nodes, moving them or reparenting them.
+Finally, the following will be updated:
+
+-  Mesh Data will be replaced by the data from the updated scene.
+-  Materials will be kept if they were not modified by the user.
+-  Portal and Room shapes will be replaced by the ones from the updated
+   scene.
+-  If the user moved a node inside Godot, the transform will be kept. If
+   the user moved a node in the source asset, the transform will be
+   replaced. Finally, if the node was moved in both places, the
+   transform will be combined.
+
+In general, if the user deletes anything from the imported scene (node,
+mesh, material, etc), updating the source asset will restore what was
+deleted. This is a good way to revert local changes to anything. If you
+really don't want a node anymore in the scene, either delete it from
+both places or add the "-noimp" tag to it in the source asset.
+
+Fresh re-import
+^^^^^^^^^^^^^^^
+
+It can also happen that the source asset changed beyond recognition and
+a full fresh re-import is desired. If so, simply re-open the 3d scene
+import dialog from the Import -> Re-Import menu and perform re-import.
+
+

asset_pipeline/importing_audio_samples.rst

@@ -0,0 +1,113 @@
+Importing audio samples
+=======================
+
+Why importing?
+--------------
+
+Importing Audio Samples into the game engine is a process that should be
+easier than it really is. Most readers are probably thinking "Why not
+just copying the .wav files to a folder inside the project and be over
+with it?".
+
+It's not usually that simple. Most game engines use uncompressed audio
+(in memory at least) for sound effects. The reason for this is because
+it's really cheap to play back and resample. Compressed streamed audio
+(such as .ogg files) takes a large amount of processor to decode so no
+more than one or two are streamed simultaneously. However, with sound
+effects, one expects a dozen of them to be playing at the same time in
+several situations.
+
+Because of this, sound effects are loaded uncompressed into memory, and
+here is where the problems begin.
+
+As is usual with graphics, the situation where programmers don't really
+know about audio and audio engineers don't know about programming is
+also common in the industry. This leads to a scenario where a project
+ends up wasting resources unnecessarily.
+
+To be more precise, sfx artists tend to work with audio formats that
+give them a lot of room for tweaking the audio with a low noise floor
+minimum aliasing, such as 96khz, 24 bits. In many cases, they work in
+stereo too. Added to that, many times they add effects with an infinite
+or really long fadeout, such as reverb, which take a long time to fade
+out. Finally, many DAWs also add silence at the beginning when
+normalizing to wav.
+
+This results in extremely large files to integrate more often than
+desired, with sound effects taking dozens of megabytes.
+
+How much does quality matter?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+First of all, it is important to know that Godot has an internal reverb
+generator. Sound effects can go to four different setups (small, medium
+and large room as well as hall), with different send amounts. This saves
+sfx artists the need to add reverb to the sound effects, reducing their
+size greatly and ensuring correct trimming. Say no to SFX with baked
+reverb!
+
+.. image:: /img/reverb.png
+
+Another common problem is that, while it's useful for working inside a
+DAW, high dynamic range (24 bits) and high sampling rate (96khz) is
+completely unnecessary for use in a game, as there is no `audible
+difference <http://www.youtube.com/watch?v=cIQ9IXSUzuM>`__. If
+positional sound is going to be used (for 2D and 3D), the panning and
+stereo reverb will be provided by the engine, so there is little need
+for stereo sound. How does this affect the resource usage? Look at the
+following comparison:
+
++---------------------------+---------------------+--------------+
+| Format                    | 1 Second of Audio   | Frame Size   |
++===========================+=====================+==============+
+| 24 bits, 96 khz, Stereo   | 576kb               | 12           |
++---------------------------+---------------------+--------------+
+| 16 bits, 44 khz, Mono     | 88kb                | 2            |
++---------------------------+---------------------+--------------+
+| 16 bits, IMA-ADPCM        | 22kb                | 1/2          |
++---------------------------+---------------------+--------------+
+
+As seen, for being no audible difference, the 16 bits, 44khz takes *6
+times less memory* than the 24 bits, 96khz, Stereo version. The
+IMA-ADPCM version takes *24 times less memory* than what was exported
+from the DAW.
+
+Trimming
+~~~~~~~~
+
+One last issue that happens often is that the waveform files received
+have silences at the beginning and at the end. These are inserted by
+DAWs when saving to a waveform, increase their size unnecessarily and
+add latency to the moment they are played back. Trimming them solves
+this, but it takes effort for the sfx artist, as they have to do it in a
+separate application. In the worst case, they may not even know the
+silences are being added.
+
+.. image:: /img/trim.png
+
+Importing audio samples
+-----------------------
+
+Godot has a simple screen for importing audio samples to the engine. SFX
+artists only have to save the .wav files to a folder outside the
+project, and the import dialog will fix the files for inclusion, as well
+as doing it automatically every time they are modified and re-imported.
+
+.. image:: /img/importaudio.png
+
+In this screen, the quality of the audio can be limited to what is
+needed, and trimming is done automatically. As a plus, several samples
+can be loaded and batch-converted, just like textures.
+
+Looping
+~~~~~~~
+
+Godot supports looping in the samples (Tools such as Sound Forge or
+Audition can add loop points to .wav files). This is useful for sound
+effects such as engines, machine guns, etc. Ping-pong looping is also
+supported.
+
+As an alternative, the import screen has a "loop" option that enables
+looping for the entire sample when importing.
+
+

asset_pipeline/importing_fonts.rst

@@ -0,0 +1,115 @@
+Importing fonts
+===============
+
+What is a font?
+---------------
+
+Fonts in modern operating systems are created as scalable vector
+graphics. They are stored as a collection of curves (usually one for
+each character), which are independent of the screen resolution, and
+stored in standardized file formats, such as TTF (TrueType) or OTF
+(OpenType).
+
+Rendering such fonts to bitmaps is a complex process, which employs
+different methods to convert curves to pixels depending on context and
+target size. Due to this, this rendering process must be done by using
+the CPU. Game engines use the GPU to render, and 3D APIs don't really
+support the means to do this efficiently, so fonts have to be converted
+to a format that is friendly to the GPU when imported to a project.
+
+Converting fonts
+----------------
+
+This conversion process consists of rendering a vector font to a given
+point size and storing all the resulting characters in a bitmap texture.
+The bitmap texture is then used by the GPU to draw a small quad for each
+character and form readable strings.
+
+.. image:: /img/bitmapfont.png
+
+The drawback of this process is that fonts must be pre-imported in the
+specific sizes that they will use in the project. However, given that
+that bitmap fonts compress really well, this is not as bad as it sounds.
+
+Importing a font
+----------------
+
+Fonts are imported via the Font import dialog. The dialog will ask for a
+font, a size, some options and a target resource fie to save.
+
+.. image:: /img/fontimport.png
+
+The dialog is fully dynamic, which means that any change will be
+reflected in the font preview window. The user ccan tweak almost every
+parameter and get instant feedback on how the font will look.
+
+Since the resulting font is a bitmap, a few more options were added to
+make the imported font look even nicer. These options were added to
+please graphic designers, who love putting gradients, outlines and
+shadows in fonts, as well as changing all the inter-spaces available :).
+The options which will be explained in the next section.
+
+Extra spacing
+~~~~~~~~~~~~~
+
+It is possible to add more space for:
+
+-  **Characters**, the space between them can be varied.
+-  **"space" character**, so the distance between words is bigger.
+-  **Top and Bottom margins**, this changes the spacing between lines as
+   well as the space between the top and bottom lines and the borders.
+
+.. image:: /img/fontspacing.png
+
+Shadows & outline
+~~~~~~~~~~~~~~~~~
+
+Fonts can be added a shadow. For this, the font is drawn again below on
+a different color and the blurred with a gaussian kernel of different
+sizes. The resulting shadow can be adjusted with an exponential function
+to make it softer or more like an outline. A second shadow is also
+provided to create some added effects, like a bump or outline+shadow.
+
+.. image:: /img/shadowoutline.png
+
+Gradients
+~~~~~~~~~
+
+Gradients are also another of the visual effects that graphic designers
+often use. To show how much we love them, we added those too. Gradients
+can be provided as a simple curve between two colors, or a special png
+file with a hand drawn gradient.
+
+.. image:: /img/fontgradients.png
+
+Internationalization
+--------------------
+
+Colors, shadows and gradients are beautiful, but it's time we get to
+serious business. Developing games for Asian markets is a common
+practice in today's globalized world and app stores.
+
+Here's when things get tricky with using bitmap fonts. Asian alphabets
+(Chinese, Japanese and Korean) contains dozens of thousands of
+characters. Generating bitmap fonts with every single of them is pretty
+expensive, as the resulting textures are huge. If the font size is small
+enough, it can be done without much trouble, but when the fonts become
+bigger, we run out of video ram pretty quickly!
+
+To solve this, Godot allows the user to specify a text file (in UTF-8
+format) where it expects to find all the characters that will be used in
+the project. This seems difficult to provide at first, and more to keep
+up to date, but it becomes rather easy when one realizes that the .csv
+with the translations can be used as such source file (see the
+[[Importing\_translations]] section). As Godot re-imports assets when
+their dependencies change, both the translation and font files will be
+updated and re-imported automatically if the translation csv changes.
+
+Another cool trick for using a text file as limit of which characters
+can be imported is when using really large fonts. For example, the user
+might want to use a super large font, but only to show numbers. For
+this, he or she writes a numbers.txt file that contains "1234567890",
+and Godot will only limit itself to import data, thus saving a lot of
+video memory.
+
+

asset_pipeline/importing_textures.rst

@@ -0,0 +1,250 @@
+Importing textures
+==================
+
+Do NOT import them in most cases
+--------------------------------
+
+In most cases you **don't** want images imported when dealing with 2D
+and GUI. Just copy them to the filesystem. Read the tutorial on
+[[Image\_Files\|dealing with image files]] before continuing! For 3D,
+textures are always imported by the 3D scene importer, so importing
+those is only useful when importing a texture used for 3D that doesn't
+come with the 3D scene (for example, in a shader). The flags and options
+are the same as here, so reading the rest of the document might help
+too.
+
+OK, you *might* want to import them
+-----------------------------------
+
+So, if you have read the previous tutorial on the texture exporter, the
+texture importer gives you more finer grained control on how textures
+are imported. If you want to change flags such as repeat, filter,
+mip-maps, fix edges, etc. ***PER texture***, importing them is the best
+way to accomplish this (since you can't save such flags in a standard
+image file).
+
+Lack of MipMaps
+---------------
+
+Images in 3D hardware are scaled with a (bi)linear filter, but this
+method has limitations. When images are shrunk too much, two problems
+arise:
+
+-  **Aliasing**: Pixels are skipped too much, and the image shows
+   discontinuities. This decrases quality.
+-  **Cache Misses**: Pixels being read are too far apart, so texture
+   cache reads a lot more data than it should. This decreases
+   performance.
+
+(Todo, find image sample of why it looks bad)
+
+To solve this, mipmaps are created. Mipmaps are versions of the image
+shrunk by half in both axis, recursively, until the image is 1 pixel of
+size. When the 3D hardware needs to shrink the image, it finds the
+largest mipmap it can scale from, and scales from there. This improves
+performance and image quality.
+
+.. image:: /img/mipmaps.png
+
+Godot automatically creates mipmaps upon load for standard image files.
+This process is time consuming (although not much) and makes load times
+a little worse. Pre-importing the textures allows the automatic
+generation of mipmaps.
+
+Unwanted MipMaps
+----------------
+
+Remember the previous point about mipmaps? Yes, they are cool, but
+mobile GPUs only support them if the textures are in power of 2
+dimensions (ie 256x256 or 512x128). In these platforms, Godot will
+stretch and enlarge the texture to the closest power of 2 size and then
+generate the mipmaps. This process takes more of a performance hit and
+it might degrade the quality a little more.
+
+Because of this, there are some scenarios when it may be desirable to
+not use them, and just use a linear filter. One of them is when working
+with graphical user interfaces (GUIs). Usually they are made of large
+images and don't stretch much. Even if the screen resolution is in a
+larger or smaller value than original art, the amount of stretch is not
+as much and the art can retain the quality. Pre-importing the textures
+also allows the disabling of mipmap generation.
+
+Blending artifacts
+------------------
+
+The `blending
+equation <http://en.wikipedia.org/wiki/Alpha_compositing>`__ used by
+applications like Photoshop is too complex for realtime. There are
+better approximations such as `pre-multiplied
+alpha <http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx?Redirected=true>`__,
+but they impose more stress in the asset pipeline. In the end, we are
+left with textures that have artifacts in the edges, because apps such
+as Photoshop store white pixels in completely transparent areas. Such
+white pixels end up showing thanks to the texture filter.
+
+Godot has an option to fix the edges of the image (by painting invisible
+pixels the same color as the visible neighbours):
+
+.. image:: /img/fixedborder.png
+
+However, this must be done every time the image changes. Pre-Importing
+the textures makes sure that every time the original file changes, this
+artifact is fixed upon automatic re-import.
+
+Texture flags
+-------------
+
+Textures have flags. The user can choose for them to repeat or clamp to
+edges (when UVs exceed the 0,0,1,1 boundary). The magnifying filter can
+also be turned off (for a Minecraft-like effect). Such values can not be
+edited in standard file formats (png, jpg, etc), but can be edited and
+saved in Godot .tex files. Then again, the user may not want to change
+the values every time the texture changes. Pre-Importing the textures
+also takes care of that.
+
+Texture compression
+-------------------
+
+Asides from the typical texture compression, which saves space on disk
+(.png, jpg, etc), there are also texture compression formats that save
+space in memory (more specifically video memory. This allows to have
+much better looking textures in games without running out of memory, and
+decrease memory bandwidth when reading them so they are a big plus.
+
+Video texture compression formats are several and non standard. Apple
+uses PVRTC. PC GPUs, consoles and nVidia Android devices use S3TC (BC),
+other chipsets use other formats. OpenGL ES 3.0 standardized on ETC
+format, but we are still a few years away from that working everywhere.
+
+Still, when using this option, Godot converts and compresses to the
+relevant format depending on the target platform (as long as the user
+pre-imported the texture and specified video ram compression!).
+
+This kind of compression is often not desirable for many types 2D games
+and UIs because it has visible visual artifacts. This is specially
+noticeable on games that use the trendy vectory social game artwork.
+However, again, the fact that it saves space and improves performance
+may make up for it.
+
+The 3D scene importer always imports textures with this option turned
+on.
+
+Atlases
+-------
+
+Remember how mobile GPUs have this limitation of textures having to be
+in power of 2 sizes to be able to generate mimpmaps for optimum
+stretching? What if we have a lot of images in different random sizes?
+All will have to be scaled and mipmapped when loaded (using more CPU and
+memory) or when imported (using more memory). This is probably still ok,
+but there is a tool that can help improve this situation.
+
+Atlases are big textures that fit a lot of small textures inside
+efficiently. Godot supports creating atlases in the importer, and the
+imported files are just small resources that reference a region of the
+bigger texture.
+
+Atlases can be a nice solution to save some space on GUI or 2D artwork
+by packing everything together. The current importer is not as useful
+for 3D though (3D Atlasses are created differently, and not all 3D
+models can use them).
+
+As a small plus, atlases can decrease the amount of "state changes" when
+drawing. If a lot of objects that are drawn using several different
+textures are converted to atlas, then the texture rebinds per object
+will go from dozens or hundreds to one. This will give the performance a
+small boost.
+
+Artists use PSD
+---------------
+
+Still wondering whether to use the texture importer or not? Remember
+that in the end, artists will often use Photoshop anyway, so it may be
+wiser to just let the import subsystem to take care of importing and
+converting the PSD files instead of asking the artist to save a png and
+copy it to the project every time.
+
+Texture importer
+----------------
+
+Finally! It's time to take a look at the texture importer. There are 3
+options in the import menu. They are pretty much (almost) the same
+dialog with a different set of defaults.
+
+.. image:: /img/importtex.png
+
+When selected, the texture import dialog will appear. This is the
+default one for 2D textures:
+
+.. image:: /img/import_images.png
+
+Each import option has a function, explained as follows:
+
+Source texture(s)
+~~~~~~~~~~~~~~~~~
+
+One or more source images can be selected from the same folder (this
+importer can do batch-conversion). This can be from inside or outside
+the project.
+
+Target path
+~~~~~~~~~~~
+
+A destination folder must be provided. It must be inside the project, as
+textures will be converted and saved to it. Extensions will be changed
+to .tex (Godot resource file for textures), but names will be kept.
+
+Texture format
+~~~~~~~~~~~~~~
+
+This combo allows to change the texture format (compression in this
+case):
+
+.. image:: /img/compressopts.png
+
+Each of the four options described in this table together with their
+advantages and disadvantages ( |image5| = Best, |image6| =Worst ):
+
++----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
+|                | Uncompressed           | Compress Lossless (PNG)   | Compress Lossy (WebP)   | Compress VRAM                                        |
++================+========================+===========================+=========================+======================================================+
+| Description    | Stored as raw pixels   | Stored as PNG             | Stored as WebP          | Stored as S3TC/BC,PVRTC/ETC, depending on platform   |
++----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
+| Size on Disk   | |image7| Large         | |image8| Small            | |image9| Very Small     | |image10| Small                                      |
++----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
+| Memory Usage   | |image11| Large        | |image12| Large           | |image13| Large         | |image14| Small                                      |
++----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
+| Performance    | |image15| Normal       | |image16| Normal          | |image17| Normal        | |image18| Fast                                       |
++----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
+| Quality Loss   | |image19| None         | |image20| None            | |image21| Slight        | |image22| Moderate                                   |
++----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
+| Load Time      | |image23| Normal       | |image24| Slow            | |image25| Slow          | |image26| Fast                                       |
++----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
+
+Texture options
+~~~~~~~~~~~~~~~
+
+Provided are a small amount of options for fine grained import control:
+
+-  **Streaming Format** - This does nothing as of yet, but a texture
+   format for streaming different mipmap levels is planned. Big engines
+   have support for this.
+-  **Fix Border Alpha** - This will fix texture borders to avoid the
+   white auras created by white invisible pixels (see the rant above).
+-  **Alpha Bit Hint** - Godot auto-detects if the texture needs alpha
+   bit support for transparency (instead of full range), which is useful
+   for compressed formats such as BC. This forces alpha to be 0 or 1.
+-  **Compress Extra** - Some VRAM compressions have alternate formats
+   that compress more at the expense of quality (PVRTC2 for example). If
+   this is ticked, texture will be smaller but look worse.
+-  **No MipMaps** - Force imported texture to NOT use mipmaps. This may
+   be desirable in some cases for 2D (as explained in the rant above),
+   though it's NEVER desirable for 3D.
+-  **Repeat** - Texture will repeat when UV coordinates go beyond 1 and
+   below 0. This is often desirable in 3D, but may generate artifacts in
+   2D.
+-  **Filter** - Enables linear filtering when a texture texel is larger
+   than a screen pixel. This is usually turned on, unless it's required
+   for artistic purposes (minecraft look, for example).
+
+

asset_pipeline/importing_translations.rst

@@ -0,0 +1,86 @@
+Importing translations
+======================
+
+Games and internationalization
+------------------------------
+
+The world is full of different markets and cultures and, to maximize
+profits™, nowadays games are released in several languages. To solve
+this, internationalized text must be supported in any modern game
+engine.
+
+In regular desktop or mobile applications, internationalized text is
+usually located in resource files (or .po files for GNU stuff). Games,
+however, can use several orders of magnitude more text than
+applications, so they must support efficient methods for dealing with
+loads of multi-language text.
+
+There are two approaches to generate multi language games and
+applications. Both are based on a key:value system. The first is to use
+one of the languages as key (usually english), the second is to use a
+specific identifier. The first approach is probably easier for
+development if a game is released first in english, later in other
+languages, but a complete nightmare if working with many languages at
+the same time.
+
+In general, games use the second approach and a unique ID is used for
+each string. This allows to revise the text while it's being translated
+to others. the unique ID can be a number, a string, or a string with a
+number (it's just a unique string anyway).
+
+Translators also, most of the time prefer to work with spreadsheets
+(either as a Microsoft Excel file or a shared Google Spreadsheet).
+
+Translation format
+------------------
+
+To complete the picture and allow efficient support for translations,
+Godot has a special importer that can read .csv files. Both Microsoft
+Excel and Google Spreadsheet can export to this format, so the only
+requirement is that the files have a special format. The csv files must
+be saved in utf-8 encoding and the format is as follows:
+
++--------+----------+----------+----------+
+|        |          |          |          |
++========+==========+==========+==========+
+| KEY1   | string   | string   | string   |
++--------+----------+----------+----------+
+| KEY2   | string   | string   | string   |
++--------+----------+----------+----------+
+| KEYN   | string   | string   | string   |
++--------+----------+----------+----------+
+
+The "lang" tags must represent a language, it must be one of the `valid
+locales <locales>`__ supported by the engine. The "KEY" tags must be
+unique and represent a string universally (they are usually in
+uppercase, to differentiate from other strings). Here's an example:
+
++---------+------------------+----------------+--------------+
+| id      | en               | es             | ja           |
++=========+==================+================+==============+
+| GREET   | Hello, friend!   | Hola, Amigo!   | こんにちは   |
++---------+------------------+----------------+--------------+
+| ASK     | How are you?     | Cómo esta?     | 元気ですか   |
++---------+------------------+----------------+--------------+
+| BYE     | Good Bye         | Adiós          | さようなら   |
++---------+------------------+----------------+--------------+
+
+Import dialog
+-------------
+
+The import dialog takes a .csv file in the previously described format
+and generates several compressed translation resource files inside the
+project.
+
+Selecting a .csv file autodetects the languages from the first row. and
+determines which column represents which language. It is possible to
+change that manually, by selecting the language for each column.
+
+.. image:: /img/trans.png
+
+The import dialog also can add the translation to the list of
+translations to load when the game runs, specified in engine.cfg (or the
+project properties). Godot allows to load and remove translations at
+runtime, too.
+
+

asset_pipeline/index.rst

@@ -4,5 +4,8 @@ Asset pipeline
 .. toctree::
    :maxdepth: 2
    :name: asset-pipeline
-   
+
    general
+   import
+   export
+

asset_pipeline/managing_image_files.rst

@@ -61,11 +61,11 @@ excessively:
 Alpha blending
 ~~~~~~~~~~~~~~
 
-The \\\ `blending
-equation\\ <http://en.wikipedia.org/wiki/Alpha_compositing>`__ used by
+The `blending
+equation <http://en.wikipedia.org/wiki/Alpha_compositing>`__ used by
 applications like Photoshop is too complex for real-time. There are
-better approximations such as \\\ `pre-multiplied
-alpha\\ <http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx?Redirected=true>`__,
+better approximations such as `pre-multiplied
+alpha <http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx?Redirected=true>`__,
 but they impose more stress in the asset pipeline. In the end, we are
 left with textures that have artifacts in the edges, because apps such
 as Photoshop store white pixels in completely transparent areas. Such
@@ -78,7 +78,7 @@ pixels the same color as the visible neighbours):
 
 To do this, open the image from the resources tab, or edit it from the
 property editor from another node or resource, then go to the object
-options and select \\"Fix Border Alpha\\", then save it.
+options and select "Fix Border Alpha", then save it.
 
 .. image:: /img/imagefixalpha.png
 

asset_pipeline/one-click_deploy.rst

@@ -0,0 +1,33 @@
+One-click deploy
+================
+
+Sounds Good, What is it?
+------------------------
+
+This feature will pop up automatically once a platform is properly
+configured and a supported device is connected to the computer. Since
+things can go wrong at many levels (platform may not be configured
+correctly, SDK may incorrectly installed, device may be improperly
+configured, kitty ate the USB cable, etc.), it's good to let the user
+know that it exists.
+
+Some platforms (at the time of this writing, only Android and Blackberry
+10) can detect when a USB device is connected to the computer, and offer
+the user to automatically export, install and run the project (in debug
+mode) on the device. This feature is called, in industry buzz-words,
+"One Click Deploy" (though, it's technically two clicks...).
+
+Steps for One Click Deploy
+--------------------------
+
+#. Configure target platform.
+#. Configure device (make sure it's in developer mode, likes the
+   computer, usb is recognized, usb cable is plugged, etc).
+#. Connect the device..
+#. And Voila!
+
+.. image:: /img/oneclick.png
+
+Click once.. and deploy!
+
+

contributing/bug_triage_guidelines.rst

@@ -0,0 +1,94 @@
+This page describes the typical workflow of the bug triage team aka
+bugsquad when handling issues and pull requests on Godot's GitHub
+repository. It is bound to evolve together with the bugsquad, so do not
+hesitate to propose modifications to the following guidelines.
+
+Issues management
+=================
+
+GitHub proposes three features to manage issues:
+
+-  Set one or several labels from a predefined list
+-  Set one milestone from a predefined list
+-  Define one contributor as "assignee" among the Godot engine
+   organization members
+
+As the Godot engine organization on GitHub currently has a restricted
+number of contributors and we are not sure yet to what extent we will
+use it or OpenProject instead, we will not use assignees extensively for
+the time being.
+
+Labels
+------
+
+The following labels are currently defined in the Godot repository:
+
+**Categories:**
+
+-  *Archived*: either a duplicate of another issue, or invalid. Such an
+   issue would also be closed.
+-  *Bug*: describes something that is not working properly.
+-  *Confirmed*: has been confirmed by at least one other contributor
+   than the bug reporter (typically for *Bug* reports).
+   The purpose of this label is to let developers know which issues are
+   still reproducible when they want to select what to work on. It is
+   therefore a good practice to add in a comment on what platform and
+   what version or commit of Godot the issue could be reproduced; if a
+   developer looks at the issue one year later, the *Confirmed* label
+   may not be relevant anymore.
+-  *Enhancement*: describes a proposed enhancement to an existing
+   functionality.
+-  *Feature request*: describes a wish for a new feature to be
+   implemented.
+-  *High priority*: the issue should be treated in priority (typically
+   critical bugs).
+-  *Needs discussion*: the issue is not consensual and needs further
+   discussion to define what exactly should be done to address the
+   topic.
+
+The categories are used for general triage of the issues. They can be
+combined in some way when relevant, e.g. an issue can be labelled *Bug*,
+*Confirmed* and *High priority* at the same time if it's a critical bug
+that was confirmed by several users, or *Feature request* and *Needs
+discussion* if it's a non-consensual feature request, or one that is not
+precise enough to be worked on.
+
+**Topics:**
+
+-  *Buildsystem*: relates to building issues, either linked to the SCons
+   buildsystem or to compiler peculiarities.
+-  *Core*: anything related to the core engine. It might be further
+   split later on as it's a pretty big topic.
+-  *Demos*: relates to the official demos.
+-  *GDScript*: relates to GDScript.
+-  *Porting*: relates to some specific platforms.
+-  *Rendering engine*: relates to the 2D and 3D rendering engines.
+-  *User interface*: relates to the UI design.
+
+Issues would typically correspond to only one topic, though it's not
+unthinkable to see issues that fit two bills. The general idea is that
+there will be specialized contributors teams behind all topics, so they
+can focus on the issues labelled with their team topic.
+
+Bug reports concerning the website or the documentation should not be
+filed in GitHub but in the appropriate tool in OpenProject, therefore
+such issues should be closed and archived once they have been moved to
+their rightful platform.
+
+| **Platforms:** *Android*, *HTML5*, *iOS*, *Linux*, *OS X*, *Windows*
+| By default, it is assumed that a given issue applies to all platforms.
+  If one of the platform labels is used, it is the exclusive and the
+  previous assumption doesn't stand anymore (so if it's a bug on e.g.
+  Android and Linux exclusively, select those two platforms).
+
+Milestones
+----------
+
+Milestones correspond to planned future versions of Godot for which
+there is an existing roadmap. Issues that fit in the said roadmap should
+be filed under the corresponding milestone; if they don't correspond to
+any current roadmap, they should be set to *Later*. As a rule of thumb,
+an issue corresponds to a given milestone if it concerns a feature that
+is new in the milestone, or a critical bug that can't be accepted in any
+future stable release, or anything that Juan wants to work on right now
+:)

contributing/documentation_guidelines.rst

@@ -0,0 +1,12 @@
+Documentation guidelines
+========================
+
+The following page will give you the detailed guidelines for writing
+documentation : [[Documentation writing and translating guidelines]].
+
+Help needed
+-----------
+
+We need your help on the following tasks :
+
+-  [[Reference filling work]]

contributing/documentation_writing_and_translating_guidelines.rst

@@ -0,0 +1,119 @@
+Documentation writing and translating guidelines
+================================================
+
+This page describes the rules to follow if you want to contribute Godot
+Engine by writing documentation or translating existing documentation.
+
+What is a good documentation ?
+------------------------------
+
+A good documentation is well written in plain English and well-formed
+sentences. It is clear and objective.
+
+A documentation page is not a tutorial page. We differentiate these
+concepts by these definitions :
+
+-  tutorial : a page aiming at explaining how to use one or more
+   concepts in Godot Editor in order to achieve a specific goal with a
+   learning purpose (ie. "make a simple 2d Pong game", "apply forces to
+   an object"...)
+-  documentation : a page describing precisely one and only one concept
+   at the time, if possible exhaustively (ie. the list of methods of the
+   Sprite class for example).
+
+You are free to write the kind of documentation you wish, as long as you
+respect the following rules.
+
+Create a new wiki page
+----------------------
+
+Creating a new documentation page or tutorial page is easy. The
+following rules must be respected :
+
+-  Choose a short and explicit title
+-  Respect the grammar and orthography
+-  Make use of the [[Wiki syntax]]
+
+| Try to structure your page in order to enable users to include a page
+  directly in another page or even forum posts using the include wiki
+  syntax. For example, the syntax to include the page you are reading is
+  :
+| !{{include(Documentation writing and translating guidelines)}}.
+
+Titles
+~~~~~~
+
+| Please always begin pages with their name:
+| ``h1. <Insert your title here>``
+
+Also, avoid American CamelCase titles: titles' first word should begin
+with a capitalized letter, and every following word should not. Thus,
+this is a good example:
+
+-  Insert your title here
+   And this is a bad example:
+-  Insert Your Title Here
+
+Only project names (and people names) should have capitalized first
+letter. This is good:
+
+-  Starting up with Godot Engine
+   and this is bad:
+-  Starting up with godot engine
+
+Note for non-English authors
+----------------------------
+
+| If you intend to create a new page in your language, you are asked to
+  firstly create the corresponding English page if it doesn't already
+  exist. **Do it even if you will not write it yourself, just leave it
+  blank.** Only then, create the corresponding page in your own
+  language. Maybe later, another contributor will translate your new
+  page to English.
+| **Remember** : even if Godot aims at being accessible to everyone,
+  English is the most frequent language for documentation.
+
+Translating existing pages
+--------------------------
+
+You are very welcome to translate existing pages from English to your
+language, or from your language to English. If these guidelines were
+respected, an English page already exists for every page of this wiki,
+even if it is empty. To translate an existing page, please follow these
+few rules :
+
+-  Respect the grammar and orthography
+-  Make use of the [[wiki syntax]]
+-  Re-use images
+-  Always keep the structure of the English page (if it is written yet,
+   follow the structure of the original language page you are
+   translating from).
+
+To translate an existing page, simply copy its original content. Then,
+create the new page in the section of your language, copy the English
+content in it and start translating.
+
+| Please add a line at the very beginning of your translation, linking
+  to the English base page you translate from :
+| Traduction de ![[Godot Engine:Creating 2D Games]]
+
+The previous link is of the form ![[:]] which enables you to add a link
+to a page located in an other project. Here, "Godot Engine" is the
+English project.
+
+Important changes and discussions
+---------------------------------
+
+You are welcome to correct mistakes or styles to respect these
+guidelines. However, in case of important changes, please do not start a
+discussion on this page : use the forum, create a new topic with a link
+to the incriminated page and start discussing there about your remarks.
+
+Licence
+-------
+
+This wiki and every page it contains is published under the terms of the
+Creative Commons By-SA 4.0.
+
+© Juan Linietsky, Ariel Mansur and contributors - License Creative
+Commons By-SA 4.0.

contributing/index.rst

@@ -0,0 +1,12 @@
+Contributing
+============
+
+.. toctree::
+   :maxdepth: 1
+   :name: contributing
+
+   bug_triage_guidelines
+   documentation_guidelines
+   documentation_writing_and_translating_guidelines
+   list_of_classes_and_documenters
+   wiki_syntax

contributing/list_of_classes_and_documenters.rst

@@ -0,0 +1,365 @@
+List of classes and documenters
+===============================
+
+Status list : Not started, Started, Finished, Removed
+
+| \| Class name \| Assigned to \| Status \| Start date \| Notes \|
+| \| @GDScript \| \| \|
+| \| @Global Scope \| \| \|
+| \| AABB \| bojidar\_bg \| Finished \|
+| \| AcceptDialog \| \| \|
+| \| AnimatedSprite \| \| \|
+| \| AnimatedSprite3D \| \| \|
+| \| Animation \| \| \|
+| \| AnimationPlayer \| \| \|
+| \| AnimationTreePlayer \| \| \|
+| \| Area \| \| \|
+| \| Area2D \| Ovnuniarchos \| Finished \| 2015/12/22 \| \|
+| \| Array \| vnen \| Started \| 10/10/2015 \|
+| \| AtlasTexture \| \| \|
+| \| AudioServer \| Akien \| Finished \|
+| \| AudioServerSW \| Akien \| Finished \|
+| \| AudioStream \| Akien \| Finished \|
+| \| AudioStreamMPC \| Akien \| Finished \|
+| \| AudioStreamOGGVorbis \| Akien \| Finished \|
+| \| AudioStreamPlayback \| Akien \| Finished \|
+| \| AudioStreamSpeex \| Akien \| Finished \|
+| \| BackBufferCopy \| \| \|
+| \| BakedLight \| \| \|
+| \| BakedLightInstance \| \| \|
+| \| BakedLightSampler \| \| \|
+| \| BaseButton \| \| \|
+| \| BitMap \| \| \|
+| \| BoneAttachment \| \| \|
+| \| BoxContainer \| \| \|
+| \| BoxShape \| \| \|
+| \| Button \| \| \|
+| \| ButtonArray \| \| \|
+| \| ButtonGroup \| \| \|
+| \| Camera \| \| \|
+| \| Camera2D \| \| \|
+| \| CanvasItem \| \| \|
+| \| CanvasItemMaterial \| \| \|
+| \| CanvasItemShader \| \| \|
+| \| CanvasItemShaderGraph \| \| \|
+| \| CanvasLayer \| \| \|
+| \| CanvasModulate \| \| \|
+| \| CapsuleShape \| \| \|
+| \| CapsuleShape2D \| Ovnuniarchos \| Finished \| \|
+| \| CenterContainer \| \| \|
+| \| CheckBox \| \| \|
+| \| CheckButton \| \| \|
+| \| CircleShape2D \| Ovnuniarchos \| Finished \| \|
+| \| CollisionObject \| \| \|
+| \| CollisionObject2D \| Ovnuniarchos \| Finished \| 2015/12/22 \| \|
+| \| CollisionPolygon \| \| \| \|
+| \| CollisionPolygon2D \| Ovnuniarchos \| Finished \| \|
+| \| CollisionShape \| \| \|
+| \| CollisionShape2D \| Ovnuniarchos \| Finished \| \|
+| \| Color \| \| \|
+| \| ColorArray \| \| \|
+| \| ColorPicker \| \| \|
+| \| ColorPickerButton \| \| \|
+| \| ColorRamp \| \| \|
+| \| ConcavePolygonShape \| \| \|
+| \| ConcavePolygonShape2D \| Ovnuniarchos \| Finished \| \|
+| \| ConeTwistJoint \| \| \|
+| \| ConfigFile \| \| \|
+| \| ConfirmationDialog \| \| \|
+| \| Container \| \| \|
+| \| Control \| \| \|
+| \| ConvexPolygonShape \| \| \|
+| \| ConvexPolygonShape2D \| Ovnuniarchos \| Finished \| \|
+| \| CubeMap \| \| \|
+| \| Curve2D \| Ovnuniarchos \| Finished \|
+| \| Curve3D \| Ovnuniarchos \| Finished \|
+| \| DampedSpringJoint2D \| \| \|
+| \| Dictionary \| \| \|
+| \| DirectionalLight \| \| \|
+| \| Directory \| vnen \| Started \| 11/10/2015 \|
+| \| EditorFileDialog \| \| \|
+| \| EditorImportPlugin \| \| \|
+| \| EditorPlugin \| \| \|
+| \| EditorScenePostImport \| \| \|
+| \| EditorScript \| \| \|
+| \| Environment \| \| \|
+| \| EventPlayer \| \| \|
+| \| EventStream \| \| \|
+| \| EventStreamChibi \| \| \|
+| \| File \| \| \|
+| \| FileDialog \| \| \|
+| \| FixedMaterial \| \| \|
+| \| Font \| \| \|
+| \| FuncRef \| \| \|
+| \| GDFunctionState \| \| \|
+| \| GDNativeClass \| \| \|
+| \| GDScript \| \| \|
+| \| Generic6DOFJoint \| \| \|
+| \| Geometry \| \| \|
+| \| GeometryInstance \| \| \|
+| \| Globals \| \| \|
+| \| GraphEdit \| StraToN \| Finished \| \| may need a tutorial. I'll
+  think about it. \|
+| \| GraphNode \| StraToN \| Finished \| \| may need a tutorial. I'll
+  think about it. \|
+| \| GridContainer \| \| \|
+| \| GridMap \| \| \|
+| \| GrooveJoint2D \| \| \|
+| \| HBoxContainer \| \| \|
+| \| HButtonArray \| \| \|
+| \| HScrollBar \| \| \|
+| \| HSeparator \| \| \|
+| \| HSlider \| \| \|
+| \| HSplitContainer \| \| \|
+| \| HTTPClient \| \| \|
+| \| HingeJoint \| \| \|
+| \| IP \| \| \|
+| \| IP\_Unix \| \| \|
+| \| Image \| \| \|
+| \| ImageTexture \| \| \|
+| \| ImmediateGeometry \| \| \|
+| \| Input \| \| \|
+| \| InputDefault \| \| \|
+| \| InputEvent \| \| \|
+| \| InputEventAction \| \| \|
+| \| InputEventJoyButton \| \| \|
+| \| InputEventJoyMotion \| \| \|
+| \| InputEventKey \| \| \|
+| \| InputEventMouseButton \| \| \|
+| \| InputEventMouseMotion \| \| \|
+| \| InputEventScreenDrag \| \| \|
+| \| InputEventScreenTouch \| \| \|
+| \| InputMap \| \| \|
+| \| IntArray \| \| \|
+| \| InterpolatedCamera \| \| \|
+| \| ItemList \| \| \|
+| \| Joint \| \| \|
+| \| Joint2D \| \| \|
+| \| KinematicBody \| \| \|
+| \| KinematicBody2D \| Ovnuniarchos \| Started \| 2015/11/23 \| \|
+| \| Label \| \| \|
+| \| LargeTexture \| \| \|
+| \| Light \| \| \|
+| \| Light2D \| \| \|
+| \| LightOccluder2D \| \| \|
+| \| LineEdit \| \| \|
+| \| LineShape2D \| Ovnuniarchos \| Finished \| \|
+| \| MainLoop \| \| \|
+| \| MarginContainer \| \| \|
+| \| Marshalls \| \| \|
+| \| Material \| \| \|
+| \| MaterialShader \| \| \|
+| \| MaterialShaderGraph \| \| \|
+| \| Matrix3 \| \| \|
+| \| Matrix32 \| \| \|
+| \| MenuButton \| \| \|
+| \| Mesh \| \| \|
+| \| MeshDataTool \| \| \|
+| \| MeshInstance \| \| \|
+| \| MeshLibrary \| \| \|
+| \| MultiMesh \| \| \|
+| \| MultiMeshInstance \| \| \|
+| \| Mutex \| \| \|
+| \| Navigation \| \| \|
+| \| Navigation2D \| \| \|
+| \| NavigationMesh \| \| \|
+| \| NavigationMeshInstance \| \| \|
+| \| NavigationPolygon \| \| \|
+| \| NavigationPolygonInstance \| \| \|
+| \| Nil \| \| \|
+| \| Node \| \| \|
+| \| Node2D \| \| \|
+| \| NodePath \| \| \|
+| \| OS \| \| \|
+| \| Object \| \| \|
+| \| OccluderPolygon2D \| \| \|
+| \| OmniLight \| \| \|
+| \| OptionButton \| \| \|
+| \| PCKPacker \| \| \|
+| \| PHashTranslation \| \| \|
+| \| PackedDataContainer \| \| \|
+| \| PackedDataContainerRef \| \| \|
+| \| PackedScene \| \| \|
+| \| PacketPeer \| \| \|
+| \| PacketPeerStream \| \| \|
+| \| PacketPeerUDP \| \| \|
+| \| Panel \| \| \|
+| \| PanelContainer \| \| \|
+| \| ParallaxBackground \| \| \|
+| \| ParallaxLayer \| \| \|
+| \| ParticleAttractor2D \| \| \|
+| \| Particles \| \| \|
+| \| Particles2D \| \| \|
+| \| Patch9Frame \| \| \|
+| \| Path \| Ovnuniarchos \| Finished \|
+| \| Path2D \| Ovnuniarchos \| Finished \|
+| \| PathFollow \| Ovnuniarchos \| Finished \|
+| \| PathFollow2D \| Ovnuniarchos \| Finished \|
+| \| PathRemap \| \| \|
+| \| Performance \| \| \|
+| \| Physics2DDirectBodyState \| \| \|
+| \| Physics2DDirectBodyStateSW \| \| \|
+| \| Physics2DDirectSpaceState \| \| \|
+| \| Physics2DServer \| \| \|
+| \| Physics2DServerSW \| \| \|
+| \| Physics2DShapeQueryParameters \| \| \|
+| \| Physics2DShapeQueryResult \| \| \|
+| \| Physics2DTestMotionResult \| \| \|
+| \| PhysicsBody \| \| \|
+| \| PhysicsBody2D \| Ovnuniarchos \| Finished \| 2015/12/22 \| \|
+| \| PhysicsDirectBodyState \| \| \|
+| \| PhysicsDirectBodyStateSW \| \| \|
+| \| PhysicsDirectSpaceState \| \| \|
+| \| PhysicsServer \| \| \|
+| \| PhysicsServerSW \| \| \|
+| \| PhysicsShapeQueryParameters \| \| \|
+| \| PhysicsShapeQueryResult \| \| \|
+| \| PinJoint \| \| \|
+| \| PinJoint2D \| \| \|
+| \| Plane \| \| \|
+| \| PlaneShape \| \| \|
+| \| Polygon2D \| \| \|
+| \| PolygonPathFinder \| \| \|
+| \| Popup \| \| \|
+| \| PopupDialog \| \| \|
+| \| PopupMenu \| \| \|
+| \| PopupPanel \| \| \|
+| \| Portal \| \| \|
+| \| Position2D \| \| \|
+| \| Position3D \| \| \|
+| \| ProgressBar \| \| \|
+| \| ProximityGroup \| \| \|
+| \| Quad \| \| \|
+| \| Quat \| \| \|
+| \| RID \| \| \|
+| \| Range \| \| \|
+| \| RawArray \| \| \|
+| \| RayCast \| \| \|
+| \| RayCast2D \| eska \| Started \| 2015-10-16 \|
+| \| RayShape \| \| \|
+| \| RayShape2D \| Ovnuniarchos \| Finished \| \|
+| \| RealArray \| \| \|
+| \| Rect2 \| bojidar\_bg \| Finished \|
+| \| RectangleShape2D \| Ovnuniarchos \| Finished \| \|
+| \| Reference \| \| \|
+| \| ReferenceFrame \| \| \|
+| \| RegEx \| Ovnuniarchos \| Finished \| 2015-11-03 \|
+| \| RemoteTransform2D \| eska \| Started \| 2015-10-16 \|
+| \| RenderTargetTexture \| \| \|
+| \| Resource \| \| \|
+| \| ResourceImportMetadata \| \| \|
+| \| ResourceInteractiveLoader \| \| \|
+| \| ResourceLoader \| \| \|
+| \| ResourcePreloader \| \| \|
+| \| ResourceSaver \| \| \|
+| \| RichTextLabel \| \| \|
+| \| RigidBody \| \| \|
+| \| RigidBody2D \| Ovnuniarchos \| Started \| 2015/11/23 \| \|
+| \| Room \| \| \|
+| \| RoomBounds \| \| \|
+| \| Sample \| Akien \| Finished \|
+| \| SampleLibrary \| Akien \| Finished \|
+| \| SamplePlayer \| Akien \| Finished \|
+| \| SamplePlayer2D \| Akien \| Finished \|
+| \| SceneTree \| \| \|
+| \| Script \| \| \|
+| \| ScrollBar \| \| \|
+| \| ScrollContainer \| \| \|
+| \| SegmentShape2D \| Ovnuniarchos \| Finished \| \|
+| \| Semaphore \| \| \|
+| \| Separator \| \| \|
+| \| Shader \| \| \|
+| \| ShaderGraph \| \| \|
+| \| ShaderMaterial \| \| \|
+| \| Shape \| \| \|
+| \| Shape2D \| Ovnuniarchos \| Finished \| \|
+| \| Skeleton \| \| \|
+| \| Slider \| \| \|
+| \| SliderJoint \| \| \|
+| \| SoundPlayer2D \| Akien \| Not started \|
+| \| SoundRoomParams \| Akien \| Not started \|
+| \| Spatial \| Akien \| Not started \|
+| \| SpatialPlayer \| Akien \| Not started \|
+| \| SpatialSamplePlayer \| Akien \| Not started \|
+| \| SpatialSound2DServer \| Akien \| Not started \|
+| \| SpatialSound2DServerSW \| Akien \| Not started \|
+| \| SpatialSoundServer \| Akien \| Not started \|
+| \| SpatialSoundServerSW \| Akien \| Not started \|
+| \| SpatialStreamPlayer \| Akien \| Not started \|
+| \| SphereShape \| \| \|
+| \| SpinBox \| \| \|
+| \| SplitContainer \| \| \|
+| \| SpotLight \| \| \|
+| \| Sprite \| \| \|
+| \| Sprite3D \| \| \|
+| \| SpriteBase3D \| \| \|
+| \| SpriteFrames \| \| \|
+| \| StaticBody \| \| \|
+| \| StaticBody2D \| Ovnuniarchos \| Started \| 2015/11/23 \| \|
+| \| StreamPeer \| \| \|
+| \| StreamPeerSSL \| \| \|
+| \| StreamPeerTCP \| \| \|
+| \| StreamPlayer \| \| \|
+| \| String \| \| \|
+| \| StringArray \| \| \|
+| \| StyleBox \| \| \|
+| \| StyleBoxEmpty \| \| \|
+| \| StyleBoxFlat \| \| \|
+| \| StyleBoxImageMask \| \| \|
+| \| StyleBoxTexture \| \| \|
+| \| SurfaceTool \| \| \|
+| \| TCP\_Server \| \| \|
+| \| TabContainer \| \| \|
+| \| Tabs \| \| \|
+| \| TestCube \| \| \|
+| \| TextEdit \| \| \|
+| \| Texture \| \| \|
+| \| TextureButton \| \| \|
+| \| TextureFrame \| \| \|
+| \| TextureProgress \| \| \|
+| \| Theme \| \| \|
+| \| Thread \| \| \|
+| \| TileMap \| Akien \| Finished \|
+| \| TileSet \| Akien \| Finished \|
+| \| Timer \| Akien \| Finished \|
+| \| ToolButton \| \| \|
+| \| TouchScreenButton \| \| \|
+| \| Transform \| \| \|
+| \| Translation \| \| \|
+| \| TranslationServer \| \| \|
+| \| Tree \| \| \|
+| \| TreeItem \| \| \|
+| \| Tween \| \| \|
+| \| UndoRedo \| \| \|
+| \| VBoxContainer \| \| \|
+| \| VButtonArray \| \| \|
+| \| VScrollBar \| \| \|
+| \| VSeparator \| \| \|
+| \| VSlider \| \| \|
+| \| VSplitContainer \| \| \|
+| \| Vector2 \| bojidar\_bg \| Finished \|
+| \| Vector2Array \| bojidar\_bg \| Finished \|
+| \| Vector3 \| bojidar\_bg \| Finished \|
+| \| Vector3Array \| bojidar\_bg \| Finished \|
+| \| VehicleBody \| \| \|
+| \| VehicleWheel \| \| \|
+| \| VideoPlayer \| \| \|
+| \| VideoStream \| \| \|
+| \| Viewport \| \| \|
+| \| ViewportSprite \| \| \|
+| \| VisibilityEnabler \| \| \|
+| \| VisibilityEnabler2D \| \| \|
+| \| VisibilityNotifier \| \| \|
+| \| VisibilityNotifier2D \| \| \|
+| \| VisualInstance \| \| \|
+| \| VisualServer \| \| \|
+| \| WeakRef \| \| \|
+| \| WindowDialog \| \| \|
+| \| World \| \| \|
+| \| World2D \| \| \|
+| \| WorldEnvironment \| \| \|
+| \| XMLParser \| \| \|
+| \| YSort \| eska \| Started \| 2015-10-16 \|
+| \| bool \| \| \|
+| \| float \| \| \|
+| \| int \| \| \|

contributing/wiki_syntax.rst

@@ -0,0 +1,4 @@
+Wiki Syntax
+===========
+
+This page is a helper for Wiki syntax. TODO.