`__
Constants
---------
Classes often have enums such as:
-|
-| enum SomeMode {
-| MODE\_FIRST,
-| MODE\_SECOND
-| };
+.. code:: cpp
-.. raw:: html
-
-
+ 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:
-VARIANT\_ENUM\_CAST( MyClass::SomeMode); // now
-functions that take SomeMode can be bound.
+.. code:: cpp
-.. raw:: html
-
-
+ VARIANT_ENUM_CAST( MyClass::SomeMode); // now functions that take SomeMode can be bound.
The constants can also be bound inside ``_bind_methods``, by using:
-|
-| BIND\_CONSTANT( MODE\_FIRST );
-| BIND\_CONSTANT( MODE\_SECOND );
+.. code:: cpp
-.. raw:: html
-
-
+ 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:
-PropertyInfo(type,name,hint,hint\_string,usage\_flags)
+.. code:: cpp
-.. raw:: html
-
-
+ PropertyInfo(type,name,hint,hint_string,usage_flags)
For example:
-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)
-
-
-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
-PropertyInfo(Variant::STRING,\\"modes\\",PROPERTY\_HINT\_ENUM,\\"Enabled,Disabled,Turbo\\")
+.. code:: cpp
-.. raw:: html
-
-
+ 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:
-ADD\_PROPERTY(
-PropertyInfo(Variant::INT,\\"amount\\"), \_SCS (\\"set\_amount\\"),
-\_SCS (\\"get\_amount\\") )
+.. code:: cpp
-.. raw:: html
-
-
+ 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).
-|
-| 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
-
-
+ 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:
-|
-| void somefunc(Object \*some\_obj) {
+.. code:: cpp
-| Button \* button = some\_obj->cast\_to<Button>();
-| }
+ void somefunc(Object *some_obj) {
-.. raw:: html
-
-
+ Button * button = some_obj->cast_to();
+ }
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:
-|
-| obj->connect(,target\_instance,target\_method)
-| //for example
-| obj->connect(\\"enter\_tree\\",this,\\"\_node\_entered\_tree\\")
+.. code:: cpp
-.. raw:: html
-
-
+ 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:
-ADD\_SIGNAL( MethodInfo(\\"been\_killed\\") )
+.. code:: cpp
-.. raw:: html
-
-
+ 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.
-|
-| class MyReference: public Reference {
-| OBJ\_TYPE( MyReference ,Reference);
-| };
+.. code:: cpp
-Ref myref = memnew( MyReference );
+ class MyReference: public Reference {
+ OBJ_TYPE( MyReference ,Reference);
+ };
-.. raw:: html
-
-
+ 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\\ `__
+- `core/reference.h `__
Resources:
----------
@@ -319,19 +262,16 @@ Resources without a path are fine too.
References:
~~~~~~~~~~~
-- \\\ `core/resource.h\\ `__
+- `core/resource.h `__
Resource loading
----------------
Resources can be loaded with the ResourceLoader API, like this:
-Ref res =
-ResourceLoader::load(\\"res://someresource.res\\")
+.. code:: cpp
-.. raw:: html
-
-
+ 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\\ `__
+- `core/io/resource\_loader.h `__
Resource saving
---------------
Saving a resource can be done with the resource saver API:
-ResourceSaver::save(\\"res://someresource.res\\",instance)
+.. code:: cpp
-.. raw:: html
-
-
+ 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\\ `__
+- `core/io/resource\_saver.h `__
diff --git a/advanced_topics/services_for_ios.rst b/advanced_topics/services_for_ios.rst
index 16bff54c0..aad77c204 100644
--- a/advanced_topics/services_for_ios.rst
+++ b/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:
-|
-| 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()
+.. code:: python
-| # 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()
+ 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()
-.. raw:: html
-
-
+ # 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:
-|
-| 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
-
-
+ 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
diff --git a/advanced_topics/variant_class.rst b/advanced_topics/variant_class.rst
index 91bf6ea09..29c49de65 100644
--- a/advanced_topics/variant_class.rst
+++ b/advanced_topics/variant_class.rst
@@ -35,7 +35,7 @@ of c++ with little effort. Become a friend of Variant today.
References:
~~~~~~~~~~~
-- \\\ `core/variant.h\\ `__
+- `core/variant.h `__
Dictionary and Array
--------------------
@@ -56,5 +56,5 @@ desired.
References:
~~~~~~~~~~~
-- \\\ `core/dictionary.h\\ `__
-- \\\ `core/array.h\\ `__
+- `core/dictionary.h `__
+- `core/array.h `__
diff --git a/asset_pipeline/export.rst b/asset_pipeline/export.rst
new file mode 100644
index 000000000..5c7dd8e16
--- /dev/null
+++ b/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
diff --git a/asset_pipeline/exporting_for_android.rst b/asset_pipeline/exporting_for_android.rst
new file mode 100644
index 000000000..984384c7f
--- /dev/null
+++ b/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!
+
+
diff --git a/asset_pipeline/exporting_for_ios.rst b/asset_pipeline/exporting_for_ios.rst
new file mode 100644
index 000000000..69692d03c
--- /dev/null
+++ b/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.
+
+
diff --git a/asset_pipeline/exporting_for_pc.rst b/asset_pipeline/exporting_for_pc.rst
new file mode 100644
index 000000000..27de90524
--- /dev/null
+++ b/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.
diff --git a/asset_pipeline/exporting_images.rst b/asset_pipeline/exporting_images.rst
new file mode 100644
index 000000000..6f104ed81
--- /dev/null
+++ b/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 `__, 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.
+
+
diff --git a/asset_pipeline/exporting_projects.rst b/asset_pipeline/exporting_projects.rst
new file mode 100644
index 000000000..1294a27af
--- /dev/null
+++ b/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
+
+
diff --git a/asset_pipeline/general.rst b/asset_pipeline/general.rst
index 7c39c954d..9bf99bdc3 100644
--- a/asset_pipeline/general.rst
+++ b/asset_pipeline/general.rst
@@ -4,5 +4,5 @@ General
.. toctree::
:maxdepth: 1
:name: general
-
+
managing_image_files
diff --git a/asset_pipeline/import.rst b/asset_pipeline/import.rst
new file mode 100644
index 000000000..46f78f32c
--- /dev/null
+++ b/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
diff --git a/asset_pipeline/import_process.rst b/asset_pipeline/import_process.rst
new file mode 100644
index 000000000..5223aa4f1
--- /dev/null
+++ b/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 `__.
+
+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
+
+
diff --git a/asset_pipeline/importing_3d_meshes.rst b/asset_pipeline/importing_3d_meshes.rst
new file mode 100644
index 000000000..e1acdbf25
--- /dev/null
+++ b/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.
+
+
diff --git a/asset_pipeline/importing_3d_scenes.rst b/asset_pipeline/importing_3d_scenes.rst
new file mode 100644
index 000000000..c10908a18
--- /dev/null
+++ b/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 `__
+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 `__
+ 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 `__ 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 `__. 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 `__ 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.
+
+
diff --git a/asset_pipeline/importing_audio_samples.rst b/asset_pipeline/importing_audio_samples.rst
new file mode 100644
index 000000000..9563aaace
--- /dev/null
+++ b/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 `__. 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.
+
+
diff --git a/asset_pipeline/importing_fonts.rst b/asset_pipeline/importing_fonts.rst
new file mode 100644
index 000000000..6d3b814c0
--- /dev/null
+++ b/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.
+
+
diff --git a/asset_pipeline/importing_textures.rst b/asset_pipeline/importing_textures.rst
new file mode 100644
index 000000000..393c5e93d
--- /dev/null
+++ b/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 `__ used by
+applications like Photoshop is too complex for realtime. There are
+better approximations such as `pre-multiplied
+alpha `__,
+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).
+
+
diff --git a/asset_pipeline/importing_translations.rst b/asset_pipeline/importing_translations.rst
new file mode 100644
index 000000000..93846e484
--- /dev/null
+++ b/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 `__ 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.
+
+
diff --git a/asset_pipeline/index.rst b/asset_pipeline/index.rst
index 53b0fc161..595422cdb 100644
--- a/asset_pipeline/index.rst
+++ b/asset_pipeline/index.rst
@@ -4,5 +4,8 @@ Asset pipeline
.. toctree::
:maxdepth: 2
:name: asset-pipeline
-
+
general
+ import
+ export
+
diff --git a/asset_pipeline/managing_image_files.rst b/asset_pipeline/managing_image_files.rst
index b4a2a10e3..603990ac9 100644
--- a/asset_pipeline/managing_image_files.rst
+++ b/asset_pipeline/managing_image_files.rst
@@ -61,11 +61,11 @@ excessively:
Alpha blending
~~~~~~~~~~~~~~
-The \\\ `blending
-equation\\ `__ used by
+The `blending
+equation `__ used by
applications like Photoshop is too complex for real-time. There are
-better approximations such as \\\ `pre-multiplied
-alpha\\ `__,
+better approximations such as `pre-multiplied
+alpha `__,
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
diff --git a/asset_pipeline/one-click_deploy.rst b/asset_pipeline/one-click_deploy.rst
new file mode 100644
index 000000000..284d06495
--- /dev/null
+++ b/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!
+
+
diff --git a/contributing/bug_triage_guidelines.rst b/contributing/bug_triage_guidelines.rst
new file mode 100644
index 000000000..ce47165f7
--- /dev/null
+++ b/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
+:)
diff --git a/contributing/documentation_guidelines.rst b/contributing/documentation_guidelines.rst
new file mode 100644
index 000000000..f1dfa7f4d
--- /dev/null
+++ b/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]]
diff --git a/contributing/documentation_writing_and_translating_guidelines.rst b/contributing/documentation_writing_and_translating_guidelines.rst
new file mode 100644
index 000000000..816d0b4df
--- /dev/null
+++ b/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. ``
+
+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.
diff --git a/contributing/index.rst b/contributing/index.rst
new file mode 100644
index 000000000..2e931a9a4
--- /dev/null
+++ b/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
diff --git a/contributing/list_of_classes_and_documenters.rst b/contributing/list_of_classes_and_documenters.rst
new file mode 100644
index 000000000..3db82a8e4
--- /dev/null
+++ b/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 \| \| \|
diff --git a/contributing/wiki_syntax.rst b/contributing/wiki_syntax.rst
new file mode 100644
index 000000000..fff4d0f14
--- /dev/null
+++ b/contributing/wiki_syntax.rst
@@ -0,0 +1,4 @@
+Wiki Syntax
+===========
+
+This page is a helper for Wiki syntax. TODO.
diff --git a/img/3dimp_blender.png b/img/3dimp_blender.png
new file mode 100644
index 000000000..2c5cf82dd
Binary files /dev/null and b/img/3dimp_blender.png differ
diff --git a/img/3dimp_menu.png b/img/3dimp_menu.png
new file mode 100644
index 000000000..765b4fef9
Binary files /dev/null and b/img/3dimp_menu.png differ
diff --git a/img/3dimp_portal.png b/img/3dimp_portal.png
new file mode 100644
index 000000000..08846ae98
Binary files /dev/null and b/img/3dimp_portal.png differ
diff --git a/img/3dmesh_instance.png b/img/3dmesh_instance.png
new file mode 100644
index 000000000..6f1d7f946
Binary files /dev/null and b/img/3dmesh_instance.png differ
diff --git a/img/Control.png b/img/Control.png
new file mode 100644
index 000000000..4867718bd
Binary files /dev/null and b/img/Control.png differ
diff --git a/img/Node2D.png b/img/Node2D.png
new file mode 100644
index 000000000..d9ae83ca7
Binary files /dev/null and b/img/Node2D.png differ
diff --git a/img/Object.png b/img/Object.png
new file mode 100644
index 000000000..be4b99a82
Binary files /dev/null and b/img/Object.png differ
diff --git a/img/Reference.png b/img/Reference.png
new file mode 100644
index 000000000..46e3fe723
Binary files /dev/null and b/img/Reference.png differ
diff --git a/img/Spatial.png b/img/Spatial.png
new file mode 100644
index 000000000..71d647f22
Binary files /dev/null and b/img/Spatial.png differ
diff --git a/img/activescene.png b/img/activescene.png
new file mode 100644
index 000000000..5854d2864
Binary files /dev/null and b/img/activescene.png differ
diff --git a/img/add_crt.png b/img/add_crt.png
new file mode 100644
index 000000000..baa0fddae
Binary files /dev/null and b/img/add_crt.png differ
diff --git a/img/addedlabel.png b/img/addedlabel.png
new file mode 100644
index 000000000..89810472c
Binary files /dev/null and b/img/addedlabel.png differ
diff --git a/img/addglobal.png b/img/addglobal.png
new file mode 100644
index 000000000..f8d7098ad
Binary files /dev/null and b/img/addglobal.png differ
diff --git a/img/addscript.png b/img/addscript.png
new file mode 100644
index 000000000..f38fa3d4a
Binary files /dev/null and b/img/addscript.png differ
diff --git a/img/anchors.png b/img/anchors.png
new file mode 100644
index 000000000..439a96c1f
Binary files /dev/null and b/img/anchors.png differ
diff --git a/img/androidsdk.png b/img/androidsdk.png
new file mode 100644
index 000000000..97eee2573
Binary files /dev/null and b/img/androidsdk.png differ
diff --git a/img/animation.png b/img/animation.png
new file mode 100644
index 000000000..cfcd8a9aa
Binary files /dev/null and b/img/animation.png differ
diff --git a/img/animedit.png b/img/animedit.png
new file mode 100644
index 000000000..2716f25f5
Binary files /dev/null and b/img/animedit.png differ
diff --git a/img/animeditor.png b/img/animeditor.png
new file mode 100644
index 000000000..b52ec0790
Binary files /dev/null and b/img/animeditor.png differ
diff --git a/img/animnew.png b/img/animnew.png
new file mode 100644
index 000000000..d79ec485c
Binary files /dev/null and b/img/animnew.png differ
diff --git a/img/animpanel.png b/img/animpanel.png
new file mode 100644
index 000000000..0e470a92c
Binary files /dev/null and b/img/animpanel.png differ
diff --git a/img/animplayer.png b/img/animplayer.png
new file mode 100644
index 000000000..c91e25395
Binary files /dev/null and b/img/animplayer.png differ
diff --git a/img/area2dcoin.png b/img/area2dcoin.png
new file mode 100644
index 000000000..dff2588f5
Binary files /dev/null and b/img/area2dcoin.png differ
diff --git a/img/autoplay.png b/img/autoplay.png
new file mode 100644
index 000000000..c0b5327a7
Binary files /dev/null and b/img/autoplay.png differ
diff --git a/img/bitmapfont.png b/img/bitmapfont.png
new file mode 100644
index 000000000..fc333f140
Binary files /dev/null and b/img/bitmapfont.png differ
diff --git a/img/brainslug.jpg b/img/brainslug.jpg
new file mode 100644
index 000000000..66aae51f4
Binary files /dev/null and b/img/brainslug.jpg differ
diff --git a/img/button_connections.png b/img/button_connections.png
new file mode 100644
index 000000000..ffd9719d5
Binary files /dev/null and b/img/button_connections.png differ
diff --git a/img/canvaslayers.png b/img/canvaslayers.png
new file mode 100644
index 000000000..d9dbcad46
Binary files /dev/null and b/img/canvaslayers.png differ
diff --git a/img/changed.png b/img/changed.png
new file mode 100644
index 000000000..ba1e55ff1
Binary files /dev/null and b/img/changed.png differ
diff --git a/img/changes.png b/img/changes.png
new file mode 100644
index 000000000..945d4ce45
Binary files /dev/null and b/img/changes.png differ
diff --git a/img/chef.png b/img/chef.png
new file mode 100644
index 000000000..9b1c03489
Binary files /dev/null and b/img/chef.png differ
diff --git a/img/clearcolor.png b/img/clearcolor.png
new file mode 100644
index 000000000..c50500623
Binary files /dev/null and b/img/clearcolor.png differ
diff --git a/img/collision_inheritance.png b/img/collision_inheritance.png
new file mode 100644
index 000000000..bf863dfaf
Binary files /dev/null and b/img/collision_inheritance.png differ
diff --git a/img/compressopts.png b/img/compressopts.png
new file mode 100644
index 000000000..0d5c6c310
Binary files /dev/null and b/img/compressopts.png differ
diff --git a/img/continst.png b/img/continst.png
new file mode 100644
index 000000000..69f15ff03
Binary files /dev/null and b/img/continst.png differ
diff --git a/img/continstanced.png b/img/continstanced.png
new file mode 100644
index 000000000..00d21e77d
Binary files /dev/null and b/img/continstanced.png differ
diff --git a/img/controot.png b/img/controot.png
new file mode 100644
index 000000000..e1b0c2bb4
Binary files /dev/null and b/img/controot.png differ
diff --git a/img/createnode.png b/img/createnode.png
new file mode 100644
index 000000000..725a05426
Binary files /dev/null and b/img/createnode.png differ
diff --git a/img/ctrl_normal.png b/img/ctrl_normal.png
new file mode 100644
index 000000000..84cd5a55d
Binary files /dev/null and b/img/ctrl_normal.png differ
diff --git a/img/ctrl_tapped.png b/img/ctrl_tapped.png
new file mode 100644
index 000000000..eecc75803
Binary files /dev/null and b/img/ctrl_tapped.png differ
diff --git a/img/decomposed.png b/img/decomposed.png
new file mode 100644
index 000000000..24168d98a
Binary files /dev/null and b/img/decomposed.png differ
diff --git a/img/edit_scheme.png b/img/edit_scheme.png
new file mode 100644
index 000000000..99e14ffa9
Binary files /dev/null and b/img/edit_scheme.png differ
diff --git a/img/editor.png b/img/editor.png
new file mode 100644
index 000000000..156f13856
Binary files /dev/null and b/img/editor.png differ
diff --git a/img/editorsettings.png b/img/editorsettings.png
new file mode 100644
index 000000000..0731cab7f
Binary files /dev/null and b/img/editorsettings.png differ
diff --git a/img/export.png b/img/export.png
new file mode 100644
index 000000000..1282cf116
Binary files /dev/null and b/img/export.png differ
diff --git a/img/export_dialog.png b/img/export_dialog.png
new file mode 100644
index 000000000..3c369ac4a
Binary files /dev/null and b/img/export_dialog.png differ
diff --git a/img/export_error.png b/img/export_error.png
new file mode 100644
index 000000000..db653ad4b
Binary files /dev/null and b/img/export_error.png differ
diff --git a/img/exportimages.png b/img/exportimages.png
new file mode 100644
index 000000000..78c676e99
Binary files /dev/null and b/img/exportimages.png differ
diff --git a/img/expres.png b/img/expres.png
new file mode 100644
index 000000000..fd69a4e8f
Binary files /dev/null and b/img/expres.png differ
diff --git a/img/expselected.png b/img/expselected.png
new file mode 100644
index 000000000..ad5cd2003
Binary files /dev/null and b/img/expselected.png differ
diff --git a/img/exptemp.png b/img/exptemp.png
new file mode 100644
index 000000000..22568caa3
Binary files /dev/null and b/img/exptemp.png differ
diff --git a/img/fixed_material_alpha.png b/img/fixed_material_alpha.png
new file mode 100644
index 000000000..00c881b55
Binary files /dev/null and b/img/fixed_material_alpha.png differ
diff --git a/img/fixed_material_blend.png b/img/fixed_material_blend.png
new file mode 100644
index 000000000..2631babeb
Binary files /dev/null and b/img/fixed_material_blend.png differ
diff --git a/img/fixed_material_colors.png b/img/fixed_material_colors.png
new file mode 100644
index 000000000..7d7d3526f
Binary files /dev/null and b/img/fixed_material_colors.png differ
diff --git a/img/fixed_material_detail.png b/img/fixed_material_detail.png
new file mode 100644
index 000000000..3fd015fd5
Binary files /dev/null and b/img/fixed_material_detail.png differ
diff --git a/img/fixed_material_glow.png b/img/fixed_material_glow.png
new file mode 100644
index 000000000..56f867684
Binary files /dev/null and b/img/fixed_material_glow.png differ
diff --git a/img/fixed_material_normal_depth.png b/img/fixed_material_normal_depth.png
new file mode 100644
index 000000000..4cff17c95
Binary files /dev/null and b/img/fixed_material_normal_depth.png differ
diff --git a/img/fixed_material_shader.png b/img/fixed_material_shader.png
new file mode 100644
index 000000000..eb0709b67
Binary files /dev/null and b/img/fixed_material_shader.png differ
diff --git a/img/fixed_material_vcols.png b/img/fixed_material_vcols.png
new file mode 100644
index 000000000..b97f3b721
Binary files /dev/null and b/img/fixed_material_vcols.png differ
diff --git a/img/fixed_materials.png b/img/fixed_materials.png
new file mode 100644
index 000000000..e6db7e2ec
Binary files /dev/null and b/img/fixed_materials.png differ
diff --git a/img/fontgradients.png b/img/fontgradients.png
new file mode 100644
index 000000000..72a88c6a4
Binary files /dev/null and b/img/fontgradients.png differ
diff --git a/img/fontimport.png b/img/fontimport.png
new file mode 100644
index 000000000..8cf3205c7
Binary files /dev/null and b/img/fontimport.png differ
diff --git a/img/fontspacing.png b/img/fontspacing.png
new file mode 100644
index 000000000..fa64128ed
Binary files /dev/null and b/img/fontspacing.png differ
diff --git a/img/godot_path.png b/img/godot_path.png
new file mode 100644
index 000000000..a4d8e1ef4
Binary files /dev/null and b/img/godot_path.png differ
diff --git a/img/groups.png b/img/groups.png
new file mode 100644
index 000000000..a57f2e048
Binary files /dev/null and b/img/groups.png differ
diff --git a/img/hdr_cave.png b/img/hdr_cave.png
new file mode 100644
index 000000000..208c32358
Binary files /dev/null and b/img/hdr_cave.png differ
diff --git a/img/hdr_gamma.png b/img/hdr_gamma.png
new file mode 100644
index 000000000..cfa7f771d
Binary files /dev/null and b/img/hdr_gamma.png differ
diff --git a/img/hdr_parameters.png b/img/hdr_parameters.png
new file mode 100644
index 000000000..84c705352
Binary files /dev/null and b/img/hdr_parameters.png differ
diff --git a/img/hdr_tonemap.png b/img/hdr_tonemap.png
new file mode 100644
index 000000000..588d2992f
Binary files /dev/null and b/img/hdr_tonemap.png differ
diff --git a/img/helloworld.png b/img/helloworld.png
new file mode 100644
index 000000000..6954426b1
Binary files /dev/null and b/img/helloworld.png differ
diff --git a/img/hw.png b/img/hw.png
new file mode 100644
index 000000000..f961079d8
Binary files /dev/null and b/img/hw.png differ
diff --git a/img/imagegroup.png b/img/imagegroup.png
new file mode 100644
index 000000000..f6315f479
Binary files /dev/null and b/img/imagegroup.png differ
diff --git a/img/import.png b/img/import.png
new file mode 100644
index 000000000..f2c56b630
Binary files /dev/null and b/img/import.png differ
diff --git a/img/import_images.png b/img/import_images.png
new file mode 100644
index 000000000..293fdad1f
Binary files /dev/null and b/img/import_images.png differ
diff --git a/img/importaudio.png b/img/importaudio.png
new file mode 100644
index 000000000..bbbd945bb
Binary files /dev/null and b/img/importaudio.png differ
diff --git a/img/importdialogs.png b/img/importdialogs.png
new file mode 100644
index 000000000..dc5b38fe0
Binary files /dev/null and b/img/importdialogs.png differ
diff --git a/img/importproject.png b/img/importproject.png
new file mode 100644
index 000000000..5a1d6a83a
Binary files /dev/null and b/img/importproject.png differ
diff --git a/img/importtex.png b/img/importtex.png
new file mode 100644
index 000000000..570ac8257
Binary files /dev/null and b/img/importtex.png differ
diff --git a/img/input_event_flow.png b/img/input_event_flow.png
new file mode 100644
index 000000000..9a9225f86
Binary files /dev/null and b/img/input_event_flow.png differ
diff --git a/img/inputmap.png b/img/inputmap.png
new file mode 100644
index 000000000..68199c2e3
Binary files /dev/null and b/img/inputmap.png differ
diff --git a/img/instancing.png b/img/instancing.png
new file mode 100644
index 000000000..3e2c27974
Binary files /dev/null and b/img/instancing.png differ
diff --git a/img/instancingpre.png b/img/instancingpre.png
new file mode 100644
index 000000000..c787414d4
Binary files /dev/null and b/img/instancingpre.png differ
diff --git a/img/instedit.png b/img/instedit.png
new file mode 100644
index 000000000..4986fddbc
Binary files /dev/null and b/img/instedit.png differ
diff --git a/img/instmany.png b/img/instmany.png
new file mode 100644
index 000000000..0259046f3
Binary files /dev/null and b/img/instmany.png differ
diff --git a/img/instmanyrun.png b/img/instmanyrun.png
new file mode 100644
index 000000000..9d5a3eb61
Binary files /dev/null and b/img/instmanyrun.png differ
diff --git a/img/inverse_kinematics.png b/img/inverse_kinematics.png
new file mode 100644
index 000000000..5ae843d15
Binary files /dev/null and b/img/inverse_kinematics.png differ
diff --git a/img/isettings.png b/img/isettings.png
new file mode 100644
index 000000000..34e2b58d7
Binary files /dev/null and b/img/isettings.png differ
diff --git a/img/kbinstance.png b/img/kbinstance.png
new file mode 100644
index 000000000..f8d9bf347
Binary files /dev/null and b/img/kbinstance.png differ
diff --git a/img/kbradius.png b/img/kbradius.png
new file mode 100644
index 000000000..8253c5676
Binary files /dev/null and b/img/kbradius.png differ
diff --git a/img/kbscene.png b/img/kbscene.png
new file mode 100644
index 000000000..4985ed4dc
Binary files /dev/null and b/img/kbscene.png differ
diff --git a/img/keyadded.png b/img/keyadded.png
new file mode 100644
index 000000000..26b70e9fe
Binary files /dev/null and b/img/keyadded.png differ
diff --git a/img/keybinds_2d.png b/img/keybinds_2d.png
new file mode 100644
index 000000000..e410563e3
Binary files /dev/null and b/img/keybinds_2d.png differ
diff --git a/img/keybinds_3d.png b/img/keybinds_3d.png
new file mode 100644
index 000000000..9dbd62307
Binary files /dev/null and b/img/keybinds_3d.png differ
diff --git a/img/keypress.png b/img/keypress.png
new file mode 100644
index 000000000..d02a48190
Binary files /dev/null and b/img/keypress.png differ
diff --git a/img/label.png b/img/label.png
new file mode 100644
index 000000000..5f68db685
Binary files /dev/null and b/img/label.png differ
diff --git a/img/light_attenuation.png b/img/light_attenuation.png
new file mode 100644
index 000000000..f3eaf60fa
Binary files /dev/null and b/img/light_attenuation.png differ
diff --git a/img/light_directional.png b/img/light_directional.png
new file mode 100644
index 000000000..8988ec459
Binary files /dev/null and b/img/light_directional.png differ
diff --git a/img/light_omni.png b/img/light_omni.png
new file mode 100644
index 000000000..40d38ee78
Binary files /dev/null and b/img/light_omni.png differ
diff --git a/img/light_params.png b/img/light_params.png
new file mode 100644
index 000000000..3253db080
Binary files /dev/null and b/img/light_params.png differ
diff --git a/img/light_spot.png b/img/light_spot.png
new file mode 100644
index 000000000..a2005fae6
Binary files /dev/null and b/img/light_spot.png differ
diff --git a/img/localization_dialog.png b/img/localization_dialog.png
new file mode 100644
index 000000000..906f34651
Binary files /dev/null and b/img/localization_dialog.png differ
diff --git a/img/localization_remaps.png b/img/localization_remaps.png
new file mode 100644
index 000000000..ff35fe4b1
Binary files /dev/null and b/img/localization_remaps.png differ
diff --git a/img/localized_name.png b/img/localized_name.png
new file mode 100644
index 000000000..c5d0b9112
Binary files /dev/null and b/img/localized_name.png differ
diff --git a/img/main_scene.png b/img/main_scene.png
new file mode 100644
index 000000000..ed1dbf62b
Binary files /dev/null and b/img/main_scene.png differ
diff --git a/img/margin.png b/img/margin.png
new file mode 100644
index 000000000..1d439110d
Binary files /dev/null and b/img/margin.png differ
diff --git a/img/marginaround.png b/img/marginaround.png
new file mode 100644
index 000000000..67da00a8b
Binary files /dev/null and b/img/marginaround.png differ
diff --git a/img/marginend.png b/img/marginend.png
new file mode 100644
index 000000000..20b94a694
Binary files /dev/null and b/img/marginend.png differ
diff --git a/img/material_depth_draw.png b/img/material_depth_draw.png
new file mode 100644
index 000000000..38f28c98b
Binary files /dev/null and b/img/material_depth_draw.png differ
diff --git a/img/material_flags.png b/img/material_flags.png
new file mode 100644
index 000000000..5cbe842b6
Binary files /dev/null and b/img/material_flags.png differ
diff --git a/img/material_unshaded.png b/img/material_unshaded.png
new file mode 100644
index 000000000..d8d992e0d
Binary files /dev/null and b/img/material_unshaded.png differ
diff --git a/img/mesh_dialog.png b/img/mesh_dialog.png
new file mode 100644
index 000000000..e7d2bc237
Binary files /dev/null and b/img/mesh_dialog.png differ
diff --git a/img/mesh_import.png b/img/mesh_import.png
new file mode 100644
index 000000000..6e442f47e
Binary files /dev/null and b/img/mesh_import.png differ
diff --git a/img/motion_diagram.png b/img/motion_diagram.png
new file mode 100644
index 000000000..ba4af2ecb
Binary files /dev/null and b/img/motion_diagram.png differ
diff --git a/img/motion_reflect.png b/img/motion_reflect.png
new file mode 100644
index 000000000..e155d4066
Binary files /dev/null and b/img/motion_reflect.png differ
diff --git a/img/move_cursor.png b/img/move_cursor.png
new file mode 100644
index 000000000..04dce14f5
Binary files /dev/null and b/img/move_cursor.png differ
diff --git a/img/neversaved.png b/img/neversaved.png
new file mode 100644
index 000000000..10de0d729
Binary files /dev/null and b/img/neversaved.png differ
diff --git a/img/newnode.png b/img/newnode.png
new file mode 100644
index 000000000..502571646
Binary files /dev/null and b/img/newnode.png differ
diff --git a/img/newproj.png b/img/newproj.png
new file mode 100644
index 000000000..86d81b66f
Binary files /dev/null and b/img/newproj.png differ
diff --git a/img/newproject.png b/img/newproject.png
new file mode 100644
index 000000000..b4a579d07
Binary files /dev/null and b/img/newproject.png differ
diff --git a/img/newscript.png b/img/newscript.png
new file mode 100644
index 000000000..5939764d3
Binary files /dev/null and b/img/newscript.png differ
diff --git a/img/nodes_resources.png b/img/nodes_resources.png
new file mode 100644
index 000000000..036ae1066
Binary files /dev/null and b/img/nodes_resources.png differ
diff --git a/img/nodesearch.png b/img/nodesearch.png
new file mode 100644
index 000000000..923886b82
Binary files /dev/null and b/img/nodesearch.png differ
diff --git a/img/oneclick.png b/img/oneclick.png
new file mode 100644
index 000000000..d4adf5642
Binary files /dev/null and b/img/oneclick.png differ
diff --git a/img/openworld_instancing.png b/img/openworld_instancing.png
new file mode 100644
index 000000000..8797f4a48
Binary files /dev/null and b/img/openworld_instancing.png differ
diff --git a/img/out.gif b/img/out.gif
new file mode 100644
index 000000000..26c59837e
Binary files /dev/null and b/img/out.gif differ
diff --git a/img/paranim1.gif b/img/paranim1.gif
new file mode 100644
index 000000000..02ccf4463
Binary files /dev/null and b/img/paranim1.gif differ
diff --git a/img/paranim10.gif b/img/paranim10.gif
new file mode 100644
index 000000000..cff13c413
Binary files /dev/null and b/img/paranim10.gif differ
diff --git a/img/paranim11.gif b/img/paranim11.gif
new file mode 100644
index 000000000..1bee8a977
Binary files /dev/null and b/img/paranim11.gif differ
diff --git a/img/paranim12.gif b/img/paranim12.gif
new file mode 100644
index 000000000..049b8c9d9
Binary files /dev/null and b/img/paranim12.gif differ
diff --git a/img/paranim13.gif b/img/paranim13.gif
new file mode 100644
index 000000000..abb1e7ac7
Binary files /dev/null and b/img/paranim13.gif differ
diff --git a/img/paranim14.gif b/img/paranim14.gif
new file mode 100644
index 000000000..070f49f1e
Binary files /dev/null and b/img/paranim14.gif differ
diff --git a/img/paranim15.gif b/img/paranim15.gif
new file mode 100644
index 000000000..d2ada7918
Binary files /dev/null and b/img/paranim15.gif differ
diff --git a/img/paranim16.gif b/img/paranim16.gif
new file mode 100644
index 000000000..a24aae807
Binary files /dev/null and b/img/paranim16.gif differ
diff --git a/img/paranim17.gif b/img/paranim17.gif
new file mode 100644
index 000000000..fcd248969
Binary files /dev/null and b/img/paranim17.gif differ
diff --git a/img/paranim18.gif b/img/paranim18.gif
new file mode 100644
index 000000000..140633c11
Binary files /dev/null and b/img/paranim18.gif differ
diff --git a/img/paranim19.gif b/img/paranim19.gif
new file mode 100644
index 000000000..dd178e31b
Binary files /dev/null and b/img/paranim19.gif differ
diff --git a/img/paranim2.gif b/img/paranim2.gif
new file mode 100644
index 000000000..d2732d5b4
Binary files /dev/null and b/img/paranim2.gif differ
diff --git a/img/paranim20.gif b/img/paranim20.gif
new file mode 100644
index 000000000..4333e9042
Binary files /dev/null and b/img/paranim20.gif differ
diff --git a/img/paranim21.gif b/img/paranim21.gif
new file mode 100644
index 000000000..1654e4c40
Binary files /dev/null and b/img/paranim21.gif differ
diff --git a/img/paranim3.gif b/img/paranim3.gif
new file mode 100644
index 000000000..87bde8188
Binary files /dev/null and b/img/paranim3.gif differ
diff --git a/img/paranim4.gif b/img/paranim4.gif
new file mode 100644
index 000000000..3dc492d3f
Binary files /dev/null and b/img/paranim4.gif differ
diff --git a/img/paranim5.gif b/img/paranim5.gif
new file mode 100644
index 000000000..b682704e2
Binary files /dev/null and b/img/paranim5.gif differ
diff --git a/img/paranim6.gif b/img/paranim6.gif
new file mode 100644
index 000000000..a60255234
Binary files /dev/null and b/img/paranim6.gif differ
diff --git a/img/paranim7.gif b/img/paranim7.gif
new file mode 100644
index 000000000..6306edc0a
Binary files /dev/null and b/img/paranim7.gif differ
diff --git a/img/paranim8.gif b/img/paranim8.gif
new file mode 100644
index 000000000..fcddf892f
Binary files /dev/null and b/img/paranim8.gif differ
diff --git a/img/paranim9.gif b/img/paranim9.gif
new file mode 100644
index 000000000..4aecc2902
Binary files /dev/null and b/img/paranim9.gif differ
diff --git a/img/particlecolorphases.png b/img/particlecolorphases.png
new file mode 100644
index 000000000..eff913bdd
Binary files /dev/null and b/img/particlecolorphases.png differ
diff --git a/img/particles1.png b/img/particles1.png
new file mode 100644
index 000000000..41577ec97
Binary files /dev/null and b/img/particles1.png differ
diff --git a/img/particles2.png b/img/particles2.png
new file mode 100644
index 000000000..04578429d
Binary files /dev/null and b/img/particles2.png differ
diff --git a/img/pause_popup.png b/img/pause_popup.png
new file mode 100644
index 000000000..68db85984
Binary files /dev/null and b/img/pause_popup.png differ
diff --git a/img/pausemode.png b/img/pausemode.png
new file mode 100644
index 000000000..3c3be5629
Binary files /dev/null and b/img/pausemode.png differ
diff --git a/img/physics2d_options.png b/img/physics2d_options.png
new file mode 100644
index 000000000..edd94d846
Binary files /dev/null and b/img/physics2d_options.png differ
diff --git a/img/playinst.png b/img/playinst.png
new file mode 100644
index 000000000..bf8ef5ffc
Binary files /dev/null and b/img/playinst.png differ
diff --git a/img/playscene.png b/img/playscene.png
new file mode 100644
index 000000000..af26018cc
Binary files /dev/null and b/img/playscene.png differ
diff --git a/img/pong_layout.png b/img/pong_layout.png
new file mode 100644
index 000000000..060738ff5
Binary files /dev/null and b/img/pong_layout.png differ
diff --git a/img/pong_nodes.png b/img/pong_nodes.png
new file mode 100644
index 000000000..0d1c6ef8e
Binary files /dev/null and b/img/pong_nodes.png differ
diff --git a/img/propertykeys.png b/img/propertykeys.png
new file mode 100644
index 000000000..11a5a3669
Binary files /dev/null and b/img/propertykeys.png differ
diff --git a/img/raycast_falsepositive.png b/img/raycast_falsepositive.png
new file mode 100644
index 000000000..7db77eb58
Binary files /dev/null and b/img/raycast_falsepositive.png differ
diff --git a/img/raycast_projection.png b/img/raycast_projection.png
new file mode 100644
index 000000000..302bdd7b2
Binary files /dev/null and b/img/raycast_projection.png differ
diff --git a/img/reimported.png b/img/reimported.png
new file mode 100644
index 000000000..32c03e004
Binary files /dev/null and b/img/reimported.png differ
diff --git a/img/resourcerobi.png b/img/resourcerobi.png
new file mode 100644
index 000000000..f03d24a59
Binary files /dev/null and b/img/resourcerobi.png differ
diff --git a/img/reverb.png b/img/reverb.png
new file mode 100644
index 000000000..e37eb9fe5
Binary files /dev/null and b/img/reverb.png differ
diff --git a/img/rfs_server.png b/img/rfs_server.png
new file mode 100644
index 000000000..fa07e5a4b
Binary files /dev/null and b/img/rfs_server.png differ
diff --git a/img/robisplashpreview.png b/img/robisplashpreview.png
new file mode 100644
index 000000000..b21868988
Binary files /dev/null and b/img/robisplashpreview.png differ
diff --git a/img/robisplashscene.png b/img/robisplashscene.png
new file mode 100644
index 000000000..a6d407836
Binary files /dev/null and b/img/robisplashscene.png differ
diff --git a/img/rtl_setup.png b/img/rtl_setup.png
new file mode 100644
index 000000000..33ad29d27
Binary files /dev/null and b/img/rtl_setup.png differ
diff --git a/img/saveasscript.png b/img/saveasscript.png
new file mode 100644
index 000000000..d4503bc9a
Binary files /dev/null and b/img/saveasscript.png differ
diff --git a/img/savescene.png b/img/savescene.png
new file mode 100644
index 000000000..0f63482a0
Binary files /dev/null and b/img/savescene.png differ
diff --git a/img/sb1.png b/img/sb1.png
new file mode 100644
index 000000000..8d1e60405
Binary files /dev/null and b/img/sb1.png differ
diff --git a/img/sb2.png b/img/sb2.png
new file mode 100644
index 000000000..8e54f3a9a
Binary files /dev/null and b/img/sb2.png differ
diff --git a/img/scene.png b/img/scene.png
new file mode 100644
index 000000000..0b57b4169
Binary files /dev/null and b/img/scene.png differ
diff --git a/img/screenres.png b/img/screenres.png
new file mode 100644
index 000000000..294e7bf51
Binary files /dev/null and b/img/screenres.png differ
diff --git a/img/script_template.png b/img/script_template.png
new file mode 100644
index 000000000..d3c9d66e5
Binary files /dev/null and b/img/script_template.png differ
diff --git a/img/scriptadded.png b/img/scriptadded.png
new file mode 100644
index 000000000..1656bf2d8
Binary files /dev/null and b/img/scriptadded.png differ
diff --git a/img/scriptcreate.png b/img/scriptcreate.png
new file mode 100644
index 000000000..bbac9e269
Binary files /dev/null and b/img/scriptcreate.png differ
diff --git a/img/scripthello.png b/img/scripthello.png
new file mode 100644
index 000000000..d0e587438
Binary files /dev/null and b/img/scripthello.png differ
diff --git a/img/scriptscene.png b/img/scriptscene.png
new file mode 100644
index 000000000..28fdff5d8
Binary files /dev/null and b/img/scriptscene.png differ
diff --git a/img/scriptsceneimg.png b/img/scriptsceneimg.png
new file mode 100644
index 000000000..d2abdeace
Binary files /dev/null and b/img/scriptsceneimg.png differ
diff --git a/img/shader_material_col.png b/img/shader_material_col.png
new file mode 100644
index 000000000..02647e6d8
Binary files /dev/null and b/img/shader_material_col.png differ
diff --git a/img/shader_material_create.png b/img/shader_material_create.png
new file mode 100644
index 000000000..b34198b0a
Binary files /dev/null and b/img/shader_material_create.png differ
diff --git a/img/shader_material_editor.png b/img/shader_material_editor.png
new file mode 100644
index 000000000..6730e868e
Binary files /dev/null and b/img/shader_material_editor.png differ
diff --git a/img/shader_material_typo.png b/img/shader_material_typo.png
new file mode 100644
index 000000000..15adf4178
Binary files /dev/null and b/img/shader_material_typo.png differ
diff --git a/img/shadow_directional.png b/img/shadow_directional.png
new file mode 100644
index 000000000..71f93cd48
Binary files /dev/null and b/img/shadow_directional.png differ
diff --git a/img/shadow_filter_options.png b/img/shadow_filter_options.png
new file mode 100644
index 000000000..85555dfcc
Binary files /dev/null and b/img/shadow_filter_options.png differ
diff --git a/img/shadow_offset_1.png b/img/shadow_offset_1.png
new file mode 100644
index 000000000..7aa6c1e9c
Binary files /dev/null and b/img/shadow_offset_1.png differ
diff --git a/img/shadow_offset_2.png b/img/shadow_offset_2.png
new file mode 100644
index 000000000..e1e3b13ed
Binary files /dev/null and b/img/shadow_offset_2.png differ
diff --git a/img/shadow_offset_3.png b/img/shadow_offset_3.png
new file mode 100644
index 000000000..265dcc074
Binary files /dev/null and b/img/shadow_offset_3.png differ
diff --git a/img/shadow_offset_4.png b/img/shadow_offset_4.png
new file mode 100644
index 000000000..5b8fbd4a2
Binary files /dev/null and b/img/shadow_offset_4.png differ
diff --git a/img/shadow_offset_5.png b/img/shadow_offset_5.png
new file mode 100644
index 000000000..bebb2f789
Binary files /dev/null and b/img/shadow_offset_5.png differ
diff --git a/img/shadow_omni.png b/img/shadow_omni.png
new file mode 100644
index 000000000..65bc3910a
Binary files /dev/null and b/img/shadow_omni.png differ
diff --git a/img/shadowoutline.png b/img/shadowoutline.png
new file mode 100644
index 000000000..67e4bcb85
Binary files /dev/null and b/img/shadowoutline.png differ
diff --git a/img/shape_rules.png b/img/shape_rules.png
new file mode 100644
index 000000000..5210c6769
Binary files /dev/null and b/img/shape_rules.png differ
diff --git a/img/shooter_instancing.png b/img/shooter_instancing.png
new file mode 100644
index 000000000..309b6569c
Binary files /dev/null and b/img/shooter_instancing.png differ
diff --git a/img/signals.png b/img/signals.png
new file mode 100644
index 000000000..455f2501e
Binary files /dev/null and b/img/signals.png differ
diff --git a/img/singlecontrol.png b/img/singlecontrol.png
new file mode 100644
index 000000000..3fa5621c4
Binary files /dev/null and b/img/singlecontrol.png differ
diff --git a/img/singleton.png b/img/singleton.png
new file mode 100644
index 000000000..cf1b112a3
Binary files /dev/null and b/img/singleton.png differ
diff --git a/img/skinbuttons1.png b/img/skinbuttons1.png
new file mode 100644
index 000000000..a7b49087c
Binary files /dev/null and b/img/skinbuttons1.png differ
diff --git a/img/skinbuttons2.png b/img/skinbuttons2.png
new file mode 100644
index 000000000..fbe875482
Binary files /dev/null and b/img/skinbuttons2.png differ
diff --git a/img/spriteprop.png b/img/spriteprop.png
new file mode 100644
index 000000000..525b451fb
Binary files /dev/null and b/img/spriteprop.png differ
diff --git a/img/spritewithcollision.png b/img/spritewithcollision.png
new file mode 100644
index 000000000..e26349aab
Binary files /dev/null and b/img/spritewithcollision.png differ
diff --git a/img/ssl_certs.png b/img/ssl_certs.png
new file mode 100644
index 000000000..b67ec0e68
Binary files /dev/null and b/img/ssl_certs.png differ
diff --git a/img/stretch.png b/img/stretch.png
new file mode 100644
index 000000000..cde6b7ea5
Binary files /dev/null and b/img/stretch.png differ
diff --git a/img/stretchsettings.png b/img/stretchsettings.png
new file mode 100644
index 000000000..9cce95fd9
Binary files /dev/null and b/img/stretchsettings.png differ
diff --git a/img/subviewport.png b/img/subviewport.png
new file mode 100644
index 000000000..ba461f436
Binary files /dev/null and b/img/subviewport.png differ
diff --git a/img/texbutton.png b/img/texbutton.png
new file mode 100644
index 000000000..502444c0d
Binary files /dev/null and b/img/texbutton.png differ
diff --git a/img/texframe.png b/img/texframe.png
new file mode 100644
index 000000000..ceb988d19
Binary files /dev/null and b/img/texframe.png differ
diff --git a/img/texscreen_bbc.png b/img/texscreen_bbc.png
new file mode 100644
index 000000000..b7c6414e2
Binary files /dev/null and b/img/texscreen_bbc.png differ
diff --git a/img/texscreen_demo1.png b/img/texscreen_demo1.png
new file mode 100644
index 000000000..82f6a7326
Binary files /dev/null and b/img/texscreen_demo1.png differ
diff --git a/img/texscreen_demo2.png b/img/texscreen_demo2.png
new file mode 100644
index 000000000..8dfff1ae3
Binary files /dev/null and b/img/texscreen_demo2.png differ
diff --git a/img/texscreen_visual_shader.png b/img/texscreen_visual_shader.png
new file mode 100644
index 000000000..d9e3967e7
Binary files /dev/null and b/img/texscreen_visual_shader.png differ
diff --git a/img/themecheck.png b/img/themecheck.png
new file mode 100644
index 000000000..272df73d0
Binary files /dev/null and b/img/themecheck.png differ
diff --git a/img/themeci.png b/img/themeci.png
new file mode 100644
index 000000000..12c8ad12b
Binary files /dev/null and b/img/themeci.png differ
diff --git a/img/themeci2.png b/img/themeci2.png
new file mode 100644
index 000000000..cedc87a0e
Binary files /dev/null and b/img/themeci2.png differ
diff --git a/img/themeci3.png b/img/themeci3.png
new file mode 100644
index 000000000..a1bc90606
Binary files /dev/null and b/img/themeci3.png differ
diff --git a/img/tile_example.png b/img/tile_example.png
new file mode 100644
index 000000000..b4776ce51
Binary files /dev/null and b/img/tile_example.png differ
diff --git a/img/tile_example2.png b/img/tile_example2.png
new file mode 100644
index 000000000..f8b8a91b0
Binary files /dev/null and b/img/tile_example2.png differ
diff --git a/img/tile_example3.png b/img/tile_example3.png
new file mode 100644
index 000000000..0e6e75b23
Binary files /dev/null and b/img/tile_example3.png differ
diff --git a/img/tile_example4.png b/img/tile_example4.png
new file mode 100644
index 000000000..25d8db2b6
Binary files /dev/null and b/img/tile_example4.png differ
diff --git a/img/tile_example5.png b/img/tile_example5.png
new file mode 100644
index 000000000..e2bc66427
Binary files /dev/null and b/img/tile_example5.png differ
diff --git a/img/tile_example6.png b/img/tile_example6.png
new file mode 100644
index 000000000..98dec82dc
Binary files /dev/null and b/img/tile_example6.png differ
diff --git a/img/tile_lock.png b/img/tile_lock.png
new file mode 100644
index 000000000..3d135a927
Binary files /dev/null and b/img/tile_lock.png differ
diff --git a/img/tilemap.png b/img/tilemap.png
new file mode 100644
index 000000000..fc4685832
Binary files /dev/null and b/img/tilemap.png differ
diff --git a/img/tilemap_scene.png b/img/tilemap_scene.png
new file mode 100644
index 000000000..0a81d4a91
Binary files /dev/null and b/img/tilemap_scene.png differ
diff --git a/img/tileset.png b/img/tileset.png
new file mode 100644
index 000000000..6cd1c42d6
Binary files /dev/null and b/img/tileset.png differ
diff --git a/img/tileset_edit_resource.png b/img/tileset_edit_resource.png
new file mode 100644
index 000000000..65f7f3ff6
Binary files /dev/null and b/img/tileset_edit_resource.png differ
diff --git a/img/tileset_export.png b/img/tileset_export.png
new file mode 100644
index 000000000..8a16b8a1c
Binary files /dev/null and b/img/tileset_export.png differ
diff --git a/img/tileset_filter.png b/img/tileset_filter.png
new file mode 100644
index 000000000..21db11061
Binary files /dev/null and b/img/tileset_filter.png differ
diff --git a/img/tileset_merge.png b/img/tileset_merge.png
new file mode 100644
index 000000000..cf14ae9f3
Binary files /dev/null and b/img/tileset_merge.png differ
diff --git a/img/tileset_property.png b/img/tileset_property.png
new file mode 100644
index 000000000..9430dc076
Binary files /dev/null and b/img/tileset_property.png differ
diff --git a/img/toptobottom.png b/img/toptobottom.png
new file mode 100644
index 000000000..16bde442c
Binary files /dev/null and b/img/toptobottom.png differ
diff --git a/img/trans.png b/img/trans.png
new file mode 100644
index 000000000..047b3da89
Binary files /dev/null and b/img/trans.png differ
diff --git a/img/tree.png b/img/tree.png
new file mode 100644
index 000000000..c923d60c9
Binary files /dev/null and b/img/tree.png differ
diff --git a/img/trim.png b/img/trim.png
new file mode 100644
index 000000000..15d09f294
Binary files /dev/null and b/img/trim.png differ
diff --git a/img/tuto_3d1.png b/img/tuto_3d1.png
new file mode 100644
index 000000000..28f509c44
Binary files /dev/null and b/img/tuto_3d1.png differ
diff --git a/img/tuto_3d10.png b/img/tuto_3d10.png
new file mode 100644
index 000000000..39d800e16
Binary files /dev/null and b/img/tuto_3d10.png differ
diff --git a/img/tuto_3d11.png b/img/tuto_3d11.png
new file mode 100644
index 000000000..ecf24b1cc
Binary files /dev/null and b/img/tuto_3d11.png differ
diff --git a/img/tuto_3d2.png b/img/tuto_3d2.png
new file mode 100644
index 000000000..0300665b1
Binary files /dev/null and b/img/tuto_3d2.png differ
diff --git a/img/tuto_3d3.png b/img/tuto_3d3.png
new file mode 100644
index 000000000..434dc1598
Binary files /dev/null and b/img/tuto_3d3.png differ
diff --git a/img/tuto_3d4.png b/img/tuto_3d4.png
new file mode 100644
index 000000000..000248f86
Binary files /dev/null and b/img/tuto_3d4.png differ
diff --git a/img/tuto_3d5.png b/img/tuto_3d5.png
new file mode 100644
index 000000000..56e27ac80
Binary files /dev/null and b/img/tuto_3d5.png differ
diff --git a/img/tuto_3d6.png b/img/tuto_3d6.png
new file mode 100644
index 000000000..9fad1a3a2
Binary files /dev/null and b/img/tuto_3d6.png differ
diff --git a/img/tuto_3d7.png b/img/tuto_3d7.png
new file mode 100644
index 000000000..169a191fa
Binary files /dev/null and b/img/tuto_3d7.png differ
diff --git a/img/tuto_3d8.png b/img/tuto_3d8.png
new file mode 100644
index 000000000..b72de069b
Binary files /dev/null and b/img/tuto_3d8.png differ
diff --git a/img/tuto_3d9.png b/img/tuto_3d9.png
new file mode 100644
index 000000000..91d449e99
Binary files /dev/null and b/img/tuto_3d9.png differ
diff --git a/img/tuto_cutout1.png b/img/tuto_cutout1.png
new file mode 100644
index 000000000..7bd711133
Binary files /dev/null and b/img/tuto_cutout1.png differ
diff --git a/img/tuto_cutout10.png b/img/tuto_cutout10.png
new file mode 100644
index 000000000..db484e4f0
Binary files /dev/null and b/img/tuto_cutout10.png differ
diff --git a/img/tuto_cutout11.png b/img/tuto_cutout11.png
new file mode 100644
index 000000000..6a8b289b3
Binary files /dev/null and b/img/tuto_cutout11.png differ
diff --git a/img/tuto_cutout12.png b/img/tuto_cutout12.png
new file mode 100644
index 000000000..aeaebdcb3
Binary files /dev/null and b/img/tuto_cutout12.png differ
diff --git a/img/tuto_cutout13.png b/img/tuto_cutout13.png
new file mode 100644
index 000000000..a11e05e96
Binary files /dev/null and b/img/tuto_cutout13.png differ
diff --git a/img/tuto_cutout14.png b/img/tuto_cutout14.png
new file mode 100644
index 000000000..73c846410
Binary files /dev/null and b/img/tuto_cutout14.png differ
diff --git a/img/tuto_cutout15.png b/img/tuto_cutout15.png
new file mode 100644
index 000000000..f317c03f1
Binary files /dev/null and b/img/tuto_cutout15.png differ
diff --git a/img/tuto_cutout16.png b/img/tuto_cutout16.png
new file mode 100644
index 000000000..0fe653055
Binary files /dev/null and b/img/tuto_cutout16.png differ
diff --git a/img/tuto_cutout17.png b/img/tuto_cutout17.png
new file mode 100644
index 000000000..d49eba9e6
Binary files /dev/null and b/img/tuto_cutout17.png differ
diff --git a/img/tuto_cutout18.png b/img/tuto_cutout18.png
new file mode 100644
index 000000000..250900d88
Binary files /dev/null and b/img/tuto_cutout18.png differ
diff --git a/img/tuto_cutout19.png b/img/tuto_cutout19.png
new file mode 100644
index 000000000..63e3d3f14
Binary files /dev/null and b/img/tuto_cutout19.png differ
diff --git a/img/tuto_cutout2.png b/img/tuto_cutout2.png
new file mode 100644
index 000000000..6f1732376
Binary files /dev/null and b/img/tuto_cutout2.png differ
diff --git a/img/tuto_cutout20.png b/img/tuto_cutout20.png
new file mode 100644
index 000000000..2befa01ba
Binary files /dev/null and b/img/tuto_cutout20.png differ
diff --git a/img/tuto_cutout21.png b/img/tuto_cutout21.png
new file mode 100644
index 000000000..0d970506f
Binary files /dev/null and b/img/tuto_cutout21.png differ
diff --git a/img/tuto_cutout22.png b/img/tuto_cutout22.png
new file mode 100644
index 000000000..df00a84c0
Binary files /dev/null and b/img/tuto_cutout22.png differ
diff --git a/img/tuto_cutout23.png b/img/tuto_cutout23.png
new file mode 100644
index 000000000..efe00a1b3
Binary files /dev/null and b/img/tuto_cutout23.png differ
diff --git a/img/tuto_cutout24.png b/img/tuto_cutout24.png
new file mode 100644
index 000000000..8729af922
Binary files /dev/null and b/img/tuto_cutout24.png differ
diff --git a/img/tuto_cutout3.png b/img/tuto_cutout3.png
new file mode 100644
index 000000000..37964616f
Binary files /dev/null and b/img/tuto_cutout3.png differ
diff --git a/img/tuto_cutout4.png b/img/tuto_cutout4.png
new file mode 100644
index 000000000..3ae5fff06
Binary files /dev/null and b/img/tuto_cutout4.png differ
diff --git a/img/tuto_cutout5.png b/img/tuto_cutout5.png
new file mode 100644
index 000000000..86928e452
Binary files /dev/null and b/img/tuto_cutout5.png differ
diff --git a/img/tuto_cutout6.png b/img/tuto_cutout6.png
new file mode 100644
index 000000000..e0a1d4700
Binary files /dev/null and b/img/tuto_cutout6.png differ
diff --git a/img/tuto_cutout7.png b/img/tuto_cutout7.png
new file mode 100644
index 000000000..dd187e820
Binary files /dev/null and b/img/tuto_cutout7.png differ
diff --git a/img/tuto_cutout8.png b/img/tuto_cutout8.png
new file mode 100644
index 000000000..184bc851b
Binary files /dev/null and b/img/tuto_cutout8.png differ
diff --git a/img/tuto_cutout9.png b/img/tuto_cutout9.png
new file mode 100644
index 000000000..b47da579a
Binary files /dev/null and b/img/tuto_cutout9.png differ
diff --git a/img/tuto_cutout_walk.gif b/img/tuto_cutout_walk.gif
new file mode 100644
index 000000000..900732b69
Binary files /dev/null and b/img/tuto_cutout_walk.gif differ
diff --git a/img/tutomat1.png b/img/tutomat1.png
new file mode 100644
index 000000000..44ecf3698
Binary files /dev/null and b/img/tutomat1.png differ
diff --git a/img/tutomat10.png b/img/tutomat10.png
new file mode 100644
index 000000000..a4c10e6b9
Binary files /dev/null and b/img/tutomat10.png differ
diff --git a/img/tutomat11.png b/img/tutomat11.png
new file mode 100644
index 000000000..23f8054a5
Binary files /dev/null and b/img/tutomat11.png differ
diff --git a/img/tutomat12.png b/img/tutomat12.png
new file mode 100644
index 000000000..845d349b5
Binary files /dev/null and b/img/tutomat12.png differ
diff --git a/img/tutomat13.png b/img/tutomat13.png
new file mode 100644
index 000000000..3ba4d43a2
Binary files /dev/null and b/img/tutomat13.png differ
diff --git a/img/tutomat14.png b/img/tutomat14.png
new file mode 100644
index 000000000..7a345d64d
Binary files /dev/null and b/img/tutomat14.png differ
diff --git a/img/tutomat15.png b/img/tutomat15.png
new file mode 100644
index 000000000..a899f1037
Binary files /dev/null and b/img/tutomat15.png differ
diff --git a/img/tutomat16.png b/img/tutomat16.png
new file mode 100644
index 000000000..e97436178
Binary files /dev/null and b/img/tutomat16.png differ
diff --git a/img/tutomat17.png b/img/tutomat17.png
new file mode 100644
index 000000000..1979862a5
Binary files /dev/null and b/img/tutomat17.png differ
diff --git a/img/tutomat2.png b/img/tutomat2.png
new file mode 100644
index 000000000..f21a20686
Binary files /dev/null and b/img/tutomat2.png differ
diff --git a/img/tutomat3.png b/img/tutomat3.png
new file mode 100644
index 000000000..b710f8d19
Binary files /dev/null and b/img/tutomat3.png differ
diff --git a/img/tutomat4.png b/img/tutomat4.png
new file mode 100644
index 000000000..ac8e46aa4
Binary files /dev/null and b/img/tutomat4.png differ
diff --git a/img/tutomat5.png b/img/tutomat5.png
new file mode 100644
index 000000000..7dc676bc6
Binary files /dev/null and b/img/tutomat5.png differ
diff --git a/img/tutomat6.png b/img/tutomat6.png
new file mode 100644
index 000000000..b3d9c9c89
Binary files /dev/null and b/img/tutomat6.png differ
diff --git a/img/tutomat7.png b/img/tutomat7.png
new file mode 100644
index 000000000..82f633b41
Binary files /dev/null and b/img/tutomat7.png differ
diff --git a/img/tutomat8.png b/img/tutomat8.png
new file mode 100644
index 000000000..45f2a1c72
Binary files /dev/null and b/img/tutomat8.png differ
diff --git a/img/tutomat9.png b/img/tutomat9.png
new file mode 100644
index 000000000..e8d68c026
Binary files /dev/null and b/img/tutomat9.png differ
diff --git a/img/tutovec1.png b/img/tutovec1.png
new file mode 100644
index 000000000..810f83028
Binary files /dev/null and b/img/tutovec1.png differ
diff --git a/img/tutovec10.png b/img/tutovec10.png
new file mode 100644
index 000000000..39bb54912
Binary files /dev/null and b/img/tutovec10.png differ
diff --git a/img/tutovec11.png b/img/tutovec11.png
new file mode 100644
index 000000000..e629816e1
Binary files /dev/null and b/img/tutovec11.png differ
diff --git a/img/tutovec12.png b/img/tutovec12.png
new file mode 100644
index 000000000..68c206e33
Binary files /dev/null and b/img/tutovec12.png differ
diff --git a/img/tutovec13.png b/img/tutovec13.png
new file mode 100644
index 000000000..0a3f31216
Binary files /dev/null and b/img/tutovec13.png differ
diff --git a/img/tutovec14.png b/img/tutovec14.png
new file mode 100644
index 000000000..37fbc8f0f
Binary files /dev/null and b/img/tutovec14.png differ
diff --git a/img/tutovec15.png b/img/tutovec15.png
new file mode 100644
index 000000000..5758fe8e5
Binary files /dev/null and b/img/tutovec15.png differ
diff --git a/img/tutovec16.png b/img/tutovec16.png
new file mode 100644
index 000000000..dac952ddf
Binary files /dev/null and b/img/tutovec16.png differ
diff --git a/img/tutovec17.png b/img/tutovec17.png
new file mode 100644
index 000000000..aff9e30ff
Binary files /dev/null and b/img/tutovec17.png differ
diff --git a/img/tutovec18.png b/img/tutovec18.png
new file mode 100644
index 000000000..45c982787
Binary files /dev/null and b/img/tutovec18.png differ
diff --git a/img/tutovec19.png b/img/tutovec19.png
new file mode 100644
index 000000000..abc9d863d
Binary files /dev/null and b/img/tutovec19.png differ
diff --git a/img/tutovec2.png b/img/tutovec2.png
new file mode 100644
index 000000000..f79d693af
Binary files /dev/null and b/img/tutovec2.png differ
diff --git a/img/tutovec2b.png b/img/tutovec2b.png
new file mode 100644
index 000000000..aab64abf3
Binary files /dev/null and b/img/tutovec2b.png differ
diff --git a/img/tutovec3.png b/img/tutovec3.png
new file mode 100644
index 000000000..3f85cb620
Binary files /dev/null and b/img/tutovec3.png differ
diff --git a/img/tutovec3b.png b/img/tutovec3b.png
new file mode 100644
index 000000000..941deeefe
Binary files /dev/null and b/img/tutovec3b.png differ
diff --git a/img/tutovec4.png b/img/tutovec4.png
new file mode 100644
index 000000000..d5e054aaa
Binary files /dev/null and b/img/tutovec4.png differ
diff --git a/img/tutovec5.png b/img/tutovec5.png
new file mode 100644
index 000000000..b80bf4d32
Binary files /dev/null and b/img/tutovec5.png differ
diff --git a/img/tutovec6.png b/img/tutovec6.png
new file mode 100644
index 000000000..168b94991
Binary files /dev/null and b/img/tutovec6.png differ
diff --git a/img/tutovec7.png b/img/tutovec7.png
new file mode 100644
index 000000000..082bc4679
Binary files /dev/null and b/img/tutovec7.png differ
diff --git a/img/tutovec8.png b/img/tutovec8.png
new file mode 100644
index 000000000..e50ee3852
Binary files /dev/null and b/img/tutovec8.png differ
diff --git a/img/tutovec9.png b/img/tutovec9.png
new file mode 100644
index 000000000..6070e7e88
Binary files /dev/null and b/img/tutovec9.png differ
diff --git a/img/tutovec_torso1.gif b/img/tutovec_torso1.gif
new file mode 100644
index 000000000..910de0624
Binary files /dev/null and b/img/tutovec_torso1.gif differ
diff --git a/img/tutovec_torso2.gif b/img/tutovec_torso2.gif
new file mode 100644
index 000000000..6b37c201d
Binary files /dev/null and b/img/tutovec_torso2.gif differ
diff --git a/img/tutovec_torso4.gif b/img/tutovec_torso4.gif
new file mode 100644
index 000000000..7abd59e1e
Binary files /dev/null and b/img/tutovec_torso4.gif differ
diff --git a/img/tutovec_torso5.gif b/img/tutovec_torso5.gif
new file mode 100644
index 000000000..d202b184a
Binary files /dev/null and b/img/tutovec_torso5.gif differ
diff --git a/img/viewport_transforms2.png b/img/viewport_transforms2.png
new file mode 100644
index 000000000..28bbe635f
Binary files /dev/null and b/img/viewport_transforms2.png differ
diff --git a/img/viewportnode.png b/img/viewportnode.png
new file mode 100644
index 000000000..6414c745b
Binary files /dev/null and b/img/viewportnode.png differ
diff --git a/index.rst b/index.rst
index 5c6b4e64d..1191b07fe 100644
--- a/index.rst
+++ b/index.rst
@@ -9,15 +9,25 @@ Welcome to Godot Engine's documentation!
The main documentation for the site is organized into a couple sections:
* :ref:`user-doc`
+* :ref:`contrib-doc`
.. toctree::
:maxdepth: 3
:caption: User documentation
:name: user-doc
-
+
+ tutorials/index
+ reference/index
asset_pipeline/index
advanced_topics/index
+.. toctree::
+ :maxdepth: 2
+ :caption: Contributor documentation
+ :name: contrib-doc
+
+ contributing/index
+
.. Indices and tables
.. ------------------
diff --git a/reference/2d_and_3d_keybindings.rst b/reference/2d_and_3d_keybindings.rst
new file mode 100644
index 000000000..818567534
--- /dev/null
+++ b/reference/2d_and_3d_keybindings.rst
@@ -0,0 +1,14 @@
+2D and 3D Keybindings
+=====================
+
+2D Viewport
+-----------
+
+.. image:: /img/keybinds_2d.png
+
+3D Viewport
+-----------
+
+.. image:: /img/keybinds_3d.png
+
+
diff --git a/reference/cheat_sheets.rst b/reference/cheat_sheets.rst
new file mode 100644
index 000000000..71bddf793
--- /dev/null
+++ b/reference/cheat_sheets.rst
@@ -0,0 +1,9 @@
+Cheat sheets
+============
+
+.. toctree::
+ :maxdepth: 1
+ :name: cheat-sheets
+
+ 2d_and_3d_keybindings
+ inheritance_class_tree
diff --git a/reference/gdscript.rst b/reference/gdscript.rst
new file mode 100644
index 000000000..f1be0bee8
--- /dev/null
+++ b/reference/gdscript.rst
@@ -0,0 +1,1046 @@
+Introduction
+============
+
+GDScript is a high level, dynamically typed programming language used to
+create content. It uses a syntax that is very similar to the Python
+language (blocks are indent-based) and its goal is to be very optimal
+and tightly integrated with the engine, allowing great flexibility for
+content creation and integration.
+
+History
+=======
+
+Initially, Godot was designed to support multiple scripting languages
+(this ability still exists today). However, only GDScript is in use
+right now. There is a little history behind this.
+
+In the early days, the engine used the `Lua `__
+scripting language. Lua is fast, but creating bindings to an object
+oriented system (by using fallbacks) was complex and slow and took an
+enormous amount of code. After some experiments with
+`Python `__, it also proved difficult to embed.
+
+The last third party scripting language that was used for shipped games
+was `Squirrel `__, but it was dropped as well.
+At that point, it became evident that Godot would work more optimally by
+using a built-in scripting language, as the following barriers were met:
+
+- Godot embeds scripts in nodes, most languages are not designed with
+ this in mind.
+- Godot uses several built-in data types for 2D and 3D math, script
+ languages do not provide this, and binding them is inefficient.
+- Godot uses threads heavily for lifting and initializing data from the
+ net or disk, script interpreters for common languages are not
+ friendly to this.
+- Godot already has a memory management model for resources, most
+ script languages provide their own, which resulted in duplicate
+ effort and bugs.
+- Binding code is always messy and results in several failure points,
+ unexpected bugs and generally low maintainability.
+
+Finally, GDScript was written as a custom solution. The language and
+interpreter for it ended up being smaller than the binding code itself
+for Lua and Squirrel, and equally as functional. With time, having a
+built-in language has proven to be a huge advantage.
+
+Example
+=======
+
+Some people can learn better by just taking a look at the syntax, so
+here's a simple example of how it looks.
+
+::
+
+ # a file is a class!
+
+ # inheritance
+
+ extends BaseClass
+
+ # member variables
+
+ var a = 5
+ var s = "Hello"
+ var arr = [1, 2, 3]
+ var dict = {"key":"value", 2:3}
+
+ # constants
+
+ const answer = 42
+ const thename = "Charly"
+
+ # built-in vector types
+
+ var v2 = Vector2(1, 2)
+ var v3 = Vector3(1, 2, 3)
+
+ # function
+
+ func some_function(param1, param2):
+ var local_var = 5
+
+ if param1 < local_var:
+ print(param1)
+ elif param2 > 5:
+ print(param2)
+ else:
+ print("fail!")
+
+ for i in range(20):
+ print(i)
+
+ while(param2 != 0):
+ param2 -= 1
+
+ var local_var2 = param1+3
+ return local_var2
+
+
+ # subclass
+
+ class Something:
+ var a = 10
+
+ # constructor
+
+ func _init():
+ print("constructed!")
+ var lv = Something.new()
+ print(lv.a)
+
+If you have previous experience with statically typed languages such as
+C, C++, or C# but never used a dynamically typed one, it is advised you
+read this tutorial: [[GDScript (More Efficiently)]].
+
+Language
+========
+
+Identifiers
+-----------
+
+Any string that restricts itself to alphabetic characters (``a`` to
+``z`` and ``A`` to ``Z``), digits (``0`` to ``9``) and ``_`` qualifies
+as an identifier. Additionally, identifiers must not begin with a digit.
+Identifiers are case-sensitive (``foo`` is different from ``FOO``).
+
+Keywords
+--------
+
+The following is the list of keywords supported by the language. Since
+keywords are reserved words (tokens), they can't be used as identifiers.
+
+Operators
+---------
+
+The following is the list of supported operators and their precedence
+(TODO, change since this was made to reflect python operators)
+
++---------------------------------------------------------------+-----------------------------------------+
+| **Operator** | **Description** |
++---------------------------------------------------------------+-----------------------------------------+
+| ``x[index]`` | Subscription, Highest Priority |
++---------------------------------------------------------------+-----------------------------------------+
+| ``x.attribute`` | Attribute Reference |
++---------------------------------------------------------------+-----------------------------------------+
+| ``extends`` | Instance Type Checker |
++---------------------------------------------------------------+-----------------------------------------+
+| ``~`` | Bitwise NOT |
++---------------------------------------------------------------+-----------------------------------------+
+| ``-x`` | Negative |
++---------------------------------------------------------------+-----------------------------------------+
+| ``*`` ``/`` ``%`` | Multiplication / Division / Remainder |
++---------------------------------------------------------------+-----------------------------------------+
+| ``+`` ``-`` | Addition / Subtraction |
++---------------------------------------------------------------+-----------------------------------------+
+| ``<<`` ``>>`` | Bit Shifting |
++---------------------------------------------------------------+-----------------------------------------+
+| ``&`` | Bitwise AND |
++---------------------------------------------------------------+-----------------------------------------+
+| ``^`` | Bitwise XOR |
++---------------------------------------------------------------+-----------------------------------------+
+| ``|`` | Bitwise OR |
++---------------------------------------------------------------+-----------------------------------------+
+| ``<`` ``>`` ``==`` ``!=`` ``>=`` ``<=`` | Comparisons |
++---------------------------------------------------------------+-----------------------------------------+
+| ``in`` | Content Test |
++---------------------------------------------------------------+-----------------------------------------+
+| ``!`` ``not`` | Boolean NOT |
++---------------------------------------------------------------+-----------------------------------------+
+| ``and`` ``&&`` | Boolean AND |
++---------------------------------------------------------------+-----------------------------------------+
+| ``or`` ``||`` | Boolean OR |
++---------------------------------------------------------------+-----------------------------------------+
+| ``=`` ``+=`` ``-=`` ``*=`` ``/=`` ``%=`` ``&=`` ``|=`` | Assignment, Lowest Priority |
++---------------------------------------------------------------+-----------------------------------------+
+
+Literals
+--------
+
++--------------------------+--------------------------------+
+| **Literal** | **Type** |
++--------------------------+--------------------------------+
+| ``45`` | Base 10 integer |
++--------------------------+--------------------------------+
+| ``0x8F51`` | Base 16 (hex) integer |
++--------------------------+--------------------------------+
+| ``3.14``, ``58.1e-10`` | Floating point number (real) |
++--------------------------+--------------------------------+
+| ``"Hello"``, ``"Hi"`` | Strings |
++--------------------------+--------------------------------+
+| ``"""Hello, Dude"""`` | Multiline string |
++--------------------------+--------------------------------+
+| ``@"Node/Label"`` | NodePath or StringName |
++--------------------------+--------------------------------+
+
+Comments
+--------
+
+Anything from a ``#`` to the end of the line is ignored and is
+considered a comment.
+
+::
+
+ # This is a comment
+
+Multi-line comments can be created using """ (three quotes in a row) at
+the beginning and end of a block of text.
+
+::
+
+ """ Everything on these
+ lines is considered
+ a comment """
+
+Built-In Types
+==============
+
+Basic Built-In Types
+--------------------
+
+A variable in GDScript can be assigned to several built-in types.
+
+null
+~~~~
+
+null is a data type that contains no information, nothing assigned, and
+it's just empty. It can only be set to one value: ``null``.
+
+bool
+~~~~
+
+The Boolean data type can only contain ``true`` or ``false``.
+
+int
+~~~
+
+The integer data type can only contain integer numbers, (both negative
+and positive).
+
+float
+~~~~~
+
+Used to contain a floating point value (real numbers).
+
+`String `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A sequence of characters in Unicode format. Strings can contain the
+standard C escape sequences.
+
+Vector Built-In Types
+---------------------
+
+`Vector2 `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+2D vector type containing ``x`` and ``y`` fields. Can alternatively
+access fields as ``width`` and ``height`` for readability. Can also be
+accessed as array.
+
+`Rect2 `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+2D Rectangle type containing two vectors fields: ``pos`` and ``size``.
+Alternatively contains an ``end`` field which is ``pos+size``.
+
+`Vector3 `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+3D vector type containing ``x``, ``y`` and ``z`` fields. This can also
+be accessed as an array.
+
+`Matrix32 `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+3x2 matrix used for 2D transforms.
+
+`Plane `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+3D Plane type in normalized form that contains a ``normal`` vector field
+and a ``d`` scalar distance.
+
+`Quat `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Quaternion is a datatype used for representing a 3D rotation. It's
+useful for interpolating rotations.
+
+`AABB `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Axis Aligned bounding box (or 3D box) contains 2 vectors fields: ``pos``
+and ``size``. Alternatively contains an ``end`` field which is
+``pos+size``. As an alias of this type, ``Rect3`` can be used
+interchangeably.
+
+`Matrix3 `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+3x3 matrix used for 3D rotation and scale. It contains 3 vector fields
+(``x``, ``y`` and ``z``) and can also be accessed as an array of 3D
+vectors.
+
+`Transform `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+3D Transform contains a Matrix3 field ``basis`` and a Vector3 field
+``origin``.
+
+Engine Built-In Types
+---------------------
+
+`Color `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Color data type contains ``r``, ``g``, ``b``, and ``a`` fields. It can
+also be accessed as ``h``, ``s``, and ``v`` for hue/saturation/value.
+
+`Image `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Contains a custom format 2D image and allows direct access to the
+pixels.
+
+`NodePath `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Compiled path to a node used mainly in the scene system. It can be
+easily assigned to, and from, a String.
+
+`RID `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Resource ID (RID). Servers use generic RIDs to reference opaque data.
+
+`Object `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Base class for anything that is not a built-in type.
+
+`InputEvent `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Events from input devices are contained in very compact form in
+InputEvent objects. Due to the fact that they can be received in high
+amounts from frame to frame they are optimized as their own data type.
+
+Container Built-In Types
+------------------------
+
+`Array `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Generic sequence of objects. Its size can be changed to anything and
+starts from index 0.
+
+::
+
+ var arr=[]
+ arr=[1, 2, 3]
+ arr[0] = "Hi!"
+
+Arrays are allocated linearly in memory, so they are fast, but very
+large arrays (more than tens of thousands of elements) may cause
+fragmentation.
+
+There are specialized arrays (listed below) for some built-in data types
+which do not suffer from this and use less memory, but they are atomic
+and generally run a little slower, so they are only justified for very
+large amount of data.
+
+`Dictionary `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Associative container which contains values referenced by unique keys.
+
+::
+
+ var d={4:5, "a key":"a value", 28:[1,2,3]}
+ d["Hi!"] = 0
+
+Lua-style table syntax is also supported, given that it's easier to
+write and read:
+
+::
+
+
+ var d = {
+ somekey = 2,
+ otherkey = [2,3,4],
+ morekey = "Hello"
+ }
+
+`ByteArray `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An array of bytes can only contain bytes (integers from 0 to 255).
+
+This, and all of the following specialized array types, are optimized
+for memory usage and can't fragment the memory.
+
+`IntArray `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Array of integers can only contain integers.
+
+`FloatArray `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Array of floats can only contain floats.
+
+`StringArray `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Array of strings can only contain strings.
+
+`Vector2Array `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Array of Vector2 can only contain 2D Vectors.
+
+`Vector3Array `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Array of Vector3 can only contain 3D Vectors.
+
+`ColorArray `__
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Array of Color can only contains colors.
+
+Data
+====
+
+Variables
+---------
+
+Variables can exist as class members or local to functions. They are
+created with the ``var`` keyword and may, optionally, be assigned a
+value upon initialization.
+
+::
+
+ var a # data type is null by default
+ var b = 5
+ var c = 3.8
+ var d = b + c # variables are always initialized in order
+
+Constants
+---------
+
+Constants are similar to variables, but must be constants or constant
+expressions and must be assigned on initialization.
+
+::
+
+ const a = 5
+ const b = Vector2(20, 20)
+ const c = 10 + 20 # constant expression
+ const d = Vector2(20, 30).x # constant expression: 20
+ const e = [1, 2, 3, 4][0] # constant expression: 1
+ const f = sin(20) # sin() can be used in constant expressions
+ const g = x + 20 # invalid; this is not a constant expression!
+
+Functions
+---------
+
+Functions always belong to a class. The scope priority for variable
+look-up is: local→class member→global. ``self`` is provided as an option
+for accessing class members, but is not always required (and must *not*
+be defined as the first parameter, like in Python). For performance
+reasons, functions are not considered class members, so they can't be
+referenced directly. A function can return at any point. The default
+return value is null.
+
+::
+
+ func myfunction(a, b):
+ print(a)
+ print(b)
+ return a + b # return is optional; without it null is returned
+
+Statements and Control Flow
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Statements are standard and can be assignments, function calls, control
+flow structures, etc (see below). ``;`` as a statement separator is
+entirely optional.
+
+if/else/elif
+~~~~~~~~~~~~
+
+Simple conditions are created by using the *if/else/elif* syntax.
+Parenthesis around statements is allowed, but not required. Given the
+nature of the tab-based indentation, elif can be used instead of
+else:/if: to maintain a level of indentation.
+
+::
+
+ if [expression]:
+ statement(s)
+ elif [expression]:
+ statement(s)
+ else:
+ statement(s)
+
+while
+~~~~~
+
+Simple loops are created by using *while* syntax. Loops can be broken
+using *break* or continued using *continue*:
+
+::
+
+ while [expression]:
+ statement(s)
+
+for
+~~~
+
+To iterate through a range, such as an array or table, a *for* loop is
+used. For loops store the index in the loop variable on each iteration.
+
+::
+
+ for i in [0, 1, 2]:
+ statement # loop iterates 3 times with i as 0, then 1 and finally 2
+
+ var dict = {"a":0, "b":1, "c":2}
+ for i in dict:
+ print(dict[i]) # loop iterates the keys; with i being "a","b" and "c" it prints 0, 1 and 2.
+
+ for i in range(3):
+ statement # similar to [0, 1, 2] but does not allocate an array
+
+ for i in range(1,3):
+ statement # similar to [1, 2] but does not allocate an array
+
+ for i in range(2,8,2):
+ statement # similar to [2, 4, 6] but does not allocate an array
+
+Function Call on Base Class
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To call a function on a base class (that was overridden in the current
+one), prepend ``.`` to the function name:
+
+::
+
+ .basefunc()
+
+However, remember that functions such as ``_init``, and most
+notifications such as ``_enter_tree``, ``_exit_tree``, ``_process``,
+``_fixed_process``, etc. are called in all base classes automatically,
+so this should be only for calling functions you write yourself.
+
+Classes
+=======
+
+By default, the body of a script file is an unnamed class and it can
+only be referenced externally as a resource or file. Class syntax is
+meant to be very compact and can only contain member variables or
+functions. Static functions are allowed, but not static members (this is
+in the spirit of thread safety since scripts can be initialized in
+separate threads without the user knowing). In the same way, member
+variables (including arrays and dictionaries) are initialized every time
+an instance is created.
+
+Class File Example
+------------------
+
+Imagine the following being stored in a file like myclass.gd.
+
+::
+
+ var a = 5
+
+ func print_value_of_a():
+ print(a)
+
+Inheritance
+-----------
+
+A class file can inherit from a global class, another file or a subclass
+inside another file. Multiple inheritance is not allowed. The
+``extends`` syntax is used. Follows is 3 methods of using extends:
+
+::
+
+ # extend from some class (global)
+ extends SomeClass
+
+::
+
+ # optionally, extend from another file
+ extends "somefile.gd"
+
+::
+
+ # extend from a subclass in another file
+ extends "somefile.gd".Subclass
+
+Inheritance Testing
+-------------------
+
+It's possible to check if an instance inherits from a given class. For
+this the ``extends`` keyword can be used as an operator instead:
+
+::
+
+ const enemy_class = preload("enemy.gd") # cache the enemy class
+
+ # [...]
+
+ if (entity extends enemy_class):
+ entity.apply_damage()
+
+Constructor
+-----------
+
+A class can have an optional constructor; a function named ``_init``
+that is called when the class is instanced.
+
+Arguments to Parent Constructor
+-------------------------------
+
+When inheriting, parent constructors are called automatically (no need
+to call ``._init()``). If a parent constructor takes arguments, they are
+passed like this:
+
+::
+
+ func _init(args).(parentargs):
+ pass
+
+Sub Classes
+-----------
+
+A class file can have subclasses. This syntax should be straightforward:
+
+::
+
+ class SomeSubClass:
+ var a = 5
+ func print_value_of_a():
+ print(a)
+
+ func _init():
+ var sc = SomeSubClass.new() #instance by calling built-in new
+ sc.print_value_of_a()
+
+Classes as Objects
+------------------
+
+It may be desired at some point to load a class from a file and then
+instance it. Since the global scope does not exist, classes must be
+loaded as a resource. Instancing is done by calling the ``new`` function
+in a class object:
+
+::
+
+ # load the class (loaded every time the script is instanced)
+ var MyClass = load("myclass.gd")
+
+ # alternatively, using the preload() function preloads the class at compile time
+ var MyClass2 = preload("myclass.gd")
+
+ func _init():
+ var a = MyClass.new()
+ a.somefunction()
+
+Exports
+-------
+
+Class members can be exported. This means their value gets saved along
+with a scene. If class members have initializers to constant
+expressions, they will be available for editing in the property editor.
+Exporting is done by using the export keyword:
+
+::
+
+ extends Button
+
+ export var data # value will be saved
+ export var number = 5 # also available to the property editor
+
+One of the fundamental benefits of exporting member variables is to have
+them visible in the property editor. This way artists and game designers
+can modify values that later influence how the program runs. For this, a
+special export syntax is provided for more detail in the exported
+variables:
+
+::
+
+ # if the exported value assigns a constant or constant expression, the type will be inferred and used in the editor
+
+ export var number = 5
+
+ # export can take a basic data type as an argument which will be used in the editor
+
+ export(int) var number
+
+ # export can also take a resource type to use as a hint
+
+ export(Texture) var character_face
+
+ # integers and strings hint enumerated values
+
+ export(int, "Warrior", "Magician", "Thief") var character_class # (editor will set them as 0, 1 and 2)
+ export(String, "Rebecca", "Mary", "Leah") var character_name
+
+ # strings as paths
+
+ export(String, FILE) var f # string is a path to a file
+ export(String, DIR) var f # string is a path to a directory
+ export(String, FILE, "*.txt") var f # string is a path to a file, custom filter provided as hint
+
+ # using paths in the global filesystem is also possible, but only in tool scripts (see further below)
+
+ export(String, FILE, GLOBAL, "*.png") var tool_image # string is a path to a PNG file in the global filesystem
+ export(String, DIR, GLOBAL) var tool_dir # string is a path to a directory in the global filesystem
+
+ # multiline strings
+
+ export(String, MULTILINE) var text # display a large window to edit strings with multiple lines
+
+ # integers and floats hint ranges
+
+ export(int, 20) var i # 0 to 20 allowed
+ export(int, -10, 20) var j # -10 to 20 allowed
+ export(float, -10, 20, 0.2) var k # -10 to 20 allowed, with stepping of 0.2
+ export(float, EXP, 100, 1000, 20) var l # exponential range, editing this property using the slider will set the value exponentially
+
+ # floats with easing hint
+
+ export(float, EASE) var transition_speed # display a visual representation of the ease() function when editing
+
+ # color can hint availability of alpha
+
+ export(Color, RGB) var col # Color is RGB
+ export(Color, RGBA) var col # Color is RGBA
+
+It must be noted that even if the script is not being run while at the
+editor, the exported properties are still editable (see below for
+"tool").
+
+Exporting bit flags
+~~~~~~~~~~~~~~~~~~~
+
+Integers used as bit flags can store multiple true/false (boolean)
+values in one property. By using the export hint ``int, FLAGS``, they
+can be set from the editor:
+
+::
+
+ export(int, FLAGS) var spell_elements = ELEMENT_WIND | ELEMENT_WATER # individually edit the bits of an integer
+
+Restricting the flags to a certain number of named flags is also
+possible. The syntax is very similar to the enumeration syntax:
+
+::
+
+ export(int, FLAGS, "Fire", "Water", "Earth", "Wind") var spell_elements = 0 # set any of the given flags from the editor
+
+In this example, ``Fire`` has value 1, ``Water`` has value 2, ``Earth``
+has value 4 and ``Wind`` corresponds to value 8. Usually, constants
+should be defined accordingly (e.g. ``const ELEMENT_WIND = 8`` and so
+on).
+
+Using bit flags requires some understanding of bitwise operations. If in
+doubt, boolean variables should be exported instead.
+
+Exporting Arrays
+~~~~~~~~~~~~~~~~
+
+Exporting arrays works too but there is a restriction. While regular
+arrays are created local to every instance, exported arrays are shared
+between all instances. This means that editing them in one instance will
+cause them to change in all other instances. Exported arrays can have
+initializers, but they must be constant expressions.
+
+::
+
+ # Exported array, shared between all instances.
+ # Default value must be a constant expression.
+
+ export var a=[1,2,3]
+
+ # Typed arrays also work, only initialized empty:
+
+ export var vector3s = Vector3Array()
+ export var strings = StringArray()
+
+ # Regular array, created local for every instance.
+ # Default value can include run-time values, but can't
+ # be exported.
+
+ var b = [a,2,3]
+
+Static Functions
+----------------
+
+A function can be declared static. When a function is static it has no
+access to the instance member variables or ``self``. This is mainly
+useful to make libraries of helper functions:
+
+::
+
+ static func sum2(a, b):
+ return a + b
+
+Setters/Getters
+---------------
+
+| It is often useful to know when an member variable changed. It may
+ also be desired to encapsulate its access. For this, GDScript provides
+ a *setter\_/\_getter* helper using the ``setget`` keyword.
+| Just add it at the end of the variable definition line like this:
+
+::
+
+ var myinteger = 5 setget myinteger_changed
+
+If the value of ``myinteger`` is modified *externally* (not from local
+usage in the class), the *setter* function will be called beforehand.
+The *setter* must, then, decide what to do with the new value. The
+*setter function* looks like this:
+
+::
+
+ func myinteger_changed(newvalue):
+ myinteger=newvalue
+
+A *setter* and a *getter* can be used together too, just define both of
+them:
+
+::
+
+ var myvar setget myvar_set,myvar_get
+
+ func myvar_set(newvalue):
+ myvar=newvalue
+
+ func myvar_get():
+ return myvar # getter must return a value
+
+Using simply a *getter* is possible too, just skip the setter:
+
+::
+
+ var myvar setget ,myvar_get
+
+This is especially useful when exporting variables to editor in tool
+scripts or plugins, for validating input.
+
+Note: As mentioned before, local access will not trigger the setter and
+getter. For example:
+
+::
+
+ func _init():
+ #does not trigger setter/getter
+ myinteger=5
+ print(myinteger)
+ #triggers setter/getter
+ self.myinteger=5
+ print(self.myinteger)
+
+Tool Mode
+---------
+
+Scripts, by default, don't run inside the editor and only the exported
+properties can be changed. In some cases it is desired that they do run
+inside the editor (as long as they don't execute game code or manually
+avoid doing so). For this, the ``tool`` keyword exists and must be
+placed at the top of the file:
+
+::
+
+ tool
+ extends Button
+
+ func _ready():
+ print("Hello")
+
+Memory Management
+-----------------
+
+If a class inherits from [[Class:Reference]], then instances will be
+freed when no longer in use. No garbage collector exists, just simple
+reference counting. By default, all classes that don't define
+inheritance extend **Reference**. If this is not desired, then a class
+must inherit [[Class:Object]] manually and must call instance.free(). To
+avoid reference cycles that can't be freed, a ``weakref`` function is
+provided for creating weak references.
+
+Function References
+-------------------
+
+Functions can't be referenced because they are not treated as class
+members. There are two alternatives to this, though. The ``call``
+function or the ``funcref`` helper.
+
+::
+
+ instance.call("funcname", args) # call a function by name
+
+ var fr = funcref(instance, "funcname") # create a function ref
+ fr.call_func(args)
+
+Signals
+-------
+
+It is often desired to send a notification that something happened in an
+instance. GDScript supports creation of built-in Godot signals.
+Declaring a signal in GDScript is easy, in the body of the class, just
+write:
+
+::
+
+ # no arguments
+ signal your_signal_name
+ # with arguments
+ signal your_signal_name_with_args(a,b)
+
+These signals, just like regular signals, can be connected in the editor
+or from code. Just take the instance of a class where the signal was
+declared and connect it to the method of another instance:
+
+::
+
+ func _callback_no_args():
+ print("Got callback!")
+
+ func _callback_args(a,b):
+ print("Got callback with args! a: ",a," and b: ",b)
+
+ func _at_some_func():
+ instance.connect("your_signal_name",self,"callback_no_args")
+ instance.connect("your_signal_name_with_args",self,"callback_args")
+
+It is also possible to bind arguments to a signal that lacks them with
+your custom values:
+
+::
+
+ func _at_some_func():
+ instance.connect("your_signal_name_with_args",self,"callback_no_args",[22,"hello"])
+
+This is very useful when a signal from many objects is connected to a
+single callback and the sender must be identified:
+
+::
+
+ func _button_pressed(which):
+ print("Button was pressed: ",which.get_name())
+
+ func _ready():
+ for b in get_node("buttons").get_children():
+ b.connect("pressed",self,"_button_pressed",[b])
+
+Finally, emitting a custom signal is done by using the
+Object.emit\_signal method:
+
+::
+
+ func _at_some_func():
+ emit_signal("your_signal_name")
+ emit_signal("your_signal_name_with_args",55,128)
+ someinstance.emit_signal("somesignal")
+
+Coroutines
+----------
+
+GDScript has some support for coroutines via the ``yield`` built-in
+function. The way it works is very simple: Calling ``yield()`` will
+immediately return from the current function, with the current frozen
+state of the same function as the return value. Calling ``resume`` on
+this resulting object will continue execution and return whatever the
+function returns. Once resumed the state object becomes invalid. Here is
+an example:
+
+::
+
+ func myfunc():
+
+ print("hello")
+ yield()
+ print("world")
+
+ func _ready():
+
+ var y = myfunc()
+ #function state saved in 'y'
+ print("my dear")
+ y.resume()
+ # 'y' resumed and is now an invalid state
+
+Will print:
+
+::
+
+ hello
+ my dear
+ world
+
+It is also possible to pass values between yield() and resume(), for
+example:
+
+::
+
+ func myfunc():
+
+ print("hello")
+ print( yield() )
+ return "cheers!"
+
+ func _ready():
+
+ var y = myfunc()
+ #function state saved in 'y'
+ print( y.resume("world") )
+ # 'y' resumed and is now an invalid state
+
+Will print:
+
+::
+
+ hello
+ world
+ cheers!
+
+Coroutines & Signals
+--------------------
+
+The real strength of using ``yield`` is when combined with signals.
+``yield`` can accept two parameters, an object and a signal. When the
+signal is activated, execution will return. Here are some examples:
+
+::
+
+ #resume execution the next frame
+ yield( get_tree(), "idle_frame" )
+
+ #resume execution when animation is done playing:
+ yield( get_node("AnimationPlayer"), "finished" )
diff --git a/reference/gdscript_more_efficiently.rst b/reference/gdscript_more_efficiently.rst
new file mode 100644
index 000000000..99a529db0
--- /dev/null
+++ b/reference/gdscript_more_efficiently.rst
@@ -0,0 +1,476 @@
+Using GDScript Efficiently
+==========================
+
+About
+-----
+
+This tutorial aims to be a quick reference for how to use GDScript more
+efficiently. It focuses in common cases specific to the language, but
+also covers a lot related to using dynamically typed languages.
+
+It's meant to be specially useful for programmers without previous or
+little experience of dynamically typed languages.
+
+Dynamic Nature
+--------------
+
+Pros & Cons of Dynamic Typing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+GDScript is a Dynamically Typed language. As such, it's main advantages
+are that:
+
+- Language is very simple to learn.
+- Most code can be written and changed quickly and without hassle.
+- Less code written means less errors & mistakes to fix.
+- Easier to read the code (less clutter).
+- No compilation is required to test.
+- Run-Time is tiny.
+- [[API:Duck-Typing]] and [[API:Polymorphism]] by nature.
+
+While the main cons are:
+
+- Less performance than statically typed languages.
+- More difficult to refactor (symbols can't be traced)
+- Some errors that would typically be detected at compile time in
+ statically typed languages only appear while running the code
+ (because expression parsing is more strict).
+- Less flexibility for code-completion (some variable types are only
+ known at run-time).
+
+This, translated to reality, means that Godot+GDScript are a combination
+designed to games very quickly and efficiently. For games that are very
+computationally intensive and can't benefit from the engine built-in
+tools (such as the Vector types, Physics Engine, Math library, etc), the
+possibility of using C++ is present too. This allows to still create the
+entire game in GDScript and add small bits of C++ in the areas that need
+a boost.
+
+Variables & Assignment
+~~~~~~~~~~~~~~~~~~~~~~
+
+All variables in a dynamicaly typed language are "variant"-like. This
+means that their type is not fixed, and is only modified through
+assignment. Example:
+
+Static:
+
+::
+
+ int a; // value uninitialized
+ a=5; // this is valid
+ a="Hi!"; // this is invalid
+
+Dynamic:
+
+::
+
+ var a # null by default
+ a=5 # valid, 'a' becomes an integer
+ a="Hi!" # valid, 'a' changed to a string
+
+As Function Arguments:
+~~~~~~~~~~~~~~~~~~~~~~
+
+Functions are of dynamic nature too, which means they can be called with
+different arguments, for example:
+
+Static:
+
+::
+
+ void print_value(int value)
+ {
+ printf("value is %i\\n",value);
+ }
+
+ [..]
+
+ print_value(55); // valid
+ print_value("Hello"); // invalid
+
+Dynamic:
+
+::
+
+ func print_value(value):
+ print(value)
+ [..]
+
+ print_value(55) # valid
+ print_value("Hello") # valid
+
+Pointers & Referencing:
+~~~~~~~~~~~~~~~~~~~~~~~
+
+In static languages such as C or C++ (and to some extent Java and C#),
+there is a distinction between a variable and a pointer/reference to a
+variable. The later allows the object to be modified by other functions
+by passing a reference to the original one.
+
+In C# or Java, everything not a built-in type (int, float, sometimes
+String) is always a pointer or a reference. References are also
+garbage-collected automatically, which means they are erased when no
+onger used. Dynamically typed languages tend to use this memory model
+too. Some Examples:
+
+// C++
+
+::
+
+ void use_class(SomeClass *instance) {
+
+ instance->use();
+ }
+
+ void do_something() {
+
+ SomeClass *instance = new SomeClass; //created as pointer
+ use_class(instance); //pass as pointer
+ delete instance; //otherwise it will leak memory
+ }
+
+Java:
+
+::
+
+ @Override
+ public final void use_class(SomeClass instance) {
+
+ instance.use();
+ }
+
+ public final void do_something() {
+
+ SomeClass instance = new SomeClass(); //created as reference
+ use_class(instance); //pass as reference
+ //garbage collector will get rid of it when not in
+ //use and freeze your game randomly for a second
+ }
+
+GDScript:
+
+::
+
+ func use_class(instance); #does not care about class type
+ instance.use() # will work with any class that has a ".use()" method.
+
+ func do_something():
+ var instance = SomeClass.new() # created as reference
+ use_class(instance) # pass as reference
+ #will be unreferenced and deleted
+
+In GDScript, only base types (int, float, string and the vector types)
+are passed by value to functions (value is copied). Everything else
+(instances, arrays, dictionaries, etc) is passed as reference. Classes
+that inherit [[API:Reference]] (the default if nothing is specified)
+will be freed when not used, but manual memory management is allowed too
+if inheriting manualy from [[API:Object]].
+
+Arrays
+------
+
+Arrays in dynamically typed languages can contain many different mixed
+datatypes inside and are always dynamic (can be resized at any time).
+Example:
+
+::
+
+ int *array = new int[4]; //create array
+ array[0]=10; //initialize manually
+ array[1]=20; //can't mix types
+ array[2]=40;
+ array[3]=60;
+ //can't resize
+ use_array(array); //passed as pointer
+ delete[] array; //must be freed
+
+//or
+
+::
+
+ std::vector array;
+ array.resize(4);
+ array[0]=10; //initialize manually
+ array[1]=20; //can't mix types
+ array[2]=40;
+ array[3]=60;
+ array.resize(3); //can be resized
+ use_array(array); //passed reference or value
+ //freed when stack ends
+
+GDScript:
+
+::
+
+ var array = [10, "hello", 40, 60] # simple, and can mix types
+ array.resize(3) # can be resized
+ use_array(array) # passed as reference
+ #freed when no longer in use
+
+In dynamically typed languages, arrays can also double as other
+datatypes, such as lists:
+
+::
+
+ var array = []
+ array.append(4)
+ array.append(5)
+ array.pop_front()
+
+or unordered sets:
+
+::
+
+ var a = 20
+ if a in [10,20,30]:
+ print("We have a Winner!")
+
+Dictionaries
+------------
+
+Dictionaries are always a very powerful in dynamically typed languages.
+Most programmers that come from statically typed languages (such as C++
+or C#) ignore their existence and make their life unnecessarily more
+difficult. This datatype is generally not present in such languages (or
+only on limited form).
+
+Dictionaries can map any value to any other value with complete
+disregard for the datatype used as either key or value. Contrary to
+popular belief, they are very efficient because they can be implemented
+with hash tables. They are, in fact, so efficient that languages such as
+Lua will go as far as implementing arrays as dictionaries.
+
+Example of Dictionary:
+
+::
+
+ var d = { "name":"john", "age":22 } # simple syntax
+ print("Name: ", d["name"], " Age: ", d["age"] )
+
+Dictionaries are also dynamic, keys can be added or removed at any point
+at little cost:
+
+::
+
+ d["mother"]="Rebecca" # addition
+ d["age"]=11 # modification
+ d.erase("name") #removal
+
+In most cases, two-dimensional arrays can often be implemented more
+easily with dictionaries. Here's a simple battleship game example:
+
+::
+
+ #battleship game
+
+ const SHIP=0
+ const SHIP_HIT=1
+ const WATER_HIT=2
+
+ var board={}
+
+ func initialize():
+ board[Vector(1,1)]=SHIP
+ board[Vector(1,2)]=SHIP
+ board[Vector(1,3)]=SHIP
+
+ func missile(pos):
+
+ if pos in board: #something at that pos
+ if board[pos]==SHIP: #there was a ship! hit it
+ board[pos]=SHIP_HIT
+ else:
+ print("already hit here!") # hey dude you already hit here
+ else: #nothing, mark as water
+ board[pos]=WATER_HIT
+
+ func game():
+ initialize()
+ missile( Vector2(1,1) )
+ missile( Vector2(5,8) )
+ missile( Vector2(2,3) )
+
+Dictionaries can also be used as data markup or quick structures. While
+GDScript dictionaries resemble python dictionaries, it also supports Lua
+style syntax an indexing, which makes it very useful for writing initial
+states and quick structs:
+
+::
+
+ # same example, lua-style support
+ # this syntax is a lot more readable and usable
+
+ var d = {
+ name="john",
+ age=22
+ }
+
+ print("Name: ", d.name, " Age: ", d.age ) # used "." based indexing
+
+ # indexing
+
+ d.nother="rebecca" #this doesn't work (use syntax below to add a key:value pair)
+ d["mother"]="rebecca" #this works
+ d.name="caroline" # if key exists, assignment does work, this is why it's like a quick struct.
+
+For & While
+-----------
+
+Iterating in some statically typed languages can be quite complex:
+
+::
+
+ const char* strings = new const char*[50];
+
+ [..]
+
+ for(int i=0;i<50;i++)
+ {
+
+ printf("value: %s\\n",i,strings[i]);
+ }
+
+ //Even in STL:
+
+ for(std::list::const_iterator it = strings.begin() ; it != strings.end() ; it++) {
+
+ std::cout << *it << std::endl;
+ }
+
+This is usually greatly simplified in dynamically typed languages:
+
+::
+
+ for s in strings:
+ print(s)
+
+Container datatypes (arrays and dictionaries) are iterable. Dictionaries
+allow iterating the keys:
+
+::
+
+ for key in dict:
+ print(key," -> ",dict[key])
+
+Iterating with indices is also possible:
+
+::
+
+ for i in range(strings.size()):
+ print(strings[i])
+
+The range() function can take 3 arguments:
+
+::
+
+ range(n) (will go from 0 to n-1)
+ range(b,n) (will go from b to n-1)
+ range(b,n,s) (will go from b to n-1, in steps of s)
+
+Some examples:
+
+::
+
+ for(int i=0;i<10;i++) {}
+
+ for(int i=5;i<10;i++) {}
+
+ for(int i=5;i<10;i+=2) {}
+
+Translate to:
+
+::
+
+ for i in range(10):
+
+ for i in range(5,10):
+
+ for i in range(5,10,2):
+
+And backwards looping is done through a negative counter:
+
+::
+
+ for(int i=10;i>0;i--) {}
+
+becomes
+
+::
+
+ for i in range(10,0,-1):
+
+While
+-----
+
+While() loops are the same everywhere:
+
+::
+
+ var i=0
+
+ while(i
+
+Duck Typing
+-----------
+
+One of the most difficult concepts to grasp when moving from a
+statically typed language to a dynamic one is Duck Typing. Duck typing
+makes overall code design much simpler and straightforward to write, but
+it's not obvious how it works.
+
+As an example, imagine a situation where a big rock is falling down a
+tunnel, smashing everything on it's way. The code for the rock, in a
+statically typed language would be something like:
+
+::
+
+ void BigRollingRock::on_object_hit(Smashable *entity)
+ {
+ entity->smash();
+ }
+
+This, way, everything that can be smashed by a rock would have to
+inherit Smashable. If a character, enemy, piece of furniture, small rock
+were all smashable, they would need to inherit from the class Smashable,
+possibly requiring multiple inheritance. If multiple inheritance was
+undesired, then they would have to inherit a common class like Entity.
+Yet, it would not be very elegant to add a virtual method "smash()" to
+Entity only if a few of them can be smashed.
+
+With dynamically typed languages, this is not a problem. Duck typing
+makes sure you only have to define a smash() function where required and
+that's it. No need to consider inheritance, base classes, etc.
+
+::
+
+ func _on_object_hit(object):
+ object.smash()
+
+And that's it. If the object that hit the big rock has a smash() method,
+it will be called. No need for inheritance or polymorphysm. Dynamically
+typed languages only care about the instance having the desired method
+or member, not what it inherits or the class type. The definition of
+Duck Typing should make this clearer:
+
+*"When I see a bird that walks like a duck and swims like a duck and
+quacks like a duck, I call that bird a duck"*
+
+In this case, it translates to:
+
+*"If the object can be smashed, don't care what it is, just smash it."*
+
+Yes, we should call it Hulk typing instead. Anyway though, there exists
+the possibility of the object being hit not having a smash() function.
+Some dynamically typed languages simply ignore a method call when it
+doesn't exist (like Objective C), but GDScript is more strict, so
+checking if the function exists is desirable:
+
+::
+
+ func _on_object_hit(object):
+ if (object.has_method("smash")):
+ object.smash()
+
+Then, simply define that method and anything the rock touches can be
+smashed.
diff --git a/reference/index.rst b/reference/index.rst
new file mode 100644
index 000000000..4496aa098
--- /dev/null
+++ b/reference/index.rst
@@ -0,0 +1,10 @@
+Reference
+=========
+
+.. toctree::
+ :maxdepth: 2
+ :name: reference
+
+ reference_filling_work
+ languages
+ cheat_sheets
diff --git a/reference/inheritance_class_tree.rst b/reference/inheritance_class_tree.rst
new file mode 100644
index 000000000..28c8a4506
--- /dev/null
+++ b/reference/inheritance_class_tree.rst
@@ -0,0 +1,33 @@
+Inheritance Class Tree
+======================
+
+2.0 A
+
+Object
+------
+
+.. image:: /img/Object.png
+
+Reference
+---------
+
+.. image:: /img/Reference.png
+
+Control
+-------
+
+.. image:: /img/Control.png
+
+Node2D
+------
+
+.. image:: /img/Node2D.png
+
+Spatial
+-------
+
+.. image:: /img/Spatial.png
+
+attachment:sources.zip
+
+
diff --git a/reference/languages.rst b/reference/languages.rst
new file mode 100644
index 000000000..6e8772fa9
--- /dev/null
+++ b/reference/languages.rst
@@ -0,0 +1,12 @@
+Languages
+=========
+
+.. toctree::
+ :maxdepth: 1
+ :name: languages
+
+ gdscript
+ gdscript_more_efficiently
+ shader
+ locales
+ richtextlabel_bbcode
diff --git a/reference/locales.rst b/reference/locales.rst
new file mode 100644
index 000000000..68c9e73b1
--- /dev/null
+++ b/reference/locales.rst
@@ -0,0 +1,315 @@
+Locales
+=======
+
+This is the list of supported locales and variants in the engine. It's
+based on the Unix standard locale strings:
+
++--------------+------------------------------------+
+| Locale | Language and Variant |
++==============+====================================+
+| ar | Arabic |
++--------------+------------------------------------+
+| ar\_AE | Arabic (United Arab Emirates) |
++--------------+------------------------------------+
+| ar\_BH | Arabic (Bahrain) |
++--------------+------------------------------------+
+| ar\_DZ | Arabic (Algeria) |
++--------------+------------------------------------+
+| ar\_EG | Arabic (Egypt) |
++--------------+------------------------------------+
+| ar\_IQ | Arabic (Iraq) |
++--------------+------------------------------------+
+| ar\_JO | Arabic (Jordan) |
++--------------+------------------------------------+
+| ar\_KW | Arabic (Kuwait) |
++--------------+------------------------------------+
+| ar\_LB | Arabic (Lebanon) |
++--------------+------------------------------------+
+| ar\_LY | Arabic (Libya) |
++--------------+------------------------------------+
+| ar\_MA | Arabic (Morocco) |
++--------------+------------------------------------+
+| ar\_OM | Arabic (Oman) |
++--------------+------------------------------------+
+| ar\_QA | Arabic (Qatar) |
++--------------+------------------------------------+
+| ar\_SA | Arabic (Saudi Arabia) |
++--------------+------------------------------------+
+| ar\_SD | Arabic (Sudan) |
++--------------+------------------------------------+
+| ar\_SY | Arabic (Syria) |
++--------------+------------------------------------+
+| ar\_TN | Arabic (Tunisia) |
++--------------+------------------------------------+
+| ar\_YE | Arabic (Yemen) |
++--------------+------------------------------------+
+| be | Belarusian |
++--------------+------------------------------------+
+| be\_BY | Belarusian (Belarus) |
++--------------+------------------------------------+
+| bg | Bulgarian |
++--------------+------------------------------------+
+| bg\_BG | Bulgarian (Bulgaria) |
++--------------+------------------------------------+
+| ca | Catalan |
++--------------+------------------------------------+
+| ca\_ES | Catalan (Spain) |
++--------------+------------------------------------+
+| cs | Czech |
++--------------+------------------------------------+
+| cs\_CZ | Czech (Czech Republic) |
++--------------+------------------------------------+
+| da | Danish |
++--------------+------------------------------------+
+| da\_DK | Danish (Denmark) |
++--------------+------------------------------------+
+| de | German |
++--------------+------------------------------------+
+| de\_AT | German (Austria) |
++--------------+------------------------------------+
+| de\_CH | German (Switzerland) |
++--------------+------------------------------------+
+| de\_DE | German (Germany) |
++--------------+------------------------------------+
+| de\_LU | German (Luxembourg) |
++--------------+------------------------------------+
+| el | Greek |
++--------------+------------------------------------+
+| el\_CY | Greek (Cyprus) |
++--------------+------------------------------------+
+| el\_GR | Greek (Greece) |
++--------------+------------------------------------+
+| en | English |
++--------------+------------------------------------+
+| en\_AU | English (Australia) |
++--------------+------------------------------------+
+| en\_CA | English (Canada) |
++--------------+------------------------------------+
+| en\_GB | English (United Kingdom) |
++--------------+------------------------------------+
+| en\_IE | English (Ireland) |
++--------------+------------------------------------+
+| en\_IN | English (India) |
++--------------+------------------------------------+
+| en\_MT | English (Malta) |
++--------------+------------------------------------+
+| en\_NZ | English (New Zealand) |
++--------------+------------------------------------+
+| en\_PH | English (Philippines) |
++--------------+------------------------------------+
+| en\_SG | English (Singapore) |
++--------------+------------------------------------+
+| en\_US | English (United States) |
++--------------+------------------------------------+
+| en\_ZA | English (South Africa) |
++--------------+------------------------------------+
+| es | Spanish |
++--------------+------------------------------------+
+| es\_AR | Spanish (Argentina) |
++--------------+------------------------------------+
+| es\_BO | Spanish (Bolivia) |
++--------------+------------------------------------+
+| es\_CL | Spanish (Chile) |
++--------------+------------------------------------+
+| es\_CO | Spanish (Colombia) |
++--------------+------------------------------------+
+| es\_CR | Spanish (Costa Rica) |
++--------------+------------------------------------+
+| es\_DO | Spanish (Dominican Republic) |
++--------------+------------------------------------+
+| es\_EC | Spanish (Ecuador) |
++--------------+------------------------------------+
+| es\_ES | Spanish (Spain) |
++--------------+------------------------------------+
+| es\_GT | Spanish (Guatemala) |
++--------------+------------------------------------+
+| es\_HN | Spanish (Honduras) |
++--------------+------------------------------------+
+| es\_MX | Spanish (Mexico) |
++--------------+------------------------------------+
+| es\_NI | Spanish (Nicaragua) |
++--------------+------------------------------------+
+| es\_PA | Spanish (Panama) |
++--------------+------------------------------------+
+| es\_PE | Spanish (Peru) |
++--------------+------------------------------------+
+| es\_PR | Spanish (Puerto Rico) |
++--------------+------------------------------------+
+| es\_PY | Spanish (Paraguay) |
++--------------+------------------------------------+
+| es\_SV | Spanish (El Salvador) |
++--------------+------------------------------------+
+| es\_US | Spanish (United States) |
++--------------+------------------------------------+
+| es\_UY | Spanish (Uruguay) |
++--------------+------------------------------------+
+| es\_VE | Spanish (Venezuela) |
++--------------+------------------------------------+
+| et | Estonian |
++--------------+------------------------------------+
+| et\_EE | Estonian (Estonia) |
++--------------+------------------------------------+
+| fi | Finnish |
++--------------+------------------------------------+
+| fi\_FI | Finnish (Finland) |
++--------------+------------------------------------+
+| fr | French |
++--------------+------------------------------------+
+| fr\_BE | French (Belgium) |
++--------------+------------------------------------+
+| fr\_CA | French (Canada) |
++--------------+------------------------------------+
+| fr\_CH | French (Switzerland) |
++--------------+------------------------------------+
+| fr\_FR | French (France) |
++--------------+------------------------------------+
+| fr\_LU | French (Luxembourg) |
++--------------+------------------------------------+
+| ga | Irish |
++--------------+------------------------------------+
+| ga\_IE | Irish (Ireland) |
++--------------+------------------------------------+
+| hi | Hindi (India) |
++--------------+------------------------------------+
+| hi\_IN | Hindi (India) |
++--------------+------------------------------------+
+| hr | Croatian |
++--------------+------------------------------------+
+| hr\_HR | Croatian (Croatia) |
++--------------+------------------------------------+
+| hu | Hungarian |
++--------------+------------------------------------+
+| hu\_HU | Hungarian (Hungary) |
++--------------+------------------------------------+
+| in | Indonesian |
++--------------+------------------------------------+
+| in\_ID | Indonesian (Indonesia) |
++--------------+------------------------------------+
+| is | Icelandic |
++--------------+------------------------------------+
+| is\_IS | Icelandic (Iceland) |
++--------------+------------------------------------+
+| it | Italian |
++--------------+------------------------------------+
+| it\_CH | Italian (Switzerland) |
++--------------+------------------------------------+
+| it\_IT | Italian (Italy) |
++--------------+------------------------------------+
+| iw | Hebrew |
++--------------+------------------------------------+
+| iw\_IL | Hebrew (Israel) |
++--------------+------------------------------------+
+| ja | Japanese |
++--------------+------------------------------------+
+| ja\_JP | Japanese (Japan) |
++--------------+------------------------------------+
+| ja\_JP\_JP | Japanese (Japan,JP) |
++--------------+------------------------------------+
+| ko | Korean |
++--------------+------------------------------------+
+| ko\_KR | Korean (South Korea) |
++--------------+------------------------------------+
+| lt | Lithuanian |
++--------------+------------------------------------+
+| lt\_LT | Lithuanian (Lithuania) |
++--------------+------------------------------------+
+| lv | Latvian |
++--------------+------------------------------------+
+| lv\_LV | Latvian (Latvia) |
++--------------+------------------------------------+
+| mk | Macedonian |
++--------------+------------------------------------+
+| mk\_MK | Macedonian (Macedonia) |
++--------------+------------------------------------+
+| ms | Malay |
++--------------+------------------------------------+
+| ms\_MY | Malay (Malaysia) |
++--------------+------------------------------------+
+| mt | Maltese |
++--------------+------------------------------------+
+| mt\_MT | Maltese (Malta) |
++--------------+------------------------------------+
+| nl | Dutch |
++--------------+------------------------------------+
+| nl\_BE | Dutch (Belgium) |
++--------------+------------------------------------+
+| nl\_NL | Dutch (Netherlands) |
++--------------+------------------------------------+
+| no | Norwegian |
++--------------+------------------------------------+
+| no\_NO | Norwegian (Norway) |
++--------------+------------------------------------+
+| no\_NO\_NY | Norwegian (Norway,Nynorsk) |
++--------------+------------------------------------+
+| pl | Polish |
++--------------+------------------------------------+
+| pl\_PL | Polish (Poland) |
++--------------+------------------------------------+
+| pt | Portuguese |
++--------------+------------------------------------+
+| pt\_BR | Portuguese (Brazil) |
++--------------+------------------------------------+
+| pt\_PT | Portuguese (Portugal) |
++--------------+------------------------------------+
+| ro | Romanian |
++--------------+------------------------------------+
+| ro\_RO | Romanian (Romania) |
++--------------+------------------------------------+
+| ru | Russian |
++--------------+------------------------------------+
+| ru\_RU | Russian (Russia) |
++--------------+------------------------------------+
+| sk | Slovak |
++--------------+------------------------------------+
+| sk\_SK | Slovak (Slovakia) |
++--------------+------------------------------------+
+| sl | Slovenian |
++--------------+------------------------------------+
+| sl\_SI | Slovenian (Slovenia) |
++--------------+------------------------------------+
+| sq | Albanian |
++--------------+------------------------------------+
+| sq\_AL | Albanian (Albania) |
++--------------+------------------------------------+
+| sr | Serbian |
++--------------+------------------------------------+
+| sr\_BA | Serbian (Bosnia and Herzegovina) |
++--------------+------------------------------------+
+| sr\_CS | Serbian (Serbia and Montenegro) |
++--------------+------------------------------------+
+| sr\_ME | Serbian (Montenegro) |
++--------------+------------------------------------+
+| sr\_RS | Serbian (Serbia) |
++--------------+------------------------------------+
+| sv | Swedish |
++--------------+------------------------------------+
+| sv\_SE | Swedish (Sweden) |
++--------------+------------------------------------+
+| th | Thai |
++--------------+------------------------------------+
+| th\_TH | Thai (Thailand) |
++--------------+------------------------------------+
+| th\_TH\_TH | Thai (Thailand,TH) |
++--------------+------------------------------------+
+| tr | Turkish |
++--------------+------------------------------------+
+| tr\_TR | Turkish (Turkey) |
++--------------+------------------------------------+
+| uk | Ukrainian |
++--------------+------------------------------------+
+| uk\_UA | Ukrainian (Ukraine) |
++--------------+------------------------------------+
+| vi | Vietnamese |
++--------------+------------------------------------+
+| vi\_VN | Vietnamese (Vietnam) |
++--------------+------------------------------------+
+| zh | Chinese |
++--------------+------------------------------------+
+| zh\_CN | Chinese (China) |
++--------------+------------------------------------+
+| zh\_HK | Chinese (Hong Kong) |
++--------------+------------------------------------+
+| zh\_SG | Chinese (Singapore) |
++--------------+------------------------------------+
+| zh\_TW | Chinese (Taiwan) |
++--------------+------------------------------------+
diff --git a/reference/reference_filling_work.rst b/reference/reference_filling_work.rst
new file mode 100644
index 000000000..6ad98b0fb
--- /dev/null
+++ b/reference/reference_filling_work.rst
@@ -0,0 +1,238 @@
+Reference filling work
+======================
+
+Godot Engine provides an important number of classes that you can make
+use of to create your games. However, the [[Reference\|reference]] that
+lists all these classes with their methods is quite incomplete. We need
+your kind help to fill this reference. This page will explain you how.
+
+> Please note: we aim at filling completely this reference in English
+first. Please do not start translating it for the moment.
+
+[[List of classes and documenters]]
+
+Editing with Github
+-------------------
+
+Fork Godot Engine
+~~~~~~~~~~~~~~~~~
+
+First of all, you need to fork the Godot Engine on your own GitHub
+repository.
+
+You will then need to clone the master branch of Godot Engine in order
+to work on the most recent version of the engine, including all of its
+features.
+
+::
+
+ git clone https://github.com/your_name/godot.git
+
+Then, create a new git branch that will contain your changes.
+
+::
+
+ git checkout -b reference-edition
+
+The branch you just created is identical to current master branch of
+Godot Engine. It already contains a doc/ folder, with the currently
+written reference.
+
+Updating the documentation template
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When classes are modified in the source code, the documentation template
+might become outdated. To make sure that you are editing an up-to-date
+version, you first need to compile Godot (you can follow the
+[[Introduction to the Godot buildsystem]] page), and then run the
+following command (assuming 64-bit Linux):
+
+::
+
+ ./bin/godot.x11.tools.64 -doctool doc/base/classes.xml
+
+The doc/base/classes.xml should then be up-to-date with current Godot
+Engine features. You can then check what changed (or not) using the
+``git diff`` command. If there are changes to other classes than the one
+you are planning to document, please commit those changes first before
+starting to edit the template:
+
+::
+
+ git add doc/base/classes.xml
+ git commit -m "Sync classes reference template with current code base"
+
+You are now ready to edit this file to add stuff.
+
+Push and request a pull of your changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once your modifications are finished, push your changes on your GitHub
+repository:
+
+::
+
+ git add doc/base/classes.xml
+ git commit -m "Explain your modifications."
+ git push
+
+When it's done, you can ask for a Pull Request on the GitHub UI of your
+Godot fork.
+
+Edit doc/base/classes.xml file
+------------------------------
+
+First of all, check the [[List of classes and documenters]]. Try to work
+on classes not already assigned nor filled.
+
+| This file is produced by Godot Engine. It is used by the editor, for
+ example in the Help window (F1, Shift+F1).
+| You can edit this file using your favourite text editor.
+
+Here is an example with the Node2D class:
+
+::
+
+
+
+ Base node for 2D system.
+
+
+ Base node for 2D system. Node2D contains a position, rotation and scale, which is used to position and animate. It can alternatively be used with a custom 2D transform ([Matrix32]). A tree of Node2Ds allows complex hierachies for animation and positioning.
+
+
+
+
+
+
+ Set the position of the 2d node.
+
+
+
+
+
+
+ Set the rotation of the 2d node.
+
+
+
+
+
+
+ Set the scale of the 2d node.
+
+
+
+
+
+
+ Return the position of the 2D node.
+
+
+
+
+
+
+ Return the rotation of the 2D node.
+
+
+
+
+
+
+ Return the scale of the 2D node.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Return the global position of the 2D node.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+As you can see, some methods in this class have no description (i.e.
+there is no text between their marks). This can also happen for the
+description and the brief\_description of the class, but in our case
+they are already filled. Let's edit the description of the rotate()
+method:
+
+::
+
+
+
+
+
+ Rotates the node of "degrees" degrees.
+
+
+| That's all!
+| You simply have to write any missing text between these marks:
+
+-
+-
+-
+
+Describe clearly and shortly what it does. You can include an example of
+use if needed. Avoid grammar faults.
+
+I don't know what this method does!
+-----------------------------------
+
+| Not a problem. Leave it behind for now, and don't forget to notify the
+ missing methods when you request a pull of your changes. Another
+ editor will take care of it.
+| If you wonder what a method does, you can still have a look at its
+ implementation in Godot Engine's source code on GitHub. Also, if you
+ have a doubt, feel free to ask on the
+ `Forums `__
+ and on IRC (freenode, #godotengine).
diff --git a/reference/richtextlabel_bbcode.rst b/reference/richtextlabel_bbcode.rst
new file mode 100644
index 000000000..f61a43c80
--- /dev/null
+++ b/reference/richtextlabel_bbcode.rst
@@ -0,0 +1,73 @@
+BBCode RichTextLabel
+====================
+
+Introduction
+------------
+
+[[RichTextLabel]] allows to display complex text markup in a control. It
+has a built-in API for generating the markup, but can also parse a
+BBCode.
+
+Setting Up
+----------
+
+For RichTextLabel to work properly, it must be set-up. This means
+loading the intended fonts in the releavant properties:
+
+.. image:: /img/rtl_setup.png
+
+Reference
+---------
+
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| Command | Tag | Description |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **bold** | ``[b]{text}[/b]`` | Makes {text} bold. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **italics** | ``[i]{text}[/i]`` | Makes {text} italics. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **underline** | ``[u]{text}[/u]`` | Makes {text} underline. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **code** | ``[code]{text}[/code]`` | Makes {text} monospace. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **center** | ``[center]{text}[/center]`` | Makes {text} centered. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **right** | ``[right]{text}[/right]`` | Makes {text} right-aligned. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **fill** | ``[fill]{text}[/fill]`` | Makes {text} fill width. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **indent** | ``[indent]{text}[/indent]`` | Incrase indent level of {text}. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **url** | ``[url]{url}[/url]`` | Show as such. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **url (ref)** | ``[url=]{text}[/url]`` | Makes {text} reference . |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **image** | ``[img=][/img]`` | Insert image at resource . |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **font** | ``[font=]{text}[/font]`` | Use custom font at for {text}. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+| **color** | ``[color=<code/name>]{text}[/color]`` | Change {text} color, use # format such as #ff00ff or name. |
++-----------------+--------------------------------------------+--------------------------------------------------------------+
+
+Built-In Color Names
+~~~~~~~~~~~~~~~~~~~~
+
+List of valid color names for the [color=] tag:
+
+- aqua
+- black
+- blue
+- fuchsia
+- gray
+- green
+- lime
+- maroon
+- navy
+- purple
+- red
+- silver
+- teal
+- white
+- yellow
+
+
diff --git a/reference/shader.rst b/reference/shader.rst
new file mode 100644
index 000000000..27035d6e8
--- /dev/null
+++ b/reference/shader.rst
@@ -0,0 +1,420 @@
+Shading Language
+================
+
+Introduction
+------------
+
+Godot uses a simplified shader language (almost a subset of GLSL).
+Shaders can be used for:
+
+- Materials
+- Post-Processing
+- 2D
+
+and are divided in *Vertex*, *Fragment* and *Light* sections.
+
+Language
+--------
+
+Typing
+~~~~~~
+
+The language is statically type and supports only a few operations.
+Arrays, classes, structures, etc are not supported. Several built-in
+datatypes are provided:
+
+Data Types
+~~~~~~~~~~
+
++-------------------+--------------------------------------------------------------+
+| DataType | Description |
++===================+==============================================================+
+| *void* | Void |
++-------------------+--------------------------------------------------------------+
+| *bool* | boolean (true or false) |
++-------------------+--------------------------------------------------------------+
+| *float* | floating point |
++-------------------+--------------------------------------------------------------+
+| *vec2* | 2-component vector, float subindices (x,y or r,g ) |
++-------------------+--------------------------------------------------------------+
+| *vec3* | 3-component vector, float subindices (x,y,z or r,g,b ) |
++-------------------+--------------------------------------------------------------+
+| *vec4*, *color* | 4-component vector, float subindices (x,y,z,w or r,g,b,a ) |
++-------------------+--------------------------------------------------------------+
+| *mat2* | 2x2 matrix, vec3 subindices (x,y) |
++-------------------+--------------------------------------------------------------+
+| *mat3* | 3x3 matrix, vec3 subindices (x,y,z) |
++-------------------+--------------------------------------------------------------+
+| *mat4* | 4x4 matrix, vec4 subindices (x,y,z,w) |
++-------------------+--------------------------------------------------------------+
+| *texture* | texture sampler, can only be used as uniform |
++-------------------+--------------------------------------------------------------+
+| *cubemap* | cubemap sampler, can only be used as uniform |
++-------------------+--------------------------------------------------------------+
+
+Syntax
+~~~~~~
+
+| The syntax is similar to C, with statements ending in ; , and comments
+ as // and /\* \*/.
+| Example:
+
+::
+
+ float a = 3;
+ vec3 b;
+ b.x = a;
+
+Swizzling
+~~~~~~~~~
+
+It is possible to use swizzling to reasigning subindices or groups of
+subindices, in order:
+
+::
+
+ vec3 a = vec3(1,2,3);
+ vec3 b = a.zyx; // b will contain vec3(3,2,1)
+ vec2 c = a.xy; // c will contain vec2(1,2)
+ vec4 d = a.xyzz; // d will contain vec4(1,2,3,3)
+
+Constructors
+~~~~~~~~~~~~
+
+Constructors take the regular amount of elements, but can also accept
+less if the element has more subindices, for example:
+
+::
+
+ vec3 a = vec3( 1, vec2(2,3) );
+ vec3 b = vec3( a );
+ vec3 c = vec3( vec2(2,3), 1 );
+ vec4 d = vec4( a, 5 );
+ mat3 m = mat3( a,b,c );
+
+Conditionals
+~~~~~~~~~~~~
+
+For now, only the "if" conditional is supported. Example:
+
+::
+
+ if (a < b) {
+ c = b;
+ }
+
+Uniforms
+~~~~~~~~
+
+A variable can be declared as uniform. In this case, it's value will
+come from outside the shader (it will be the responsibility of the
+material or whatever using the shader to provide it).
+
+::
+
+ uniform vec3 direction;
+ uniform color tint;
+
+ vec3 result = tint.rgb * direction;
+
+Functions
+~~~~~~~~~
+
+Simple support for functions is provided. Functions can't access
+uniforms or other shader variables.
+
+::
+
+ vec3 addtwo( vec3 a, vec3 b) {
+
+ return a+b;
+ }
+
+ vec3 c = addtwo(vec3(1,1,1)+vec3(2,2,2));
+
+Built-In Functions
+------------------
+
+Several Built-in functions are provided for convenience, listed as
+follows:
+
+| \|\ *. Function \|*. Description \|
+| \| float *sin*\ ( float ) \| Sine \|
+| \| float *cos*\ ( float ) \| Cosine \|
+| \| float *tan*\ ( float ) \| Tangent \|
+| \| float *asin*\ ( float ) \| arc-Sine \|
+| \| float *acos*\ ( float ) \| arc-Cosine \|
+| \| float *atan*\ ( float ) \| arc-Tangent \|
+| \| vec\_type *pow*\ ( vec\_type, float ) \| Power \|
+| \| vec\_type *pow*\ ( vec\_type, vec\_type ) \| Power (Vec. Exponent)
+ \|
+| \| vec\_type *exp*\ ( vec\_type ) \| Base-e Exponential \|
+| \| vec\_type *log*\ ( vec\_type ) \| Natural Logarithm \|
+| \| vec\_type *sqrt*\ ( vec\_type ) \| Square Root \|
+| \| vec\_type *abs*\ ( vec\_type ) \| Absolute \|
+| \| vec\_type *sign*\ ( vec\_type ) \| Sign \|
+| \| vec\_type *floor*\ ( vec\_type ) \| Floor \|
+| \| vec\_type *trunc*\ ( vec\_type ) \| Trunc \|
+| \| vec\_type *ceil*\ ( vec\_type ) \| Ceiling \|
+| \| vec\_type *fract*\ ( vec\_type ) \| Fractional \|
+| \| vec\_type *mod*\ ( vec\_type,vec\_type ) \| Remainder \|
+| \| vec\_type *min*\ ( vec\_type,vec\_type ) \| Minimum \|
+| \| vec\_type *min*\ ( vec\_type,vec\_type ) \| Maximum \|
+| \| vec\_type *clamp*\ ( vec\_type value,vec\_type min, vec\_type max )
+ \| Clamp to Min-Max \|
+| \| vec\_type *mix*\ ( vec\_type a,vec\_type b, float c ) \| Linear
+ Interpolate \|
+| \| vec\_type *mix*\ ( vec\_type a,vec\_type b, vec\_type c ) \| Linear
+ Interpolate (Vector Coef.)\|
+| \| vec\_type *step*\ ( vec\_type a,vec\_type b) \| \` a[i] < b[i] ?
+ 0.0 : 1.0\`\|
+| \| vec\_type *smoothstep*\ ( vec\_type a,vec\_type b,vec\_type c) \|
+ \|
+| \| float *length*\ ( vec\_type ) \| Vector Length \|
+| \| float *distance*\ ( vec\_type, vec\_type ) \| Distance between
+ vector. \|
+| \| float *dot*\ ( vec\_type, vec\_type ) \| Dot Product \|
+| \| vec3 *dot*\ ( vec3, vec3 ) \| Cross Product \|
+| \| vec\_type *normalize*\ ( vec\_type ) \| Normalize to unit length \|
+| \| vec3 *reflect*\ ( vec3, vec3 ) \| Reflect \|
+| \| color *tex*\ ( texture, vec2 ) \| Read from a texture in
+ noormalized coords \|
+| \| color *texcube*\ ( texture, vec3 ) \| Read from a cubemap \|
+| \| color *texscreen*\ ( vec2 ) \| Read from screen (generates a copy)
+ \|
+
+Built-In Variables
+------------------
+
+Depending on the shader type, several built-in variables are available,
+listed as follows:
+
+Material - VertexShader
+~~~~~~~~~~~~~~~~~~~~~~~
+
+| \|\ *. Variable \|*. Description \|
+| \| const vec3 *SRC\_VERTEX* \| Model-Space Vertex \|
+| \| const vec3 *SRC\_NORMAL* \| Model-Space Normal \|
+| \| const vec3 *SRC\_TANGENT* \| Model-Space Tangent \|
+| \| const float *SRC\_BINORMALF* \| Direction to Compute Binormal \|
+| \| vec3 *VERTEX* \| View-Space Vertex \|
+| \| vec3 *NORMAL* \| View-Space Normal \|
+| \| vec3 *TANGENT* \| View-Space Tangent \|
+| \| vec3 *BINORMAL* \| View-Space Binormal \|
+| \| vec2 *UV* \| UV \|
+| \| vec2 *UV2* \| UV2 \|
+| \| color *COLOR* \| Vertex Color \|
+| \| out vec4 *VAR1* \| Varying 1 Output \|
+| \| out vec4 *VAR2* \| Varying 2 Output \|
+| \| out float *SPEC\_EXP* \| Specular Exponent (for Vertex Lighting) \|
+| \| out float *POINT\_SIZE* \| Point Size (for points) \|
+| \| const mat4 *WORLD\_MATRIX* \| Object World Matrix \|
+| \| const mat4 *INV\_CAMERA\_MATRIX* \| Inverse Camera Matrix \|
+| \| const mat4 *PROJECTION\_MATRIX* \| Projection Matrix \|
+| \| const mat4 *MODELVIEW\_MATRIX* \| (InvCamera \* Projection) \|
+| \| const float *INSTANCE\_ID* \| Instance ID (for multimesh)\|
+| \| const float *TIME* \| Time (in seconds) \|
+
+Material - FragmentShader
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
++----------------------------------+----------------------------------------------------------------------------------+
+| Variable | Description |
++==================================+==================================================================================+
+| const vec3 *VERTEX* | View-Space vertex |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec4 *POSITION* | View-Space Position |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec3 *NORMAL* | View-Space Normal |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec3 *TANGENT* | View-Space Tangent |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec3 *BINORMAL* | View-Space Binormal |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec3 *NORMALMAP* | Alternative to NORMAL, use for normal texture output. |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec3 *NORMALMAP\_DEPTH* | Complementary to the above, allows changing depth of normalmap. |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec2 *UV* | UV |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec2 *UV2* | UV2 |
++----------------------------------+----------------------------------------------------------------------------------+
+| const color *COLOR* | Vertex Color |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec4 *VAR1* | Varying 1 |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec4 *VAR2* | Varying 2 |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec2 *SCREEN\_UV* | Screen Texture Coordinate (for using with texscreen) |
++----------------------------------+----------------------------------------------------------------------------------+
+| const float *TIME* | Time (in seconds) |
++----------------------------------+----------------------------------------------------------------------------------+
+| const vec2 *POINT\_COORD* | UV for point, when drawing point sprites. |
++----------------------------------+----------------------------------------------------------------------------------+
+| out vec3 *DIFFUSE* | Diffuse Color |
++----------------------------------+----------------------------------------------------------------------------------+
+| out vec4 *DIFFUSE\_ALPHA* | Diffuse Color with Alpha (using this sends geometry to alpha pipeline) |
++----------------------------------+----------------------------------------------------------------------------------+
+| out vec3 *SPECULAR* | Specular Color |
++----------------------------------+----------------------------------------------------------------------------------+
+| out vec3 *EMISSION* | Emission Color |
++----------------------------------+----------------------------------------------------------------------------------+
+| out float *SPEC\_EXP* | Specular Exponent (Fragment Version) |
++----------------------------------+----------------------------------------------------------------------------------+
+| out float *GLOW* | Glow |
++----------------------------------+----------------------------------------------------------------------------------+
+| out mat4 *INV\_CAMERA\_MATRIX* | Inverse camera matrix, can be used to obtain world coords (see example below). |
++----------------------------------+----------------------------------------------------------------------------------+
+
+Material - LightShader
+~~~~~~~~~~~~~~~~~~~~~~
+
++--------------------------------+-------------------------------+
+| Variable | Description |
++================================+===============================+
+| const vec3 *NORMAL* | View-Space normal |
++--------------------------------+-------------------------------+
+| const vec3 *LIGHT\_DIR* | View-Space Light Direction |
++--------------------------------+-------------------------------+
+| const vec3 *EYE\_VEC* | View-Space Eye-Point Vector |
++--------------------------------+-------------------------------+
+| const vec3 *DIFFUSE* | Material Diffuse Color |
++--------------------------------+-------------------------------+
+| const vec3 *LIGHT\_DIFFUSE* | Light Diffuse Color |
++--------------------------------+-------------------------------+
+| const vec3 *SPECULAR* | Material Specular Color |
++--------------------------------+-------------------------------+
+| const vec3 *LIGHT\_SPECULAR* | Light Specular Color |
++--------------------------------+-------------------------------+
+| const float *SPECULAR\_EXP* | Specular Exponent |
++--------------------------------+-------------------------------+
+| const vec1 *SHADE\_PARAM* | Generic Shade Parameter |
++--------------------------------+-------------------------------+
+| const vec2 *POINT\_COORD* | Current UV for Point Sprite |
++--------------------------------+-------------------------------+
+| out vec2 *LIGHT* | Resulting Light |
++--------------------------------+-------------------------------+
+| const float *TIME* | Time (in seconds) |
++--------------------------------+-------------------------------+
+
+CanvasItem (2D) - VertexShader
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+| \|\ *. Variable \|*. Description \|
+| \| const vec2 *SRC\_VERTEX* \| CanvasItem space vertex. \|
+| \| vec2 *UV* \| UV \|
+| \| out vec2 *VERTEX* \| Output LocalSpace vertex. \|
+| \| out vec2 *WORLD\_VERTEX* \| Output WorldSpace vertex. (use this or
+ the one above) \|
+| \| color *COLOR* \| Vertex Color \|
+| \| out vec4 *VAR1* \| Varying 1 Output \|
+| \| out vec4 *VAR2* \| Varying 2 Output \|
+| \| out float *POINT\_SIZE* \| Point Size (for points) \|
+| \| const mat4 *WORLD\_MATRIX* \| Object World Matrix \|
+| \| const mat4 *EXTRA\_MATRIX* \| Extra (user supplied) matrix via
+ `CanvasItem.draw\_set\_transform() `__.
+ Identity by default. \|
+| \| const mat4 *PROJECTION\_MATRIX* \| Projection Matrix (model coords
+ to screen).\|
+| \| const float *TIME* \| Time (in seconds) \|
+
+CanvasItem (2D) - FragmentShader
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+| \|\ *. Variable \|*. Description \|
+| \| const vec4 *SRC\_COLOR* \| Vertex color \|
+| \| const vec4 *POSITION* \| Screen Position \|
+| \| vec2 *UV* \| UV \|
+| \| out color *COLOR* \| Output Color \|
+| \| out vec3 *NORMAL* \| Optional Normal (used for 2D Lighting) \|
+| \| out vec3 *NORMALMAP* \| Optional Normal in standard normalmap
+ format (flipped y and Z from 0 to 1) \|
+| \| out float *NORMALMAP\_DEPTH* \| Depth option for above normalmap
+ output, default value is 1.0 \|
+| \| const texture *TEXTURE* \| Current texture in use for CanvasItem \|
+| \| const vec2 *TEXTURE\_PIXEL\_SIZE* \| Pixel size for current 2D
+ texture \|
+| \| in vec4 *VAR1* \| Varying 1 Output \|
+| \| in vec4 *VAR2* \| Varying 2 Output \|
+| \| const vec2 *SCREEN\_UV*\ \| Screen Texture Coordinate (for using
+ with texscreen) \|
+| \| const vec2 *POINT\_COORD* \| Current UV for Point Sprite \|
+| \| const float *TIME*\ \| Time (in seconds) \|
+
+CanvasItem (2D) - LightShader
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+| \|\ *. Variable \|*. Description \|
+| \| const vec4 *POSITION* \| Screen Position \|
+| \| in vec3 *NORMAL* \| Input Normal \|
+| \| in vec2 *UV* \| UV \|
+| \| in color *COLOR* \| Input Color \|
+| \| const texture *TEXTURE* \| Current texture in use for CanvasItem \|
+| \| const vec2 *TEXTURE\_PIXEL\_SIZE* \| Pixel size for current 2D
+ texture \|
+| \| in vec4 *VAR1* \| Varying 1 Output \|
+| \| in vec4 *VAR2* \| Varying 2 Output \|
+| \| const vec2 *SCREEN\_UV*\ \| Screen Texture Coordinate (for using
+ with texscreen) \|
+| \| const vec2 *POINT\_COORD* \| Current UV for Point Sprite \|
+| \| const float *TIME*\ \| Time (in seconds) \|
+| \| vec2 *LIGHT\_VEC* \| Vector from light to fragment, can be modified
+ to alter shadow computation. \|
+| \| const float *LIGHT\_HEIGHT* \| Height of Light \|
+| \| const color *LIGHT\_COLOR* \| Color of Light \|
+| \| out vec4 *LIGHT* \| Light Ouput (shader is ignored if this is not
+ used) \|
+
+Examples
+--------
+
+Material that reads a texture, a color and multiples them, fragment
+program:
+
+::
+
+ uniform color modulate;
+ uniform texture source;
+
+ DIFFUSE = modulate.rgb * tex(source,UV).rgb;
+
+Material that glows from red to white:
+
+::
+
+ DIFFUSE = vec3(1,0,0) + vec(1,1,1)*mod(TIME,1.0);
+
+Standard Blinn Lighting Shader
+
+::
+
+ float NdotL = max(0.0,dot( NORMAL, LIGHT_DIR ));
+ vec3 half_vec = normalize(LIGHT_DIR + EYE_VEC);
+ float eye_light = max(dot(NORMAL, half_vec),0.0);
+ LIGHT = LIGHT_DIFFUSE + DIFFUSE + NdotL;
+ if (NdotL > 0.0) {
+ LIGHT+=LIGHT_SPECULAR + SPECULAR + pow( eye_light, SPECULAR_EXP );
+ };
+
+Obtaining world-space normal and position in material fragment program:
+
+::
+
+ //use reverse multiply because INV_CAMERA_MATRIX is world2cam
+
+ vec3 world_normal = NORMAL * mat3(INV_CAMERA_MATRIX);
+ vec3 world_pos = (VERTEX-INV_CAMERA_MATRIX.w.xyz) * mat3(INV_CAMERA_MATRIX);
+
+Notes
+-----
+
+| \* **Do not** use DIFFUSE\_ALPHA unless you really intend to use
+ transparency. Transparent materials must be sorted by depth and slow
+ down the rendering pipeline. For opaque materials, just use DIFFUSE.
+| \* **Do not** use DISCARD unless you really need it. Discard makes
+ rendering slower, specially on mobile devices.
+| \* TIME may reset after a while (may last an hour or so), it's meant
+ for effects that vary over time.
+| \* In general, every built-in variable not used results in less shader
+ code generated, so writing a single giant shader with a lot of code
+ and optional scenarios is often not a good idea.
diff --git a/tutorials/.directory b/tutorials/.directory
new file mode 100644
index 000000000..91108c0c2
--- /dev/null
+++ b/tutorials/.directory
@@ -0,0 +1,7 @@
+[Dolphin]
+HeaderColumnWidths=340,63,124,144
+SortRole=type
+Timestamp=2016,2,6,1,11,25
+Version=3
+ViewMode=1
+VisibleRoles=Details_text,Details_size,Details_date,Details_type,CustomizedDetails
diff --git a/tutorials/2d_tutorials.rst b/tutorials/2d_tutorials.rst
new file mode 100644
index 000000000..90ad128e3
--- /dev/null
+++ b/tutorials/2d_tutorials.rst
@@ -0,0 +1,21 @@
+2D tutorials
+============
+
+.. toctree::
+ :maxdepth: 1
+ :name: 2d-tutorials
+
+ physics_and_collision_2d
+ tilemap
+ kinematic_character_2d
+ gui_skinning
+ particle_systems_2d
+ canvas_layers
+ viewport_and_canvas_transforms
+ custom_drawing_in_node2d_control
+ custom_gui_controls
+ screen-reading_shaders
+ ray-casting
+ cut-out_animation
+.. gui_containers
+.. phyics_objet_guide
diff --git a/tutorials/3d_performance_and_limitations.rst b/tutorials/3d_performance_and_limitations.rst
new file mode 100644
index 000000000..f6e752842
--- /dev/null
+++ b/tutorials/3d_performance_and_limitations.rst
@@ -0,0 +1,189 @@
+3D Performance & Limitations
+============================
+
+Introduction
+~~~~~~~~~~~~
+
+Godot follows a balanced performance philosophy. In performance world,
+there are always trade-offs, which consist in trading speed for
+usability and flexibility. Some practical examples of this are:
+
+- Rendering objects efficiently in high amounts is easy, but when a
+ large scene must be rendered it can become inefficient. To solve
+ this, visibility computation must be added to the rendering, which
+ makes rendering less efficient, but at the same less objects are
+ rendered, so efficiency overall improves.
+- Configuring the properties of every material for every object that
+ needs to be renderer is also slow. To solve this, objects are sorted
+ by material to reduce the costs, but at the same time sorting has a
+ cost.
+- In 3D physics a similar situation happens. The best algorithms to
+ handle large amounts of physics objects (such as SAP) are very slow
+ at insertion/removal of objects and ray-casting. Algorithms that
+ allow faster insertion and removal, as well as ray-casting will not
+ be able to handle as many active objects.
+
+And there are many more examples of this! Game engines strive to be
+general purpose in nature, so balanced algorithms are always favored
+over algorithms that might be the fast in some situations and slow in
+others.. or algorithms that are fast but make usability more difficult.
+
+Godot is not an exception and, while it is designed to have backends
+swappable for different algorithms, the default ones (or more like, the
+only ones that are there for now) prioritize balance and flexibility
+over performance.
+
+With this clear, the aim of this tutorial is to explain how to get the
+maximum performance out of Godot.
+
+Rendering
+~~~~~~~~~
+
+3D rendering is one of the most difficult areas to get performance from,
+so this section will have a list of tips.
+
+Reuse Shaders and Materials
+---------------------------
+
+Godot renderer is a little different to what is out there. It's designed
+to minimize GPU state changes as much as possible.
+`FixedMaterial `__
+does a good job at reusing materials that need similar shaders but, if
+custom shaders are used, make sure to reuse them as much as possible.
+Godot's priorities will be like this:
+
+- **Reusing Materials**: The less amount of different materials in the
+ scene, the faster the rendering will be. If a scene has a huge amount
+ of objects (in the hundreds or thousands) try reusing the materials
+ or in the worst case use atlases.
+- **Reusing Shaders**: If materials can't be reused, at least try to
+ re-use shaders (or FixedMaterials with different parameters but same
+ configuration).
+
+If a scene has, for example, 20.000 objects with 20.000 different
+materials each, rendering will be really slow. If the same scene has
+20.000 objects, but only uses 100 materials, rendering will be blazing
+fast.
+
+Pixels Cost vs Vertex Cost
+--------------------------
+
+It is a common thought that the lower the polygons in a model, the
+faster it will be rendered. This is *really* relative and depends on
+many factors.
+
+On a modern PC and consoles, vertex cost is low. Very low. GPUs
+originally only rendered triangles, so all the vertices:
+
+| 1. Had to be transformed by the CPU (including clipping).
+| 1. Had to be sent to the GPU memory from the main RAM.
+
+Nowadays, all this is handled inside the GPU, so the performance is
+extremely high. 3D artists usually have the wrong feeling about
+polycount performance because 3D DCCs (such as Blender, Max, etc) need
+to keep geometry in CPU memory in order for it to be edited, reducing
+actual performance. Truth is, a model rendered by a 3D engine is much
+more optimal than how 3D DCCs display them.
+
+On mobile devices, the story is different. PC and Console GPUs are
+brute-force monsters that can pull as much electricity as they need from
+the power grid. Mobile GPUs are limited to a tiny battery, so they need
+to be a lot more power efficient.
+
+To be more efficient, mobile GPUs attempt to avoid *overdraw*. This
+means, the same pixel on the screen being rendered (as in, with lighting
+calculation, etc) more than once. Imagine a town with several buildings,
+GPUs don't really know what is visible and what is hidden until they
+draw it. A house might be drawn and then another house in front of it
+(rendering happened twice for the same pixel!). PC GPUs normally don't
+care much about this and just throw more pixel processors to the
+hardware to increase performance (but this also increases power
+consumption).
+
+On mobile, pulling more power is not an option, so a technique called
+"Tile Based Rendering" is used (almost every mobile hardware uses a
+variant of it), which divide the screen into a grid. Each cell keps the
+list of triangles drawn to it and sorts them by depth to minimize
+*overdraw*. This technique improves performance and reduces power
+consumption, but takes a toll on vertex performance. As a result, less
+vertices and triangles can be processed for drawing.
+
+Generally, this is not so bad, but there is a corner case on mobile that
+must be avoided, which is to have small objects with a lot of geometry
+within a small portion of the screen. This forces mobile GPUs to put a
+lot of strain on a single screen cell, considerably decreasing
+performance (as all the other cells must wait for it to complete in
+order to display the frame).
+
+To make it short, do not worry about vertex count so much on mobile, but
+avoid concentration of vertices in small parts of the screen. If, for
+example, a character, NPC, vehicle, etc is far away (so it looks tiny),
+use a smaller level of detail (LOD) model instead.
+
+An extra situation where vertex cost must be considered is objects that
+have extra processing per vertex, such as:
+
+- Skinning (skeletal animation)
+- Morphs (shape keys)
+- Vertex Lit Objects (common on mobile)
+
+Texture Compression
+-------------------
+
+| Godot offers to compress textures of 3D models when imported (VRAM
+ compression). Video Ram compression is not as efficient in size as PNG
+ or JPG when stored, but increase performance enormously when drawing.
+| This is because the main goal of texture compression is bandwidth
+ reduction between memory and the GPU.
+
+In 3D, the shapes of objects depend more on the geometry than the
+texture, so compression is generally not noticeable. In 2D, compression
+depends more on shapes inside the textures, so the artifacting resulting
+from the compression is more noticeable.
+
+As a warning, most Android devices do not support texture compression of
+textures with transparency (only opaque), so keep this in mind.
+
+Transparent Objects
+-------------------
+
+As mentioned before, Godot sorts objects by material and shader to
+improve performance. This, however, can not be done on transparent
+objects. Transparent objects are rendered from back to front to make
+blending with what is behind work. As a result, please try to keep
+transparent objects to a minimum! If an object has a small section with
+transparency, try to make that section a separate material.
+
+Level of Detail (LOD)
+---------------------
+
+As also mentioned before, using objects with less vertices can improve
+performance in some cases. Godot has a very simple system to use level
+of detail,
+`GeometryInstance `__
+based objects have a visibility range that can be defined. Having
+several GeometryInstance objects in different ranges works as LOD.
+
+Use Instancing (MultiMesh)
+--------------------------
+
+If several identical objects have to be drawn in the same place or
+nearby, try using
+`MultiMesh `__
+instead. MultiMesh allows drawing of dozens of thousands of objects at
+very little performance cost, making it ideal for flocks, grass,
+particles, etc.
+
+Bake Lighting
+-------------
+
+Small lights are usually not a performance issue. Shadows a little more.
+In general, if several lights need to affect a scene, it's ideal to bake
+it ([[Light Baking]]). Baking can also improve the scene quality by
+adding indirect light bounces.
+
+If working on mobile, baking to texture is recommended, since this
+method is even faster.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/3d_tutorials.rst b/tutorials/3d_tutorials.rst
new file mode 100644
index 000000000..c100a3141
--- /dev/null
+++ b/tutorials/3d_tutorials.rst
@@ -0,0 +1,27 @@
+3D tutorials
+============
+
+.. toctree::
+ :maxdepth: 1
+ :name: 3d-tutorials
+
+ creating_3d_games
+ materials
+ fixed_materials
+ shader_materials
+ lighting
+ shadow_mapping
+ high_dynamic_range
+ 3d_performance_and_limitations
+ ray-casting
+ working_with_3d_skeletons
+ inverse_kinematics
+.. procedural_geometry
+.. light_baking
+.. 3d_sprites
+.. using_the_animationtreeplayer
+.. portals_and_rooms
+.. vehicle
+.. grimap
+.. spatial_audio
+.. toon_shading
diff --git a/tutorials/advanced.rst b/tutorials/advanced.rst
new file mode 100644
index 000000000..34caf8147
--- /dev/null
+++ b/tutorials/advanced.rst
@@ -0,0 +1,10 @@
+Engine
+======
+
+.. toctree::
+ :maxdepth: 1
+ :name: engine
+
+ paths
+ http_client_class
+.. thread_safety
diff --git a/tutorials/animation.rst b/tutorials/animation.rst
new file mode 100644
index 000000000..f1e771d77
--- /dev/null
+++ b/tutorials/animation.rst
@@ -0,0 +1,98 @@
+Animation Tutorial
+==================
+
+Introduction
+------------
+
+This tutorial will explain how everything is animated in Godot. Godot
+animation system is extremely powerful and flexible.
+
+To begin, let's just use the scene from the previous tutorial (splash
+screen). The goal will be to add a simple animation to it. Here's a copy
+just in case: attachment:robisplash.zip
+
+Creating the Animation
+----------------------
+
+First of all, add an
+`AnimationPlayer `__
+node to the scene, make it a child of bg (the root node):
+
+.. image:: /img/animplayer.png
+
+When a node of this type is selected, the animation editor panel will
+appear:
+
+.. image:: /img/animpanel.png
+
+So, it's time to create a new animation! Press the new animation button
+and name the animation "intro".
+
+.. image:: /img/animnew.png
+
+After the animation has been created, then it's time to edit it, by
+pressing the "edit" button:
+
+.. image:: /img/animedit.png
+
+Editing the Animation
+---------------------
+
+Now this is when the magic happens! Several things happen when the
+"edit" button is pressed, the first one is that the animation editor
+appears above the animation panel.
+
+.. image:: /img/animeditor.png
+
+But the second, and most important, is that the property editor enters
+into "animation editing" mode. In this mode, a key icon appears next to
+every property of the property editor. This means that, in Godot, *any
+property of any object* can be animated:
+
+.. image:: /img/propertykeys.png
+
+Making the Logo Appear
+----------------------
+
+| Next, the logo will appear from the top of the screen. After selecting
+ the animation player, the editor panel will stay visible until
+ manually hidden (or the animation node is erased). Taking advantage of
+ this, select the "logo" node and go to the "pos" property, move it up,
+ to position: 114,-400.
+| Once in this position, press the key button next to the property:
+
+.. image:: /img/keypress.png
+
+As the track is new, a dialog will appear asking to create it. Confirm
+it!
+
+.. image:: /img/addtrack.png
+
+And the keyframe will be added in the animation player editor:
+
+.. image:: /img/keyadded.png
+
+Second, move the editor cursor to the end, by clicking here:
+
+.. image:: /img/move_cursor.png
+
+Change the logo position to 114,0 and a keyframe again. With two
+keyframes, the animation happens.
+
+.. image:: /img/animation.png
+
+Pressing Play on the animation panel will make the logo descend. To test
+it by running the scene, the autoplay button can tag the animation to
+start automatically when the scene starts:
+
+.. image:: /img/autoplay.png
+
+And finally, when running the scene, the animation should look like
+this:
+
+.. image:: /img/out.gif
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/background_loading.rst b/tutorials/background_loading.rst
new file mode 100644
index 000000000..d0b1767ae
--- /dev/null
+++ b/tutorials/background_loading.rst
@@ -0,0 +1,371 @@
+Background loading
+==================
+
+When switching the main scene of your game (for example going to a new
+level), you might want to show a loading screen with some indication
+that progress is being made. The main load method
+(``ResourceLoader::load`` or just ``load`` from gdscript) blocks your
+thread while the resource is being loaded, so It's not good. This
+document discusses the ``ResourceInteractiveLoader`` class for smoother
+load screens.
+
+ResourceInteractiveLoader
+-------------------------
+
+The ``ResourceInteractiveLoader`` class allows you to load a resource in
+stages. Every time the method ``poll`` is called, a new stage is loaded,
+and control is returned to the caller. Each stage is generally a
+sub-resource that is loaded by the main resource. For example, if you're
+loading a scene that loads 10 images, each image will be one stage.
+
+Usage
+-----
+
+Usage is generally as follows
+
+Obtaining a ResourceInteractiveLoader
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Ref ResourceLoader::load_interactive(String p_path);
+
+This method will give you a ResourceInteractiveLoader that you will use
+to manage the load operation.
+
+Polling
+~~~~~~~
+
+::
+
+ Error ResourceInteractiveLoader::poll();
+
+Use this method to advance the progress of the load. Each call to
+``poll`` will load the next stage of your resource. Keep in mind that
+each stage is one entire "atomic" resource, such as an image, or a mesh,
+so it will take several frames to load.
+
+Returns ``OK`` on no errors, ``ERR_FILE_EOF`` when loading is finished.
+Any other return value means there was an error and loading has stopped.
+
+Load Progress (optional)
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+To query the progress of the load, use the following methods:
+
+::
+
+ int ResourceInteractiveLoader::get_stage_count() const;
+ int ResourceInteractiveLoader::get_stage() const;
+
+.. raw:: html
+
+
+
+get\_stage\_count
+
+.. raw:: html
+
+
+
+| returns the total number of stages to load
+|
+
+.. raw:: html
+
+
+
+get\_stage
+
+.. raw:: html
+
+
+
+returns the current stage being loaded
+
+Forcing completion (optional)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Error ResourceInteractiveLoader::wait();
+
+Use this method if you need to load the entire resource in the current
+frame, without any more steps.
+
+Obtaining the resource
+~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Ref ResourceInteractiveLoader::get_resource();
+
+If everything goes well, use this method to retrieve your loaded
+resource.
+
+Example
+-------
+
+This example demostrates how to load a new scene. Consider it in the
+context of the
+[[https://github.com/okamstudio/godot/wiki/tutorial\_singletons#scene-switcher]]
+example.
+
+First we setup some variables and initialize the
+
+.. raw:: html
+
+
+
+current\_scene
+
+.. raw:: html
+
+
+
+with the main scene of the game:
+
+::
+
+ var loader
+ var wait_frames
+ var time_max = 100 h1. msec
+ var current_scene
+
+ func _ready():
+ var root = get_tree().get_root()
+ current_scene = root.get_child( root.get_child_count() -1 )
+
+The function
+
+.. raw:: html
+
+
+
+goto\_scene
+
+.. raw:: html
+
+
+
+is called from the game when the scene needs to be switched. It requests
+an interactive loader, and calls
+
+.. raw:: html
+
+
+
+set\_progress(true)
+
+.. raw:: html
+
+
+
+to start polling the loader in the
+
+.. raw:: html
+
+
+
+\_progress
+
+.. raw:: html
+
+
+
+callback. It also starts a "loading" animation, which can show a
+progress bar or loading screen, etc.
+
+::
+
+ func goto_scene(path): h1. game requests to switch to this scene
+ loader = ResourceLoader.load_interactive(path)
+ if loader == null: # check for errors
+ show_error()
+ return
+ set_process(true)
+
+ current_scene.queue_free() # get rid of the old scene
+
+ # start your "loading..." animation
+ get_node("animation").play("loading")
+
+ wait_frames = 1
+
+``_process`` is where the loader is polled. ``poll`` is called, and then
+we deal with the return value from that call. ``OK`` means keep polling,
+``ERR_FILE_EOF`` means load is done, anything else means there was an
+error. Also note we skip one frame (via ``wait_frames``, set on the
+``goto_scene`` function) to allow the loading screen to show up.
+
+Note how use use ``OS.get_ticks_msec`` to control how long we block the
+thread. Some stages might load really fast, which means we might be able
+to cram more than one call to ``poll`` in one frame, some might take way
+more than your value for ``time_max``, so keep in mind we won't have
+precise control over the timings.
+
+::
+
+ func _process(time):
+ if loader == null:
+ # no need to process anymore
+ set_process(false)
+ return
+
+ if wait_frames > 0: # wait for frames to let the "loading" animation to show up
+ wait_frames -= 1
+ return
+
+ var t = OS.get_ticks_msec()
+ while OS.get_ticks_msec() < t + time_max: # use "time_max" to control how much time we block this thread
+
+ # poll your loader
+ var err = loader.poll()
+
+ if err == ERR_FILE_EOF: # load finished
+ var resource = loader.get_resource()
+ loader = null
+ set_new_scene(resource)
+ break
+ elif err == OK:
+ update_progress()
+ else: h1. error during loading
+ show_error()
+ loader = null
+ break
+
+Some extra helper functions. ``update_progress`` updates a progress bar,
+or can also update a paused animation (the animation represents the
+entire load process from beginning to end). ``set_new_scene`` puts the
+newly loaded scene on the tree. Because it's a scene being loaded,
+``instance()`` needs to be called on the resource obtained from the
+loader.
+
+::
+
+ func update_progress():
+ var progress = float(loader.get_stage()) / loader.get_stage_count()
+ # update your progress bar?
+ get_node("progress").set_progress(progress)
+
+ # or update a progress animation?
+ var len = get_node("animation").get_current_animation_length()
+
+ # call this on a paused animation. use "true" as the second parameter to force the animation to update
+ get_node("animation").seek(progress * len, true)
+
+ func set_new_scene(scene_resource):
+ current_scene = scene_resource.instance()
+ get_node("/root").add_child(current_scene)
+
+Using multiple threads
+======================
+
+ResourceInteractiveLoader can be used from multiple threads. A couple of
+things to keep in mind if you attempt it:
+
+Use a Semaphore
+~~~~~~~~~~~~~~~
+
+While your thread waits for the main thread to request a new resource,
+use a Semaphore to sleep (instead of a busy loop or anything similar).
+
+Don't block the main thread during the call to ``poll``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you have a mutex to allow calls from the main thread to your loader
+class, don't lock it while you call ``poll`` on the loader. When a
+resource is finished loading, it might require some resources from the
+low level APIs (VisualServer, etc), which might need to lock the main
+thread to acquire them. This might cause a deadlock if the main thread
+is waiting for your mutex while your thread is waiting to load a
+resource.
+
+Example class
+-------------
+
+You can find an example class for loading resources in threads
+`here `__.
+Usage is as follows:
+
+::
+
+ func start()
+
+Call after you instance the class to start the thread.
+
+::
+
+ func queue_resource(path, p_in_front = false)
+
+Queue a resource. Use optional parameter "p\_in\_front" to put it in
+front of the queue.
+
+::
+
+ func cancel_resource(path)
+
+Remove a resource from the queue, discarding any loading done.
+
+::
+
+ func is_ready(path)
+
+Returns true if a resource is done loading and ready to be retrieved.
+
+::
+
+ func get_progress(path)
+
+Get the progress of a resource. Returns -1 on error (for example if the
+resource is not on the queue), or a number between 0.0 and 1.0 with the
+progress of the load. Use mostly for cosmetic purposes (updating
+progress bars, etc), use ``is_ready`` to find out if a resource is
+actually ready.
+
+::
+
+ func get_resource(path)
+
+Returns the fully loaded resource, or null on error. If the resource is
+not done loading (``is_ready`` returns false), it will block your thread
+and finish the load. If the resource is not on the queue, it will call
+``ResourceLoader::load`` to load it normally and return it.
+
+Example:
+~~~~~~~~
+
+::
+
+ # initialize
+ queue = preload("res://resource_queue.gd").new()
+ queue.start()
+
+ # suppose your game starts with a 10 second custscene, during which the user can't interact with the game.
+ # For that time we know they won't use the pause menu, so we can queue it to load during the cutscene:
+ queue.queue_resource("res://pause_menu.xml")
+ start_curscene()
+
+ # later when the user presses the pause button for the first time:
+ pause_menu = queue.get_resource("res://pause_menu.xml").instance()
+ pause_menu.show()
+
+ # when you need a new scene:
+ queue.queue_resource("res://level_1.xml", true) # use "true" as the second parameter to put it at the front
+ # of the queue, pausing the load of any other resource
+
+ # to check progress
+ if queue.is_ready("res://level_1.xml"):
+ show_new_level(queue.get_resource("res://level_1.xml"))
+ else:
+ update_progress(queue.get_process("res://level_1.xml"))
+
+ # when the user walks away from the trigger zone in your Metroidvania game:
+ queue.cancel_resource("res://zone_2.xml")
+
+**Note**: this code in its current form is not tested in real world
+scenarios. Find me on IRC (punto on irc.freenode.net) or e-mail me
+(punto@okamstudio.com) for help.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/basic.rst b/tutorials/basic.rst
new file mode 100644
index 000000000..cb8525696
--- /dev/null
+++ b/tutorials/basic.rst
@@ -0,0 +1,20 @@
+Basic (step by step)
+====================
+
+.. toctree::
+ :maxdepth: 1
+ :name: basic
+
+ scenes_and_nodes
+ instancing
+ instancing_continued
+ scripting
+ scripting_continued
+ creating_2d_games
+ gui_introduction
+ creating_splash_screen
+ animation
+ resources
+ file_system
+ scene_tree
+ singletons_autoload
diff --git a/tutorials/canvas_layers.rst b/tutorials/canvas_layers.rst
new file mode 100644
index 000000000..622e556c6
--- /dev/null
+++ b/tutorials/canvas_layers.rst
@@ -0,0 +1,84 @@
+Canvas Layers
+=============
+
+Viewport and Canvas Items
+-------------------------
+
+Regular 2D nodes, such as
+`Node2D `__ or
+`Control `__
+both inherit from
+`CanvasItem `__,
+which is the base for all 2D nodes. CanvasItems can be arranged in trees
+and they will inherit their transform. This means that, moving the
+parent, the children will be moved too.
+
+| These nodes are placed as direct or indirect children to a
+ `Viewport `__,
+ and will be displayed through it.
+| Viewport has a property "canvas\_transform"
+ (`Viewport.set\_canvas\_transform() `__,
+ which allows to transform all the CanvasItem hierarchy by a custom
+ `Matrix32 `__
+ transform. Nodes such as
+ `Camera2D `__,
+ work by changing that transform.
+
+Changing the canvas transform is useful because it is a lot more
+efficient than moving the root canvas item (and hence the whole scene).
+Canvas transform is a simple matrix that offsets the whole 2D drawing,
+so it's the most efficient way to do scrolling.
+
+Not Enough..
+------------
+
+But this is not enough. There are often situations where the game or
+application may not want *everything* transformed by the canvas
+transform. Examples of this are:
+
+- **Parallax Backgrounds**: Backgrounds that move slower than the rest
+ of the stage.
+- **HUD**: Head's up display, or user interface. If the world moves,
+ the life counter, points, etc must stay static.
+- **Transitions**: Effects used for transitions (fades, blends) may
+ also want it to remain at a fixed location.
+
+How can these problems be solved in a single scene tree?
+
+CanvasLayers
+------------
+
+The answer is
+`CanvasLayer `__,
+which is a node that adds a separate 2D rendering layer for all it's
+children and grand-children. Viewport children will draw by default at
+layer "0", while a CanvasLayer will draw at any numeric layer. Layers
+with a greater number will be drawn above those with a smaller number.
+CanvasLayers also have their own transform, and do not depend of the
+transform of other layers. This allows the UI to be fixed in-place,
+while the word moves.
+
+An example of this is creating a parallax background. This can be done
+with a CanvasLayer at layer "-1". The screen with the points, life
+counter and pause button can also be created at layer "1".
+
+Here's a diagram of how it looks:
+
+.. image:: /img/canvaslayers.png
+
+CanvasLayers are independent of tree order, and they only depend on
+their layer number, so they can be instantiated when needed.
+
+Performance
+-----------
+
+Even though there shouldn't be any performance limitation, it is not
+advised to use excessive amount of layers to arrange drawing order of
+nodes. The most optimal way will always be arranging them by tree order.
+In the future, nodes will also have a priority or sub-layer index which
+should aid for this.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/changing_scenes_advanced.rst b/tutorials/changing_scenes_advanced.rst
new file mode 100644
index 000000000..bb4a23182
--- /dev/null
+++ b/tutorials/changing_scenes_advanced.rst
@@ -0,0 +1,13 @@
+Introduction
+============
+
+| Changing a scene in Godot is not often as straightforward, this is due
+ to the high flexibility offered by the scene system. As there is
+ nothing that really defines a "loaded scene", this must be done
+ manually.
+| The advantage of this is that it's easy to handle different common
+ situations, such as loading screens (with progress bar), transitions
+ (fadeins/fadeouts), preloaded scenes, etc.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/creating_2d_games.rst b/tutorials/creating_2d_games.rst
new file mode 100644
index 000000000..9c15cf08d
--- /dev/null
+++ b/tutorials/creating_2d_games.rst
@@ -0,0 +1,194 @@
+Simple 2D Game (Pong!)
+======================
+
+Pong
+~~~~
+
+In this simple tutorial, a basic game of Pong will be created. There are
+plenty of more complex examples in the demos included with the engine,
+but this should get introduced to basic functionality for 2D Games.
+
+Assets
+~~~~~~
+
+Some assets are included for this tutorial, the
+attachment:pong\_assets.zip.
+
+Scene Setup
+~~~~~~~~~~~
+
+For the sake of the old times, the game will be in 640x400 pixels
+resolution. This can be configured in the Project Settings (see previous
+tutorials). The default background color should be set to black:
+
+.. image:: /img/clearcolor.png
+
+Create a [[class\_node2d]] node for the project root. Node2D is the base
+type for the 2D engine. After this, add some sprites ([[class\_sprite]]
+node) and set each to the corresponding texture. The final scene layour
+should look similar to this (note: the ball is in the middle!):
+
+.. image:: /img/pong_layout.png
+
+The scene tree should, then look similar to this:
+
+.. image:: /img/pong_nodes.png
+
+Save the scene as "pong.scn" and set it as the main scene in the project
+properties.
+
+Input Actions Setup
+~~~~~~~~~~~~~~~~~~~
+
+There are so many input methods for video games... Keyboard, Joypad,
+Mouse, Touchscreen (Multitouch). Yet this is pong. The only input that
+matters is for the pads going up and down.
+
+Handling all possible input methods can be very frustrating and take a
+lot of code. The fact that most games allow controller customization
+makes this worse. For this, Godot created the "Input Actions". An action
+is defined, then input methods that trigger it are added.
+
+| Open the project properties dialog again, but this time move to the
+ "Input Map" tab.
+| On it, add 4 actions:
+ "left\_move\_up","left\_move\_down","right\_move\_up","right\_move\_down".
+ Assign the keys that you desire. A/Z for left and Up/Down as keys
+ should work in most cases.
+
+.. image:: /img/inputmap.png
+
+Script
+~~~~~~
+
+Create a script for the root node of the scene and open it (should have
+been explained in the previous tutorial!). The script will inherit
+Node2D:
+
+::
+
+ extends Node2D
+
+ func _ready():
+ pass
+
+In the constructor, two things will be done. The first is to enable
+processing, and the second to store some useful values. Such values are
+the dimensions of the screen and the pad:
+
+::
+
+
+ extends Node2D
+
+ var screen_size
+ var pad_size
+
+ func _ready():
+ screen_size = get_viewport_rect().size
+ pad_size = get_node("left").get_texture().get_size()
+ set_process(true)
+
+Then, some variables used for in-game will be added:
+
+::
+
+ #speed of the ball (in pixels/second0
+
+ var ball_speed = 80
+ #direction of the ball (normal vector)
+
+ var direction = Vector2(-1,0)
+ #constant for pad speed (also in pixels/second)
+
+ const PAD_SPEED = 150
+
+Finally, the process function:
+
+::
+
+ func _process(delta):
+
+Get some useful values for computation. The first is the ball position
+(from the node), the second is the rectangles (Rect2) of the pads.
+Sprites by defaut center the textures, so a small adjustment of size/2
+must be added.
+
+::
+
+ var ball_pos = get_node("ball").get_pos()
+ var left_rect = Rect2( get_node("left").get_pos() - pad_size/2, pad_size )
+ var right_rect = Rect2( get_node("right").get_pos() - pad_size/2, pad_size )
+
+Since the ball pos was obtained, integrating it should be simple:
+
+::
+
+ ball_pos+=direction*ball_speed*delta
+
+Then, now that the ball has a new position, it should be tested against
+everything. First, the floor and the roof:
+
+::
+
+ if ( (ball_pos.y<0 and direction.y <0) or (ball_pos.y>screen_size.y and direction.y>0)):
+ direction.y = -direction.y
+
+If one of the pads was touched, change direction and increase speed a
+little.
+
+::
+
+ if ( (left_rect.has_point(ball_pos) and direction.x < 0) or (right_rect.has_point(ball_pos) and direction.x > 0)):
+ direction.x=-direction.x
+ ball_speed*=1.1
+ direction.y=randf()*2.0-1
+ direction = direction.normalized()
+
+If the ball went out of the screen, it's game over. Game restarts:
+
+::
+
+ if (ball_pos.x<0 or ball_pos.x>screen_size.x):
+ ball_pos=screen_size*0.5 #ball goes to screen center
+ ball_speed=80
+ direction=Vector2(-1,0)
+
+Once everything was done with the ball, the node is updated with the new
+position:
+
+::
+
+ get_node("ball").set_pos(ball_pos)
+
+Only updating the pads according to player input. the Input class is
+really useful here:
+
+::
+
+ #move left pad
+ var left_pos = get_node("left").get_pos()
+
+ if (left_pos.y > 0 and Input.is_action_pressed("left_move_up")):
+ left_pos.y+=-PAD_SPEED*delta
+ if (left_pos.y < screen_size.y and Input.is_action_pressed("left_move_down")):
+ left_pos.y+=PAD_SPEED*delta
+
+ get_node("left").set_pos(left_pos)
+
+ #move right pad
+ var right_pos = get_node("right").get_pos()
+
+ if (right_pos.y > 0 and Input.is_action_pressed("right_move_up")):
+ right_pos.y+=-PAD_SPEED*delta
+ if (right_pos.y < screen_size.y and Input.is_action_pressed("right_move_down")):
+ right_pos.y+=PAD_SPEED*delta
+
+ get_node("right").set_pos(right_pos)
+
+And that's it! a simple Pong was written with a few lines of code.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/creating_3d_games.rst b/tutorials/creating_3d_games.rst
new file mode 100644
index 000000000..5f62bd892
--- /dev/null
+++ b/tutorials/creating_3d_games.rst
@@ -0,0 +1,253 @@
+Creating 3D games
+=================
+
+Introduction
+~~~~~~~~~~~~
+
+Creating a 3D game can be challenging. That extra Z coordinate makes
+many of the common techniques that helped to make 2D games simple no
+longer work. To aid in this transition, it is worth mentioning that
+Godot uses very similar APIs for 2D and 3D. Most nodes are the same and
+are present in both 2D and 3D versions. In fact, it is worth checking
+the 3D platformer tutorial, or the 3D kinematic character tutorials,
+which are almost identical to their 2D counterparts.
+
+In 3D, math is a little more complex than in 2D, so also checking the
+[[Vector Math]] in the wiki (which were specially created for game
+developers, not mathematicians or engineers) will help pave the way into
+efficiently developing 3D games.
+
+Spatial Node
+~~~~~~~~~~~~
+
+`Node2D `__ is
+the base node for 2D.
+`Control `__ is
+the base node for everything GUI. Following this reasoning, the 3D
+engine uses the
+`Spatial `__
+node for everything 3D.
+
+.. image:: /img/tuto_3d1.png
+
+Spatial nodes have a local transform, which is relative to the parent
+node (as long as the parent node is also **or inherits** of type
+Spatial). This transform can be accessed as a 4x3
+`Transform `__,
+or as 3
+`Vector3 `__
+members representing location, euler rotation (x,y and z angles) and
+scale.
+
+.. image:: /img/tuto_3d2.png
+
+3D Content
+~~~~~~~~~~
+
+Unlike 2D, where loading image content and drawing is straightforward,
+3D is a little more difficult. The content needs to be created with
+special 3D tool (usually referred to as DCCs) and exported to an
+exchange file format in order to be imported in Godot (3D formats are
+not as standardized as images).
+
+DCC-Created Models
+------------------
+
+There are two pipelines to import 3D models in Godot. The first and most
+common one is through the [[Import 3D]] importer, which allows to import
+entire scenes (just as they look in the DCC), including animation,
+skeletal rigs, blend shapes, etc.
+
+The second pipeline is through the [[Import Meshes]] importer. This
+second method allows importing simple .OBJ files as mesh resources,
+which can be then put inside a
+`MeshInstance `__
+node for display.
+
+Generated Geometry
+------------------
+
+It is possible to create custom geometry by using the
+`Mesh `__ resource
+directly, simply create your arrays and use the
+`Mesh.add\_surface `__
+function. A helper class is also available,
+`SurfaceTool `__,
+which provides a more straightforward API and helpers for indexing,
+generating normals, tangents, etc.
+
+In any case, this method is meant for generating static geometry (models
+that will not be updated often), as creating vertex arrays and
+submitting them to the 3D API has a significant performance cost.
+
+Immediate Geometry
+------------------
+
+If, instead, there is a requirement to generate simple geometry that
+will be updated often, Godot provides a special node,
+`ImmediateGeometry `__
+which provides an OpenGL 1.x style immediate-mode API to create points,
+lines, triangles, etc.
+
+2D in 3D
+--------
+
+While Godot packs a powerful 2D engine, many types of games use 2D in a
+3D environment. By using a fixed camera (either orthogonal or
+perspective) that does not rotate, nodes such as
+`Sprite3D `__
+and
+`AnimatedSprite3D `__
+can be used to create 2D games that take advantage of mixing with 3D
+backgrounds, more realistic parallax, lighting/shadow effects, etc.
+
+The disadvantage is, of course, that added complexity and reduced
+performance in comparison to plain 2D, as well as the lack of reference
+of working in pixels.
+
+Environment
+~~~~~~~~~~~
+
+Besides editing a scene, it is often common to edit the environment.
+Godot provides a
+`WorldEnvironment `__
+node that allows changing the background color, mode (as in, put a
+skybox), and applying several types of built-in post-processing effects.
+Environments can also be overriden in the Camera.
+
+3D Viewport
+~~~~~~~~~~~
+
+Editing 3D scenes is done in the 3D tab. This tab can be selected
+manually, but it will be automatically enabled when a Spatial node is
+selected.
+
+.. image:: /img/tuto_3d3.png
+
+Default 3D scene navigation controls are similar to Blender (aiming to
+have some sort of consistency in the free software pipeline..), but
+options are included to customize mouse buttons and behavior to be
+similar to other tools in Editor Settings:
+
+.. image:: /img/tuto_3d4.png
+
+Coordinate System
+-----------------
+
+Godot uses the `metric `__
+system for everything. 3D Physics and other areas are tuned for this, so
+attempting to use a different scale is usually a bad idea (unless you
+know what you are doing).
+
+When working with 3D assets, it's always best to work in the correct
+scale (set your DCC to metric). Godot allows scaling post-import and,
+while this works in most cases, in rare situations it may introduce
+floating point precision issues (and thus, glitches or artifacts) in
+delicate areas such as rendering or physics. So, make sure your artists
+always work in the right scale!
+
+The Y coordinate is used for "up", though for most objects that need
+alignment (like lights, cameras, capsule collider, vehicle, etc), the Z
+axis is used as a "pointing towards" direction. This convention roughly
+means that:
+
+- **X** is sides
+- **Y** is up/down
+- **Z** is front/back
+
+Space and Manipulation Gizmos
+-----------------------------
+
+Moving objects in the 3D view is done through the manipulator gizmos.
+Each axis is represented by a color: Red, Green, Blue represent X,Y,Z
+respectively. This convention applies to the grid and other gizmos too
+(and also to the shader language, ordering of components for
+Vector3,Color,etc).
+
+.. image:: /img/tuto_3d5.png
+
+Some useful keybindings:
+
+- To snap motion or rotation, press the "s" key while moving, scaling
+ or rotating.
+- To center the view on the selected object, press the "f" key.
+
+View Menu
+---------
+
+The view options are controlled by the \`[view]\` menu. Pay attention to
+this little menu inside the window because it is often overlooked!
+
+.. image:: /img/tuto_3d6.png
+
+Default Lighting
+----------------
+
+The 3D View has by some default options on lighting:
+
+- There is a directional light that makes objects visible while editing
+ turned on by default. It is no longer visible when running the game.
+- There is subtle default environment light to avoid places not reached
+ by the light to remain visible. It is also no longer visible when
+ running the game (and when the default light is turned off).
+
+These can be turned off by toggling the "Default Light" option:
+
+.. image:: /img/tuto_3d8.png
+
+Customizing this (and other default view options) is also possible via
+the settings menu:
+
+.. image:: /img/tuto_3d7.png
+
+which opens this window, allowing to customize ambient light color and
+default light direction:
+
+.. image:: /img/tuto_3d9.png
+
+Cameras
+-------
+
+No matter how many objects are placed in 3D space, nothing will be
+displayed unless a
+`Camera `__ is
+also added to the scene. Cameras can either work in orthogonal or
+perspective projections:
+
+.. image:: /img/tuto_3d10.png
+
+Cameras are associated and only display to a parent or grand-parent
+viewport. Since the root of the scene tree is a viewport, cameras will
+display on it by default, but if sub-viewports (either as render target
+or picture-in-picture) are desired, they need their own children cameras
+to display.
+
+.. image:: /img/tuto_3d11.png
+
+When dealing with multiple cameras, the following rules are followed for
+each viewport:
+
+- If no cameras are present in the scene tree, the first one that
+ enters it will become the active camera. Further cameras entering the
+ scene will be ignored (unless they are set as *current*).
+- If a camera has the "*current*" property set, it will be used
+ regardless of any other camera in the scene. If the property is set,
+ it will become active, replacing the previous camera.
+- If an active camera leaves the scene tree, the first camera in
+ tree-order will take it's place.
+
+Lights
+------
+
+There is no limitation on the number of lights and types in Godot. As
+many as desired can be added (as long as performance allows). Shadow
+maps are, however, limited. The more they are used, the less the quality
+overall.
+
+It is possible to use [[Light Baking]], to avoid using large amount of
+real-time lights and improve performance.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/creating_splash_screen.rst b/tutorials/creating_splash_screen.rst
new file mode 100644
index 000000000..10f8c9338
--- /dev/null
+++ b/tutorials/creating_splash_screen.rst
@@ -0,0 +1,50 @@
+Splash Screen
+=============
+
+Tutorial
+--------
+
+This will be a simple tutorial to cement the basic idea of how the GUI
+subsystem works. The goal will be to create a really simple, static,
+splash screen.
+
+Following is a file with the assets that will be used:
+
+attachment:robisplash\_assets.zip
+
+Setting Up
+----------
+
+Create a scene with screen resolution 800x450, and set it up like this:
+
+.. image:: /img/robisplashscene.png
+
+.. image:: /img/robisplashpreview.png
+
+The nodes 'background" and "logo" are of
+`TextureFrame `__
+type. These have a special property for setting the texture to be
+displayed, just load the corresponding file.
+
+.. image:: /img/texframe.png
+
+The node "start" is a
+`TextureButton `__,
+it takes several images for different states, but only the normal and
+pressed will be supplied in this example:
+
+.. image:: /img/texbutton.png
+
+Finally, the node "copyright" is a
+`Label `__. Labels
+can be set a custom font by editing the following property:
+
+.. image:: /img/label.png
+
+As a side note, the font was imported from a TTF, there is a [[Importing
+Fonts]] for importing fonts.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/custom_drawing_in_node2d_control.rst b/tutorials/custom_drawing_in_node2d_control.rst
new file mode 100644
index 000000000..a5a325cda
--- /dev/null
+++ b/tutorials/custom_drawing_in_node2d_control.rst
@@ -0,0 +1,115 @@
+Custom Drawing in 2D
+====================
+
+Why?
+----
+
+Godot has nodes to draw sprites, polygons, particles, and all sort of
+stuff. For far most cases this is enough, but not always. If something
+desired is not supported, and before crying in fear, angst and range
+because a node to draw that-specific-something does not exist.. it would
+be good to know that it is possible to easily make any 2D node (be it
+`Control `__ or
+`Node2D `__
+based) draw custom commands. It is *really* easy to do it too.
+
+But..
+-----
+
+Custom drawing manually in a node is *really* useful. Here are some
+examples why:
+
+- Drawing shapes or logic that is not handled by nodes (example: making
+ a node that draws a circle, an image with trails, a special kind of
+ animated polygon, etc).
+- Visualizations that are not that compatible with nodes: (example: a
+ tetris board). The tetris example uses a custom draw function to draw
+ the blocks.
+- Managing drawing logic of a large amount of simple objects (in the
+ hundreds of thousands). Using a thousand nodes is probably not nearly
+ as efficient as drawing, but a thousand of draw calls are cheap.
+ Check the "Shower of Bullets" demo as example.
+- Making a custom UI control. There are plenty of controls available,
+ but it's easy to run into the need to make a new, custom one.
+
+OK, How?
+--------
+
+Add a script to any
+`CanvasItem `__
+derived node, like
+`Control `__ or
+`Node2D `__.
+Override the \_draw() function.
+
+::
+
+ extends Node2D
+
+ func _draw():
+ #your draw commands here
+ pass
+
+Draw commands are described in the
+`CanvasItem `__
+class reference. There are plenty of them.
+
+Updating
+--------
+
+The \_draw() function is only called once, and then the draw commands
+are cached and remembered, so further calls are unnecessary.
+
+If re-drawing is required because a state or something else changed,
+simply call
+`CanvasItem.update() `__
+in that same node and a new \_draw() call will happen.
+
+Here is a little more complex example. A texture variable that will be
+redrawn if modified:
+
+::
+
+ extends Node2D
+
+ var texture setget _set_texture
+
+ func _set_texture(value):
+ #if the texture variable is modified externally,
+ #this callback is called.
+ texture=value #texture was changed
+ update() #update the node
+
+ func _draw():
+ draw_texture(texture,Vector2())
+
+In some cases, it may be desired to draw every frame. For this, just
+call update() from the \_process() callback, like this:
+
+::
+
+ extends Node2D
+
+ func _draw():
+ #your draw commands here
+ pass
+
+ func _process(delta):
+ update()
+
+ func _ready():
+ set_process(true)
+
+OK! This is basically it! Enjoy drawing your own nodes!
+
+Tools
+-----
+
+| Drawing your own nodes might also be desired while running them in the
+ editor, to use as preview or visualization of some feature or
+ behavior.
+| Remember to just use the "tool" keyword at the top of the script
+ (check the [[GDScript]] reference if you forgot what this does).
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/custom_gui_controls.rst b/tutorials/custom_gui_controls.rst
new file mode 100644
index 000000000..b0ab3cd09
--- /dev/null
+++ b/tutorials/custom_gui_controls.rst
@@ -0,0 +1,149 @@
+Custom GUI Controls
+===================
+
+So Many Controls..
+------------------
+
+Yet there are never enough. Creating your own custom controls that act
+just the way you want them is an obsession of almost every GUI
+programmer. Godot provides plenty of them, but they may not work exactly
+the way you want. Before contacting the developers with a pull-request
+to support diagonal scrollbars, at least it will be good to know how to
+create these controls easily from script.
+
+Drawing
+-------
+
+For drawing, it is recommended to check the [[Custom Draw 2D]] tutorial.
+The same applies. Some functions are worth mentioning due to their
+usefulness when drawing, so they will be detailed next:
+
+Checking Control Size
+~~~~~~~~~~~~~~~~~~~~~
+
+Unlike 2D nodes, "size" is very important with controls, as it helps to
+organize them in proper layouts. For this, the
+`Control.get\_size() `__
+method is provided. Checking it during \_draw() is vital to ensure
+everything is kept in-bounds.
+
+Checking Focus
+~~~~~~~~~~~~~~
+
+Some controls (such as buttons or text editors) might provide input
+focus for keyboard or joypad input. Examples of this are entering text
+or pressing a button. This is controlled with the
+`Control.set\_focus\_mode() `__
+function. When drawing, and if the control supports input focus, it is
+always desired to show some sort of indicator (highight, box, etc) to
+indicate that this is the currently focused control. To check for this
+status, the
+`Control.has\_focus() `__
+exists. Example
+
+::
+
+ func _draw():
+ if (has_focus()):
+ draw_selected()
+ else:
+ draw_normal()
+
+Sizing
+------
+
+As mentioned before, size is very important to controls. This allows
+them to lay out properly, when set into grids, containers, or anchored.
+Controls most of the time provide a *minimum size* to help to properly
+lay them out. For example, if controls are placed vertically on top of
+each other using a
+`VBoxContainer `__,
+the minimum size will make sure your custom control is not squished by
+the other controls in the container.
+
+To provide this callback, just override
+`Control.get\_minimum\_size() `__,
+for example:
+
+::
+
+ func get_minimum_size():
+ return Vector2(30,30)
+
+Or alternatively, set it via function:
+
+::
+
+ func _ready():
+ set_custom_minimum_size( Vector2(30,30) )
+
+Input
+-----
+
+Controls provide a few helpers to make managing input events much esier
+than regular nodes.
+
+Input Events
+~~~~~~~~~~~~
+
+There are a few tutorials about input before this one, but it's worth
+mentioning that controls have a special input method that only works
+when:
+
+- The mouse pointer is over the control.
+- The left button was pressed over this control (control always
+ captures input until button si released)
+- Control provides keyboard/joypad focus via
+ `Control.set\_focus\_mode `__.
+
+This function is
+`Control.\_input\_event(event) `__.
+Simply override it in your control. No processing needs to be set.
+
+::
+
+ extends Control
+
+ func _input_event(ev):
+ if (ev.type==InputEvent.MOUSE_BUTTON and ev.button_index==BUTTON_LEFT and ev.pressed):
+ print("Left mouse button was pressed!")
+
+For more information about events themselves, check the [[Input Events]]
+tutorial.
+
+Notifications
+~~~~~~~~~~~~~
+
+Controls also have many useful notifications for which no callback
+exists, but can be checked with the \_notification callback:
+
+::
+
+ func _notification(what):
+
+ if (what==NOTIFICATION_MOUSE_ENTER):
+ pass # mouse entered the area of this control
+ elif (what==NOTIFICATION_MOUSE_EXIT):
+ pass # mouse exited the area of this control
+ elif (what==NOTIFICATION_FOCUS_ENTER):
+ pass # control gained focus
+ elif (what==NOTIFICATION_FOCUS_EXIT):
+ pass # control lost focus
+ elif (what==NOTIFICATION_THEME_CHANGED):
+ pass # theme used to draw the control changed
+ # update and redraw is recommended if using a theme
+ elif (what==NOTIFICATION_VISIBILITY_CHANGED):
+ pass # control became visible/invisible
+ # check new status with is_visible()
+ elif (what==NOTIFICATION_THEME_CHANGED):
+ pass # theme used to draw the control changed
+ # update and redraw is recommended if using a theme
+ elif (what==NOTIFICATION_RESIZED):
+ pass # control changed size, check new size
+ # with get_size()
+ elif (what==NOTIFICATION_MODAL_CLOSED):
+ pass # for modal popups, notification
+ # that the popup was closed
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/cut-out_animation.rst b/tutorials/cut-out_animation.rst
new file mode 100644
index 000000000..c47059782
--- /dev/null
+++ b/tutorials/cut-out_animation.rst
@@ -0,0 +1,358 @@
+Cutout Animation
+================
+
+What is it?
+~~~~~~~~~~~
+
+Cut-out is a technique of animating in 2D where pieces of paper (or
+similar material) are cut in special shapes and laid one over the other.
+The papers are animated and photographed, frame by frame using a stop
+motion technique (more info
+`here `__.
+
+With the advent of the digital age, this technique became possible using
+computers, which resulted in an increased amount of animation TV shows
+using digital Cut-out. Notable examples are `South
+Park `__ or `Jake and the Never
+Land
+Pirates `__
+.
+
+In video games, this technique also become very popular. Examples of
+this are `Paper
+Mario `__ or `Rayman
+Origins `__ .
+
+Cutout in Godot
+~~~~~~~~~~~~~~~
+
+Godot provides a few tools for working with these kind of assets, but
+it's overall design makes it ideal for the workflow. The reason is that,
+unlike other tools meant for this, Godot has the following advantages:
+
+- **The animation system is fully integrated with the engine**: This
+ means, animations can control much more than just motion of objects,
+ such as textures, sprite sizes, pivots, opacity, color modulation,
+ etc. Everything can be animated and blended.
+- **Mix with Traditional**: AnimatedSprite allows traditional animation
+ to be mixed, very useful for complex objects, such as shape of hands
+ and foot, changing face expression, etc.
+- **Custom Shaped Elements**: Can be created with
+ `Polygon2D `__
+ allowing the mixing of UV animation, deformations, etc.
+- **Particle Systems**: Can also be mixed with the traditional
+ animation hierarchy, useful for magic effecs, jetpacks, etc.
+- **Custom Colliders**: Set colliders and influence areas in different
+ parts of the skeletons, great for bosses, fighting games, etc.
+- **Animation Tree**: Allows complex combinations and blendings of
+ several animations, the same way it works in 3D.
+
+And much more!
+
+Making of GBot!
+~~~~~~~~~~~~~~~
+
+For this tutorial, we will use as demo content the pieces of the
+`GBot `__
+character, created by Andreas Esau.
+
+.. image:: /img/tuto_cutout_walk.gif
+
+Get your assets attachment:gbot\_resources.zip .
+
+Setting up the Rig
+~~~~~~~~~~~~~~~~~~
+
+Create an empty Node2D as root of the scene, weĺl work under it:
+
+.. image:: /img/tuto_cutout1.png
+
+OK, the first node of the model that we will create will be the hip.
+Generally, both in 2D and 3D, the hip is the root of the skeleton. This
+makes it easier to animate:
+
+.. image:: /img/tuto_cutout2.png
+
+Next will be the torso. The torso needs to be a child of the hip, so
+create a child sprite and load the torso, later accommodate it properly:
+
+.. image:: /img/tuto_cutout3.png
+
+This looks good. Let's try if our hierarchy works as a skeleton by
+rotating the torso:
+
+.. image:: /img/tutovec_torso1.gif
+
+| Ouch, that doesn't look good! The rotation pivot is wrong, this means
+ it needs to be adjusted.
+| This small little cross in the middle of the
+ `Sprite `__ is
+ the rotation pivot:
+
+.. image:: /img/tuto_cutout4.png
+
+Adjusting the Pivot
+~~~~~~~~~~~~~~~~~~~
+
+The Pivot can be adjusted by changing the *offset* property in the
+Sprite:
+
+.. image:: /img/tuto_cutout5.png
+
+However, there is a way to do it more *visually*. Pick the object and
+move it normally. After the motion has begun and while the left mouse
+button is being held, press the "v" key *without releasing* the mouse
+button. Further motion will move the object around the pivot. This small
+tool allows adjusting the pivot easily. Finally, move the pivot to the
+right place:
+
+.. image:: /img/tutovec_torso2.gif
+
+Now it looks good! Let's continue adding body pieces, starting by the
+right arm. Make sure to put the sprites in hierarchy, so their rotations
+and translations are relative to the parent:
+
+.. image:: /img/tuto_cutout6.png
+
+This seems easy, so continue with the right arm. The rest should be
+simple! Or maybe not:
+
+.. image:: /img/tuto_cutout7.png
+
+Right. Remember your tutorials, Luke. In 2D, parent nodes appear below
+children nodes. Well, this sucks. It seems Godot does not support cutout
+rigs after all. Come back next year, maybe for 1.2.. no wait. Just
+Kidding! It works just fine.
+
+But how can this problem be solved? We want the whole to appear behind
+the hip and the torso. For this, we can move the nodes behind the hip:
+
+.. image:: /img/tuto_cutout8.png
+
+But then, we lose the hierarchy layout, which allows to control the
+skeleton like.. a skeleton. Is there any hope?.. Of Course!
+
+RemoteTransform2D Node
+~~~~~~~~~~~~~~~~~~~~~~
+
+| Godot provides a special node,
+ `RemoteTransform2D `__.
+ This node will transform nodes that are sitting somewhere else in the
+ hierarchy, by copying it's transform to the remote node.
+| This enables to have a visibility order independent from the
+ hierarchy.
+
+Simply create two more nodes as children from torso, remote\_arm\_l and
+remote\_hand\_l and link them to the actual sprites:
+
+.. image:: /img/tuto_cutout9.png
+
+Moving the remote transform nodes will move the sprites, allowing to
+easily animate and pose the character:
+
+.. image:: /img/tutovec_torso4.gif
+
+Completing the Skeleton
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Complete the skeleton by following the same steps for the rest of the
+parts. The resulting scene should look similar to this:
+
+.. image:: /img/tuto_cutout10.png
+
+The resulting rig should be easy to animate, by selecting the nodes and
+rotating them you can animate forward kinematic (FK) efficiently.
+
+For simple objects and rigs this is fine, however the following problems
+are common:
+
+- Selecting sprites can become difficult for complex rigs, and the
+ scene tree ends being used due to the difficulty of clicking over the
+ proper sprite.
+- Inverse Kinematics is often desired for extremities.
+
+To solve these problems, Godot supports a simple method of skeletons.
+
+Skeletons
+~~~~~~~~~
+
+Godot *does not really* support actual skeletons. What exists is a
+helper to create "bones" between nodes. This is enough for most cases,
+but the way it works is not completely obvious.
+
+As an example, let's turn the right arm into a skeleton. To create
+skeletons, a chain of nodes must be selected from top to bottom:
+
+.. image:: /img/tuto_cutout11.png
+
+Then, the option to create a skeleton is located at Edit [STRIKEOUT:>
+Skeleton]> Make Bones:
+
+.. image:: /img/tuto_cutout12.png
+
+This will add bones covering the arm, but the result is not quite what
+is expected.
+
+.. image:: /img/tuto_cutout13.png
+
+It looks like the bones are shifted up in the hierarchy. The hand
+connects to the arm, and the arm to the body. So the question is:
+
+- Why does the hand lack a bone?
+- Why does the arm connect to the body?
+
+This might seem strange at first, but will make sense later on. In
+traditional skeleton systems, bones have a position, an orientation and
+a length. In Godot, bones are mostly helpers so they connect the current
+node with the parent. Because of this, **toggling a node as a bone will
+just connect it to the parent**.
+
+So, with this knowledge. Let's do the same again so we have an actual,
+useful skeleton.
+
+The first step is creating an endpoint node. Any kind of node will do,
+but
+`Position2D `__
+is preferred because it's visible in the editor. The endpoint node will
+ensure that the last bone has orientation
+
+.. image:: /img/tuto_cutout14.png
+
+Now select the whole chain, from the endpoint to the arm and create
+bones:
+
+.. image:: /img/tuto_cutout15.png
+
+The result resembles a skeleton a lot more, and now the arm and forearm
+can be selected and animated.
+
+Finally, create endpoints in all meaningful extremities and connect the
+whole skeleton with bones up to the hip:
+
+.. image:: /img/tuto_cutout16.png
+
+Finally! the whole skeleton is rigged! On close look, it is noticeable
+that there is a second set of endpoints in the hands. This will make
+sense soon.
+
+Now that a whole skeleton is rigged, the next step is setting up the IK
+chains. IK chains allow for more natural control of extremities.
+
+IK Chains
+~~~~~~~~~
+
+To add in animation, IK chains are a powerful tool. Imagine you want to
+pose a foot in a specific position in the ground. Moving the foot
+involves also moving the rest of the leg bones. Each motion of the foot
+involves rotating several other bones. This is quite complex and leads
+to imprecise results.
+
+| So, what if we could just move the foot and let the rest of the leg
+ accommodate to the new foot position?
+| This type of posing is called IK (Inverse Kinematic).
+
+To create an IK chain, simply select a chain of bones from endpoint to
+the base for the chain. For example, to create an IK chain for the right
+leg select the following:
+
+.. image:: /img/tuto_cutout17.png
+
+Then enable this chain for IK. Go to Edit [STRIKEOUT:> Skeleton]> Make
+IK Chain
+
+.. image:: /img/tuto_cutout18.png
+
+As a result, the base of the chain will turn *Yellow*.
+
+.. image:: /img/tuto_cutout19.png
+
+Once the IK chain is set-up, simply grab any of the bones in the
+extremity, any child or grand-child of the base of the chain and try to
+grab it and move it. Result will be pleasant, satisfaction warranted!
+
+.. image:: /img/tutovec_torso5.gif
+
+Animation
+~~~~~~~~~
+
+The following section will be a collection of tips for creating
+animation for your rigs. If unsure about how the animation system in
+Godot works, refresh it by checking again the [[tutorial\_animation]].
+
+2D Animation
+------------
+
+When doing animation in 2D, a helper will be present in the top menu.
+This helper only appears when the animation editor window is opened:
+
+.. image:: /img/tuto_cutout20.png
+
+The key button will insert location/rotation/scale keyframes to the
+selected objects or bones. This depends on the mask enabled. Green items
+will insert keys while red ones will not, so modify the key insertion
+mask to your preference.
+
+Rest Pose
+~~~~~~~~~
+
+These kind of rigs do not have a "rest" pose, so it's recommended to
+create a reference rest pose in one of the animations.
+
+Simply do the following steps:
+
+| 1. Make sure the rig is in "rest" (not doing any specific pose).
+| 2. Create a new animation, rename it to "rest".
+| 3. Select all nodes (box selection should work fine).
+| 4. Select "loc" and "rot" on the top menu.
+| 5. Push the key button. Keys will be inserted for everything, creating
+ a default pose.
+
+.. image:: /img/tuto_cutout21.png
+
+Rotation
+~~~~~~~~
+
+Animating these models means only modifying the rotation of the nodes.
+Location and scale are rarely used, with the only exception of moving
+the entire rig from the hip (which is the root node).
+
+As a result, when inserting keys, only the "rot" button needs to be
+pressed most of the time:
+
+.. image:: /img/tuto_cutout22.png
+
+This will avoid the creation of extra animation tracks for the position
+that will remain unused.
+
+Keyframing IK
+~~~~~~~~~~~~~
+
+When editing IK chains, is is not neccesary to select the whole chain to
+add keyframes. Selecting the endpoint of the chain and inserting a
+keyframe will automatically insert keyframes until the chain base too.
+This makes the task of animating extremities much simpler.
+
+Moving Sprites Above and Behind Others.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+RemoteTransform2D works in most cases, but sometimes it is really
+necessary to have a node above and below others during an animation. To
+aid on this the "Behind Parent" property exists on any Node2D:
+
+.. image:: /img/tuto_cutout23.png
+
+Batch Setting Transition Curves
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When creating really complex animations and inserting lots of keyframes,
+editing the individual keyframe curves for each can become an endless
+task. For this, the Animation Editor has a small menu where changing all
+the curves is easy. Just select every single keyframe and (generally)
+apply the "Out-In" transition curve to smooth the animation:
+
+.. image:: /img/tuto_cutout24.png
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/editor_plugins.rst b/tutorials/editor_plugins.rst
new file mode 100644
index 000000000..d03f70f07
--- /dev/null
+++ b/tutorials/editor_plugins.rst
@@ -0,0 +1,12 @@
+Editor plug-ins
+===============
+
+.. toctree::
+ :maxdepth: 1
+ :name: editor-plugins
+
+.. editor_plugin
+.. editor_extension
+.. editor_import_export
+.. editor_scene_loader
+.. editor_3d_import
diff --git a/tutorials/encrypting_save_games.rst b/tutorials/encrypting_save_games.rst
new file mode 100644
index 000000000..960093d21
--- /dev/null
+++ b/tutorials/encrypting_save_games.rst
@@ -0,0 +1,59 @@
+Encrypting Save Games
+=====================
+
+Why?
+----
+
+Because the world today is not the world of yesterday. A capitalist
+oligarchy runs the world and forces us to consume in order to keep the
+gears of this rotten society on track. As such, the biggest market for
+video game consumption today is the mobile one. It is a market of poor
+souls forced to compulsively consume digital content in order to forget
+the misery of their every day life, commute, or just any other brief
+free moment they have that they are not using to produce goods or
+services for the ruling class. These individuals need to keep focusing
+on their video games (because not doing so will produce them a
+tremendous existential angst), so they go as far as spending money on
+them to extend their experience, and their preferred way of doing so is
+through in-app purchases and virtual currency.
+
+But, imagine if someone was to find a way to edit the saved games and
+assign the items and currency without effort? This would be terrible,
+because it would help players consume the content much faster, and as
+such run out of it sooner than expected. If this happens they will have
+nothing that avoids them to think, and the tremendous agony of realizing
+their own irrelevance would again take over their life.
+
+No, we definitely do not want this to happen, so let's see how to
+encrypt savegames and protect the world order.
+
+How?
+----
+
+The class `File `__
+is simple to use, just open a location and read/write data (integers,
+strings and variants). To create an encrypted file, a passphrase must be
+provided, like this:
+
+::
+
+ var f = File.new()
+ var err = f.open_encrypted_with_pass("user://savedata.bin",File.WRITE,"mypass")
+ f.store_var( game_state )
+ f.close()
+
+This will make the file unreadable to users, but will still not avoid
+them to share savefiles. To solve this, using the device unique id or
+some unique user identifier is needed, for example:
+
+::
+
+ var f = File.new()
+ var err = f.open_encrypted_with_pass("user://savedata.bin",File.WRITE,OS.get_unique_ID())
+ f.store_var( game_state )
+ f.close()
+
+This is all! Thanks for your cooperation, citizen.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/engine.rst b/tutorials/engine.rst
new file mode 100644
index 000000000..79cde2f86
--- /dev/null
+++ b/tutorials/engine.rst
@@ -0,0 +1,23 @@
+Engine
+======
+
+.. toctree::
+ :maxdepth: 1
+ :name: engine
+
+ viewports
+ screen_scaling_and_multiple_resolutions
+ input_events_and_actions
+ mouse_and_input_coordinates
+ version_control_and_project_organization
+ gui_control_repositioning
+ background_loading
+ saving_your_game
+ encrypting_save_games
+ internationalizing_a_game
+ handling_quit_request
+ pausing_the_game
+ ssl_certificates
+ changing_scenes_advanced
+.. basic_networking_tcp_and_udp
+.. gamepad_keyboard_controlled_guis
diff --git a/tutorials/file_system.rst b/tutorials/file_system.rst
new file mode 100644
index 000000000..6eca58079
--- /dev/null
+++ b/tutorials/file_system.rst
@@ -0,0 +1,110 @@
+File System
+===========
+
+Introduction
+------------
+
+Filesystem usage is yet another hot topic in engine development. This
+means, where are assets stored, how are they accessed, how do multiple
+programmers edit the same repository, etc.
+
+Initial versions of the engine (and previous iterations before it was
+named Godot) used a database. Assets were stored there and assigned an
+ID. Other approaches were tested, too, with local databases, files with
+metadata, etc. To say truth, and after a long time, simplicity proved to
+be best and Godot stores all assets as files in the flesystem.
+
+Implementation
+--------------
+
+Godot stores resources to disk. Anything, from a script, to a scene or a
+PNG image is a resource to the engine. If a resource contains properties
+that referece other resources on disk, the path to that resource is
+included. If it has sub-resources that are built-in, the resource is
+saved in a single file together with all the bundled sub-resources. For
+example, a font resource is often saved with the character textures
+bundled inside.
+
+Metadata files were also dropped and the whole engine design tries to
+avoid them. The reason for this is simple, existing asset managers and
+VCSs are just much better than anything we can implement, so Godot tries
+the best to play along with SVN, Git, Mercurial, Perforce, etc.
+
+engine.cfg
+----------
+
+| The mere existence of this file marks that there is a Godot project in
+ that directory and all sub-directories.
+| This file contains the project configuration in plain text, win.ini
+ style, though it will work to mark the existence of a project even if
+ the file is empty.
+
+Example of a filesystem:
+
+::
+
+ /engine.cfg
+ /enemy/enemy.scn
+ /enemy/enemy.gd
+ /enemy/enemysprite.png
+ /player/player.gd
+
+Directory Delimiter
+-------------------
+
+Godot only supports "/" as a directory delimiter. This is done for
+portability reasons. All operating systems support this, even Windows,
+so a path such as c:\\\\project\\\\engine.cfg needs to be typed as
+c:/project/engine.cfg.
+
+Resource Path
+-------------
+
+For accessing resources, using the host OS filesystem layout can be
+cumbersome and non portable. To solve this problem, the specal path
+\`"res://"\` was created.
+
+The path \`"res://"\` will always point at the project root (where
+engine.cfg is located, so in fact \`"res://engine.cfg"\` is always
+valid).
+
+This filesystem is read-write only when running the project locally from
+the editor. When exported or when running on different devices (such as
+phones or consoles, or running from DVD), the filesystem will become
+read-only and writing will no longer be permitted.
+
+User Path
+---------
+
+Writing to disk is still needed often, from doing a savegame to
+downloading content packs. For this, the engine ensures that there is a
+special path \`"user://"\` that is always writable.
+
+Host Filesystem
+---------------
+
+Of course, opening the host filesystem always works, as this is always
+useful when Godot is used to write tools, but for shipped projects this
+is discouraged and may not even be supported in some platforms.
+
+Drawbacks
+---------
+
+Not everything is rosy. Using resources and files and the plain
+filesystem has two main drawbacks. The first is that moving assets
+around (renaming them or moving them from a directory to another inside
+the project) once they are referenced is not that easy. If this is done,
+then dependencies will need to be re-satisfied upon load.
+
+The second is that under Windows or OSX, file access is case
+insensitive. If a developer works in this operating system and saves a
+file like "myfile.PNG", then references it as "myfile.png", it will work
+there, but not on any other platform, such as Linux, Android, etc. It
+may also not work on exported binaries, which use a compressed package
+for files.
+
+Because of this, please instruct your team to use a specific naming
+convention for files when working with Godot!
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/fixed_materials.rst b/tutorials/fixed_materials.rst
new file mode 100644
index 000000000..e17eb1be0
--- /dev/null
+++ b/tutorials/fixed_materials.rst
@@ -0,0 +1,181 @@
+Fixed Materials
+===============
+
+Introduction
+------------
+
+Fixed materials (originally Fixed Pipeline Materials) are the most
+common type of materials, using the most common material options found
+in 3D DCCs (such as Maya, 3DS Max or Blender). The big advantage of
+using them is that 3D artists are very familiar with this layout. They
+also allow to try out different things quickly without the need of
+writing shaders. Fixed Materials inherit from
+`Material `__,
+which also has several options. If you haven't read it before, reading
+the [[Materials]] tutorial is recommended.
+
+Options
+-------
+
+Here is the list of all the options available for fixed materials:
+
+.. image:: /img/fixed_materials.png
+
+From this point, every option will be explained in detail:
+
+Fixed Flags
+-----------
+
+These are a set of flags that control general aspects of the material.
+
+Use Alpha
+~~~~~~~~~
+
+This flag needs to be active for transparent materials to blend with
+what is behind, otherwise display will always be opaque. Do not enable
+this flag unless the material really needs it, because it can severely
+affect performance and quality. Materials with transparency will also
+not cast shadows (unless they contain opaque areas and the "opaque
+pre-pass" hint is turned on, see the [[Materials]] tutorial for more
+information).
+
+.. image:: /img/fixed_material_alpha.png
+
+Use Vertex Colors
+~~~~~~~~~~~~~~~~~
+
+Vertex color painting is a very common technique to add detail to
+geometry. 3D DCCs all support this, and many even support baking
+occlusion to it. Godot allows this information to be used in the fixed
+material by modulating the diffuse color when enabled.
+
+.. image:: /img/fixed_material_vcols.png
+
+Point Size
+~~~~~~~~~~
+
+Point size is used to set the point size (in pixels) for when rendering
+points. This feature is mostly used in tools and HUDs
+
+Discard Alpha
+~~~~~~~~~~~~~
+
+| When alpha is enabled (see above) the invisible pixels are blended
+ with what is behind them. In some combinations (of using alpha to
+ render depth) it may be possible that invisible pixels cover other
+ objects.
+| If this is the case, enable this option for the material. This option
+ is often used in combination with "opaque pre-pass" hint (see the
+ [[Materials]] tutorial for more information).
+
+Parameters
+----------
+
+Diffuse, Specular, Emission and Specular Exponent
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These are the base colors for the material.
+
+- Diffuse Color is responsible for the light that reaches the material,
+ then gets diffused around. This color varies by the angle to the
+ light and the distance (in the case of spot and omni lights). It is
+ the color that best represents the material. It can also have alpha
+ (transparency)
+- Specular color is the color of the reflected light and responsible
+ for shines. It is affected by the specular exponent.
+- Emission is the color of the light generated within the material
+ (althought it will not lit anything else around unless baking). This
+ color is constant.
+- Specular Exponent (or "Shininess"/"Intensity" in some 3D DCCs) is the
+ way light is reflected. If the value is high, light is reflected
+ completely, otherwise it is diffused more and more.
+
+Below is an example of how they interact:
+
+.. image:: /img/fixed_material_colors.png
+
+Shader & Shader Param
+~~~~~~~~~~~~~~~~~~~~~
+
+Regular shader materials allow custom lighting code. Fixed materials
+come with four predefined shader types:
+
+- **Lambert**: The standard diffuse light, where the amount of light is
+ proportional to the angle with the light emissor.
+- **Wrap**: A variation on Lambert, where the "coverage" of the light
+ can be changed. This is useful for many types of materials such as
+ wood, clay, hair, etc.
+- **Velvet**: This is similar to Lambert, but adds light scattering in
+ the edges. It's useful for leathers and some types of metals.
+- **Toon**: Standard toon shading with a coverage parameter. The
+ specular component also becomes toon-ized.
+
+.. image:: /img/fixed_material_shader.png
+
+Detail & Detail Mix
+~~~~~~~~~~~~~~~~~~~
+
+Detail is a second diffuse texture which can be mixed with the first one
+(more on textures later!). Detail blend and mix control how these are
+added together, here's an example of what detail textures are for:
+
+.. image:: /img/fixed_material_detail.png
+
+Normal Depth
+~~~~~~~~~~~~
+
+Normal depth controls the inensity of the normal-mapping as well as the
+direction. On 1 (the default) normalmapping applies normaly, on -1 the
+map is inverted and on 0 is disabled. Intermediate or greater values are
+accepted. Here's how it's supposed to look:
+
+.. image:: /img/fixed_material_normal_depth.png
+
+Glow
+~~~~
+
+This value controls how much of the color is sent to the glow buffer. It
+can be greater than 1 for a stronger effect. For glow to work, a
+WorldEnvironment must exist with Glow activated.
+
+.. image:: /img/fixed_material_glow.png
+
+Blend Mode
+~~~~~~~~~~
+
+Objects are usually blended in Mix mode. Other blend modes (Add and Sub)
+exist for special cases (usually particle effects, light rays, etc) but
+materials can be set to them:
+
+.. image:: /img/fixed_material_blend.png
+
+Point Size, Line Width
+~~~~~~~~~~~~~~~~~~~~~~
+
+When drawing points or lines, the size of them can be adjusted here per
+material.
+
+Textures
+--------
+
+Almost all of the parameters above can have a texture assigned to them.
+There are four options to where they can get their UV coordinates:
+
+- **UV Coordinates (UV Array)**: This is the regular UV coordinate
+ array that was imported with the model.
+- **UV x UV XForm**: UV Coordinates multiplied by the UV Xform matrix.
+- **UV2 Coordinates**: Some imported models might have come with a
+ second set of UV coordinates. These are common for detail textures or
+ for baked light textures.
+- **Sphere**: Spherical coordinates (difference of the normal at the
+ pixel by the camera normal).
+
+The value of every pixel of the texture is multiplied by the original
+parameter. This means that if a texture is loaded for diffuse, it will
+be multiplied by the color of the diffuse color parameter. Same applies
+to all the others except for specular exponent, which is replaced.
+
+© Juan Linietsky, Ariel Manzur, Distributed under the terms of the
+[[https://creativecommons.org/licenses/by/3.0/legalcode]] license.
+
+
diff --git a/tutorials/gui_control_repositioning.rst b/tutorials/gui_control_repositioning.rst
new file mode 100644
index 000000000..79e05fc11
--- /dev/null
+++ b/tutorials/gui_control_repositioning.rst
@@ -0,0 +1,56 @@
+Size and Anchors
+----------------
+
+If a game was to be always run in the same device and at the same
+resolution, positioning controls would be a simple matter of setting the
+position and size of each one of them. Unfortunately, it is rarely the
+case.
+
+Only TVs nowadays have a standard resolution and aspect ratio.
+Everything else, from computer monitors to tablets, portable consoles
+and mobile phones have different resolutions and aspect ratios.
+
+There are several ways to handle this, but for now let's just imagine
+that the screen resolution has changed and the controls need to be
+re-positioned. Some will need to follow the bottom of the screen, others
+the top of the screen, or maybe the right or left margins.
+
+.. image:: /img/anchors.png
+
+This is done by editing the *margin* properties of controls. Each
+control has four margins: left, right, bottom and top. By default all of
+them represent a distance in pixels relative to the top-left corner of
+the parent control or (in case there is no parent control) the viewport.
+
+.. image:: /img/margin.png
+
+When horizontal (left,right) and/or vertical (top,bottom) anchors are
+changed to END, the margin values become relative to the bottom-right
+corner of the parent control or viewport.
+
+.. image:: /img/marginend.png
+
+Here the control is set to expand it's bottom-right corner with that of
+the parent, so when re-sizing the parent, the control will always cover
+it, leaving a 20 pixel margin:
+
+.. image:: /img/marginaround.png
+
+Finally, there is also a ratio option, where 0 means left, 1 means right
+and anything in between is interpolated.
+
+[STRIKEOUT:Containers] (TODO)
+-----------------------------
+
+- [STRIKEOUT:This poses a difficult problem]
+- [STRIKEOUT:There are two ways of dealing]
+- [STRIKEOUT:style boxes]
+- [STRIKEOUT:title menu example]
+- [STRIKEOUT:containers]
+- [STRIKEOUT:theme]
+- [STRIKEOUT:focus]
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/gui_introduction.rst b/tutorials/gui_introduction.rst
new file mode 100644
index 000000000..5768c730e
--- /dev/null
+++ b/tutorials/gui_introduction.rst
@@ -0,0 +1,187 @@
+GUI Tutorial
+============
+
+Introduction
+~~~~~~~~~~~~
+
+If there is something that most programmers hate with passion, that is
+programming graphical user interfaces (GUIs). It's boring, tedious and
+unchallenging. Several aspects make matters worse such as:
+
+- Pixel alignment of UI elements is difficult (so it looks just like
+ the designer intends).
+- UIs are changed constantly due to design and usability issues that
+ appear during testing.
+- Handling proper screen re-sizing for different display resolutions.
+- Animating several screen components, to make it look less static.
+
+GUI programming is one of the leading causes of programmer burnout.
+During the development of Godot (and previous engine iterations),
+several techniques and philosophies for UI development were put in
+practice, such as immediate mode, containers, anchors, scripting, etc.
+This was always done with the main goal of reducing the stress
+programmers had to face while putting together user interfaces.
+
+In the end, the resulting UI subsystem in Godot is an efficient solution
+to this problem, and works by mixing together a few different
+approaches. While the learning curve is a little steeper than in other
+toolkits, developers can put together complex user interfaces in very
+little time, by sharing the same set of tools with designers and
+animators.
+
+Control
+~~~~~~~
+
+The basic node for UI elements is
+`Control `__
+(sometimes called "Widget" or "Box" in other toolkits). Every node that
+provides user interface functionality descends from it.
+
+When controls are put in a scene tree as a child of another control,
+it's coordinates (position, size) are always relative to the parent.
+This sets the basis for editing complex user interface quickly and
+visually.
+
+Input and Drawing
+~~~~~~~~~~~~~~~~~
+
+Controls receive input events by means of the
+`\_input\_event() `__
+callback. Only one control, the one in focus, will receive
+keyboard/joypad events (see
+`set\_focus\_mode() `__
+and
+`grab\_focus() `__.
+
+Mouse Motion events are received by the control directly below the mouse
+pointer. When a control receives a mouse button pressed event, all
+subsequent motion events are received by the pressed control until that
+button is released, even if the pointer moves outside the control
+boundary.
+
+Like any class that inherits from
+`CanvasItem `__
+(Control does), a
+`\_draw() `__
+callback will be received at the begining and every time the control
+needs to be redrawn (programmer needs to call
+`update() `__
+to enqueue the CanvasItem for redraw). If the control is not visible
+(yet aother CanvasItem property), the control does not receive any
+input.
+
+In general though, the programmer does not need to deal with drawing and
+input events directly when building UIs, (that is more useful when
+creating custom controls). Instead, controls emit different kinds of
+signals with contextural information for when action occurs. For
+example, a
+`Button `__ emits
+a "pressed" signal when pressed, a
+`Slider `__ will
+emit a "value\_changed" when dragged, etc.
+
+Custom Control Mini Tutorial
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+| Before going into more depth, creating a custom control will be a good
+ way to get the picture on how controls works, as they are not as
+ complex as it might seem.
+| Additionally, even though Godot comes with dozens of controls for
+ different purposes, it happens often that it's just easier to attain a
+ specific functionality by creating a new one.
+
+To begin, create a single-node scene. The node is of type "Control" and
+has a certain area of the screen in the 2D editor, like this:
+
+.. image:: /img/singlecontrol.png
+
+Add a script to that node, with the following code:
+
+::
+
+ extends Control
+
+ var tapped=false
+
+ func _draw():
+
+ var r = Rect2( Vector2(), get_size() )
+ if (tapped):
+ draw_rect(r, Color(1,0,0) )
+ else:
+ draw_rect(r, Color(0,0,1) )
+
+ func _input_event(ev):
+
+ if (ev.type==InputEvent.MOUSE_BUTTON and ev.pressed):
+ tapped=true
+ update()
+
+Then run the scene. When the rectangle is clicked/taped, it will go from
+blue to red. That synnergy between the events and drawing is pretty much
+how most controls work internally.
+
+.. image:: /img/ctrl_normal.png
+
+.. image:: /img/ctrl_tapped.png
+
+UI Complexity
+~~~~~~~~~~~~~
+
+As mentioned before, Godot includes dozens of controls ready for using
+in a user interface. Such controls are divided in two categories. The
+first is a small set of controls that work well for creating most game
+user interfaces. The second (and most controls are of this type) are
+meant for complex user interfaces and uniform skinning trough styles. A
+description is presented as follows to help understand which one should
+be used in which case.
+
+Simplified UI Controls
+~~~~~~~~~~~~~~~~~~~~~~
+
+This set of controls is enough for most games, where complex
+interactions or ways to present information are not necessary. The can
+be skinned easily with regular textures.
+
+- `Label `__ :
+ Node used for showing text.
+- `TextureFrame `__
+ : Displays a single texture, which can be scaled or kept fixed.
+- `TextureButton `__
+ : Displays a simple texture buttons, states such as pressed, hover,
+ disabled, etc can be set.
+- `TextureProgress `__
+ : Displays a single textured progress bar.
+
+Additionally, re-positioning of controls is most efficiently done with
+anchors in this case (see the [[GUI Repositioning]] tutorial for more
+info).
+
+In any case, it will happen often that even for simple games, more
+complex UI behaviors will be required. An example of this is a scrolling
+list of elements (for a high score table, for example), which needs a
+`ScrollContainer `__
+and a
+`VBoxContainer `__.
+These kind of more advanced controls can be mixed with the regular ones
+seamlessly (they are all controls anyway).
+
+Complex UI Controls
+~~~~~~~~~~~~~~~~~~~
+
+The rest of the controls (and there are dozens of them!) are meant for
+another set of scenarios, most commonly:
+
+- Games that require complex UIs, such as PC RPGs, MMOs, strategy,
+ sims, etc.
+- Creating custom development tools to speed up content creation.
+- Creating Godot Editor Plugins, to extend the engine functionality.
+
+Re-positioning controls for these kind of interfaces is more commonly
+done with containers (see the [[GUI Repositioning]] tutorial for more
+info).
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/gui_skinning.rst b/tutorials/gui_skinning.rst
new file mode 100644
index 000000000..e1d89e7aa
--- /dev/null
+++ b/tutorials/gui_skinning.rst
@@ -0,0 +1,168 @@
+Skinning a GUI
+==============
+
+Oh Beautiful GUI!
+~~~~~~~~~~~~~~~~~
+
+This tutorial is about advanced skinning of an user interface. Most
+games generally don't need this, as they end up just relying on
+`Label `__,
+`TextureFrame `__,
+`TextureButton `__
+and
+`TextureProgress `__.
+
+However, many types of games often need complex user interfaces, like
+MMOs, traditional RPGs, Simulators, Strategy, etc. These kind of
+interfaces are also common in some games that include editors to create
+content, or interfaces for network connectivity.
+
+Godot user interface uses these kind of controls with the default theme,
+but they can be skinned to resemble pretty much any kind of user
+interface.
+
+Theme
+~~~~~
+
+The GUI is skinned through the
+`Theme `__
+resource. Theme contains all the information required to change the
+entire visual styling of all controls. Theme options are named, so it's
+not obvious which name changes what (specialy from code), but several
+tools are provided. The ultimate place to look at what each theme option
+is for each control, which will always be more up to date than any
+documentation is the file
+https://github.com/okamstudio/godot/blob/master/scene/resources/default\_theme/default\_theme.cpp.
+The rest of this document will explain the different tools used to
+customize the theme.
+
+A Theme can be applied to any control in the scene. As a result, all
+children and grand-children controls will use that same theme too
+(unless another theme is specified further down the tree). If a value is
+not found in a theme, it will be searched in themes higher up in the
+hierarchy towards the root. If nothing was found, the default theme is
+used. This system allows for flexible overriding of themes in complex
+user interfaces.
+
+Theme Options
+~~~~~~~~~~~~~
+
+Each kind of option in a theme can be:
+
+- **An integer constant**: A single numerical constant. Generally used
+ to define spacing between compoments or alignment.
+- **A Color**: A single color, with or without transparency. Colors are
+ usually applied to fonts and icons.
+- **A Texture**: A single image. Textures are not often used, but when
+ they are they represent handles to pick or icons in a complex control
+ (such as file dialog).
+- **A Font**: Every control that uses text can be assigned the fonts
+ used to draw strings.
+- **A StyleBox**: Stylebox is a resource that defines how to draw a
+ panel in varying sizes (more information on them later).
+
+Every option is associated to:
+
+- A name (the name of the option)
+- A Control (the name of the control)
+
+An example usage:
+
+::
+
+ var t = Theme.new()
+ t.set_color("font_color","Label",Color(1.0,1.0,1.0))
+
+ var l = Label.new()
+ l.set_theme(t)
+
+In the example above, a new theme is created. The "font\_color" option
+is changed and then applied to a label. As a result, the label (and all
+children and grand children labels) will use that color.
+
+It is possible to override those options without using the theme
+directly and only for a specific control by using the override API in
+`Control `__:
+
+::
+
+ var l = Label.new()
+ l.add_color_override("font_color",Color(1.0,1.0,1.0))
+
+In the inline help of Godot (help tab) you can check which theme options
+are overrideable. This is not yet available in the wiki class reference,
+but will be soon.
+
+Customizing a Control
+~~~~~~~~~~~~~~~~~~~~~
+
+If only a few controls need to be skinned. It is often not neccesary to
+create a new theme. Controls offer their theme options as special kind
+of properties. If checked, overriding will take place:
+
+.. image:: /img/themecheck.png
+
+As can be see in the image above, theme options have little check-boxes.
+If checked, they can be used to override the value of the theme just for
+that control.
+
+Creating a Theme
+~~~~~~~~~~~~~~~~
+
+The simplest way to create a theme is to edit a theme resource. Create a
+Theme from the resource menu, the editor will appear immediately.
+Following to this, save it (to, as example, myheme.thm):
+
+.. image:: /img/themecheck.png
+
+This will create an empty theme that can later be loaded and assigned to
+controls.
+
+Example: Themeing a Button
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Take some assets attachment:skin\_assets.zip, go to the "theme" menu and
+select `Add Class Item <>`__
+
+.. image:: /img/themeci.png
+
+A menu will appear promting the type of control to create. Select
+`Button <>`__
+
+.. image:: /img/themeci2.png
+
+Immediately, all button theme options will appear in the property
+editor, where they can be edited:
+
+.. image:: /img/themeci3.png
+
+Select the "normal" stylebox and create a new "StyleBoxTexture", then
+edit it. A texture stylebox basically contains a texture and the size of
+the margins that will not stretch when the texture is stretched. This is
+called "3x3" stretching:
+
+.. image:: /img/sb1.png
+
+Repeat the steps and add the other assets. There is no hover or disabled
+image in the example files, so use the same stylebox as in normal. Set
+the supplied font as the button font and change the font color to black.
+Soon, your button will look different and retro:
+
+.. image:: /img/sb2.png
+
+Save this theme to the .thm file. Go to the 2D editor and create a few
+buttons:
+
+.. image:: /img/skinbuttons1.png
+
+Now, go to the root node of the scene and locate the "theme" property,
+replace it by the theme that was just created. It should look like this:
+
+.. image:: /img/skinbuttons2.png
+
+Congratulations! You have created a reusable GUI Theme!
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/handling_quit_request.rst b/tutorials/handling_quit_request.rst
new file mode 100644
index 000000000..32f647701
--- /dev/null
+++ b/tutorials/handling_quit_request.rst
@@ -0,0 +1,39 @@
+Handling Quit Request
+=====================
+
+Quitting
+--------
+
+Most platforms have the option to request the application to quit. On
+desktops, this is usually done with the "x" icon on the window titlebar.
+On Android, the back button is used to quit when on the main screen (and
+to go back otherwise).
+
+Handling the Notification
+-------------------------
+
+The
+`MainLoop `__
+has a special notification that is sent to all nodes when quit is
+requested: MainLoop.NOTIFICATION\_WM\_QUIT.
+
+Handling it is done as follows (on any node):
+
+::
+
+ func _notification(what):
+ if (what==MainLoop.NOTIFICATION_WM_QUIT_REQUEST):
+ get_tree().quit() #default behavior
+
+When developing mobile apps, quitting is not desired unless the user is
+on the main screen, so the behavior can be changed.
+
+It is important to note that by default, Godot apps have the built-in
+behavior to quit when quit is requested, this can be changed:
+
+::
+
+ get_tree().set_auto_accept_quit(false)
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/high_dynamic_range.rst b/tutorials/high_dynamic_range.rst
new file mode 100644
index 000000000..52a9e4300
--- /dev/null
+++ b/tutorials/high_dynamic_range.rst
@@ -0,0 +1,169 @@
+High Dynamic Range
+==================
+
+Introduction
+------------
+
+Normally, an artist does all the 3D modelling, then all the texturing,
+looks at his or her awesome looking model in the 3D DCC and says "looks
+fantastic, ready for integration!" then goes into the game, lighting is
+setup and the game runs.
+
+So where does all this HDR stuff thing come from? The idea is that
+instead of dealing with colors that go from black to white (0 to 1), we
+use colors whiter than white (for example, 0 to 8 times white).
+
+| To be more practical, imagine that in a regular scene, the intensity
+ of a light (generally 1.0) is set to 5.0. The whole scene will turn
+ very bright (towards white) and look horrible.
+| After this the luminance of the scene is computed by averaging the
+ luminance of every pixel of it, and this value is used to bring the
+ scene back to normal ranges. This last operation is called
+ tone-mapping. Finally, we are at a similar place from where we
+ started:
+
+.. image:: /img/hdr_tonemap.png
+
+Except the scene is more contrasted, because there is a higher light
+range in play. What is this all useful for? The idea is that the scene
+luminance will change while you move through the world, allowing
+situations like this to happen:
+
+.. image:: /img/hdr_cave.png
+
+Additionally, it is possible to set a threshold value to send to the
+glow buffer depending on the pixel luminance. This allows for more
+realistic light bleeding effects in the scene.
+
+Linear Color Space
+------------------
+
+| The problem with this technique is that computer monitors apply a
+ gamma curve to adapt better to the way the human eye sees. Artists
+ create their art on the screen too, so their art has an implicit gamma
+ curve applied to it.
+| The color space where images created in computer monitors exist is
+ called "sRGB". Every visual content that people has on their computers
+ or downloads from the internet (such as pictures, movies, porn, etc)
+ is in this colorspace.
+
+.. image:: /img/hdr_gamma.png
+
+The mathematics of HDR require that we multiply the scene by different
+values to adjust the luminance and exposure to different light ranges,
+and this curve gets in the way as we need colors in linear space for
+this.
+
+Linear Color Space & Asset Pipeline
+-----------------------------------
+
+Working in HDR is not just pressing a switch. First, imported image
+assets must be converted to linear space on import. There are two ways
+to do this:
+
+SRGB->Linear conversion on image import
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is the most compatible way of using linear-space assets and it will
+work everywhere including all mobile devices. The main issue with this
+is loss of quality, as sRGB exists to avoid this same problem. Using 8
+bits per channel to represent linear colors is inefficient from the
+point of view of the human eye. These textures might be later compressed
+too, which makes the problem worse.
+
+In any case though, this is the easy solution that works everywhere.
+
+Hardware sRGB -> Linear conversion.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is the most correct way to use assets in linear-space, as the
+texture sampler on the GPU will do the conversion after reading the
+texel using floating point. This works fine on PC and consoles, but most
+mobile devices do no support it, or do not support it on compressed
+texture format (iOS for example).
+
+Linear -> sRGB at the end.
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After all the rendering is done, the linear-space rendered image must be
+converted back to sRGB. To do this, simply enable sRGB conversion in the
+current
+`Environment `__
+(more on that below).
+
+Keep in mind that sRGB [STRIKEOUT:> Linear and Linear]> sRGB conversions
+must always be **both** enabled. Failing to enable one of them will
+result in horrible visuals suitable only for avant garde experimental
+indie games.
+
+Parameters of HDR
+-----------------
+
+HDR is found in the
+`Environment `__
+resource. These are found most of the time inside a
+`WorldEnvironment `__
+node, or set in a camera. There are many parameters for HDR:
+
+.. image:: /img/hdr_parameters.png
+
+ToneMapper
+~~~~~~~~~~
+
+The ToneMapper is the heart of the algorithm. Many options for
+tonemappers are provided:
+
+- Linear: Simplest tonemapper. It does it's job for adjusting scene
+ brightness, but if the differences in light are too big, it will
+ cause colors to be too saturated.
+- Log: Similar to linear, but not as extreme.
+- Reinhardt: Classical tonemapper (modified so it will not desaturate
+ as much)
+- ReinhardtAutoWhite: Same as above, but uses the max scene luminance
+ to adjust the white value.
+
+Exposure
+~~~~~~~~
+
+The same exposure parameter as in real cameras. Controls how much light
+enters the camera. Higher values will result in a brighter scene and
+lower values will result in a darker scene.
+
+White
+~~~~~
+
+Maximum value of white.
+
+Glow Threshold
+~~~~~~~~~~~~~~
+
+Determine above which value (from 0 to 1 after the scene is tonemapped),
+light will start bleeding.
+
+Glow Scale
+~~~~~~~~~~
+
+Determine how much light will bleed.
+
+Min Luminance
+~~~~~~~~~~~~~
+
+Lower bound value of light for the scene at which the tonemapper stops
+working. This allows dark scenes to remain dark.
+
+Max Luminance
+~~~~~~~~~~~~~
+
+Upper bound value of light for the scene at which the tonemapper stops
+working. This allows bright scenes to remain saturated.
+
+Exposure Adjustment Speed
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Auto-exposure will change slowly and will take a while to adjust (like
+in real cameras). Bigger values means faster adjustment.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/http_client_class.rst b/tutorials/http_client_class.rst
new file mode 100644
index 000000000..3ba6c5962
--- /dev/null
+++ b/tutorials/http_client_class.rst
@@ -0,0 +1,110 @@
+Example
+=======
+
+Here's an example of using the
+`HTTPClient `__
+class. It's just a script, so it can be run by executing:
+
+.. raw:: html
+
+
+
+| c
+| c:\\\\godot> godot -s http\_test.gd
+|
+
+.. raw:: html
+
+
+
+It will connect and fetch a website.
+
+::
+
+ extends SceneTree
+
+ # HTTPClient demo
+ # This simple class can do HTTP requests, it will not block but it needs to be polled
+
+ func _init():
+
+ var err=0
+ var http = HTTPClient.new() # Create the Client
+
+ var err = http.connect("www.php.net",80) # Connect to host/port
+ assert(err==OK) # Make sure connection was OK
+
+
+ while( http.get_status()==HTTPClient.STATUS_CONNECTING or http.get_status()==HTTPClient.STATUS_RESOLVING):
+ #Wait until resolved and connected
+ http.poll()
+ print("Connecting..")
+ OS.delay_msec(500)
+
+ assert( http.get_status() == HTTPClient.STATUS_CONNECTED ) # Could not connect
+
+ # Some headers
+
+ var headers=[
+ "User-Agent: Pirulo/1.0 (Godot)",
+ "Accept: */*"
+ ]
+
+ err = http.request(HTTPClient.METHOD_GET,"/ChangeLog-5.php",headers) # Request a page from the site (this one was chunked..)
+
+ assert( err == OK ) # Make sure all is OK
+
+ while (http.get_status() == HTTPClient.STATUS_REQUESTING):
+ # Keep polling until the request is going on
+ http.poll()
+ print("Requesting..")
+ OS.delay_msec(500)
+
+
+ assert( http.get_status() == HTTPClient.STATUS_BODY or http.get_status() == HTTPClient.STATUS_CONNECTED ) # Make sure request finished well.
+
+ print("response? ",http.has_response()) # Site might not have a response.
+
+
+ if (http.has_response()):
+ #If there is a response..
+
+ var headers = http.get_response_headers_as_dictionary() # Get response headers
+ print("code: ",http.get_response_code()) # Show response code
+ print("**headers:\\n",headers) # Show headers
+
+ #Getting the HTTP Body
+
+ if (http.is_response_chunked()):
+ #Does it use chunks?
+ print("Respose is Chunked!")
+ else:
+ #Or just plain Content-Length
+ var bl = http.get_response_body_length()
+ print("Response Length: ",bl)
+
+ #This method works for both anyway
+
+ var rb = RawArray() #array that will hold the data
+
+ while(http.get_status()==HTTPClient.STATUS_BODY):
+ #While there is body left to be read
+ http.poll()
+ var chunk = http.read_response_body_chunk() # Get a chunk
+ if (chunk.size()==0):
+ #got nothing, wait for buffers to fill a bit
+ OS.delay_usec(1000)
+ else:
+ rb = rb + chunk # append to read bufer
+
+
+ #done!
+
+ print("bytes got: ",rb.size())
+ var text = rb.get_string_from_ascii()
+ print("Text: ",text)
+
+
+ quit()
+
+
diff --git a/tutorials/index.rst b/tutorials/index.rst
new file mode 100644
index 000000000..c4632e6a5
--- /dev/null
+++ b/tutorials/index.rst
@@ -0,0 +1,15 @@
+Tutorials
+=========
+
+.. toctree::
+ :maxdepth: 2
+ :name: tutorials
+
+ basic
+ engine
+ 2d_tutorials
+ 3d_tutorials
+ shaders
+ math
+ advanced
+ editor_plugins
diff --git a/tutorials/input_events_and_actions.rst b/tutorials/input_events_and_actions.rst
new file mode 100644
index 000000000..509135fb1
--- /dev/null
+++ b/tutorials/input_events_and_actions.rst
@@ -0,0 +1,151 @@
+InputEvent
+==========
+
+What is it?
+-----------
+
+Managing input is usually complex, no matter the OS or platform. To ease
+this a little, a special built-in type is provided, [[API:InputEvent]].
+This datatype can be configured to contain several types of input
+events. Input Events travel through the engine and can be received in
+multiple locations, depending on the purpose.
+
+How does it work?
+-----------------
+
+Every input event is originated from the user/player (though it's
+possible to generate an InputEvent and feed then back to the engine,
+which is useful for gestures). The OS object for each platform will read
+events from the device, then feed the to MainLoop. As [[API::SceneTree]]
+is the default MainLoop implementation, events are fed to it. Godot
+provides a function to get the current SceneTree object :
+**get\_tree()**.
+
+But SceneTree does not know what to do with the event, so it will give
+it to the viewports, starting by the "root" [[API:Viewport]] (the first
+node of the scene tree). Viewport does quite a lot of stuff with the
+received input, in order:
+
+.. image:: /img/input_event_flow.png
+
+| 1. First, it will try to feed the input to the GUI, and see if any
+ control can receive it. If so, the [[API:Control]] will be called the
+ virtual function [[API:Control.\_input\_event()]] and the signal
+ "input\_event" will be emitted (this function is re-implementable by
+ script by inheriting from it). If the control wants to "consume" the
+ event, it will call [[API:Control.accept\_event()]] and the event will
+ not spread any more.
+| 2. If the GUI does not want the event, the standard \_input function
+ will be called in any node with input processing enabled (enable with
+ [[API:Node.set\_process\_input()]]) and override
+ [[API:Node.\_input()]]). If any function consumes the event, it can
+ call [[API:SceneTree.set\_input\_as\_handled()]], and the event will
+ not spread any more.
+| 3. If so far no one consumed the event, the unhandled input callback
+ will be called (enable with
+ [[API:Node.set\_process\_unhandled\_input()]]) and override
+ [[API:Node.\_unhandled\_input()]]). If any function consumes the
+ event, it can call [[SceneTree.set\_input\_as\_handled()]], and the
+ event will not spread any more.
+| 4. If no one wanted the event so far, and a [[API:Camera]] is assigned
+ to the Viewport, a ray to the physics world (in the ray direction from
+ he click) will be casted. If this ray hits an object, it will call the
+ [[API:CollisionObject.\_input\_event()]] function in the relevant
+ physics object (bodies receive this callback by default, but areas do
+ not. This can be configured through [[API:Area]] properties).
+| 5. Finally, if the event was unhandled, it will be passed to the next
+ Viewport in the tree, or it will be ignored.
+
+Anatomy of an InputEvent
+------------------------
+
+| [[API:InputEvent]] is just a base built-in type, it does not represent
+ anything and only contains some basic information, such as event ID
+ (which is increased for each event), device index, etc.
+| InputEvent has a "type" member. By assigning it, it can become
+ different types of input event. Every type of InputEvent has different
+ properties, according to it's role.
+
+Example of changing event type.
+
+::
+
+ # create event
+ var ev = InputEvent()
+ # set type index
+ ev.type=InputEvent.MOUSE_BUTTON
+ # button_index is only available for the above type
+ ev.button_index=BUTTON_LEFT
+
+There are several types of InputEvent, described in the table below:
+
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| Event | Type Index | Description |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| ------- | ------------ | ------------- |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEvent]] | NONE | Empty Input Event |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventKey]] | KEY | Contains a scancode and unicode value, as well as modifiers |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventMouseButton]] | MOUSE\_BUTTON | Contains click information, such as button, modifiers, etc. |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventMouseMotion]] | MOUSE\_MOTION | Contains motion information, such as relative, absolute positions and speed. |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventJoystickMotion]] | JOYSTICK\_MOTION | Contains Joystick/Joypad analog axis information. |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventJoystickButton]] | JOYSTICK\_BUTTON | Contains Joystick/Joypad button information. |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventScreenTouch]] | SCREEN\_TOUCH | Contains multi-touch press/release information. (only available on mobile devices) |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventScreenDrag]] | SCREEN\_DRAG | Contains multi-touch drag information. (only available on mobile devices) |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+| [[API:InputEventAction]] | SCREEN\_ACTION | Contains a generic action. These events are often generated by the programmer as feedback. (more on this below) |
++------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
+
+Actions
+-------
+
+An InputEvent may or may not represent a pre-defined action. Actions are
+useful because they abstract the input device when programming the game
+logic. This allows for:
+
+- The same code to work on different devices with different inputs (ie:
+ keyboard on PC, Joypad on console)
+- Input to be reconfigured at run-time.
+
+Actions can be created from the Project Settings menu in the Actions
+tab. If you read the [[Tutorial 2D]], there is an explanation on how
+does the action editor work.
+
+Any event has the methods [[API:InputEvent.is\_action()]],
+[[API:InputEvent.is\_pressed()]] and [[API:InputEvent.is\_echo()]].
+
+Alternatively, it may be desired to supply the game back with an action
+from the game code (a good example of this is detecting gestures).
+SceneTree (derived from MainLoop) has a method for this:
+[[API:MainLoop.input\_event(ev)]]. You would normally use it like this:
+
+::
+
+ var ev = InputEvent()
+ ev.type=InputEvent.ACTION
+ # set as move_left, pressed
+ ev.set_as_action("move_left",true)
+ # feedback
+ get_tree().input_event(ev)
+
+InputMap
+--------
+
+Customizing and re-mapping input from code is often desired. If your
+whole workflow depends on actions, the [[API:InputMap]] singleton is
+ideal for reassigning or creating different actions at run-time. This
+singleton is not saved (must be modified manually) and it's state is run
+from the project settings (engine.cfg). So any dynamic system of this
+type needs to store settings in the way the programmer sees best fit.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/instancing.rst b/tutorials/instancing.rst
new file mode 100644
index 000000000..e75880f7e
--- /dev/null
+++ b/tutorials/instancing.rst
@@ -0,0 +1,114 @@
+Instancing
+==========
+
+Rationale
+---------
+
+Having a scene and throwing nodes to it might work for small projects,
+but as a project grows, more and more nodes are used and it can quickly
+become unmanageable. To solve this, Godot allows a project to be
+separated in several scenes. This, however, does not work the same way
+as in other game engines. In fact, it's quite different, So please do
+not skip this tutorial!
+
+To recap: A scene is a collection of nodes organized as a tree, where
+they can have only one single node as the tree root.
+
+.. image:: /img/tree.png
+
+In Godot, a scene can be created and saved it to disk. As many scenes
+can be created and saved as desired.
+
+.. image:: /img/instancingpre.png
+
+Afterwards, while editing an existing or a new scene, other scenes can
+be instanced as part of it:
+
+.. image:: /img/instancing.png
+
+In the above picture, Scene B was added to Scene A as an instance. It
+may seem weird at first, but at the end of this tutorial it will make
+complete sense!
+
+Instancing, Step by Step
+------------------------
+
+To learn how to do instancing, let's start with downloading
+attachment:instancing.zip.
+
+Unzip this scene in any place of our preference. Then, add this scene to
+the project manager using the 'Import' option:
+
+.. image:: /img/importproject.png
+
+Simply browse to inside the project location and open the "engine.cfg"
+file. The new project will appear on the list of projects. Edit the
+project by using the 'Edit' option.
+
+This project contains two scenes "ball.scn" and "container.scn". The
+ball scene is just a ball with physics, while container scene has a
+nicely shaped collision, so balls can be thrown in there.
+
+| p=. |image4|
+| |image5|
+
+Open the container scene, then select the root node:
+
+.. image:: /img/controot.png
+
+Afterwards, push the '+' shaped button, this is the instancing button!
+
+.. image:: /img/continst.png
+
+| Select the ball scene (ball.scn), the ball should appear in the origin
+ (0,0), move it to around the center
+| of the scene, like this:
+
+.. image:: /img/continstanced.png
+
+Press Play and Voila!
+
+.. image:: /img/playinst.png
+
+The instanced ball fell to the bottom of the pit.
+
+A Little More
+-------------
+
+There can be as many instances as desired in a scene, just try
+instancing more balls, or duplicating them (ctrl-D or duplicate button):
+
+.. image:: /img/instmany.png
+
+Then try running the scene again:
+
+.. image:: /img/instmanyrun.png
+
+Cool, huh? This is how instancing works.
+
+Editing Instances
+-----------------
+
+Select one of the many copies of the balls and go to the property
+editor. Let's make it bounce a lot more, so look for the bounce
+parameter and set it to 1.0:
+
+.. image:: /img/instedit.png
+
+The next it will happen is that a green "revert" button appears. When
+this button is present, it means we modified a property from the
+instanced scene to override for a specific value in this instance. Even
+if that property is modified in the original scene, the custom value
+will always overwrite it. Pressing the revert button will restore the
+property to the original value that came from the scene.
+
+Conclusion
+----------
+
+Instancing seems handy, but there is more to it than it meets the eye!
+The next part of the instancing tutorial should cover the rest..
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/instancing_continued.rst b/tutorials/instancing_continued.rst
new file mode 100644
index 000000000..91d3f4d91
--- /dev/null
+++ b/tutorials/instancing_continued.rst
@@ -0,0 +1,80 @@
+Instancing (continued)
+======================
+
+Recap
+-----
+
+Instancing has many handy uses. At a glance, with instancing you have:
+
+- The ability to subdivide scenes and make them easier to manage.
+- A more flexible alternative to prefabs (and much more powerful given
+ instances work at many levels).
+- A way to design more complex game flows or even UIs (UI Elements are
+ nodes in Godot too).
+
+Design Language
+---------------
+
+But the real strong point of instancing scenes is that it works as an
+excellent design language. This is pretty much what makes Godot special
+and different to any other engine out there. All the engine was designed
+from the ground around this concept.
+
+When making games with Godot, the recommended approach is to leave aside
+other design patterns such as MVC or Entity-Relationship diagrams and
+start thinking games in a more natural way. Start by imagining the
+visible elements in a game, the ones that can be named not by just a
+programmer but by anyone.
+
+For example, here's how a simple shooter game can be imagined:
+
+.. image:: /img/shooter_instancing.png
+
+It's pretty easy to come up with a diagram like this for almost any kind
+of game. Just write down the elements that come to mind, and then the
+arrows that represent ownership.
+
+Once this diagram exists, making a game is about creating a scene for
+each of those nodes, and use instancing (either by code [STRIKEOUT:more
+of that later] or from the editor) to represent ownership.
+
+Most of the time programming games (or software in general) is spent
+designing an architecture and fitting game components to that
+architecture. Designing based on scenes replaces that and makes
+development much faster and more straightforward, allowing to
+concentrate on the game itself. Scene/Instancing based design is
+extremely efficient at saving a large part of that work, since most of
+the components designed map directly to a scene. This way, none or
+little architectural code is needed.
+
+The following is a more complex example, an open-world type of game with
+lots of assets and parts that interact:
+
+.. image:: /img/openworld_instancing.png
+
+| Make some rooms with furniture, then connect them. Make a house later,
+ and use those rooms are the interior.
+| The house can be part of a citadel, which has many houses. Finally the
+ citadel can be put on the world map terrain. Add also guards and other
+ NPCs to the citadel by previously creating their scenes.
+
+With Godot, games can grow as quickly as desired, as only more scenes
+have to be made and instanced. The editor UI is also designed to be
+operated by non programmers too, so an usual team development process
+involves 3D or 2D artists, level designers, game designers, animators,
+etc all working with the editor interface.
+
+Information Overload!
+---------------------
+
+Do not worry to much, the important part of this tutorial is to create
+awareness on how scenes and instancing are used in real life. The best
+way to understand all this is to make some games.
+
+Everything will become very obvious when put to practice, so, please do
+not scratch your head and go on to the next tutorial!
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/internationalizing_a_game.rst b/tutorials/internationalizing_a_game.rst
new file mode 100644
index 000000000..c21321741
--- /dev/null
+++ b/tutorials/internationalizing_a_game.rst
@@ -0,0 +1,122 @@
+Internationalization
+====================
+
+Introduction
+------------
+
+Sería excelente que el mundo hablara solo un idioma. Unfortunately for
+us developers, that is not the case. While not generally a big
+requirement when developing indie or niche games, it is also very common
+that games going into a more massive market require localization.
+
+Godot offers many tools to make this process more straightforward, so
+this tutorial is more like a collection of tips and tricks.
+
+Localization is usually done by specific studios hired for the job and,
+despite the huge amount of software and file formats available for this,
+the most common way to do localization to this day is still with
+spreadsheets. The process of creating the spreadsheets and importing
+them is already covered in the [[Import Translation]] tutorial, so this
+one could be seen more like a follow up to that one.
+
+Configuring the Imported Translation
+------------------------------------
+
+The translations can get updated and re-imported when they change, but
+they still have to be added to the project. This is done in Scene
+[STRIKEOUT:> Project Settings]> Localization:
+
+.. image:: /img/localization_dialog.png
+
+This dialog allows to add or remove translations project-wide.
+
+Localizing Resources
+--------------------
+
+It is also possible to instruct Godot to open alternative versions of
+assets (resources) depending on the current language. For this the
+"Remaps" tab exists:
+
+.. image:: /img/localization_remaps.png
+
+Select the resource to be remapped, and the alternatives for each
+locale.
+
+Converting Keys to Text
+-----------------------
+
+Some controls such as
+`Button `__.
+will automatically fetch a translation each time they are set a key
+instead of a text. For example, if a label is assigned
+"MAIN\_SCREEN\_GREETING1" and a key to different languages exists in the
+translations, this will be automatically converted. This process is done
+upon load though, so if the project in question has a dialog that allows
+changing the language in the settings, the scenes (or at least the
+settings scene) will have to be re-loaded for new text to have effect.
+
+For code, the
+`Object.tr() `__
+function can be used. This will just look-up the text into the
+translations and convert it if found:
+
+::
+
+ level.set_text(tr("LEVEL_5_NAME"))
+ status.set_text(tr("GAME_STATUS_"+str(status_index)))
+
+Making Controls Resizeable
+--------------------------
+
+The same text in different languages can vary greatly in length. For
+this, make sure to read the tutorial on [[GUI Repositioning]], as having
+dynamically adjusted control sizes may help.
+`Containers `__
+can be very useful, as well as the multiple options in
+`Label `__ for
+text wrapping.
+
+TranslationServer
+-----------------
+
+Godot has a server for handling the low level translation management
+called the
+`TranslationServer `__.
+Translations can be added or removed during run-time, and the current
+language be changed too.
+
+Command Line
+------------
+
+Language can be tested when running Godot from command line. For
+example, to test a game in french, the following arguments can be
+supplied:
+
+.. raw:: html
+
+
+
+| c:\\\\MyGame> godot -lang fr
+|
+
+.. raw:: html
+
+
+
+Translating the Project Name
+----------------------------
+
+The project name becomes the app name when exporting to different
+operating systems and platforms. To specify the project name in more
+than one language. In the project settings dialog, create a new setting
+application/name and append it the locale identifier. For example:
+
+.. image:: /img/localized_name.png
+
+As always, If you don't know the code of a language or zone, `check the
+list `__.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/inverse_kinematics.rst b/tutorials/inverse_kinematics.rst
new file mode 100644
index 000000000..34d0b7455
--- /dev/null
+++ b/tutorials/inverse_kinematics.rst
@@ -0,0 +1,157 @@
+| Before continuing on, I'd recommend reading some theory, the simplest
+ article I find is this:
+| http://freespace.virgin.net/hugo.elias/models/m\_ik2.htm
+
+Initial problem
+~~~~~~~~~~~~~~~
+
+Talking in Godot terminology, the task we want to solve here is position
+our 2 angles we talked about above so, that the tip of lowerarm bone is
+as close to target point, which is set by target Vector3() as possible
+using only rotations. This task is very calculation-intensive and never
+resolved by analytical equation solve. lso, it is underconstrained
+problem, which means there is unlimited number of solutions to the
+equation.
+
+.. image:: /img/inverse_kinematics.png
+
+For easy calculation, for this chapter we consider target is also
+child of Skeleton. If it is not the case for your setup you can always
+reparent it in your script, as you will save on calculations if you
+do.
+
+In the picture you see angles alpha and beta. In this case we don't
+use poles and constraints, so we need to add our own. On the picture
+the angles are 2D angles living in plane which is defined by bone
+base, bone tip and target.
+
+The rotation axis is easily calculated using cross-product of bone
+vector and target vector. The rotation in this case will be always in
+positive direction. If t is Transform which we get from
+get\_bone\_global\_pose() function, the bone vector is
+
+::
+
+ t.basis[2]
+
+so we have all information here to execute our algorithm.
+
+In game dev it is common to resolve this problem by iteratively closing
+to the desired location, adding/subtracting small numbers to the angles
+until the distance change achieved is less than some small error value.
+Sounds easy enough, but there are Godot problems we need to resolve
+there to achieve our goal.
+
+- **how to find coordinates of tip of the bone?**
+- **how to find vector from bone base to target?**
+
+For our goal (tip of the bone is within area of target), we need to know
+where is a tip of our IK bone. As we don't use leaf bone as IK bone, we
+know, that coordinate of tip is the base of child bone. But all these
+calculations are quite depend on skeleton structure. You can use
+pre-calculated constant as well. You can add extra bone for the tip of
+IK and calculate using that.
+
+Implementation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We will just use exported variable for bone length to be easy.
+
+::
+
+ export var IK_bone="lowerarm"
+ export var IK_bone_length=1.0
+ export var IK_error = 0.1
+
+Now, we need to apply our transformations from IK bone to the base of
+chain. So we apply rotation to IK bone then move from our IK bone upt to
+its parent, then apply rotation again, then move to the parent of
+current bone again, etc. So we need to limit our chain somewhat.
+
+::
+
+ export var IK_limit = 2
+
+For ``_ready()`` function:
+
+::
+
+ var skel
+ func _ready():
+ skel = get_node("arm/Armature/Skeleton")
+ set_process(true)
+
+Now we can write our chain-passing function:
+
+::
+
+ func pass_chain():
+ var b = skel.find_bone(IK_bone)
+ var l = IK_limit
+ while b >= 0 and l > 0:
+ print( "name":", skel.get_bone_name(b))
+ print( "local transform":", skel.get_bone_pose(b))
+ print( "global transform":", skel.get_bone_global_pose(b))
+ b = skel.get_bone_parent(b)
+ l = l - 1
+
+And for the ``_process()`` function:
+
+::
+
+ func _process(dt):
+ pass_chain(dt)
+
+Executing this script will just pass through bone chain printing bone
+transforms.
+
+::
+
+ extends Spatial
+
+ export var IK_bone="lowerarm"
+ export var IK_bone_length=1.0
+ export var IK_error = 0.1
+ export var IK_limit = 2
+ var skel
+ func _ready():
+ skel = get_node("arm/Armature/Skeleton")
+ set_process(true)
+ func pass_chain(dt):
+ var b = skel.find_bone(IK_bone)
+ var l = IK_limit
+ while b >= 0 and l > 0:
+ print("name: ", skel.get_bone_name(b))
+ print("local transform: ", skel.get_bone_pose(b))
+ print( "global transform:", skel.get_bone_global_pose(b))
+ b = skel.get_bone_parent(b)
+ l = l - 1
+ func _process(dt):
+ pass_chain(dt)
+
+Now we need to actually work with target. The target should be placed
+somewhere accessible. Since "arm" is imported scene, we better place
+target node within our top level scene. But for us to work with target
+easily its Transform should be on the same level as Skeleton.
+
+To cope with this problem we create "target" node under our scene root
+node and at script run we will reparent it copying global transform,
+which will achieve wanted effect.
+
+Create new Spatial node under root node and rename it to "target".
+Then modify ``_ready()`` function to look like this:
+
+::
+
+ var skel
+ var target
+ func _ready():
+ skel = get_node("arm/Armature/Skeleton")
+ target = get_node("target")
+ var ttrans = target.get_global_transform()
+ remove_child(target)
+ skel.add_child(target)
+ target.set_global_transform(ttrans)
+ set_process(true)
+
+
diff --git a/tutorials/kinematic_character_2d.rst b/tutorials/kinematic_character_2d.rst
new file mode 100644
index 000000000..b011909b6
--- /dev/null
+++ b/tutorials/kinematic_character_2d.rst
@@ -0,0 +1,252 @@
+Kinematic Character (2D)
+========================
+
+Introduction
+~~~~~~~~~~~~
+
+| Yes, the name sounds strange. "Kinematic Character" WTF is that? The
+ reason is that when physics engines came out, they were called
+ "Dynamics" engines (because they dealt mainly with collision
+ responses). Many attempts were made to create a character controller
+ using the dynamics engines but it wasn't as easy as it seems. Godot
+ has one of the best implementations of dynamic character controller
+ you can find (as it can be seen in the 2d/platformer demo), but using
+ it requieres a considerable level of skill and understanding of
+ physics engines (or a lot of patience with trial and error).
+| Some physics engines such as Havok seem to swear by dynamic character
+ controllers as the best alternative, while others (PhysX) would rather
+ promote the Kinematic one.
+
+So, what is really the difference?:
+
+- A **dynamic character controller** uses a rigid body with infinite
+ inertial tensor. Basically, it's a rigid body that can't rotate.
+ Physics engines always let objects collide, then solve their
+ collisions all together. This makes dynamic character controllers
+ able to interact with other physics objects seamlessly (as seen in
+ the platformer demo), however these interactions are not always
+ predictable. Collisions also can take more than one frame to be
+ solved, so a few collisions may seem to displace a tiny bit. Those
+ problems can be fixed, but require a certain amount of skill.
+- A **kinematic character controller** is assumed to always begin in a
+ non-colliding state, and will always move to a non colliding state.
+ If it starts in a colliding state, it will try to free itself (like
+ rigid bodies do) but this is the exception, not the rule. This makes
+ their control and motion a lot more predictable and easier to
+ program. However, as a downside, they can't directly interact with
+ other physics objects (unless done by hand in code).
+
+This short tutorial will focus on the kinematic character controller.
+Basically, the oldschool way of handling collisions (which is not
+necessarily simpler under the hood, but well hidden and presented as a
+nice and simple API).
+
+Fixed Process
+~~~~~~~~~~~~~
+
+To manage the logic of a kinematic body or character, it is always
+advised to use fixed process, which is called the same amount of times
+per second, always. This makes physics and motion calculation work in a
+more predictable way than using regular process, which might have spikes
+or lose precision is the frame rate is too high or too low.
+
+::
+
+ extends KinematicBody2D
+
+ func _fixed_process(delta):
+ pass
+
+ func _ready():
+ set_fixed_process(true)
+
+Scene Setup
+~~~~~~~~~~~
+
+To have something to test, here's the scene (from the tilemap tutorial)
+attachment:kbscene.zip. We'll be creating a new scene for the character.
+Use the robot sprite and create a scene like this:
+
+.. image:: /img/kbscene.png
+
+Let's add a circular collision shape to the collision body, create a new
+CircleShape2D in the shape property of CollisionShape2D. Set the radius
+to 30:
+
+.. image:: /img/kbradius.png
+
+**Note: As mentioned before in the physics tutorial, the physics engine
+can't handle scale on most types of shapes (only collision polygons,
+planes and segments work), so always change the parameters (such as
+radius) of the shape instead of scaling it. The same is also true for
+the kinematic/rigid/static bodies themselves, as their scale affect the
+shape scale.**
+
+| Now create a script for the character, the one used as an example
+ above should work as a base.
+| Finally, instance that character scene in the tilemap, and make the
+ map scene the main one, so it runs when pressing play.
+
+.. image:: /img/kbinstance.png
+
+Moving the Kinematic Character
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Go back to the character scene, and open the script, the magic begins
+now! Kinematic body will do nothing by default, but it has a really
+useful function called
+`move(motion\_vector:Vector2) `__.
+This function takes a
+`Vector2 `__ as
+an argument, and tries to apply that motion to the kinematic body. If a
+collision happens, it stops right at the moment of the collision.
+
+So, let's move our sprite downwards until it hits the floor:
+
+::
+
+ extends KinematicBody2D
+
+ func _fixed_process(delta):
+ move( Vector2(0,1) ) #move down 1 pixel per physics frame
+
+ func _ready():
+ set_fixed_process(true)
+
+| The result is that the character will move, but stop right when
+ hitting the floor. Pretty cool, huh?
+| The next step will be adding gravity to the mix, this way it behaves a
+ little more like an actual game character:
+
+::
+
+ extends KinematicBody2D
+
+ const GRAVITY = 200.0
+ var velocity = Vector2()
+
+ func _fixed_process(delta):
+
+ velocity.y += delta * GRAVITY
+
+ var motion = velocity * delta
+ move( motion )
+
+ func _ready():
+ set_fixed_process(true)
+
+Now the character falls smoothly. Let's make it walk to the sides, left
+and right when touching the directional keys. Remember that the values
+being used (for speed at least) is pixels/second.
+
+This adds simple walking support by pressing left and right:
+
+::
+
+ extends KinematicBody2D
+
+ const GRAVITY = 200.0
+ const WALK_SPEED = 200
+
+ var velocity = Vector2()
+
+ func _fixed_process(delta):
+
+ velocity.y += delta * GRAVITY
+
+ if (Input.is_action_pressed("ui_left")):
+ velocity.x = -WALK_SPEED
+ elif (Input.is_action_pressed("ui_right")):
+ velocity.x = WALK_SPEED
+ else:
+ velocity.x = 0
+
+ var motion = velocity * delta
+ move( motion )
+
+ func _ready():
+ set_fixed_process(true)
+
+And give it a try.
+
+Problem?
+~~~~~~~~
+
+And.. it doesn't work very well. If you go to the left against a wall,
+it gets stuck unless you release the arrow key. Once it is on the floor,
+it also gets stuck and it won't walk. What is going on??
+
+The answer is, what it seems like it should be simple, it isn't that
+simple in reality. If the motion can't be completed, the character will
+stop moving. It's as simple as that. This diagram should illustrate
+better what is going on:
+
+.. image:: /img/motion_diagram.png
+
+Basically, the desired motion vector will never complete because it hits
+the floor and the wall too early in the motion trajectory and that makes
+it stop there. Remember that even though the character is on the floor,
+the gravity is always turning the motion vector downwards.
+
+Solution!
+~~~~~~~~~
+
+The solution? This situation is solved by "sliding" by the collision
+normal. KinematicBody2D provides two useful functions:
+
+- `KinematicBody2D.is\_colliding() `__
+- `KinematicBody2D.get\_collision\_normal() `__
+
+So what we want to do is this:
+
+.. image:: /img/motion_reflect.png
+
+| When colliding, the function move() returns the "remainder" of the
+ motion vector. That means, if the motion vector is 40 pixels, but
+ collision happened at 10 pixels, the same vector but 30 pixels long is
+ returned.
+| The correct way to solve the motion is, then, to slide by the normal
+ this way:
+
+::
+
+ func _fixed_process(delta):
+
+ velocity.y += delta * GRAVITY
+ if (Input.is_action_pressed("ui_left")):
+ velocity.x = - WALK_SPEED
+ elif (Input.is_action_pressed("ui_right")):
+ velocity.x = WALK_SPEED
+ else:
+ velocity.x = 0
+
+ var motion = velocity * delta
+ motion = move( motion )
+
+ if (is_colliding()):
+ var n = get_collision_normal()
+ motion = n.slide( motion )
+ velocity = n.slide( velocity )
+ move( motion )
+
+
+
+ func _ready():
+ set_fixed_process(true)
+
+| Note that not only the motion has been modified but also the velocity.
+ This makes sense as it helps keep
+| the new direction too.
+
+The normal can also be used to detect that the character is on floor, by
+checking the angle. If the normal points up (or at least, within a
+certain threshold), the character can be determined to be there.
+
+A more complete demo can be found in the demo zip distributed with the
+engine, or in the
+https://github.com/okamstudio/godot/tree/master/demos/2d/kinematic\_char.
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/lighting.rst b/tutorials/lighting.rst
new file mode 100644
index 000000000..4796e5d41
--- /dev/null
+++ b/tutorials/lighting.rst
@@ -0,0 +1,113 @@
+Lighting
+========
+
+Introduction
+------------
+
+Lights emit light that mix with the materials and produces a visible
+result. Light can come from several types of sources in a scene:
+
+- From the Material itself, in the form of the emission color (though
+ it does not affect nearby objects unless baked).
+- Light Nodes: Directional, Omni and Spot.
+- Ambient Light in the
+ `Environment `__.
+- Baked Light (read [[Light Baking]]).
+
+The emission color is a material property, as seen in the previous
+tutorials about materials (go read them if you didn't at this point!).
+
+Light Nodes
+-----------
+
+As mentioned before, there are three types of light nodes: Directional,
+Ambient and Spot. Each has different uses and will be described in
+detail below, but firs let's take a look at the common parameters for
+lights:
+
+.. image:: /img/light_params.png
+
+Each one has a specific function:
+
+- **Enabled**: Lights can be disabled at any time.
+- **Bake Mode**: When using the light baker, the role of this light can
+ be defined in this enumerator. The role will be followed even if the
+ light is disabled, which allows to configure a light and then disable
+ it for baking.
+- **Energy**: This value is a multiplier for the light, it's specially
+ useful for [[HRD]] and for Spot and Omni lights, because it can
+ create very bright spots near the emissor.
+- **Diffuse and Specular**: These light values get multiplied by the
+ material light and diffuse colors, so a white value does not mean
+ that light will be white, but that the original color will be kept.
+- **Operator**: It is possible to make some lights negative for a
+ darkening effect.
+- **Projector**: Lights can project a texture for the diffuse light
+ (currently only supported in Spot light).
+
+Directional Light
+~~~~~~~~~~~~~~~~~
+
+This is the most common type of light and represents the sun. It is also
+the cheapest light to compute and should be used whenever possible
+(although it's not the cheapest shadow-map to compute, but more on that
+later). Directional light nodes are represented by a big arrow, which
+represent the direction of the light, however the position of the node
+does not affect the lighting at all, and can be anywhere.
+
+.. image:: /img/light_directional.png
+
+Basically what faces the light is lit, what doesn't is dark. Most lights
+have specific parameters but directional lights are pretty simple in
+nature so they don't.
+
+Omni Light
+~~~~~~~~~~
+
+Omni light is a point that throws light all around it up to a given
+radius (distance) that can be controlled by the user. The light
+attenuates with the distance and reaches 0 at the edge. It represents
+lamps or any other light source that comes from a point.
+
+.. image:: /img/light_omni.png
+
+| The attenuation curve for these kind of lights in nature is computed
+ with an inverse-quadratic function that never reaches zero and has
+ almost infinitely large values near the emissor.
+| This makes them considerably inconvenient to tweak for artists, so
+ Godot simulates them with an artist-controlled exponential curve
+ instead.
+
+.. image:: /img/light_attenuation.png
+
+Spot Light
+~~~~~~~~~~
+
+Spot lights are similar to Omni lights, except they only operate between
+a given angle (or "cutoff"). They are useful to simulate flashlights,
+car lights, etc. This kind of light is also attenuated towards the
+opposite direction it points to.
+
+.. image:: /img/light_spot.png
+
+Ambient Light
+-------------
+
+Ambient light can be found in the properties of a WorldEnvironment
+(remember only one of such can be instanced per scene). Ambient light
+consists of a uniform light and energy. This light is applied the same
+to every single pixel of the rendered scene, except to objects that used
+baked light.
+
+Baked Light
+-----------
+
+Baked Light stands for pre-computed ambient light. It can serve multiple
+purposes, such as baking light emissors that are not going to be used in
+real-time, and baking light bounces from real-time lights to add more
+realism to a scene (see Baked Light]] tutorial for more information).
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/materials.rst b/tutorials/materials.rst
new file mode 100644
index 000000000..bab85e2f1
--- /dev/null
+++ b/tutorials/materials.rst
@@ -0,0 +1,119 @@
+Materials
+=========
+
+Introduction
+------------
+
+| Materials can be applied to most visible 3D objects, they basically
+ are a description to how light reacts to that object. There are many
+ types of materials, but the main ones are the
+ `FixedMaterial `__
+ and
+ `ShaderMaterial `__.
+ Tutorials for each of them exist [[Fixed Material]] and [[Shader
+ Material]].
+| This tutorial is about the basic properties shared between them.
+
+.. image:: /img/material_flags.png
+
+Flags
+-----
+
+Materials, no matter which type they are, have a set of flags
+associated. Each has a different use and will be explained as follows.
+
+Visible
+~~~~~~~
+
+Toggles whether the material is visible. If unchecked, the object will
+not be shown.
+
+Double Sided & Invert Faces
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+| Godot by default only shows geometry faces (triangles) when facing the
+ camera. To do this it needs them to be in view in clockwise order.
+ This saves a lot of GPU power by ensuring that not visible triangles
+ are not drawn.
+| Some flat objects might need to be drawn all the times though, for
+ this the "double sided" flag will make sure that no matter the facing,
+ the triangle will always be drawn. It is also possible to invert this
+ check and draw counter-clockwise looking faces too, though it's not
+ very useful except for a few cases (like drawing outlines).
+
+Unshaded
+~~~~~~~~
+
+Objects are always black unless light affects them, and their shading
+changes according to the type and direction of lights. When this flag is
+turned on, the diffuse color is displayed right the same as it appears
+in the texture or parameter:
+
+.. image:: /img/material_unshaded.png
+
+On Top
+~~~~~~
+
+When this flag is turned on, te object will be drawn after everything
+else has been drawn and without a depth test. This is generally only
+useful for HUD effects or gizmos.
+
+Ligthmap on UV2
+~~~~~~~~~~~~~~~
+
+When using lightmapping (see the [[Light Baking]] tutorial), this option
+determines that the lightmap should be accessed on the UV2 array instead
+of regular UV.
+
+Parameters
+----------
+
+Some parameters also exist for controlling drawing and blending:
+
+Blend Mode
+~~~~~~~~~~
+
+Objects are usually blended in Mix mode. Other blend modes (Add and Sub)
+exist for special cases (usually particle effects, light rays, etc) but
+materials can be set to them:
+
+.. image:: /img/fixed_material_blend.png
+
+Line Width
+~~~~~~~~~~
+
+When drawing lines, the size of them can be adjusted here per material.
+
+Depth Draw Mode
+~~~~~~~~~~~~~~~
+
+This is a tricky but very useful setting. By default, opaque objects are
+drawn using the depth buffer and translucent objects are not (but are
+sorted by depth). This behavior can be changed here. The options are:
+
+- **Always**: Draw objects with depth always, even those with alpha.
+ This often results in glitches like the one in the first image (which
+ is why it's not the default).
+- **Opaque Only**: Draw objects with depth only when they are opaque,
+ and do not se depth for alpha. This is the default because it's fast,
+ but it's not the most correct setting. Objects with transparency that
+ self-intersect will always look wrong, specially those that mix
+ opaque and transparent areas, like grass tree leaves, etc. Objects
+ with transparency also can't cast shadows, this is evident i the
+ second image.
+- **Alpha Pre-Pass**: The same as above, but a depth pass is performed
+ for the opaque areas of objects with transparency. This makes objects
+ with transparency look much more correct. In the third image it is
+ evident how the leaves cast shadows between them and into the floor.
+ This setting is turned off by default because, while on PC this is
+ not very costly, mobile devices suffer a lot when this setting is
+ turned on, so use it with care.
+- **Never**: Never use the depth buffer for this material. This is
+ mostly useful in combination with the "On Top" flag explained above.
+
+.. image:: /img/material_depth_draw.png
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
+
+
diff --git a/tutorials/math.rst b/tutorials/math.rst
new file mode 100644
index 000000000..f8c21c782
--- /dev/null
+++ b/tutorials/math.rst
@@ -0,0 +1,9 @@
+Math
+====
+
+.. toctree::
+ :maxdepth: 1
+ :name: math
+
+ vector_math
+ matrices_and_transforms
diff --git a/tutorials/matrices_and_transforms.rst b/tutorials/matrices_and_transforms.rst
new file mode 100644
index 000000000..e68aed101
--- /dev/null
+++ b/tutorials/matrices_and_transforms.rst
@@ -0,0 +1,499 @@
+Matrices & Transforms
+=====================
+
+Introduction
+------------
+
+Before reading this tutorial, it is advised to read the previous one
+about [[Vector Math]] as this one is a direct continuation.
+
+| This tutorial will be about *transformations* and will cover a little
+ about matrices (but not in-depth).
+| Transformations are most of the time applied as translation, rotation
+ and scale so they will be considered as priority here.
+
+Oriented Coordinate System (OCS)
+--------------------------------
+
+Imagine we have a spaceship somewhere in space. In Godot this is easy,
+just move the ship somewhere and rotate it:
+
+.. image:: /img/tutomat1.png
+
+Ok, so in 2D this looks simple, a position and an angle for a rotation.
+But remember, we are grown ups here and don't use angles (plus, angles
+are not really even that useful when working in 3D).
+
+| We should realize that at some point, someone *designed* this
+ spaceship. Be it for 2D in a drawing such as Paint.net, Gimp,
+ Photoshop, etc. or in 3D through a 3D DCC tool such as Blender, Max,
+ Maya, etc.
+| When it was designed, it was not rotated. It was designed in it's own
+ *coordinate system*.
+
+.. image:: /img/tutomat2.png
+
+| This means that the tip of the ship has a coordinate, the fin has
+ another, etc. Be it in pixels (2D) or vertices (3D).
+| So, let's recall again that the ship was somewhere in space:
+
+.. image:: /img/tutomat3.png
+
+How did it get there? What moved it and rotated it from the place it was
+designed to it's current position? The answer is... a **transform**, the
+ship was *transformed* from their original position to the new one. This
+allows the ship to be displayed where it is.
+
+So, a transform is too generic of a term. To solve this puzzle, we will
+overimpose the ship's original design position at their current
+position:
+
+.. image:: /img/tutomat4.png
+
+So, we can see that the "design space" has been transformed too. How can
+we best represent this transformation? Let's use 3 vectors for this (in
+2D), a unit vector pointing towards X positive, a unit vector pointing
+towards Y positive and a translation.
+
+.. image:: /img/tutomat5.png
+
+Let's call the 3 vectors "X", "Y" and "Origin", and let's also
+overimpose them over the ship so it makes more sense:
+
+.. image:: /img/tutomat6.png
+
+Ok, this is nicer, but it still does not make sense. What do X,Y and
+Origin have to do with how the ship got there?
+
+Well, let's take the point from top tip of the ship as reference:
+
+.. image:: /img/tutomat7.png
+
+And let's apply the following operation to it (and to all the points in
+the ship too, but we'll track the top tip as our reference point):
+
+::
+
+ var new_pos = pos - origin
+
+Doing this to the selected point will move it back to the center:
+
+.. image:: /img/tutomat8.png
+
+This was expected, but then let's do something more interesting. Use the
+dot product of X and the point, and add it to the dot product of Y and
+the point:
+
+::
+
+ var final_pos = x.dot(new_pos) + y.dot(new_pos)
+
+Then what we have is.. wait a minute, it's the ship in it's design
+position!
+
+.. image:: /img/tutomat9.png
+
+| How did this black magic happen? The ship was lost in space, and now
+ it's back home!
+| It might seem strange, but it does have plenty of logic. Remember, as
+ we have seen in the [[tutorial\_vector\_math#distance-to-plane]], what
+ happened is that the distance to X axis, and the distance to Y axis
+ were computed. Calculating distance in a direction or plane was one of
+ the uses for the dot product. This was enough to obtain back the
+ design coordinates for every point in the ship.
+
+So, what he have been working with so far (with X, Y and Origin) is an
+*Oriented Coordinate System\*. X an Y are the **Basis**, and \*Origin*
+is the offset.
+
+Basis
+-----
+
+The Origin we know what it is. It's where the 0.0 (origin) of the design
+coordinate system ended up after being transformed to a new position.
+This is why it's called *Origin*, But in practice, it's just an offset
+to the new position.
+
+The Basis is more interesting. The basis is the X and Y of the new,
+transformed, OCS are pointing towards. It's telling what is in change of
+drawing 2D and 3D "Hey, the original X and Y axes or your design are
+*right here*, pointing towards *these directions*".
+
+So, let's change the representation of the basis. Instead of 2 vectors,
+let's use a *matrix*.
+
+.. image:: /img/tutomat10.png
+
+The vectors are up there in the matrix, horizontally. The next problem
+now is that.. what is this matrix thing? Well, we'll assume you've never
+heard of a matrix.
+
+Transforms in Godot
+-------------------
+
+This tutorial will not explain matrix math (and their operations) in
+depth, only it's practical use. There is plenty of material for that,
+which should be a lot simpler to understand after completing this
+tutorial. We'll just explain how to use transforms.
+
+Matrix32
+--------
+
+`Matrix32 `__
+is a 3x2 matrix. It has 3 Vector2 elements and it's used for 2D. The "X"
+axis is the element 0, "Y" axis is the element 1 and "Origin" is element
+2. It's not divided in basis/origin for convenience, due to it's
+simplicity.
+
+::
+
+ var m = Matrix32()
+ var x = m[0] # 'X'
+ var y = m[1] # 'Y'
+ var o = m[2] # 'Origin'
+
+Most operations will be explained with this datatype (Matrix32), but the
+same logic applies to 3D.
+
+Identity
+--------
+
+By default, Matrix32 is created as an "identity" matrix. This means:
+
+- 'X' Points right: Vector2(1,0)
+- 'Y' Points up (or down in pixels): Vector2(0,1)
+- 'Origin' is the origin Vector2(0,0)
+
+.. image:: /img/tutomat11.png
+
+It's easy to guess that an *identity* matrix is just a matrix that
+aligns the transform to it's parent coordinate system. It's an *OCS*
+that hasn't been translated, rotated or scaled. All transform types in
+Godot are created with *identity*.
+
+Operations
+----------
+
+Rotation
+--------
+
+Rotating Matrix32 is done by using the "rotated" function:
+
+::
+
+ var m = Matrix32()
+ m = m.rotated(PI/2) # rotate 90°
+
+.. image:: /img/tutomat12.png
+
+Translation
+-----------
+
+There are two ways to translate a Matrix32, the first one is just moving
+the origin:
+
+::
+
+ # Move 2 units to the right
+ var m = Matrix32()
+ m = m.rotated(PI/2) # rotate 90°
+ m[2]+=Vector2(2,0)
+
+.. image:: /img/tutomat13.png
+
+| This will always work in global coordinates.
+| If instead, translation is desired in *local* coordinates of the
+ matrix (towards where the *basis* is oriented), there is the
+ `Matrix32.translated `__
+ method:
+
+::
+
+ # Move 2 units towards where the basis is oriented
+ var m = Matrix32()
+ m = m.rotated(PI/2) # rotate 90°
+ m=m.translated( Vector2(2,0) )
+
+.. image:: /img/tutomat14.png
+
+Scale
+-----
+
+A matrix can be scaled too. Scaling will multiply the basis vectors by a
+vetor (X vector by x component of the scale, Y vector by y component of
+the scale). It will leave the origin alone:
+
+::
+
+ # Make the basis twice it's size.
+ var m = Matrix32()
+ m = m.scaled( Vector2(2,2) )
+
+.. image:: /img/tutomat15.png
+
+These kind of operations in matrices are accumulative. It means every
+one starts relative to the previous one. For those that have been living
+on this planet long enough, a good reference of how transform works is
+this:
+
+.. image:: /img/tutomat16.png
+
+A matrix is used similarly to a turtle. The turtle most likely had a
+matrix inside (and you are likely learning this may years *after*
+discovering Santa is not real).
+
+Transform
+---------
+
+Transform is the act of switching between coordinate systems. To convert
+a position (either 2D or 3D) from "designer" coordinate system to the
+OCS, the "xform" method is used.
+
+::
+
+ var new_pos = m.xform(pos)
+
+And only for basis (no translation):
+
+::
+
+ var new_pos = m.basis_xform(pos)
+
+Post - multiplying is also valid:
+
+::
+
+ var new_pos = m * pos
+
+Inverse Transform
+-----------------
+
+To do the opposite operation (what we did up there with the rocket), the
+"xform\_inv" method is used:
+
+::
+
+ var new_pos = m.xform_inv(pos)
+
+Only for Basis:
+
+::
+
+ var new_pos = m.basis_xform_inv(pos)
+
+Or pre-multiplication:
+
+::
+
+ var new_pos = pos * m
+
+Orthonormal Matrices
+--------------------
+
+| However, if the Matrix has been scaled (vectors are not unit length),
+ or the basis vectors are not orthogonal (90°), the inverse transform
+ will not work.
+| In other words, inverse transform is only valid in *orthonormal*
+ matrices. For this, these cases an affine inverse must be computed.
+
+The transform, or inverse transform of an identity matrix will return
+the position unchanged:
+
+::
+
+ # Does nothing, pos is unchanged
+ pos = Matrix32().xform(pos)
+
+Affine Inverse
+--------------
+
+The affine inverse is a matrix that does the inverse operation of
+another matrix, no matter if the matrix has scale or the axis vectors
+are not orthogonal. The affine inverse is calculated with the
+affine\_inverse() method:
+
+::
+
+ var mi = m.affine_inverse()
+ var pos = m.xform(pos)
+ pos = mi.xform(pos)
+ #pos is unchanged
+
+If the matrix is orthonormal, then:
+
+::
+
+ #if m is orthonormal, then
+ pos = mi.xform(pos)
+ #is the same is
+ pos = m.xform_inv(pos)
+
+Matrix Multiplication
+---------------------
+
+| Matrices can be multiplied. Multiplication of two matrices "chains"
+ (concatenates) their transforms.
+| However, as per convention, multiplication takes place in reverse
+ order.
+
+Example:
+
+::
+
+ var m = more_transforms * some_transforms
+
+To make it a little clearer, this:
+
+::
+
+ pos = transform1.xform(pos)
+ pos = transform2.xform(pos)
+
+Is the same as:
+
+::
+
+ h1. note the inverse order
+ pos = (transform2 * transform1).xform(pos)
+
+However, this is not the same:
+
+::
+
+ # yields a different results
+ pos = (transform1 * transform2).xform(pos)
+
+Because in matrix math, A + B is not the same as B + A.
+
+Multiplication by Inverse
+-------------------------
+
+Multiplying a matrix by it's inverse, results in identity
+
+::
+
+ # No matter what A is, B will be identity
+ B = A.affine_inverse() * A
+
+Multiplication by Identity
+--------------------------
+
+Multiplying a matrix by identity, will result in the unchanged matrix:
+
+::
+
+ h1. B will be equal to A
+ B = A * Matrix32()
+
+Matrix tips
+-----------
+
+When using a transform hierarchy, remember that matrix multiplication is
+reversed! To obtain the global transform for a hierarchy, do:
+
+::
+
+ var global_xform = parent_matrix * child_matrix
+
+For 3 levels:
+
+::
+
+ # due to reverse order, parenthesis are needed
+ var global_xform = gradparent_matrix + (parent_matrix + child_matrix)
+
+To make a matrix relative to the parent, use the affine inverse (or
+regular inverse for orthonormal matrices).
+
+::
+
+ # transform B from a global matrix to one local to A
+ var B_local_to_A = A.affine_inverse() * B
+
+Revert it just like the example above:
+
+::
+
+ # transform back local B to global B
+ var B = A * B_local_to_A
+
+OK, hopefully this should be enough! Let's complete the tutorial by
+moving to 3D matrices
+
+Matrices & Transforms in 3D
+---------------------------
+
+As mentioned before, for 3D, we deal with 3
+`Vector3 `__
+vectors for the rotation matrix, and an extra one for the origin.
+
+Matrix3
+-------
+
+Godot has a special type for a 3x3 matrix, named
+`Matrix3 `__. It
+can be used to represent a 3D rotation and scale. Sub vectors can be
+accessed as:
+
+::
+
+ var m = Matrix3()
+ var x = m[0] h1. Vector3
+ var y = m[1] h1. Vector3
+ var z = m[2] h1. Vector3
+
+or, alternatively as:
+
+::
+
+ var m = Matrix3()
+ var x = m.x h1. Vector3
+ var y = m.y h1. Vector3
+ var z = m.z h1. Vector3
+
+Matrix3 is also initialized to Identity by default:
+
+.. image:: /img/tutomat17.png
+
+Rotation in 3D
+--------------
+
+Rotation in 3D is more complex than in 2D (translation and scale are the
+same), because rotation is an implicit 2D operation. To rotate in 3D, an
+*axis*, must be picked. Rotation, then, happens around this axis.
+
+The axis for the rotation must be a *normal vector*. As in, a vector
+that can point to any direction, but length must be one (1.0).
+
+::
+
+ #rotate in Y axis
+ var m3 = Matrix3()
+ m3 = m3.rotated( Vector3(0,1,0), PI/2 )
+
+Transform
+---------
+
+To add the final component to the mix, Godot provides the
+`Transform `__
+type. Transform has two members:
+
+- *basis* (of type
+ `Matrix3 `__
+- *origin* (of type
+ `Vector3 `__
+
+Any 3D transform can be represented with Transform, and the separation
+of basis and origin makes it easier to work translation and rotation
+separately.
+
+An example:
+
+::
+
+ var t = Transform()
+ pos = t.xform(pos) #transform 3D position
+ pos = t.basis.xform(pos) h1. (only rotate)
+ pos = t.origin + pos (only translate)
+
+
diff --git a/tutorials/mesh_generation_with_heightmap_and_shaders.rst b/tutorials/mesh_generation_with_heightmap_and_shaders.rst
new file mode 100644
index 000000000..aff031622
--- /dev/null
+++ b/tutorials/mesh_generation_with_heightmap_and_shaders.rst
@@ -0,0 +1,206 @@
+Generate a mesh using a heightmap and vertex fragment shaders
+=============================================================
+
+Introduction
+------------
+
+| This tutorial will help you to use Godot shaders to deform a plane
+ mesh so it appears like a basic terrain. Remember that this solution
+ has pros and cons.
+| Pros:
+
+- Pretty easy to do.
+- This approach allows computation of LOD terrains.
+- The heightmap can be used in Godot to create a normal map.
+
+Cons:
+
+- The Vertex Shader can't re-compute normals of the faces. Thus, if
+ your mesh is not static, this method will **not** work with shaded
+ materials.
+- This tutorial uses a plane mesh imported from Blender to Godot
+ Engine. Godot is able to create meshes as well.
+
+See this tutorial as an introduction, not a method that you should
+employ in your games, except if you intend to do LOD. Otherwise, this is
+probably not the best way.
+
+However, let's first create a heightmap. To do so, let's first create a
+heightmap. To do this, I'll use GIMP editor, but you can use any image
+editor you like.
+
+The heightmap
+-------------
+
+| We will use a few functions of GIMP image editor to produce a simple
+ heightmap. Start GIMP and create a square image of 512x512 pixels.
+| |image0|
+| You are now in front of a new, blank, square image.
+| |image1|
+| Then, use a filter to render some clouds on this new image.
+| |image2|
+| Parameter this filter to whatever you want. A white pixel corresponds
+ to the highest point of the heightmap, a black pixel corresponds to
+ the lowest one. So, darker regions are valleys and brighter are
+ mountains. If you want, you can check "tileable" to render a heightmap
+ that can be cloned and tiled close together with another one. X and Y
+ size don't matter a lot as long as they are big enough to provide a
+ decent ground. A value of 4.0 or 5.0 for both is nice. Click on the
+ "New Seed" button to roll a dice and GIMP will create a new random
+ heightmap. Once you are happy with the result, click "OK".
+| |image3|
+| You can continue to edit your image if you wish. For our example,
+ let's keep the heightmap as is, and let's export it to a PNG file, say
+ "heightmap.png". Save it in your Godot project folder.
+
+The plane mesh
+--------------
+
+| Now, we will need a plane mesh to import in Godot. Let's run Blender.
+| |image4|
+| Remove the start cube mesh, then add a new plane to the scene.
+| |image5|
+| Zoom a bit, then switch to Edit mode (Tab key) and in the Tools
+ buttongroup at the left, hit "Subdivide" 5 or 6 times.
+| |image6|
+| Your mesh is now subdivided, which means we added vertices to the
+ plane mesh that we will later be able to move. Job's not finished yet:
+ in order to texture this mesh a proper UV map is necessary. Currently,
+ the default UV map contains only the 4 corner vertices we had at the
+ beginning. However, we now have more, and we want to be able to
+ texture over the whole mesh correctly.
+
+| If all the vertices of your mesh are not selected, select them all
+ (hit "A"). They must appear orange, not black. Then, in the
+ Shading/UVs button group a the left, click the "Unwrap" button (or
+ simply hit "U") and select "Smart UV Project". Keep the default
+ options and hit "Ok".
+| |image7|
+| Now, we need to switch our view to "UV/Image editor".
+| |image8|
+| Select all the vertices again ("A") then in the UV button, select
+ "Export UV Layout".
+| |image9|
+| Export the layout as a PNG file. Name it "plane.png" and save it in
+ your Godot project folder. Now, let's export our mesh as an OBJ file.
+ Top of the screen, click "File/Export/Wavefront (obj)". Save your
+ object as "plane.obj" in your Godot project folder.
+
+Shader magic
+------------
+
+| Let's now open Godot Editor.
+| Create a new project in the folder you previously created and name it
+ what you want.
+| |image10|
+| In our default scene (3D), create a root node "Spatial". Next, import
+ the mesh OBJ file. Click "Import", choose "3D Mesh" and select your
+ plane.obj file, set the target path as "/" (or wherever you want in
+ your project folder).
+| |image11|
+| I like to check "Normals" in the import popup so the import will also
+ consider faces normals, which can be useful (even if we don't use them
+ in this tutorial). Your mesh is now displayed in the FileSystem in
+ "res://".
+| |image12|
+| Create a MeshInstance node. In the Inspector, load the mesh we just
+ imported. Select "plane.msh" and hit ok.
+| |image13|
+| Great! Our plane is now rendered in the 3D view.
+| |image14|
+| It is time to add some shader stuff. In the Inspector, in the
+ "Material Override" line, add a "New ShaderMaterial". Edit it by
+ clicking the ">" button just right to it.
+| |image15|
+| You have two ways to create a shader: by code (MaterialShader), or
+ using a shader graph (MaterialShaderGraph). The second one is a bit
+ more visual, but we will not cover it for now. Create a "New
+ MaterialShader".
+| |image16|
+| Edit it by clicking the ">" button just right to it. The Shaders
+ editor opens.
+| |image17|
+| The Vertex tab is for the Vertex shader, and the Fragment tab is for
+ the Fragment shader. No need to explain what both of them do, right?
+ If so, head to the [[Shader]] page. Else, let's start with the
+ Fragment shader. This one is used to texture the plane using an image.
+ For this example, we will texture it with the heightmap image itself,
+ so we'll actually see mountains as brighter regions and canyons as
+ darker regions. Use this code:
+
+::
+
+ uniform texture source;
+ uniform color col;
+ DIFFUSE = col.rgb * tex(source,UV).rgb;
+
+This shader is very simple (it actually comes from the [[Shader]] page).
+What it basically does is take 2 parameters that we have to provide from
+outside the shader ("uniform"):
+
+- the texture file
+- a color
+ Then, we multiply every pixel of the image given by
+ ``tex(source, UV).rgb`` by the color defined ``col`` and we set it to
+ DIFFUSE variable, which is the rendered color. Remember that the
+ ``UV`` variable is a shader variable that returns the 2D position of
+ the pixel in the texture image, according to the vertex we are
+ currently dealing with. That is the use of the UV Layout we made
+ before. The color ``col`` is actually not necessary to display the
+ texture, but it is interesting to play and see how it does, right?
+
+| However, the plane is displayed black! This is because we didn't set
+ the texture file and the color to use.
+| |image18|
+| In the Inspector, click the "Previous" button to get back to the
+ ShaderMaterial. This is where you want to set the texture and the
+ color. In "Source", click "Load" and select the texture file
+ "heightmap.png". But the mesh is still black! This is because our
+ Fragment shader multiplies each pixel value of the texture by the
+ ``col`` parameter. However, this color is currently set to black
+ (0,0,0), and as you know, 0\*x = 0 ;) . Just change the ``col``
+ parameter to another color to see your texture appear:
+| |image19|
+| Good. Now, the Vertex Shader.
+
+The Vertex Shader is the first shader to be executed by the pipeline. It
+deals with vertices.
+
+Click the "Vertex" tab to switch, and paste this code:
+
+::
+
+ uniform texture source;
+ uniform float height_range;
+ vec2 xz = SRC_VERTEX.xz;
+ float h = tex(source, UV).g * height_range;
+ VERTEX = vec3(xz.x, h, xz.y);
+ VERTEX = MODELVIEW_MATRIX * VERTEX;
+
+| This shader uses two "uniform" parameters. The ``source`` parameter is
+ already set for the fragment shader. Thus, the same image will be used
+ in this shader as the heightmap. The ``height_range`` parameter is a
+ parameter that we will use to increase the height effect.
+| At line 3, we save the x and z position of the SRC\_VERTEX, because we
+ do not want them to change : the plane must remain square. Remember
+ that Y axis corresponds to the "altitude", which is the only one we
+ want to change with the heightmap.
+| At line 4, we compute an ``h`` variable by multiplying the pixel value
+ at the UV position and the ``height_range``. As the heightmap is a
+ greyscale image, all r, g and b channels contain the same value. I
+ used ``g``, but any of r, g and b have the same effect.
+| At line 5, we set the current vertex' position at (xz.x, h, xz.y)
+ position. Concerning xz.y remember that its type is "vec2". Thus, its
+ components are x and y. The y component simply contains the z position
+ we set at line 3.
+| Finally, at line 6, we multiply the vertex by the model/view matrix in
+ order to set its position according to camera position. If you try to
+ comment this line, you'll see that the mesh behaves weird as you move
+ and rotate the camera.
+
+| That's all good, but our plane remains flat. This is because the
+ ``height_range`` value is 0. Increase this value to observe the mesh
+ distort and take to form of the terrain we set before:
+| |image20|
+
+
diff --git a/tutorials/mouse_and_input_coordinates.rst b/tutorials/mouse_and_input_coordinates.rst
new file mode 100644
index 000000000..2bfc3692f
--- /dev/null
+++ b/tutorials/mouse_and_input_coordinates.rst
@@ -0,0 +1,66 @@
+Mouse & Input Coordinates
+=========================
+
+About
+-----
+
+The reason for this small tutorial is to clear up many common mistakes
+about input coordinates, obtaining mouse position and screen resolution,
+etc.
+
+Hardware Display Coordinates
+----------------------------
+
+Using hardware coordinates makes sense in the case of writing complex
+UIs meant to run on PC, such as editors, MMOs, tools, etc. Yet, make not
+as much sense outside of that scope.
+
+[STRIKEOUT:The only way to reliably obtain this information is by using
+functions such as:]
+
+**This method is no longer supported:** It was too confusing and caused
+errors for users making 2D games. Screen would stretch to different
+resolutions and input would stop making sense. Please use the
+\`\`\_input\`\` function
+
+::
+
+ OS.get_video_mode_size()
+ Input.get_mouse_pos()
+
+However, this is discouraged for pretty much any situation. Please do
+not use these functions unless you really know what you are doing.
+
+Viewport Display Coordinates
+----------------------------
+
+Godot uses viewports to display content, and viewports can be scaled by
+several options (see [[tutorial\_multires]] tutorial). Use, then, the
+functions in nodes to obtain the mouse coordinates and viewport size,
+for example:
+
+::
+
+ func _input(ev):
+ # Mouse in viewport coordinates
+
+ if (ev.type==InputEvent.MOUSE_BUTTON):
+ print("Mouse Click/Unclick at: ",ev.pos)
+ elif (ev.type==InputEvent.MOUSE_MOTION):
+ print("Mouse Motion at: ",ev.pos)
+
+ # Print the size of the viewport
+
+ print("Viewport Resolution is: ",get_viewport_rect().size)
+
+ func _ready():
+ set_process_input(true)
+
+Alternatively it's possible to ask the viewport for the mouse position
+
+::
+
+ get_viewport().get_mouse_pos()
+
+*Juan Linietsky, Ariel Manzur, Distributed under the terms of the `CC
+By `__ license.*
diff --git a/tutorials/particle_systems_2d.rst b/tutorials/particle_systems_2d.rst
new file mode 100644
index 000000000..b5239b520
--- /dev/null
+++ b/tutorials/particle_systems_2d.rst
@@ -0,0 +1,262 @@
+Particle Systems (2D)
+=====================
+
+Intro
+-----
+
+A simple (but flexible enough for most uses) particle system is
+provided. Particle systems are used to simulate complex physical effects
+tsuch as sparks, fire, magic particles, smoke, mist, magic, etc.
+
+The idea is that a "particle" is emitted at a fixed interval and with a
+fixed lifetime. During his lifetime, every particle will have the same
+base behavior. What makes every particle different and provides a more
+organic look is the "randomness" associated to each parameter. In
+essence, creating a particle system means setting base physics
+parameters and then adding randomness to them.
+
+Particles2D
+~~~~~~~~~~~
+
+Particle systems are added to the scene via the
+`Particles2D