stan220/godot-docs
1
0
Fork 0
mirror of https://github.com/stan220/godot-docs.git synced 2026-09-08 18:29:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Finish importing full OP contents

Browse Source
This commit is contained in:
Rémi Verschelde
2016-02-08 18:24:54 +01:00
parent 86563cc374
commit b1ae87dade
429 changed files with 15072 additions and 625 deletions
Download Patch File Download Diff File Expand all files Collapse all files
advanced_topics/binary_serialization_api.rst
+18 -18
View File
@@ -307,21 +307,21 @@ This field is padded to 4 bytes.
15: image
~~~~~~~~~
+---------------------+-------+-----------+------------------------------------------------------+
| Offset | Len | Type | Description |
+=====================+=======+===========+======================================================+
| 4 | 4 | Integer | Format (see FORMAT\_\* in \\"Image\\":class\_image |
+---------------------+-------+-----------+------------------------------------------------------+
| 8 | 4 | Integer | Mip-Maps (0 means no mip-maps). |
+---------------------+-------+-----------+------------------------------------------------------+
| 12 | 4 | Integer | Width (Pixels) |
+---------------------+-------+-----------+------------------------------------------------------+
| 16 | 4 | Integer | Height (Pixels) |
+---------------------+-------+-----------+------------------------------------------------------+
| 20 | 4 | Integer | Data Length |
+---------------------+-------+-----------+------------------------------------------------------+
| 24..24+DataLength | 1 | Byte | Image Data |
+---------------------+-------+-----------+------------------------------------------------------+
+---------------------+-------+-----------+--------------------------------------------------+
| Offset | Len | Type | Description |
+=====================+=======+===========+==================================================+
| 4 | 4 | Integer | Format (see FORMAT\_\* in "Image":class\_image |
+---------------------+-------+-----------+--------------------------------------------------+
| 8 | 4 | Integer | Mip-Maps (0 means no mip-maps). |
+---------------------+-------+-----------+--------------------------------------------------+
| 12 | 4 | Integer | Width (Pixels) |
+---------------------+-------+-----------+--------------------------------------------------+
| 16 | 4 | Integer | Height (Pixels) |
+---------------------+-------+-----------+--------------------------------------------------+
| 20 | 4 | Integer | Data Length |
+---------------------+-------+-----------+--------------------------------------------------+
| 24..24+DataLength | 1 | Byte | Image Data |
+---------------------+-------+-----------+--------------------------------------------------+
This field is padded to 4 bytes.
@@ -386,7 +386,7 @@ Every name string is is padded to 4 bytes.
| 4 | 4 | Integer | val&0x7FFFFFFF = elements, val&0x80000000 = shared (bool) |
+----------+-------+-----------+---------------------------------------------------------------------+
| Then what follows is, for amount of \\"elements\\", pairs of key and
| Then what follows is, for amount of "elements", pairs of key and
value, one after the other, using
| this same format.
@@ -399,8 +399,8 @@ Every name string is is padded to 4 bytes.
| 4 | 4 | Integer | val&0x7FFFFFFF = elements, val&0x80000000 = shared (bool) |
+----------+-------+-----------+---------------------------------------------------------------------+
| Then what follows is, for amount of \\"elements\\", values one after
the other, using
| Then what follows is, for amount of "elements", values one after the
other, using
| this same format.
22: byte array
advanced_topics/command_line_tutorial.rst
+7 -10
View File
@@ -100,7 +100,7 @@ that is headless (server build, no video) is ideal for this.
::
user@host:~/newgame$ godot -export \"Linux X11\" /var/builds/project
user@host:~/newgame$ godot -export "Linux X11" /var/builds/project
user@host:~/newgame$ godot -export Android /var/builds/project.apk
The platform names recognized by the ``-export`` switch are the same as
@@ -122,17 +122,14 @@ Running a script
Here is a simple example of how it works:
| <pre class=\\"python\\">
| #sayhello.gd
| extends SceneTree
.. code:: python
| func \_init():
| print(\\"Hello!\\")
| quit()
#sayhello.gd
extends SceneTree
.. raw:: html
</pre>
func _init():
print("Hello!")
quit()
And how to run it:
advanced_topics/compiling_for_android.rst
+6 -6
View File
@@ -30,8 +30,8 @@ Setting Up SCons
Android NDK.
To set those environment variables on Windows, press Windows+R, type
\\"control system\\", then click on **Advanced system settings** in the
left pane, then click on **Environment variables** on the window that
"control system", then click on **Advanced system settings** in the left
pane, then click on **Environment variables** on the window that
appears.
To set those environment variables on Linux, use
@@ -78,8 +78,8 @@ platform, for each build type (release, debug, etc), it must be
replaced.
**Note**: The file inside libs/armeabi must be renamed to
**\\"libgodot\_android.so\\"**, or else unsatisfied link error will
happen at runtime.
**"libgodot\_android.so"**, or else unsatisfied link error will happen
at runtime.
If you also want to include support for x86 Android, add the following
compile flag: ``x86=yes`` , then copy/symlink the resulting folder to
@@ -102,8 +102,8 @@ the current numbers, then set the following environment variables:
::
NDK_TOOLCHAIN (by default set to \"arm-eabi-4.4.0\")
NDK_TARGET (by default set to \"arm-linux-androideabi-4.8\")
NDK_TOOLCHAIN (by default set to "arm-eabi-4.4.0")
NDK_TARGET (by default set to "arm-linux-androideabi-4.8")
Building the APK
----------------
advanced_topics/compiling_for_ios.rst
+1 -1
View File
@@ -40,5 +40,5 @@ Run
| To run on a device or simulator, follow these instructions:
[[Exporting for iOS]].
| Replace or add your executable to the Xcode project, and change the
\\"executable name\\" property on Info.plist accordingly if you use an
"executable name" property on Info.plist accordingly if you use an
alternative build.
advanced_topics/compiling_for_linux.rst
+3 -3
View File
@@ -41,9 +41,9 @@ Start a terminal, go to the root dir of the engine source code and type:
user@host:~/godot$ scons platform=x11
If all goes well, the resulting binary executable will be placed in the
\\"bin\\" subdirectory. This executable file contains the whole engine
and runs without any dependencies. Executing it will bring up the
project manager.
"bin" subdirectory. This executable file contains the whole engine and
runs without any dependencies. Executing it will bring up the project
manager.
Building export templates
-------------------------
advanced_topics/compiling_for_osx.rst
+5 -6
View File
@@ -21,9 +21,9 @@ Start a terminal, go to the root dir of the engine source code and type:
user@host:~/godot$ scons platform=osx
If all goes well, the resulting binary executable will be placed in the
\\"bin\\" subdirectory. This executable file contains the whole engine
and runs without any dependencies. Executing it will bring up the
project manager. There is a .app template to put the binary into in
"bin" subdirectory. This executable file contains the whole engine and
runs without any dependencies. Executing it will bring up the project
manager. There is a .app template to put the binary into in
tools/Godot.app.
Cross-compiling
@@ -31,9 +31,8 @@ Cross-compiling
It is possible to compile for OS X in a Linux environment (and maybe
also in Windows with Cygwin). For that you will need
\\\ `OSXCross\\ <https://github.com/tpoechtrager/osxcross>`__ for being
able to use OS X as target. First, follow the instructions to install
it:
`OSXCross <https://github.com/tpoechtrager/osxcross>`__ for being able
to use OS X as target. First, follow the instructions to install it:
# Clone the OSXCross repository
(https://github.com/tpoechtrager/osxcross) somewhere in your machine (or
advanced_topics/compiling_for_universal_windows_apps.rst
+51 -55
View File
@@ -1,32 +1,31 @@
Compiling for Universal Windows Apps
====================================
This page documents the current state of the \\"winrt\\" platform, used
to support \\"Windows Store Apps\\" for Windows 8.1, and Windows Phone
8.1 apps using Microsoft's new \\"Universal\\" APIs.
This page documents the current state of the "winrt" platform, used to
support "Windows Store Apps" for Windows 8.1, and Windows Phone 8.1 apps
using Microsoft's new "Universal" APIs.
Requirements
------------
- Windows 8
- SCons (see [[Compiling for Windows]] for more details)
- Visual Studio 2013 for Windows (but *not* \\"for Windows Desktop\\").
Tested on \\"Microsoft Visual Studio Express 2013 for Windows Version
12.0.31101.00 Update 4\\".
- Visual Studio 2013 for Windows (but *not* "for Windows Desktop").
Tested on "Microsoft Visual Studio Express 2013 for Windows Version
12.0.31101.00 Update 4".
Compiling
---------
The platform can compile binaries for both Windows 8.1 and Windows Phone
8.1. The architecture is decided by the environment variable
\\"PLATFORM\\".
8.1. The architecture is decided by the environment variable "PLATFORM".
Windows 8.1
~~~~~~~~~~~
\* Open a \\"VS 2013 x64 Cross Tools Command Prompt\\"
\* Open a "VS 2013 x64 Cross Tools Command Prompt"
\* The value of environment variable \\"PLATFORM\\" should be \\"x64\\"
\* The value of environment variable "PLATFORM" should be "x64"
\* Run scons with platform=winrt from the root of the source tree
@@ -35,15 +34,15 @@ Windows 8.1
C:\\godot_source> scons platform=winrt
- You should get an executable file inside bin/ named according to your
build options, for the architecture \\"x64\\", for example
\\"godot.winrt.tools.x64.exe\\".
build options, for the architecture "x64", for example
"godot.winrt.tools.x64.exe".
Windows Phone 8.1
~~~~~~~~~~~~~~~~~
\* Open a \\"Visual Studio 2012 ARM Phone Tools Command Prompt\\"
\* Open a "Visual Studio 2012 ARM Phone Tools Command Prompt"
\* The value of environment variable \\"PLATFORM\\" should be \\"arm\\"
\* The value of environment variable "PLATFORM" should be "arm"
\* Run scons with platform=winrt from the root of the source tree
@@ -52,26 +51,26 @@ Windows Phone 8.1
C:\\godot_source> scons platform=winrt
- You should get an executable file inside bin/ named according to your
build options, for the architecture \\"arm\\", for example
\\"godot.winrt.tools.arm.exe\\".
build options, for the architecture "arm", for example
"godot.winrt.tools.arm.exe".
Running
-------
On Visual studio, create a new project using any of the \\"Unversal
App\\" templates found under Visual C++ -> Store Apps -> Universal Apps.
\\"Blank App\\" should be fine.
On Visual studio, create a new project using any of the "Unversal App"
templates found under Visual C++ -> Store Apps -> Universal Apps. "Blank
App" should be fine.
On the \\"Solution Explorer\\" box, you should have 3 sections,
\\"App.Windows (Windows 8.1)\\", \\"App.WindowsPhone (Windows Phone
8.1)\\" and \\"App.Shared\\". You need to add files to each section:
On the "Solution Explorer" box, you should have 3 sections, "App.Windows
(Windows 8.1)", "App.WindowsPhone (Windows Phone 8.1)" and "App.Shared".
You need to add files to each section:
App.Shared
~~~~~~~~~~
- Add a folder named \\"game\\" containing your game content (can be
individual files or your data.pck). Remember to set the \\"Content\\"
property of each file to \\"True\\", otherwise your files won't get
- Add a folder named "game" containing your game content (can be
individual files or your data.pck). Remember to set the "Content"
property of each file to "True", otherwise your files won't get
included in the package.
App.Windows
@@ -79,13 +78,13 @@ App.Windows
\* Add your windows executable, and all the .dll files found on
platform/winrt/x64/bin on the godot source. Remember to also set the
\\"Content\\" property.
"Content" property.
\* Find the file \\"Package.appxmanifest\\". Right click on it and
select \\"Open with...\\" then \\"XML (Text) Editor\\" from the list.
\* Find the file "Package.appxmanifest". Right click on it and select
"Open with..." then "XML (Text) Editor" from the list.
\* Find the \\"Application\\" section, and add (or modify) the
\\"Executable\\" property with the name of your .exe. Example:
\* Find the "Application" section, and add (or modify) the "Executable"
property with the name of your .exe. Example:
::
@@ -94,23 +93,21 @@ App.WindowsPhone
- Repeat all the steps from App.Windows, using your arm executable and
the dlls found in platform/winrt/arm/bin. Remember to set the
\\"Content\\" property for all the files.
"Content" property for all the files.
Use the green \\"Play\\" button on the top to run. The drop down menu
next to it should let you choose the project (App.Windows or
App.WindowsPhone) and the device (\\"Local Machine\\", \\"Device\\" for
an attached phone, etc).
Use the green "Play" button on the top to run. The drop down menu next
to it should let you choose the project (App.Windows or
App.WindowsPhone) and the device ("Local Machine", "Device" for an
attached phone, etc).
Angle
-----
ANGLE precompiled binaries are provided on platform/winrt/x64 and
platform/winrt/arm. They are built from MSOpenTech's \\"future-dev\\"
branch, found here:
\\\ `https://github.com/MSOpenTech/angle\\ <https://github.com/MSOpenTech/angle>`__.
The visual studio 'solutions' used are found on
\\"projects/winrt/windows/angle.sln\\" and
\\"projects/winrt/windowsphone/angle.sln\\".
platform/winrt/arm. They are built from MSOpenTech's "future-dev"
branch, found here: https://github.com/MSOpenTech/angle. The visual
studio 'solutions' used are found on "projects/winrt/windows/angle.sln"
and "projects/winrt/windowsphone/angle.sln".
What's missing
--------------
@@ -131,18 +128,17 @@ Packages
This is what we know:
- App packages are documented here:
\\\ `http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464929.aspx\\ <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464929.aspx>`__
- There are 2 command line tools that might be useful, \\\ `App
Packager\\ <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh446767.aspx>`__
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464929.aspx
- There are 2 command line tools that might be useful, `App
Packager <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh446767.aspx>`__
and
\\\ `SignTool\\ <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/ff551778.aspx>`__.
- There are a bunch of tools on \\"powershell\\" that deal with
packages that might be relevant:
\\\ `http://technet.microsoft.com/library/dn448373.aspx\\ <http://technet.microsoft.com/library/dn448373.aspx>`__
- When running a Windows 8.1 app on \\"Local Machine\\" from Visual
studio, the app seems to run from an uncompressed directory on the
filesystem in an arbitrary location (ie. outside of the proper
directory where Apps are installed), but there is some special
registry entry made for it, so we know it's possible to skip the
packaging step to run locally (in the case of very big games this can
be useful).
`SignTool <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/ff551778.aspx>`__.
- There are a bunch of tools on "powershell" that deal with packages
that might be relevant:
http://technet.microsoft.com/library/dn448373.aspx
- When running a Windows 8.1 app on "Local Machine" from Visual studio,
the app seems to run from an uncompressed directory on the filesystem
in an arbitrary location (ie. outside of the proper directory where
Apps are installed), but there is some special registry entry made
for it, so we know it's possible to skip the packaging step to run
locally (in the case of very big games this can be useful).
advanced_topics/compiling_for_windows.rst
+15 -17
View File
@@ -6,27 +6,25 @@ Requirements
For compiling under Windows, the following is required:
- \\\ `Visual C++\\ <http://www.microsoft.com/visualstudio>`__, Visual
C++ Express compiler or Visual Studio Community (recommended) at
least the 2010 version (10.0) up to 2015 (14.0). **Make sure you get
a version that can compile for C++, Desktop**.
- \\\ `Python 2.7+\\ <http://www.python.org/getit/releases/2.7/>`__
(3.0 is untested as of now). Using the 32-bits installer is
recommended.
- \\\ `Pywin32 Python
Extension\\ <http://sourceforge.net/projects/pywin32>`__ for parallel
- `Visual C++ <http://www.microsoft.com/visualstudio>`__, Visual C++
Express compiler or Visual Studio Community (recommended) at least
the 2010 version (10.0) up to 2015 (14.0). **Make sure you get a
version that can compile for C++, Desktop**.
- `Python 2.7+ <http://www.python.org/getit/releases/2.7/>`__ (3.0 is
untested as of now). Using the 32-bits installer is recommended.
- `Pywin32 Python
Extension <http://sourceforge.net/projects/pywin32>`__ for parallel
builds (which increase the build speed by a great factor).
- \\\ `SCons\\ <http://www.scons.org>`__ build system.
- `SCons <http://www.scons.org>`__ build system.
Setting up SCons
----------------
Python adds the interpreter (python.exe) to the path. It usually
installs in C:\\\\Python (or C:\\\\Python[Version]). SCons installs
inside the python install and provides a .bat file called
\\"scons.bat\\". The location of this file can be added to the path or
it can simply be copied to C:\\\\Python together with the interpreter
executable.
inside the python install and provides a .bat file called "scons.bat".
The location of this file can be added to the path or it can simply be
copied to C:\\\\Python together with the interpreter executable.
Compiling
---------
@@ -64,7 +62,7 @@ build it seems to be by running:
::
\"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\vcvarsall.bat\" && c:\\python27\\scons p=windows
"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\vcvarsall.bat" && c:\\python27\\scons p=windows
(or however your VS and Scons are installed)
@@ -91,8 +89,8 @@ following env variables:
::
export MINGW32_PREFIX=\"/path/to/i586-mingw32msvc-\"
export MINGW64_PREFIX=\"/path/to/i686-w64-mingw32-\"
export MINGW32_PREFIX="/path/to/i586-mingw32msvc-"
export MINGW64_PREFIX="/path/to/i686-w64-mingw32-"
To make sure you are doing things correctly, executing the following in
the shell should result in a working compiler:
advanced_topics/core_types.rst
+12 -12
View File
@@ -31,7 +31,7 @@ directly to wchar\_t.
References:
~~~~~~~~~~~
- \\\ `core/typedefs.h\\ <https://github.com/okamstudio/godot/blob/master/core/typedefs.h>`__
- `core/typedefs.h <https://github.com/okamstudio/godot/blob/master/core/typedefs.h>`__
Memory model
------------
@@ -128,8 +128,8 @@ locked until they go out of scope.
References:
~~~~~~~~~~~
- \\\ `core/os/memory.h\\ <https://github.com/okamstudio/godot/blob/master/core/os/memory.h>`__
- \\\ `core/dvector.h\\ <https://github.com/okamstudio/godot/blob/master/core/dvector.h>`__
- `core/os/memory.h <https://github.com/okamstudio/godot/blob/master/core/os/memory.h>`__
- `core/dvector.h <https://github.com/okamstudio/godot/blob/master/core/dvector.h>`__
Containers
----------
@@ -162,10 +162,10 @@ The Vector<> class also has a few nice features:
References:
~~~~~~~~~~~
- \\\ `core/vector.h\\ <https://github.com/okamstudio/godot/blob/master/core/vector.h>`__
- \\\ `core/list.h\\ <https://github.com/okamstudio/godot/blob/master/core/list.h>`__
- \\\ `core/set.h\\ <https://github.com/okamstudio/godot/blob/master/core/set.h>`__
- \\\ `core/map.h\\ <https://github.com/okamstudio/godot/blob/master/core/map.h>`__
- `core/vector.h <https://github.com/okamstudio/godot/blob/master/core/vector.h>`__
- `core/list.h <https://github.com/okamstudio/godot/blob/master/core/list.h>`__
- `core/set.h <https://github.com/okamstudio/godot/blob/master/core/set.h>`__
- `core/map.h <https://github.com/okamstudio/godot/blob/master/core/map.h>`__
String
------
@@ -178,7 +178,7 @@ conversion and visualization.
References:
~~~~~~~~~~~
- \\\ `core/ustring.h\\ <https://github.com/okamstudio/godot/blob/master/core/ustring.h>`__
- `core/ustring.h <https://github.com/okamstudio/godot/blob/master/core/ustring.h>`__
StringName
----------
@@ -193,7 +193,7 @@ StringName
References:
~~~~~~~~~~~
- \\\ `core/string\_db.h\\ <https://github.com/okamstudio/godot/blob/master/core/string_db.h>`__
- `core/string\_db.h <https://github.com/okamstudio/godot/blob/master/core/string_db.h>`__
Math types
----------
@@ -204,7 +204,7 @@ directory, they are basically just that.
References:
~~~~~~~~~~~
- \\\ `core/math\\ <https://github.com/okamstudio/godot/blob/master/core/math>`__
- `core/math <https://github.com/okamstudio/godot/blob/master/core/math>`__
NodePath
--------
@@ -215,7 +215,7 @@ referencing them fast.
References:
~~~~~~~~~~~
- \\\ `core/path\_db.h\\ <https://github.com/okamstudio/godot/blob/master/core/path_db.h>`__
- `core/path\_db.h <https://github.com/okamstudio/godot/blob/master/core/path_db.h>`__
RID
---
@@ -228,4 +228,4 @@ referenced data.
References:
~~~~~~~~~~~
- \\\ `core/rid.h\\ <https://github.com/okamstudio/godot/blob/master/core/rid.h>`__
- `core/rid.h <https://github.com/okamstudio/godot/blob/master/core/rid.h>`__
advanced_topics/creating_android_modules.rst
+87 -117
View File
@@ -64,29 +64,23 @@ In the config.py for the module, some extra functions are provided for
convenience. First, it's often wise to detect if android is being built
and only enable building in this case:
| <pre class=\\"python\\">
| def can\_build(plat):
| return plat==\\"android\\"
.. code:: python
.. raw:: html
</pre>
def can_build(plat):
return plat=="android"
If more than one platform can be built (typical if implementing the
module also for iOS), check manually for Android in the configure
functions:
| <pre class=\\"python\\">
| def can\_build(plat):
| return plat\\"android\\" or plat\\"iphone\\"
.. code:: python
| def configure(env):
| if env['platform'] == 'android':
| #androd specific code
def can_build(plat):
return plat=="android" or plat=="iphone"
.. raw:: html
</pre>
def configure(env):
if env['platform'] == 'android':
#androd specific code
Java singleton
--------------
@@ -95,56 +89,51 @@ An android module will usually have a singleton class that will load it,
this class inherits from ``Godot.SingletonBase``. A singleton object
template follows:
| <pre class=\\"java\\">
| //namespace is wrong, will eventually change
| package com.android.godot;
.. code:: java
public class MySingleton extends Godot.SingletonBase {
//namespace is wrong, will eventually change
package com.android.godot;
| public int myFunction(String p\_str) {
| // a function to bind
| }
public class MySingleton extends Godot.SingletonBase {
static public Godot.SingletonBase initialize(Activity p\_activity) {
| return new MySingleton(p\_activity);
| }
public int myFunction(String p_str) {
// a function to bind
}
| public MySingleton(Activity p\_activity) {
| //register class name and functions to bind
| registerClass(\\"MySingleton\\", new String[]{\\"myFunction\\"});
static public Godot.SingletonBase initialize(Activity p_activity) {
| // you might want to try initializing your singleton here, but android
| // threads are weird and this runs in another thread, so you usually
have to do
| activity.runOnUiThread(new Runnable() {
| public void run() {
| //useful way to get config info from engine.cfg
| String key = GodotLib.getGlobal(\\"plugin/api\_key\\");
| SDK.initializeHere();
| }
| });
return new MySingleton(p_activity);
}
}
public MySingleton(Activity p_activity) {
//register class name and functions to bind
registerClass("MySingleton", new String[]{"myFunction"});
// forwarded callbacks you can reimplement, as SDKs often need them
// you might want to try initializing your singleton here, but android
// threads are weird and this runs in another thread, so you usually have to do
activity.runOnUiThread(new Runnable() {
public void run() {
//useful way to get config info from engine.cfg
String key = GodotLib.getGlobal("plugin/api_key");
SDK.initializeHere();
}
});
protected void onMainActivityResult(int requestCode, int resultCode,
Intent data) {}
}
| protected void onMainPause() {}
| protected void onMainResume() {}
| protected void onMainDestroy() {}
// forwarded callbacks you can reimplement, as SDKs often need them
| protected void onGLDrawFrame(GL10 gl) {}
| protected void onGLSurfaceChanged(GL10 gl, int width, int height) {}
// singletons will always miss first onGLSurfaceChanged call
protected void onMainActivityResult(int requestCode, int resultCode, Intent data) {}
}
protected void onMainPause() {}
protected void onMainResume() {}
protected void onMainDestroy() {}
.. raw:: html
protected void onGLDrawFrame(GL10 gl) {}
protected void onGLSurfaceChanged(GL10 gl, int width, int height) {} // singletons will always miss first onGLSurfaceChanged call
</pre>
}
Calling back to Godot from Java is a little more difficult. The instance
ID of the script must be known first, this is obtained by calling
@@ -154,30 +143,23 @@ passed to Java.
From Java, use the calldeferred function to communicate back with Godot.
Java will most likely run in a separate thread, so calls are deferred:
<pre class=\\"java\\">GodotLib.calldeferred(, \\"\\", new
Object[]{param1,param2,etc});
.. code:: java
.. raw:: html
</pre>
GodotLib.calldeferred(, "", new Object[]{param1,param2,etc});
Add this singleton to the build of the project by adding the following
to config.py:
| <pre class=\\"python\\">
| def can\_build(plat):
| return plat\\"android\\" or plat\\"iphone\\"
.. code:: python
| def configure(env):
| if env['platform'] == 'android':
| # will copy this to the java folder
| env.android\_module\_file(\\"MySingleton.java\\")
| #env.android\_module\_file(\\"MySingleton2.java\\") call again for
more files
def can_build(plat):
return plat=="android" or plat=="iphone"
.. raw:: html
</pre>
def configure(env):
if env['platform'] == 'android':
# will copy this to the java folder
env.android_module_file("MySingleton.java")
#env.android_module_file("MySingleton2.java") call again for more files
AndroidManifest
---------------
@@ -189,19 +171,16 @@ maybe other functionalities are needed.
Create the custom chunk of android manifest and put it inside the
module, add it like this:
| <pre class=\\"python\\">
| def can\_build(plat):
| return plat\\"android\\" or plat\\"iphone\\"
.. code:: python
| def configure(env):
| if env['platform'] == 'android':
| # will copy this to the java folder
| env.android\_module\_file(\\"MySingleton.java\\")
| env.android\_module\_manifest(\\"AndroidManifestChunk.xml\\")
def can_build(plat):
return plat=="android" or plat=="iphone"
.. raw:: html
</pre>
def configure(env):
if env['platform'] == 'android':
# will copy this to the java folder
env.android_module_file("MySingleton.java")
env.android_module_manifest("AndroidManifestChunk.xml")
SDK library
-----------
@@ -210,20 +189,17 @@ So, finally it's time to add the SDK library. The library can come in
two flavors, a JAR file or an Android project for ant. JAR is the
easiest to integrate, just put it in the module directory and add it:
| <pre class=\\"python\\">
| def can\_build(plat):
| return plat\\"android\\" or plat\\"iphone\\"
.. code:: python
| def configure(env):
| if env['platform'] == 'android':
| # will copy this to the java folder
| env.android\_module\_file(\\"MySingleton.java\\")
| env.android\_module\_manifest(\\"AndroidManifestChunk.xml\\")
| env.android\_module\_library(\\"MyLibrary-3.1.jar\\")
def can_build(plat):
return plat=="android" or plat=="iphone"
.. raw:: html
</pre>
def configure(env):
if env['platform'] == 'android':
# will copy this to the java folder
env.android_module_file("MySingleton.java")
env.android_module_manifest("AndroidManifestChunk.xml")
env.android_module_library("MyLibrary-3.1.jar")
SDK project
-----------
@@ -238,24 +214,21 @@ the project folder inside the module directory and configure it:
As of this writing, godot uses minsdk 10 and target sdk 15. If this ever
changes, should be reflected in the manifest template:
\\\ `https://github.com/okamstudio/godot/blob/master/platform/android/AndroidManifest.xml.template\\ <https://github.com/okamstudio/godot/blob/master/platform/android/AndroidManifest.xml.template>`__
https://github.com/okamstudio/godot/blob/master/platform/android/AndroidManifest.xml.template
Then, add the module folder to the project:
| <pre class=\\"python\\">
| def can\_build(plat):
| return plat\\"android\\" or plat\\"iphone\\"
.. code:: python
| def configure(env):
| if env['platform'] == 'android':
| # will copy this to the java folder
| env.android\_module\_file(\\"MySingleton.java\\")
| env.android\_module\_manifest(\\"AndroidManifestChunk.xml\\")
| env.android\_module\_source(\\"sdk-1.2\\",\\"\\")
def can_build(plat):
return plat=="android" or plat=="iphone"
.. raw:: html
</pre>
def configure(env):
if env['platform'] == 'android':
# will copy this to the java folder
env.android_module_file("MySingleton.java")
env.android_module_manifest("AndroidManifestChunk.xml")
env.android_module_source("sdk-1.2","")
Building
--------
@@ -299,7 +272,7 @@ the following line to engine.cfg:
[android]
modules=\"com/android/godot/MySingleton\"
modules="com/android/godot/MySingleton"
More than one singleton module can be enable by separating with comma:
@@ -307,22 +280,19 @@ More than one singleton module can be enable by separating with comma:
[android]
modules=\"com/android/godot/MySingleton,com/android/godot/MyOtherSingleton\"
modules="com/android/godot/MySingleton,com/android/godot/MyOtherSingleton"
Then just request the singleton Java object from Globals like this:
| <pre class=\\"python\\">
| #in any file
.. code:: python
var singleton=null
#in any file
| func \_init():
| singleton = Globals.get\_singleton(\\"MySingleton\\")
| print( singleton.myFunction(\\"Hello\\") )
var singleton=null
.. raw:: html
</pre>
func _init():
singleton = Globals.get_singleton("MySingleton")
print( singleton.myFunction("Hello") )
Troubleshooting
---------------
@@ -350,5 +320,5 @@ Future
class = JavaClassWrapper.wrap()
This is most likely not functional yet, if you want to test it and help
us make it work, contact us through the \\\ `developer mailing
list\\ <https://groups.google.com/forum/#!forum/godot-engine>`__.
us make it work, contact us through the `developer mailing
list <https://groups.google.com/forum/#!forum/godot-engine>`__.
advanced_topics/cross-compiling_for_ios_on_linux.rst
+17 -17
View File
@@ -11,10 +11,10 @@ Disclaimer
While it is possible to compile for iOS on a Linux environment, Apple is
very restrictive about the tools to be used (specially hardware-wise),
allowing pretty much only their products to be used for development. So
this is **not official**. However, a \\\ `statement from Apple in
2010\\ <http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html>`__
says they relaxed some of the \\\ `App Store review
guidelines\\ <https://developer.apple.com/app-store/review/guidelines/>`__
this is **not official**. However, a `statement from Apple in
2010 <http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html>`__
says they relaxed some of the `App Store review
guidelines <https://developer.apple.com/app-store/review/guidelines/>`__
to allow any tool to be used, as long as the resulting binary do not
download any code, which means it should be OK to use the procedure
described here and cross-compiling the binary.
@@ -22,21 +22,21 @@ described here and cross-compiling the binary.
Requirements
------------
- \\\ `**XCode with the iOS
SDK**\\ <https://developer.apple.com/xcode/download>`__ (a dmg image)
- \\\ `**Clang >=3.5**\\ <http://clang.llvm.org>`__ for your
development machine installed and in the ``PATH``. It needs to be
version >= 3.5 to target ``arm64`` architecture.
- \\\ `**Fuse**\\ <http://fuse.sourceforge.net>`__ for mounting and
umounting the dmg image.
- \\\ `**darling-dmg**\\ <https://github.com/darlinghq/darling-dmg>`__,
which needs to be built from source. The procedure for that is
explained below.
- `**XCode with the iOS
SDK** <https://developer.apple.com/xcode/download>`__ (a dmg image)
- `**Clang >=3.5** <http://clang.llvm.org>`__ for your development
machine installed and in the ``PATH``. It needs to be version >= 3.5
to target ``arm64`` architecture.
- `**Fuse** <http://fuse.sourceforge.net>`__ for mounting and umounting
the dmg image.
- `**darling-dmg** <https://github.com/darlinghq/darling-dmg>`__, which
needs to be built from source. The procedure for that is explained
below.
- For building darling-dmg, you'll need the development packages of
the following libraries: **fuse, icu, openssl, zlib, bzip2**.
- \\\ `**cctools-port**\\ <https://github.com/tpoechtrager/cctools-port>`__
- `**cctools-port** <https://github.com/tpoechtrager/cctools-port>`__
for the needed build tools. The procedure for building is quite
peculiar and is described below.
@@ -138,8 +138,8 @@ way, with some additional arguments to provide the correct paths:
::
$ scons -j 4 platform=iphone bits=32 target=release_debug IPHONESDK=\"/path/to/iPhoneSDK\" IPHONEPATH=\"/path/to/iostoolchain\" ios_triple=\"arm-apple-darwin11-\"
$ scons -j 4 platform=iphone bits=64 target=release_debug IPHONESDK=\"/path/to/iPhoneSDK\" IPHONEPATH=\"/path/to/iostoolchain\" ios_triple=\"arm-apple-darwin11-\"
$ scons -j 4 platform=iphone bits=32 target=release_debug IPHONESDK="/path/to/iPhoneSDK" IPHONEPATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"
$ scons -j 4 platform=iphone bits=64 target=release_debug IPHONESDK="/path/to/iPhoneSDK" IPHONEPATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"
Producing fat binaries
~~~~~~~~~~~~~~~~~~~~~~
advanced_topics/custom_modules_in_c++.rst
+74 -99
View File
@@ -38,9 +38,9 @@ To create a new module, the first step is creating a directory inside
modules. If you want to maintain the module separately, you can checkout
a different VCS into modules and use it.
The example module will be called \\"sumator\\", and is placed inside
the Godot source tree (C:\\\\godot refers to wherever the Godot sources
are located):
The example module will be called "sumator", and is placed inside the
Godot source tree (C:\\\\godot refers to wherever the Godot sources are
located):
::
@@ -51,71 +51,65 @@ are located):
Inside we will create a simple sumator class:
| <pre class=\\"cpp\\">
| /\* sumator.h \*/
| #ifndef SUMATOR\_H
| #define SUMATOR\_H
.. code:: cpp
#include "reference.h&quot;
/* sumator.h */
#ifndef SUMATOR_H
#define SUMATOR_H
| class Sumator : public Reference {
| OBJ\_TYPE(Sumator,Reference);
#include "reference.h"
int count;
class Sumator : public Reference {
OBJ_TYPE(Sumator,Reference);
| protected:
| static void \_bind\_methods();
| public:
int count;
| void add(int value);
| void reset();
| int get\_total() const;
protected:
static void _bind_methods();
public:
| Sumator();
| };
void add(int value);
void reset();
int get_total() const;
#endif
Sumator();
};
.. raw:: html
</pre>
#endif
And then the cpp file.
| <pre class=\\"cpp\\">
| /\* sumator.cpp \*/
.. code:: cpp
#include "sumator.h&quot;
/* sumator.cpp */
void Sumator::add(int value) {
#include "sumator.h"
| count+=value;
| }
void Sumator::add(int value) {
void Sumator::reset() {
count+=value;
}
| count=0;
| }
void Sumator::reset() {
int Sumator::get\_total() const {
count=0;
}
| return count;
| }
int Sumator::get_total() const {
void Sumator::\_bind\_methods() {
return count;
}
| ObjectTypeDB::bind\_method("add&quot;,&Sumator::add);
| ObjectTypeDB::bind\_method("reset&quot;,&Sumator::reset);
| ObjectTypeDB::bind\_method("get\_total&quot;,&Sumator::get\_total);
| }
void Sumator::_bind_methods() {
| Sumator::Sumator() {
| count=0;
| }
ObjectTypeDB::bind_method("add",&Sumator::add);
ObjectTypeDB::bind_method("reset",&Sumator::reset);
ObjectTypeDB::bind_method("get_total",&Sumator::get_total);
}
.. raw:: html
</pre>
Sumator::Sumator() {
count=0;
}
Then, the new class needs to be registered somehow, so two more files
need to be created:
@@ -127,69 +121,53 @@ need to be created:
With the following contents
| <pre class=\\"cpp\\">
| /\* register\_types.h \*/
.. code:: cpp
| void register\_sumator\_types();
| void unregister\_sumator\_types();
| /\* yes, the word in the middle must be the same as the module folder
name \*/
/* register_types.h */
.. raw:: html
void register_sumator_types();
void unregister_sumator_types();
/* yes, the word in the middle must be the same as the module folder name */
</pre>
.. code:: cpp
| <pre class=\\"cpp\\">
| /\* register\_types.cpp \*/
/* register_types.cpp */
| #include "register\_types.h&quot;
| #include "object\_type\_db.h&quot;
| #include "sumator.h&quot;
#include "register_types.h"
#include "object_type_db.h"
#include "sumator.h"
void register\_sumator\_types() {
void register_sumator_types() {
| ObjectTypeDB::register\_type&lt;Sumator&gt;();
| }
ObjectTypeDB::register_type<Sumator>();
}
| void unregister\_sumator\_types() {
| //nothing to do here
| }
.. raw:: html
</pre>
void unregister_sumator_types() {
//nothing to do here
}
Next, we need to create a SCsub so the build system compiles this
module:
<pre class=\\"python\\">
.. code:: python
#. SCsub
Import('env')
# SCsub
Import('env')
env.add\_source\_files(env.modules\_sources,"\*.cpp&quot;) # just add
all cpp files to the build
.. raw:: html
</pre>
env.add_source_files(env.modules_sources,"*.cpp") # just add all cpp files to the build
And finally, the configuration file for the module, this is a simple
python script that must be named 'config.py'
<pre class=\\"python\\">
.. code:: python
#. config.py
# config.py
| def can\_build(platform):
| return True
def can_build(platform):
return True
| def configure(env):
| pass
.. raw:: html
</pre>
def configure(env):
pass
The module is asked if it's ok to build for the specific platform (in
this case, True means it will build for every platform).
@@ -221,17 +199,14 @@ Using the module
Using your newly created module is very easy, from any script you can
do:
| <pre class=\\"python\\">
| var s = Sumator.new()
| s.add(10)
| s.add(20)
| s.add(30)
| print( s.get\_total() )
| s.reset()
.. code:: python
.. raw:: html
</pre>
var s = Sumator.new()
s.add(10)
s.add(20)
s.add(30)
print( s.get_total() )
s.reset()
And the output will be ``60``.
@@ -250,7 +225,7 @@ some surprises.
- If you inherit from [[API:Node]] (or any derived node type, such as
Sprite), your new class will appear in the editor, in the inheritance
tree in the \\"Add Node\\" dialog.
tree in the "Add Node" dialog.
- If you inherit from [[API:Resource]], it will appear int the resource
list, and all the exposed properties can be serialized when
saved/loaded.
advanced_topics/introduction_to_the_buildsystem.rst
+11 -11
View File
@@ -4,12 +4,12 @@ Introduction to the buildsystem
Scons
-----
Godot uses \\\ `Scons\\ <http://www.scons.org>`__ to build. We love it,
we are not changing it for anything else. We are not even sure other
build systems are up to the task of building Godot. We constantly get
requests to move the build system to CMake, or Visual Studio, but this
is not going to happen. There are many reasons why we have chosen SCons
over other alternatives and are listed as follows:
Godot uses `Scons <http://www.scons.org>`__ to build. We love it, we are
not changing it for anything else. We are not even sure other build
systems are up to the task of building Godot. We constantly get requests
to move the build system to CMake, or Visual Studio, but this is not
going to happen. There are many reasons why we have chosen SCons over
other alternatives and are listed as follows:
- Godot can be compiled for a dozen different platforms. All PC
platforms, all mobile platforms, many consoles, and many web-based
@@ -149,9 +149,9 @@ Target controls optimization and debug flags. Each mode means:
scons platform= target=debug/release_debug/release
This flag appends \\".debug\\" suffix (for debug), or \\".tools\\" (for
debug with tools enables). When optimization is enabled (release) it
appends the \\".opt\\" suffix.
This flag appends ".debug" suffix (for debug), or ".tools" (for debug
with tools enables). When optimization is enabled (release) it appends
the ".opt" suffix.
Bits
----
@@ -171,8 +171,8 @@ else.
scons platform= bits=default/32/64
This flag appends \\".32\\" or \\".64\\" suffixes to resulting binaries
when relevant.
This flag appends ".32" or ".64" suffixes to resulting binaries when
relevant.
Export templates
----------------
advanced_topics/object_class.rst
+70 -134
View File
@@ -6,33 +6,26 @@ inherit directly or indirectly from it. Objects provide reflection and
editable properties, and declaring them is a matter of using a single
macro like this.
| <pre class=\\"cpp\\">
| class CustomObject : public Object {
.. code:: cpp
| OBJ\_TYPE(CustomObject,Object); // this required to inherit
| };
class CustomObject : public Object {
.. raw:: html
</pre>
OBJ_TYPE(CustomObject,Object); // this required to inherit
};
This makes objects gain a lot of functionality, like for example
| <pre class=\\"cpp\\">
| obj = memnew(CustomObject);
| print\_line("Object Type: ",obj->get\_type()); //print object type
.. code:: cpp
obj2 = obj->cast\_to&lt;OtherType&gt;(); // converting between types,
this also works without RTTI enabled.
obj = memnew(CustomObject);
print_line("Object Type: ",obj->get_type()); //print object type
.. raw:: html
</pre>
obj2 = obj->cast_to<OtherType>(); // converting between types, this also works without RTTI enabled.
References:
~~~~~~~~~~~
- \\\ `core/object.h\\ <https://github.com/okamstudio/godot/blob/master/core/object.h>`__
- `core/object.h <https://github.com/okamstudio/godot/blob/master/core/object.h>`__
Registering an Object
---------------------
@@ -43,22 +36,18 @@ their methods properties and integer constants.
Classes are registered by calling:
<pre class=\\"cpp\\">ObjectTypeDB::register\_type()
.. code:: cpp
.. raw:: html
</pre>
ObjectTypeDB::register_type()
Registering it will allow the type to be instanced by scripts, code, or
creating them again when deserializing.
Registering as virtual is the same but it can't be instanced.
<pre class=\\"cpp\\">ObjectTypeDB::register\_virtual\_type()
.. code:: cpp
.. raw:: html
</pre>
ObjectTypeDB::register_virtual_type()
Object derived classes can override a static function
``static void _bind_methods()``, when one class is registered, this
@@ -70,25 +59,18 @@ virtual automatically.
Inside ``_bind_methods``, there are a couple of things that can be done.
Registering functions is one:
<pre
class=\\"cpp\\">ObjectTypeDB::register\_method(\_MD (\\"methodname\\",\\"arg1name\\",\\"arg2name\\"),&MyCustethod);
.. code:: cpp
.. raw:: html
</pre>
ObjectTypeDB::register_method(_MD("methodname","arg1name","arg2name"),&MyCustethod);
Default values for arguments can be passed in reverse order:
<pre
class=\\"cpp\\">ObjectTypeDB::register\_method(\_MD (\\"methodname\\",\\"arg1name\\",\\"arg2name\\"),&MyCustomType::method,DEFVAL (-1));
//default argument for arg2name
.. code:: cpp
.. raw:: html
ObjectTypeDB::register_method(_MD("methodname","arg1name","arg2name"),&MyCustomType::method,DEFVAL(-1)); //default argument for arg2name
</pre>
``_MD`` is a macro that convers \\"methodname\\" to a stringname for
more efficiency. Argument names are used for instrospection, but when
``_MD`` is a macro that convers "methodname" to a stringname for more
efficiency. Argument names are used for instrospection, but when
compiling on release, the macro ignores them, so the strings are unused
and optimized away.
@@ -101,42 +83,33 @@ string passing the name can be passed for brevity.
References:
~~~~~~~~~~~
- \\\ `core/object\_type\_db.h\\ <https://github.com/okamstudio/godot/blob/master/core/object_type_db.h>`__
- `core/object\_type\_db.h <https://github.com/okamstudio/godot/blob/master/core/object_type_db.h>`__
Constants
---------
Classes often have enums such as:
| <pre class=\\"cpp\\">
| enum SomeMode {
| MODE\_FIRST,
| MODE\_SECOND
| };
.. code:: cpp
.. raw:: html
</pre>
enum SomeMode {
MODE_FIRST,
MODE_SECOND
};
For these to work when binding to methods, the enum must be declared
convertible to int, for this a macro is provided:
<pre class=\\"cpp\\">VARIANT\_ENUM\_CAST( MyClass::SomeMode); // now
functions that take SomeMode can be bound.
.. code:: cpp
.. raw:: html
</pre>
VARIANT_ENUM_CAST( MyClass::SomeMode); // now functions that take SomeMode can be bound.
The constants can also be bound inside ``_bind_methods``, by using:
| <pre class=\\"cpp\\">
| BIND\_CONSTANT( MODE\_FIRST );
| BIND\_CONSTANT( MODE\_SECOND );
.. code:: cpp
.. raw:: html
</pre>
BIND_CONSTANT( MODE_FIRST );
BIND_CONSTANT( MODE_SECOND );
Properties (set/get)
--------------------
@@ -149,34 +122,25 @@ Objects export properties, properties are useful for the following:
Properties are usually defined by the PropertyInfo() class. Usually
constructed as:
<pre
class=\\"cpp\\">PropertyInfo(type,name,hint,hint\_string,usage\_flags)
.. code:: cpp
.. raw:: html
</pre>
PropertyInfo(type,name,hint,hint_string,usage_flags)
For example:
<pre
class=\\"cpp\\">PropertyInfo(Variant::INT,\\"amount\\",PROPERTY\_HINT\_RANGE,\\"0,49,1\\",PROPERTY\_USAGE\_EDITOR)
.. code:: cpp
.. raw:: html
PropertyInfo(Variant::INT,"amount",PROPERTY_HINT_RANGE,"0,49,1",PROPERTY_USAGE_EDITOR)
</pre>
This is an integer property, named \\"amount\\", hint is a range, range
goes from 0 to 49 in steps of 1 (integers). It is only usable for the
editor (edit value visually) but wont be serialized.
This is an integer property, named "amount", hint is a range, range goes
from 0 to 49 in steps of 1 (integers). It is only usable for the editor
(edit value visually) but wont be serialized.
or
<pre
class=\\"cpp\\">PropertyInfo(Variant::STRING,\\"modes\\",PROPERTY\_HINT\_ENUM,\\"Enabled,Disabled,Turbo\\")
.. code:: cpp
.. raw:: html
</pre>
PropertyInfo(Variant::STRING,"modes",PROPERTY_HINT_ENUM,"Enabled,Disabled,Turbo")
This is a string property, can take any string but the editor will only
allow the defined hint ones. Since no hint flags were specified, the
@@ -188,19 +152,15 @@ check.
Properties can also work like C# properties and be accessed from script
using indexing, but ths usage is generally discouraged, as using
functions is preferred for legibility. Many properties are also bound
with categories, such as \\"animation/frame\\" which also make indexing
with categories, such as "animation/frame" which also make indexing
imposssible unless using operator [].
From ``_bind_methods()``, properties can be created and bound as long as
a set/get functions exist. Example:
<pre class=\\"cpp\\">ADD\_PROPERTY(
PropertyInfo(Variant::INT,\\"amount\\"), \_SCS (\\"set\_amount\\"),
\_SCS (\\"get\_amount\\") )
.. code:: cpp
.. raw:: html
</pre>
ADD_PROPERTY( PropertyInfo(Variant::INT,"amount"), _SCS("set_amount"), _SCS("get_amount") )
This creates the property using the setter and the getter. ``_SCS`` is a
macro that creates a StringName efficiently.
@@ -216,17 +176,11 @@ they are NOT virtual, DO NOT make them virtual, they are called for
every override and the previous ones are not invalidated (multilevel
call).
| <pre class=\\"cpp\\">
| void \_get\_property\_info(List \*r\_props); //return list of
propertes
| bool \_get(const StringName& p\_property, Variany& r\_value) const;
//return true if property was found
| bool \_set(const StringName& p\_property, const Variany& p\_value);
//return true if property was found
.. code:: cpp
.. raw:: html
</pre>
void _get_property_info(List *r_props); //return list of propertes
bool _get(const StringName& p_property, Variany& r_value) const; //return true if property was found
bool _set(const StringName& p_property, const Variany& p_value); //return true if property was found
This is also a little less efficient since ``p_property`` must be
compared against the desired names in serial order.
@@ -237,15 +191,12 @@ Dynamic casting
Godot provides dynamic casting between Object Derived classes, for
example:
| <pre class=\\"cpp\\">
| void somefunc(Object \*some\_obj) {
.. code:: cpp
| Button \* button = some\_obj->cast\_to&lt;Button&gt;();
| }
void somefunc(Object *some_obj) {
.. raw:: html
</pre>
Button * button = some_obj->cast_to<Button>();
}
If cast fails, NULL is returned. This system uses RTTI, but it also
works fine (although a bit slower) when RTTI is disabled. This is useful
@@ -258,14 +209,11 @@ Signals
Objects can have a set of signals defined (similar to Delegates in other
languages). Connecting to them is rather easy:
| <pre class=\\"cpp\\">
| obj->connect(,target\_instance,target\_method)
| //for example
| obj->connect(\\"enter\_tree\\",this,\\"\_node\_entered\_tree\\")
.. code:: cpp
.. raw:: html
</pre>
obj->connect(,target_instance,target_method)
//for example
obj->connect("enter_tree",this,"_node_entered_tree")
The method ``_node_entered_tree`` must be registered to the class using
``ObjectTypeDB::register_method`` (explained before).
@@ -273,11 +221,9 @@ The method ``_node_entered_tree`` must be registered to the class using
Adding signals to a class is done in ``_bind_methods``, using the
``ADD_SIGNAL`` macro, for example:
<pre class=\\"cpp\\">ADD\_SIGNAL( MethodInfo(\\"been\_killed\\") )
.. code:: cpp
.. raw:: html
</pre>
ADD_SIGNAL( MethodInfo("been_killed") )
References
----------
@@ -286,16 +232,13 @@ Reference inherits from Object and holds a reference count. It is the
base for reference counted object types. Declaring them must be done
using Ref<> template. For example.
| <pre class=\\"cpp\\">
| class MyReference: public Reference {
| OBJ\_TYPE( MyReference ,Reference);
| };
.. code:: cpp
Ref myref = memnew( MyReference );
class MyReference: public Reference {
OBJ_TYPE( MyReference ,Reference);
};
.. raw:: html
</pre>
Ref myref = memnew( MyReference );
``myref`` is reference counted. It will be freed when no more Ref<>
templates point to it.
@@ -303,7 +246,7 @@ templates point to it.
References:
~~~~~~~~~~~
- \\\ `core/reference.h\\ <https://github.com/okamstudio/godot/blob/master/core/reference.h>`__
- `core/reference.h <https://github.com/okamstudio/godot/blob/master/core/reference.h>`__
Resources:
----------
@@ -319,19 +262,16 @@ Resources without a path are fine too.
References:
~~~~~~~~~~~
- \\\ `core/resource.h\\ <https://github.com/okamstudio/godot/blob/master/core/resource.h>`__
- `core/resource.h <https://github.com/okamstudio/godot/blob/master/core/resource.h>`__
Resource loading
----------------
Resources can be loaded with the ResourceLoader API, like this:
<pre class=\\"cpp\\">Ref res =
ResourceLoader::load(\\"res://someresource.res\\")
.. code:: cpp
.. raw:: html
</pre>
Ref res = ResourceLoader::load("res://someresource.res")
If a reference to that resource has been loaded previously and is in
memory, the resource loader will return that reference. This means that
@@ -343,27 +283,23 @@ the same time.
References:
~~~~~~~~~~~
- \\\ `core/io/resource\_loader.h\\ <https://github.com/okamstudio/godot/blob/master/core/io/resource_loader.h>`__
- `core/io/resource\_loader.h <https://github.com/okamstudio/godot/blob/master/core/io/resource_loader.h>`__
Resource saving
---------------
Saving a resource can be done with the resource saver API:
<pre
class=\\"cpp\\">ResourceSaver::save(\\"res://someresource.res\\",instance)
.. code:: cpp
.. raw:: html
</pre>
ResourceSaver::save("res://someresource.res",instance)
Instance will be saved. Sub resources that have a path to a file will be
saved as a reference to that resource. Sub resources without a path will
be bundled with the saved resource and assigned sub-IDs, like
\\"res://somereource.res::1\\". This also helps to cache them when
loaded.
"res://somereource.res::1". This also helps to cache them when loaded.
References:
~~~~~~~~~~~
- \\\ `core/io/resource\_saver.h\\ <https://github.com/okamstudio/godot/blob/master/core/io/resource_saver.h>`__
- `core/io/resource\_saver.h <https://github.com/okamstudio/godot/blob/master/core/io/resource_saver.h>`__
advanced_topics/services_for_ios.rst
+99 -108
View File
@@ -23,29 +23,24 @@ locally (no internet connection, API incorrectly configured, etc). If
the error value is 'OK', a response event will be produced and added to
the 'pending events' queue. Example:
| <pre class=\\"python\\">
| func on\_purchase\_pressed():
| var result = InAppStore.purchase( { \\\ `product\_id\\ <>`__
\\"my\_product\\" } )
| if result == OK:
| animation.play(\\"busy\\") # show the \\"waiting for response\\"
animation
| else:
| show\_error()
.. 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
</pre>
# put this on a 1 second timer or something
func check_events():
while InAppStore.get_pending_event_count() > 0:
var event = InAppStore.pop_pending_event()
if event.type == "purchase":
if event.result == "ok":
show_success(event.product_id)
else:
show_error()
Remember that when a call returns OK, the API will *always* produce an
event through the pending\_event interface, even if it's an error, or a
@@ -66,9 +61,9 @@ Store Kit
Implemented in platform/iphone/in\_app\_store.mm
The Store Kit API is accessible through the \\"InAppStore\\" singleton
(will always be available from gdscript). It is initialized
automatically. It has 2 methods for purchasing:
The Store Kit API is accessible through the "InAppStore" singleton (will
always be available from gdscript). It is initialized automatically. It
has 2 methods for purchasing:
- ``Error purchase(Variant p_params);``
- ``Error request_product_info(Variant p_params);``
@@ -93,7 +88,7 @@ string with your product id. Example:
::
var result = InAppStore.purchase( { \"product_id\": \"my_product\" } )
var result = InAppStore.purchase( { "product_id": "my_product" } )
Response event
^^^^^^^^^^^^^^
@@ -105,9 +100,9 @@ On error:
::
{
\"type\": \"purchase\",
\"result\": \"error\",
\"product_id\": \"the product id requested\"
"type": "purchase",
"result": "error",
"product_id": "the product id requested"
}
On success:
@@ -115,9 +110,9 @@ On success:
::
{
\"type\": \"purchase\",
\"result\": \"ok\",
\"product_id\": \"the product id requested\"
"type": "purchase",
"result": "ok",
"product_id": "the product id requested"
}
request\_product\_info
@@ -133,7 +128,7 @@ string array with a list of product ids. Example:
::
var result = InAppStore.request_product_info( { \"product_ids\": [\"my_product1\", \"my_product2\"] } )
var result = InAppStore.request_product_info( { "product_ids": ["my_product1", "my_product2"] } )
Response event
^^^^^^^^^^^^^^
@@ -143,14 +138,14 @@ The response event will be a dictionary with the following fields:
::
{
\"type\": \"product_info\",
\"result\": \"ok\",
\"invalid_ids\": [ list of requested ids that were invalid ],
\"ids\": [ list of ids that were valid ],
\"titles\": [ list of valid product titles (corresponds with list of valid ids) ],
\"descriptions\": [ list of valid product descriptions ] ,
\"prices\": [ list of valid product prices ],
\"localized_prices\": [ list of valid product localized prices ],
"type": "product_info",
"result": "ok",
"invalid_ids": [ list of requested ids that were invalid ],
"ids": [ list of ids that were valid ],
"titles": [ list of valid product titles (corresponds with list of valid ids) ],
"descriptions": [ list of valid product descriptions ] ,
"prices": [ list of valid product prices ],
"localized_prices": [ list of valid product localized prices ],
}
Game Center
@@ -158,8 +153,8 @@ Game Center
Implemented in platform/iphone/game\_center.mm
The Game Center API is available through the \\"GameCenter\\" singleton.
It has 6 methods:
The Game Center API is available through the "GameCenter" singleton. It
has 6 methods:
- ``Error post_score(Variant p_score);``
- ``Erroraward_achievement(Variant p_params);``
@@ -187,7 +182,7 @@ Example:
::
var result = GameCenter.post_score( { \"value\": 100, \"category\": \"my_leaderboard\", } )
var result = GameCenter.post_score( { "value": 100, "category": "my_leaderboard", } )
Response event
^^^^^^^^^^^^^^
@@ -199,10 +194,10 @@ On error:
::
{
\"type\": \"post_score\",
\"result\": \"error\",
\"error_code\": the value from NSError::code,
\"error_description\": the value from NSError::localizedDescription,
"type": "post_score",
"result": "error",
"error_code": the value from NSError::code,
"error_description": the value from NSError::localizedDescription,
}
On success:
@@ -210,8 +205,8 @@ On success:
::
{
\"type\": \"post_score\",
\"result\": \"ok\",
"type": "post_score",
"result": "ok",
}
award\_achievement
@@ -234,7 +229,7 @@ Example:
::
var result = award_achievement( { \"name\": \"hard_mode_completed\", \"progress\": 6.1 } )
var result = award_achievement( { "name": "hard_mode_completed", "progress": 6.1 } )
Response event
^^^^^^^^^^^^^^
@@ -246,9 +241,9 @@ On error:
::
{
\"type\": \"award_achievement\",
\"result\": \"error\",
\"error_code\": the error code taken from NSError::code,
"type": "award_achievement",
"result": "error",
"error_code": the error code taken from NSError::code,
}
On success:
@@ -256,8 +251,8 @@ On success:
::
{
\"type\": \"award_achievement\",
\"result\": \"ok\",
"type": "award_achievement",
"result": "ok",
}
reset\_achievements
@@ -275,9 +270,9 @@ On error:
::
{
\"type\": \"reset_achievements\",
\"result\": \"error\",
\"error_code\": the value from NSError::code
"type": "reset_achievements",
"result": "error",
"error_code": the value from NSError::code
}
On success:
@@ -285,8 +280,8 @@ On success:
::
{
\"type\": \"reset_achievements\",
\"result\": \"ok\",
"type": "reset_achievements",
"result": "ok",
}
request\_achievements
@@ -305,9 +300,9 @@ On error:
::
{
\"type\": \"achievements\",
\"result\": \"error\",
\"error_code\": the value from NSError::code
"type": "achievements",
"result": "error",
"error_code": the value from NSError::code
}
On success:
@@ -315,10 +310,10 @@ On success:
::
{
\"type\": \"achievements\",
\"result\": \"ok\",
\"names\": [ list of the name of each achievement ],
\"progress\": [ list of the progress made on each achievement ]
"type": "achievements",
"result": "ok",
"names": [ list of the name of each achievement ],
"progress": [ list of the progress made on each achievement ]
}
request\_achievement\_descriptions
@@ -337,9 +332,9 @@ On error:
::
{
\"type\": \"achievement_descriptions\",
\"result\": \"error\",
\"error_code\": the value from NSError::code
"type": "achievement_descriptions",
"result": "error",
"error_code": the value from NSError::code
}
On success:
@@ -347,15 +342,15 @@ On success:
::
{
\"type\": \"achievement_descriptions\",
\"result\": \"ok\",
\"names\": [ list of the name of each achievement ],
\"titles\": [ list of the title of each achievement ]
\"unachieved_descriptions\": [ list of the description of each achievement when it is unachieved ]
\"achieved_descriptions\": [ list of the description of each achievement when it is achieved ]
\"maximum_points\": [ list of the points earned by completing each achievement ]
\"hidden\": [ list of booleans indicating whether each achievement is initially visible ]
\"replayable\": [ list of booleans indicating whether each achievement can be earned more than once ]
"type": "achievement_descriptions",
"result": "ok",
"names": [ list of the name of each achievement ],
"titles": [ list of the title of each achievement ]
"unachieved_descriptions": [ list of the description of each achievement when it is unachieved ]
"achieved_descriptions": [ list of the description of each achievement when it is achieved ]
"maximum_points": [ list of the points earned by completing each achievement ]
"hidden": [ list of booleans indicating whether each achievement is initially visible ]
"replayable": [ list of booleans indicating whether each achievement can be earned more than once ]
}
show\_game\_center
@@ -370,19 +365,19 @@ Parameters
Takes a Dictionary as a parameter, with 2 fields:
- ``view`` (string) (optional) the name of the view to present. Accepts
\\"default\\", \\"leaderboards\\", \\"achievements\\", or
\\"challenges\\". Defaults to \\"default\\".
"default", "leaderboards", "achievements", or "challenges". Defaults
to "default".
- ``leaderboard_name`` (string) (optional) the name of the leaderboard
to present. Only used when \\"view\\" is \\"leaderboards\\" (or
\\"default\\" is configured to show leaderboards). If not specified,
Game Center will display the aggregate leaderboard.
to present. Only used when "view" is "leaderboards" (or "default" is
configured to show leaderboards). If not specified, Game Center will
display the aggregate leaderboard.
Examples:
::
var result = show_game_center( { \"view\": \"leaderboards\", \"leaderboard_name\": \"best_time_leaderboard\" } )
var result = show_game_center( { \"view\": \"achievements\" } )
var result = show_game_center( { "view": "leaderboards", "leaderboard_name": "best_time_leaderboard" } )
var result = show_game_center( { "view": "achievements" } )
Response event
^^^^^^^^^^^^^^
@@ -394,41 +389,37 @@ On close:
::
{
\"type\": \"show_game_center\",
\"result\": \"ok\",
"type": "show_game_center",
"result": "ok",
}
Multi-platform games
--------------------
When working on a multi-platform game, you won't always have the
\\"GameCenter\\" singleton available (for example when running on PC or
"GameCenter" singleton available (for example when running on PC or
Android). Because the gdscript compiler looks up the singletons at
compile time, you can't just query the singletons to see and use what
you need inside a conditional block, you need to also define them as
valid identifiers (local variable or class member). This is an example
of how to work around this in a class:
| <pre class=\\"python\\">
| var GameCenter = null # define it as a class member
.. code:: python
| func post\_score(p\_score):
| if GameCenter == null:
| return
| GameCenter.post\_score( { \\\ `value\\ <>`__ p\_score,
\\\ `category\\ <>`__ \\"my\_leaderboard\\" } )
var GameCenter = null # define it as a class member
| func check\_events():
| while GameCenter.get\_pending\_event\_count() > 0:
| # do something with events here
| pass
func post_score(p_score):
if GameCenter == null:
return
GameCenter.post_score( { "value": p_score, "category": "my_leaderboard" } )
| func \_ready():
| # check if the singleton exists
| if Globals.has\_singleton(\\"GameCenter\\"):
| GameCenter = Globals.get\_singleton(\\"GameCenter\\")
| # connect your timer here to the \\"check\_events\\" function
func check_events():
while GameCenter.get_pending_event_count() > 0:
# do something with events here
pass
.. raw:: html
</pre>
func _ready():
# check if the singleton exists
if Globals.has_singleton("GameCenter"):
GameCenter = Globals.get_singleton("GameCenter")
# connect your timer here to the "check_events" function
advanced_topics/variant_class.rst
+3 -3
View File
@@ -35,7 +35,7 @@ of c++ with little effort. Become a friend of Variant today.
References:
~~~~~~~~~~~
- \\\ `core/variant.h\\ <https://github.com/okamstudio/godot/blob/master/core/variant.h>`__
- `core/variant.h <https://github.com/okamstudio/godot/blob/master/core/variant.h>`__
Dictionary and Array
--------------------
@@ -56,5 +56,5 @@ desired.
References:
~~~~~~~~~~~
- \\\ `core/dictionary.h\\ <https://github.com/okamstudio/godot/blob/master/core/dictionary.h>`__
- \\\ `core/array.h\\ <https://github.com/okamstudio/godot/blob/master/core/array.h>`__
- `core/dictionary.h <https://github.com/okamstudio/godot/blob/master/core/dictionary.h>`__
- `core/array.h <https://github.com/okamstudio/godot/blob/master/core/array.h>`__
asset_pipeline/export.rst
+17
View File
@@ -0,0 +1,17 @@
Export
======
.. toctree::
:maxdepth: 1
:name: export
exporting_projects
one-click_deploy
exporting_images
exporting_for_pc
exporting_for_android
exporting_for_ios
.. exporting_for_bb10
.. exporting_for_nacl
.. exporting_for_html5
.. exporting_for_consoles
asset_pipeline/exporting_for_android.rst
+63
View File
@@ -0,0 +1,63 @@
Exporting for Android
=====================
Exporting for android has much less requirements than compiling Godot
for it. As follows are the steps to setup the SDK and the engine.
Download the Android SDK
------------------------
Download and install the Android SDK from
http://developer.android.com/sdk/index.html
Download the Java 6 or OpenJDK6
-------------------------------
Download and install Java 6 or OpenJDK 6, Android needs this version and
it seems that jarsigner (what is used to sign APKs) from greater
versions do not work.
Create a debug.keystore
-----------------------
Android needs a debug keystore file to install to devices and distribute
non-release APKs. If you have used the SDK before and have built
projects, ant or eclipse probably generated one for you (In Linux and
OSX, you can find it in the ~/.android folder).
If you can't find it or need to generate one, the keytool command from
the JDK can be used for this purpose:
keytool -keyalg RSA -genkeypair -alias androiddebugkey -keypass android
-keystore debug.keystore -storepass android -dname "CN=Android
Debug,O=Android,C=US" -validity 9999
Make sure you have adb
----------------------
ADB is the command line tool used to communicate with Android devices.
It's installed with the SDK, but you may need to install one (any) of
the Android API levels for it to be installed in the SDK directory.
Setting it up in Godot
----------------------
Enter the Editor Settings screen. This screens contains the editor
settings for the user account in the computer (It's independent from the
project).
.. image:: /img/editorsettings.png
Scroll down to the section where the Android settings are located:
.. image:: /img/androidsdk.png
In that screen, the path to 3 files needs to be set:
- The *adb* executable (adb.exe on Windows)
- The *jarsigner* executable (from JDK6)
- The debug *keystore*
Once that is configured, everything is ready to export to Android!
asset_pipeline/exporting_for_ios.rst
+76
View File
@@ -0,0 +1,76 @@
Exporting for iOS
=================
Exporting for iOS is done manually at the moment. These are the steps to
load your game in an XCode project, where you can deploy to a device,
publish, etc.
Requirements
------------
- Download XCode for iOS
- Download the export templates:
http://www.godotengine.org/projects/godot-engine/documents
- Since there is no automatic deployer yet, unzip export\_templates.tpz
manually and extract GodotiOSXCode.zip from it.
The zip contains an XCode project, godot\_ios.xcodeproj, an empty
data.pck file and the engine executable. Open the project, and modify
the game name, icon, organization, provisioning signing certificate
identities (??), etc.
Add your project data
---------------------
Using the Godot editor, [[Exporting\_for\_pc\|export your project for
Windows]], to obtain the data.pck file. Replace the empty data.pck in
the XCode project with the new one, and run/archive.
If you want to test your scenes on the iOS device as you edit them, you
can add your game directory to the project (instead of data.pck), and
add a property "godot\_path" to Info.plist, with the name of your
directory as its value.
.. image:: /img/godot_path.png
Alternatively you can add all the files from your game directly, with
"engine.cfg" at the root.
Loading files from a host
-------------------------
Sometimes your game becomes too big and deploying to the device takes
too long every time you run. In that case you can deploy only the engine
executable, and serve the game files from your computer.
Setting up the file host
~~~~~~~~~~~~~~~~~~~~~~~~
On your PC, open the editor, and click the righ-most icon on the
top-center group of icons, and select "Enable File Server". The icon
turns red. Your PC will open a port and accept connections to serve
files from your project's directory (so enable your local firewall
accordingly).
.. image:: /img/rfs_server.png
Setting up the game
~~~~~~~~~~~~~~~~~~~
On XCode, click on your app name (top left, next to the "Stop" button),
and select "Edit Scheme". Go to the "Arguments" tab, and add 2
arguments, "-rfs" and the IP of your PC.
.. image:: /img/edit_scheme.png
When you run, your device will connect to the host and open the files
remotely. Note that the directory with the game data ("platformer") is
no longer added to the project, only the engine executable.
Services for iOS
----------------
Special iOS services can be used in Godot. Check out the [[Services for
iOS]] page.
asset_pipeline/exporting_for_pc.rst
+15
View File
@@ -0,0 +1,15 @@
Exporting for PC
================
The simplest way to distribute a game for PC is to copy the executables
(godot.exe on windows, godot on the rest), zip the folder and send it to
someone else. However, this is often not desired.
Godot offers a more elegant approach for PC distribution when using the
export system. When exporting for PC (Linux, Windows, Mac), the exporter
takes all the project files and creates a "data.pck" file. This file is
bundled with a specially optimized binary that is smaller, faster and
lacks tools and debugger.
Optionally, the files can be bundled inside the executable, though this
does not always works properly.
asset_pipeline/exporting_images.rst
+67
View File
@@ -0,0 +1,67 @@
Exporting images
================
It is often desired to do an operation to all or a group of images upon
export. Godot provides some tools for this. Examples of such operations
are:
- Converting all images from a lossless format to a lossy one (ie: png
-> web) for greater compression.
- Shrinking all images to half the size, to create a low resolution
build for smaller screens.
- Create an atlas for a group of images and crop them, for higher
performance and less memory usage.
Image Export Options
--------------------
In the `Export Dialog <export>`__, go to the Images tab:
.. image:: /img/exportimages.png
In this dialog the image extensions for conversion can be selected, and
operations can be performed that apply to all images (except those in
groups -next section for that-):
- **Convert Image Format**: Probably the most useful operation is to
convert to Lossy (WebP) to save disk space. For lossy, a Quality bar
can set the quality/vs size ratio.
- **Shrink**: This allows to shrink all images by a given amount. It's
useful to export a game to half or less resolution for special
devices.
- **Compress Formats**: Allows to select which image exensions to
convert.
On export, Godot will perform the desired operation. The first export
might be really slow, but subsequent exports will be fast, as the
converted images will be cached.
Image Group Export Options
--------------------------
This section is similar to the previous one, except it can operate on a
selected group of images. When a image is in a group, the settings from
the global export options are overridden by the ones from the group. An
image can only be in one group at the same time. So if the image is in
another group different to the current one being edited, it will not be
selectable.
.. image:: /img/imagegroup.png
Atlas
~~~~~
As a plus, an atlas can be created from a group. When this mode is
active, a button to preview the resulting atlas becomes available. Make
sure that atlases don't become too big, as some hardware will not
support textures bigger than 2048x2048 pixels. If this happens, just
create another atlas.
The atlas can be useful to speed up drawing of some scenes, as state
changes are minimized when drawing from it (through unlike other
engines, Godot is designed so state changes do not affect it as much).
Textures added to an atlas get cropped (empty spaces around the image
are removed), so this is another reason to use them (save space). If
unsure, though, just leave that option disabled.
asset_pipeline/exporting_projects.rst
+127
View File
@@ -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&quot; scenes and dependencies into a single file, which is
*really* useful for games distributed on optical media.
.. image:: /img/expselected.png
asset_pipeline/general.rst
+1 -1
View File
@@ -4,5 +4,5 @@ General
.. toctree::
:maxdepth: 1
:name: general
managing_image_files
asset_pipeline/import.rst
+14
View File
@@ -0,0 +1,14 @@
Import
======
.. toctree::
:maxdepth: 1
:name: import
import_process
importing_textures
importing_3d_meshes
importing_3d_scenes
importing_fonts
importing_audio_samples
importing_translations
asset_pipeline/import_process.rst
+166
View File
@@ -0,0 +1,166 @@
Import process
==============
What is it for?
---------------
When Godot was created, it was probably after several failed and not so
failed engine attempts (well, each attempt failed a little less.. and so
on). One of the most difficult areas of creating game engines is
managing the import process. That means, getting the assets that artists
make into the game, in a way that functions optimally.
Artists use certain tools and formats, and programmers would rather have
their data into a different format. This is because artists put their
focus on creating assets with the best quality possible, while
programmers have to make sure they actually run at decent speed (or run
at all), use a certain amount of memory, and don't take ages loading
from disk.
One would think that just writing a converter/importer would be enough,
but this is not all there is to it. The same way programmers iterate
several times over their code, artists keep making changes to their
assets. This generates some bottleneck, because *someone* has to keep
re-importing that artwork right? And importing assets is often something
that has to be agreed by both parties, as the programmer needs to decide
how the artwork is imported and the artists needs to see how it looks.
The goal to establishing an import process is that both can agree on how
the rules under which the assets are going to be imported the first
time, and the system will apply those rules automatically each time the
asset is re-imported.
Godot does not do the re-import process automatically, though. It gives
the team the option to do it at any time ( a red icon on the top right
of the screen, allows the ability to do it at any desired time).
Does it always work?
--------------------
The aim of the import system is that it works well enough for most
common cases and projects. What is there has been tested and seems to
cover most needs.
However, as mentioned before, this is on of the most difficult areas of
writing a game engine. It may happen often (specially on large projects,
ports, or projects with unusual requirement) that what is provided is
not enough. It's easy to say that the engine is open source and that the
programmer should make their own if they don't like what is there, but
that would be making a huge disservice to the users and not the right
attitude. Because of that, we made sure to provide as many tools and
helpers as possible to support a custom import process, for example:
- Access to the internals of almost all data structures is provided to
the scripting and C++ API, as well as saving and loading in all
supported file formats.
- Some importers (like the 3D asset importer) support scripts to modify
the data being imported.
- Support for creating custom import plugins is also provided, even for
replacing the existing ones.
- If all else fails, Godot supports for adding custom resource loaders,
to load data in alternative formats, without intermediate conversion.
Both the import system and the custom tools provided will improve over
time as more use cases are revealed to us.
Importing assets
----------------
Source asset location
~~~~~~~~~~~~~~~~~~~~~
To begin, it is a good idea to define where the original assets created
by the artists (before they are imported) will be located. Normally,
Godot does not mind much about the location, but if the project has
several developers, it is a good idea to understand the simple rule for
it to work for everyone.
First of all, it would be really good for this location to **not** be
inside the project path (where engine.cfg is located, or any
sub-folder). Godot expects regular resources in there, and may consider
many of the files used as source art as regular resources. This would
lead to it bundling all of them when the project is exported, something
which is undesired.
Now that it is clear that this location must be outside the project
folder, the rule that Godot uses to reference external assets can be
explained. When an asset is imported, the engine stores a relative path
from the project path to the asset (In windows, this works as long as
they are on the same drive, otherwise an absolute path is stored). This
ensures that the same asset can be re-imported in another computer.
The usual approach to this, when using a VCS such as Subversion,
Perforce or GIT, is to create the project in a subfolder, so both it and
the source assets can be commited to a same repository. For example:
Repository layout:
::
source_assets/sfx/explosion.wav
source_assets/sfx/crash.wav
source_assets/fonts/myfont.ttf
source_assets/translation/strings.csv
source_assets/art/niceart.psd
game/engine.cfg
In the above example, artists, musican, translators, etc. can work in
the source\_assets/ folder, then import the assets to the game/ folder.
When the repository is updated, anyone can re-import the assets if they
changed.
Import dialogs
~~~~~~~~~~~~~~
Godot provides for importing several types of assets, all of them can be
accessed from the import dialog:
.. image:: /img/import.png
Each of the dialog shares a similar function, a source file (or several
of them) must be provided, as well as a target destination inside the
project folders. Once imported, Godot saves this information as metadata
in the imported asset itself.
.. image:: /img/importdialogs.png
More information about each specific type of asset can be found in
specific sections, such as `Importing Textures <import_textures>`__.
Tracking changes and re-importing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Godot tracks changes in the source assets constantly. If at least one
asset has been found to be modified (md5 is different than when it was
imported), a small red indicator will appear in the top right corner of
the screen.
.. image:: /img/changes.png
| From that moment onward, the user can choose to re-import at any given
time by clicking on the red-icon. When this action is done, a dialog
will pop-up showing which resources can be re-imported (all selected
by default).
| Accepting that dialog will immediately re-import the resources and
will update any of them currently in use in the editor (like a
texture, model or audio file).
.. image:: /img/changed.png
Manually re-importing
~~~~~~~~~~~~~~~~~~~~~
The re-import process is automatic, but it may be desired at some point
to change the settings of an already imported file, so it can be
re-imported differently. For this, the Import Settings window is
provided.
.. image:: /img/isettings.png
This screen allows the user to re-open the corresponding import-window
to re-import that asset again, with the ability to change any of the
settings.
.. image:: /img/reimported.png
asset_pipeline/importing_3d_meshes.rst
+60
View File
@@ -0,0 +1,60 @@
Importing 3D meshes
===================
Introduction
------------
Godot supports a flexible and powerful [[3D Scene importer]], that
allows for full scene importing. For a lot of artists and developers
this is more than enough. However, many do not like this workflow as
much and prefer to import individual 3D Meshes and build the scenes
inside the Godot 3D editor themselves. (Note that for more advanced
features such as skeletal animation, there is no option to the 3D Scene
Importer).
The 3D mesh import workflow is simple and works using the OBJ file
format. The imported meshes result in a .msh binary file which the user
can put into a [[API:MeshInstance]], which in turn can be placed
somewhere in the edited scene.
Importing
---------
Importing is done through the Import 3D Mesh menu:
.. image:: /img/mesh_import.png
Which opens the Mesh import window:
.. image:: /img/mesh_dialog.png
This dialog allows the import of one more more OBJ files into a target
path. OBJ files are converted to .msh files. Files are imported without
any material on them, material has to be added by the user (see the
[[Fixed materials]] tutorial). If the external OBJ file is changed it
will be re-imported, while keeping the newly assigned material.
Options
-------
A few options are present. Normals is needed for regular shading, while
Tangents is needed if you plan to use normal-mapping on the material. In
general, OBJ files describe how to be shaded very well, but an option to
force smooth shading is available.
Finally, there is an option to weld vertices. Given OBJ files are
text-based, it is common to find some of these with vertices that do not
mach, which results in strange shading. The weld vertices option merges
vertices that are too close to keep proper smooth shading.
Usage
-----
Mesh resources (what this importer imports) are used inside MeshInstance
nodes. Simply set them to the Mesh property of them.
.. image:: /img/3dmesh_instance.png
And that is it.
asset_pipeline/importing_3d_scenes.rst
+411
View File
@@ -0,0 +1,411 @@
Importing 3D scenes
===================
Introduction
------------
Most game engines just import 3D objects, which may contain skeletons or
animations and then all further work is done in the engine UI, like
object placement, full scene animations, etc. In Godot, given the node
system is very similar to how 3D DCC (Such as Maya, 3DS Max or Blender)
tools work, full 3D scenes can be imported in all their glory.
Additionally, by using a simple language tag system, it is possible to
specify that objects are imported as several things, such as collidable,
rooms and portals, vehicles and wheels, LOD distances, billboards, etc.
This allows for some interesting features:
- Importing simple scenes, rigged objects, animations, etc.
- Importing full scenes. Entire scenarios can be created and updated in
the 3D DCC and imported to Godot each time they change, then only
little editing is needed from the engine side.
- Full cutscenes can be imported, including multiple character
animation, lighting, camera motion, etc.
- Scenes can be further edited and scripted in the engine, where
shaders and environment effects can be added, enemies can be
instanced, etc. The importer will update geometry changes if the
source scene changes but keep the local changes too (in real-time
while using the Godot editor!)
- Textures can be all batch-imported and updated when the source scene
changes.
This is achieved by using a very simple language tag that will be
explained in detail later.
Exporting DAE files
-------------------
Why not FBX?
~~~~~~~~~~~~
Most game engines use the FBX format for importing 3D scenes, which is
definitely one of the most standardized in the industry. However, this
format requires the use of a closed library from Autodesk which is
distributed with a more restrictive licensing terms than Godot. The plan
is, sometime in the future, to implement an external conversion binary,
but meanwhile FBX is not really supported.
Exporting DAE files from Maya and 3DS Max
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Autodesk added built-in collada support to Maya and 3DS Max, but It's
really broken and should not be used. The best way to export this format
is by using the
`OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`__
plugins. They work really well, although they are not always up-to date
with the latest version of the software.
Exporting DAE files from Blender
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Blender also has built-in collada support, but It's really broken and
should not be used either.
| Godot provides a `Python
Plugin <https://github.com/okamstudio/godot/tree/master/tools/export/blender25>`__
that will do a much better job at exporting the scenes.
The import process
------------------
Import process begins with the 3D scene import menu:
.. image:: /img/3dimp_menu.png
That opens what is probably the biggest of all the import dialogs:
| p=. |image1|
| Many options exist in there, so each section will be explained as
follows:
Source & target paths
---------------------
| To import, two options are needed. The first is a source .dae file
(.dae stands for Collada. More import formats will eventually added,
but Collada is the most complete open format as of this writing).
| A target folder needs to be provided, so the importer can import the
scene there. The imported scene will have the same filename as the
source one, except for the .scn extension, so make sure you pick good
names when you export!
The textures will be copied and converted. Textures in 3D applications
are usually just PNG or JPG files. Godot will convert them to video
memory texture compression format (s3tc, pvrtc, ericsson, etc) by
default to improve performance and save resources.
Since the original textures, 3d file and textues are usually not needed,
it's recommended you keep them outside the project. For some hints on
how to do this the best way, you can check the [[Version control &
Project organization]] tutorial.
Two options for textures are provided. They can be copied to the same
place as the scene, or they can be copied to a common path (configurable
in the project settings). If you choose this, make sure no two textures
are names the same.
3D rigging tips
---------------
Before going into the options, here are some tips for making sure your
rigs import properly
- Only up to 4 weights are imported per vertex, if a vertex depends of
more than 4 bones, only the 4 most important bones (the one with the
most weight) will be imported. For most models this usually works
fine, but just keep it in mind.
- Do not use non-uniform scale in bone animation, as this will likely
not import properly. Try to accomplish the same effect with more
bones.
- When exporting from Blender, make sure that objects modified by a
skeleton are children of it. Many objects can be modified by a single
skeleton, but they all should be direct children.
- The same way, when using Blender, make sure that the relative
transform of children nodes to the skeleton is zero (no rotation, no
translation, no scale. All zero and scale at 1.0). The position of
both objects (the little orange dot) should be at the same place.
3D import options
-----------------
This section contains many options to change the way import workflow
works. Some (like HDR) will be better explained in other sections, but
in general a pattern can be visible in the options and that is, many of
the options end with "-something". For example:
- Remove Nodes (-noimp)
- Set Alpha in Materials (-alpha)
- Create Collisions (-col).
This means that the object names in the 3D DCC need to have those
options appended at the end for the importer to tell what they are. When
imported, Godot will convert them to what they are meant to be.
**Note:** Maya users must use “\_" (underscore) instead of "-" (minus).
Here is an example of how a scene in the 3D dcc looks (using blender),
and how it is imported to Godot:
.. image:: /img/3dimp_blender.png
Notice that:
- The camera was imported normally.
- A Room was created (-room).
- A Portal was created (-portal).
- The Mesh got static collision added (-col).
- The Light was not imported (-noimp).
Options in detail
-----------------
Following is a list of most import options and what they do in more
detail.
Remove nodes (-noimp)
^^^^^^^^^^^^^^^^^^^^^
Node names that have this at the end will be removed at import time, mo
matter their type. Erasing them afterwards is most of the times
pointless because the will be restored if the source scene changes.
Import animations
^^^^^^^^^^^^^^^^^
Some scene formats (.dae) support one or more animations. If this is
checked, an `AnimationPlayer <class_animationplayer>`__ node will be
created, containing the animations.
Compress geometry
^^^^^^^^^^^^^^^^^
This option (disabled [STRIKEOUT:or more like, always enabled] at the
moment at the time of writing this) will compress geometry so it takes
less space and renders faster (at the cost of less precision).
Force generation of tangent arrays
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The importer detects when you have used a normalmap texture, or when the
source file contains tangent/binormal information. These arrays are
needed for normalmapping to work, and most exporters know what they do
when they export this. However, it might be possible to run into source
scenes that do not have this information which, as a result, make
normal-mapping not work. If you notice that normal-maps do not work when
importing the scene, turn this on!
SRGB -> linear of diffuse textures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When rendering using HDR (High Dynamic Range) it might be desirable to
use linear-space textures to achieve a more real-life lighting.
Otherwise, colors may saturate and contrast too much when exposure
changes. This option must be used together with the SRGB option in
`WorldEnvironment <class_worldenvironment>`__. The texture import
options also have the option to do this conversion, but if this one is
turned on, conversion will always be done to diffuse textures (usually
what is desired). For more information, read the [[HDR]].
Set alpha in materials (-alpha)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When working with most 3D dccs, its pretty obvious when a texture is
transparent and has opacity and this rarely affects the workflow or
final rendering. However, when dealing with real-time rendering,
materials with alpha blending are usually less optimal to draw, so they
must be explicitly marked as such.
Originally Godot detected this based on whether if the source texture
had an alpha channel, but most image manipulation apps like Photoshop or
Gimp will export this channel anyway even if not used. Code was added
later to check manually if there really was any transparency in the
texture, but artists will anyway and very often lay uvmaps into opaque
parts of a texture and leave unused areas (where no UV exists)
transparent, making this detection worthless.
Finally, it was decided that it's best to import everything as opaque
and leave artists to fix materials that need transparency when it's
obvious that they are not looking right (see the [Fixed Ma
As a helper, since every 3D dcc allows naming the materials and keeping
their name upon export, the (-alpha) modifier in their name will hint
the 3D scene importer in Godot that this material will use the alpha
channel for transparency.
Set vert. color in materials (-vcol)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Most 3D DCCs support vertex color painting. This is generally applied as
multiplication or screen blending. However, it is also often the case
that your exporter will export this information as all 1s, or export it
as something else and you will not realize it. Since most of the cases
this option is not desired, just add this to any material to confirm
that vertex colors are desired.
Create collisions (-col, -colonly)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These will only work for Mesh nodes, If the "-col" option is detected, a
child static collision node will be added, using the same geometry as
the mesh.
However, it is often the case that the visual geometry is too complex or
too un-smooth for collisions, which end up not working well. To solve
this, the "-colonly" modifier exists, which will remove the mesh upon
import and create a `StaticBody <class_staticbody>`__ collision instead.
This helps the visual mesh and actual collision to be separated.
Create rooms (-room)
^^^^^^^^^^^^^^^^^^^^
This is used to create a room. As a general rule, any node that is a
child of this node will be considered inside the room (including
portals). For more information about rooms/portals, look at the
[[Portals and Rooms]] tutorial.
There are two ways in which this modifier can be used. The first is
using a Dummy/Empty node in the 3D app with the "-room" tag. For this to
work, the "interior" of the room must be closed (geometry of the
childrens should contain walls, roof, floor, etc and the only holes to
the outside should be covered with portals). The importer will then
create a simplified version of the geometry for the room.
The second way is to use the "-room" modifier on a mesh node. This will
use the mesh as the base for the BSP tree that contains the room bounds.
Make sure that the mesh shape is **closed**, all normals **point
outside** and that the geometry is **not self-intersecting**, otherwise
the bounds may be computed wrong (BSP Trees are too picky and difficult
to work with, which is why they are barely used anymore..).
Anyway, the room will need portals, which are described next.
Create portals (-portal)
^^^^^^^^^^^^^^^^^^^^^^^^
Portals are the view to look outside a room. They are always some flat
shape on the surface of a room. If the portal is left alone, it is used
to activate occlusion when looking inside<->outside the room. Again,
more information on the [[Portals and Rooms]] tutorial.
Basically, the conditions to make and import a portal from the 3D DCC
are:
- It should be a child of a room.
- It should lay on the surface of the room (this doesn't need to be
super exact, just make it as close as you can by eye and Godot will
adjust it)
- It must be a flat, convex shape, any flat and convex shape is ok, no
matter the axis or size.
- Normals for the flat shape faces must **all point towards the
OUTSIDE** of the room.
Here is how it usually looks:
.. image:: /img/3dimp_portal.png
To connect to rooms, simply make two identical portals for both rooms
and place them overlapped. This does not need to be perfectly exact,
again, as Godot will fix it.
[..]
^^^^
The rest of the tags in this section should be rather obvious, or will
be documented/changed in the future.
Double-sidedness
----------------
| Collada and other formats support specifying the double-sidedness of
the geometry (in other words, when not double-sided, back-faces are
not drawn). Godot supports this option per Material, not per Geometry.
| When exporting from 3D DCCs that work with per-object double-sidedness
(such as Blender of Maya), make sure that the double sided objects do
not share a material with the single sided ones or the importer will
not be able to discern.
Animation options
-----------------
| Some things to keep in mind when importing animations. 3D DCCs allow
animating with curves for every x,y,z component, doing IK constraints
and other stuff. When imported for real-time, animations are sampled
(at small intervals) so all this information is lost. Sampled
animations are fast to process, but can use considerable amounts of
memory.
| Because of this, the "Optimize" option exists but, in some cases, this
option might get to break an animation, so make it sure to disable if
you see this.
Some animations are meant to be cycled (like walk animations) if this is
the case, animation names that end in "-cycle" or "-loop" are
automatically set to loop.
Import script
-------------
Creating a script to parse the imported scene is actually really simple.
This is great for post processing, changing materials, doing funny stuff
with the geometry, etc.
Create a script that basically looks like this:
::
tool #needed so it runs in editor
extends EditorScenePostImport
func post_import(scene):
#do your stuff here
pass # scene contains the imported scene starting from the root node
The post-import function takes the imported scene as parameter (the
parameter is actually the root node of the scene).
Update logic
------------
Other types of resources (like samples, meshes, fonts, images, etc.) are
re-imported entirely when changed and user changes are not kept.
Because of 3D Scenes can be really complex, they use a different update
strategy. The user might have done local changes to take advantage of
the engine features and it would be really frustrating if everything is
lost on re-import because the source asset changed.
This led to the implementation of a special update strategy. The idea
behind is that the user will not lose anything he or she did, and only
added data or data that can't be edited inside Godot will be updated.
It works like this:
Strategy
^^^^^^^^
Upon changes on the source asset (ie: .dae), and on re-import, the
editor will remember the way the scene originally was, and will track
your local changes like renaming nodes, moving them or reparenting them.
Finally, the following will be updated:
- Mesh Data will be replaced by the data from the updated scene.
- Materials will be kept if they were not modified by the user.
- Portal and Room shapes will be replaced by the ones from the updated
scene.
- If the user moved a node inside Godot, the transform will be kept. If
the user moved a node in the source asset, the transform will be
replaced. Finally, if the node was moved in both places, the
transform will be combined.
In general, if the user deletes anything from the imported scene (node,
mesh, material, etc), updating the source asset will restore what was
deleted. This is a good way to revert local changes to anything. If you
really don't want a node anymore in the scene, either delete it from
both places or add the "-noimp" tag to it in the source asset.
Fresh re-import
^^^^^^^^^^^^^^^
It can also happen that the source asset changed beyond recognition and
a full fresh re-import is desired. If so, simply re-open the 3d scene
import dialog from the Import -> Re-Import menu and perform re-import.
asset_pipeline/importing_audio_samples.rst
+113
View File
@@ -0,0 +1,113 @@
Importing audio samples
=======================
Why importing?
--------------
Importing Audio Samples into the game engine is a process that should be
easier than it really is. Most readers are probably thinking "Why not
just copying the .wav files to a folder inside the project and be over
with it?".
It's not usually that simple. Most game engines use uncompressed audio
(in memory at least) for sound effects. The reason for this is because
it's really cheap to play back and resample. Compressed streamed audio
(such as .ogg files) takes a large amount of processor to decode so no
more than one or two are streamed simultaneously. However, with sound
effects, one expects a dozen of them to be playing at the same time in
several situations.
Because of this, sound effects are loaded uncompressed into memory, and
here is where the problems begin.
As is usual with graphics, the situation where programmers don't really
know about audio and audio engineers don't know about programming is
also common in the industry. This leads to a scenario where a project
ends up wasting resources unnecessarily.
To be more precise, sfx artists tend to work with audio formats that
give them a lot of room for tweaking the audio with a low noise floor
minimum aliasing, such as 96khz, 24 bits. In many cases, they work in
stereo too. Added to that, many times they add effects with an infinite
or really long fadeout, such as reverb, which take a long time to fade
out. Finally, many DAWs also add silence at the beginning when
normalizing to wav.
This results in extremely large files to integrate more often than
desired, with sound effects taking dozens of megabytes.
How much does quality matter?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First of all, it is important to know that Godot has an internal reverb
generator. Sound effects can go to four different setups (small, medium
and large room as well as hall), with different send amounts. This saves
sfx artists the need to add reverb to the sound effects, reducing their
size greatly and ensuring correct trimming. Say no to SFX with baked
reverb!
.. image:: /img/reverb.png
Another common problem is that, while it's useful for working inside a
DAW, high dynamic range (24 bits) and high sampling rate (96khz) is
completely unnecessary for use in a game, as there is no `audible
difference <http://www.youtube.com/watch?v=cIQ9IXSUzuM>`__. If
positional sound is going to be used (for 2D and 3D), the panning and
stereo reverb will be provided by the engine, so there is little need
for stereo sound. How does this affect the resource usage? Look at the
following comparison:
+---------------------------+---------------------+--------------+
| Format | 1 Second of Audio | Frame Size |
+===========================+=====================+==============+
| 24 bits, 96 khz, Stereo | 576kb | 12 |
+---------------------------+---------------------+--------------+
| 16 bits, 44 khz, Mono | 88kb | 2 |
+---------------------------+---------------------+--------------+
| 16 bits, IMA-ADPCM | 22kb | 1/2 |
+---------------------------+---------------------+--------------+
As seen, for being no audible difference, the 16 bits, 44khz takes *6
times less memory* than the 24 bits, 96khz, Stereo version. The
IMA-ADPCM version takes *24 times less memory* than what was exported
from the DAW.
Trimming
~~~~~~~~
One last issue that happens often is that the waveform files received
have silences at the beginning and at the end. These are inserted by
DAWs when saving to a waveform, increase their size unnecessarily and
add latency to the moment they are played back. Trimming them solves
this, but it takes effort for the sfx artist, as they have to do it in a
separate application. In the worst case, they may not even know the
silences are being added.
.. image:: /img/trim.png
Importing audio samples
-----------------------
Godot has a simple screen for importing audio samples to the engine. SFX
artists only have to save the .wav files to a folder outside the
project, and the import dialog will fix the files for inclusion, as well
as doing it automatically every time they are modified and re-imported.
.. image:: /img/importaudio.png
In this screen, the quality of the audio can be limited to what is
needed, and trimming is done automatically. As a plus, several samples
can be loaded and batch-converted, just like textures.
Looping
~~~~~~~
Godot supports looping in the samples (Tools such as Sound Forge or
Audition can add loop points to .wav files). This is useful for sound
effects such as engines, machine guns, etc. Ping-pong looping is also
supported.
As an alternative, the import screen has a "loop" option that enables
looping for the entire sample when importing.
asset_pipeline/importing_fonts.rst
+115
View File
@@ -0,0 +1,115 @@
Importing fonts
===============
What is a font?
---------------
Fonts in modern operating systems are created as scalable vector
graphics. They are stored as a collection of curves (usually one for
each character), which are independent of the screen resolution, and
stored in standardized file formats, such as TTF (TrueType) or OTF
(OpenType).
Rendering such fonts to bitmaps is a complex process, which employs
different methods to convert curves to pixels depending on context and
target size. Due to this, this rendering process must be done by using
the CPU. Game engines use the GPU to render, and 3D APIs don't really
support the means to do this efficiently, so fonts have to be converted
to a format that is friendly to the GPU when imported to a project.
Converting fonts
----------------
This conversion process consists of rendering a vector font to a given
point size and storing all the resulting characters in a bitmap texture.
The bitmap texture is then used by the GPU to draw a small quad for each
character and form readable strings.
.. image:: /img/bitmapfont.png
The drawback of this process is that fonts must be pre-imported in the
specific sizes that they will use in the project. However, given that
that bitmap fonts compress really well, this is not as bad as it sounds.
Importing a font
----------------
Fonts are imported via the Font import dialog. The dialog will ask for a
font, a size, some options and a target resource fie to save.
.. image:: /img/fontimport.png
The dialog is fully dynamic, which means that any change will be
reflected in the font preview window. The user ccan tweak almost every
parameter and get instant feedback on how the font will look.
Since the resulting font is a bitmap, a few more options were added to
make the imported font look even nicer. These options were added to
please graphic designers, who love putting gradients, outlines and
shadows in fonts, as well as changing all the inter-spaces available :).
The options which will be explained in the next section.
Extra spacing
~~~~~~~~~~~~~
It is possible to add more space for:
- **Characters**, the space between them can be varied.
- **"space" character**, so the distance between words is bigger.
- **Top and Bottom margins**, this changes the spacing between lines as
well as the space between the top and bottom lines and the borders.
.. image:: /img/fontspacing.png
Shadows & outline
~~~~~~~~~~~~~~~~~
Fonts can be added a shadow. For this, the font is drawn again below on
a different color and the blurred with a gaussian kernel of different
sizes. The resulting shadow can be adjusted with an exponential function
to make it softer or more like an outline. A second shadow is also
provided to create some added effects, like a bump or outline+shadow.
.. image:: /img/shadowoutline.png
Gradients
~~~~~~~~~
Gradients are also another of the visual effects that graphic designers
often use. To show how much we love them, we added those too. Gradients
can be provided as a simple curve between two colors, or a special png
file with a hand drawn gradient.
.. image:: /img/fontgradients.png
Internationalization
--------------------
Colors, shadows and gradients are beautiful, but it's time we get to
serious business. Developing games for Asian markets is a common
practice in today's globalized world and app stores.
Here's when things get tricky with using bitmap fonts. Asian alphabets
(Chinese, Japanese and Korean) contains dozens of thousands of
characters. Generating bitmap fonts with every single of them is pretty
expensive, as the resulting textures are huge. If the font size is small
enough, it can be done without much trouble, but when the fonts become
bigger, we run out of video ram pretty quickly!
To solve this, Godot allows the user to specify a text file (in UTF-8
format) where it expects to find all the characters that will be used in
the project. This seems difficult to provide at first, and more to keep
up to date, but it becomes rather easy when one realizes that the .csv
with the translations can be used as such source file (see the
[[Importing\_translations]] section). As Godot re-imports assets when
their dependencies change, both the translation and font files will be
updated and re-imported automatically if the translation csv changes.
Another cool trick for using a text file as limit of which characters
can be imported is when using really large fonts. For example, the user
might want to use a super large font, but only to show numbers. For
this, he or she writes a numbers.txt file that contains "1234567890",
and Godot will only limit itself to import data, thus saving a lot of
video memory.
asset_pipeline/importing_textures.rst
+250
View File
@@ -0,0 +1,250 @@
Importing textures
==================
Do NOT import them in most cases
--------------------------------
In most cases you **don't** want images imported when dealing with 2D
and GUI. Just copy them to the filesystem. Read the tutorial on
[[Image\_Files\|dealing with image files]] before continuing! For 3D,
textures are always imported by the 3D scene importer, so importing
those is only useful when importing a texture used for 3D that doesn't
come with the 3D scene (for example, in a shader). The flags and options
are the same as here, so reading the rest of the document might help
too.
OK, you *might* want to import them
-----------------------------------
So, if you have read the previous tutorial on the texture exporter, the
texture importer gives you more finer grained control on how textures
are imported. If you want to change flags such as repeat, filter,
mip-maps, fix edges, etc. ***PER texture***, importing them is the best
way to accomplish this (since you can't save such flags in a standard
image file).
Lack of MipMaps
---------------
Images in 3D hardware are scaled with a (bi)linear filter, but this
method has limitations. When images are shrunk too much, two problems
arise:
- **Aliasing**: Pixels are skipped too much, and the image shows
discontinuities. This decrases quality.
- **Cache Misses**: Pixels being read are too far apart, so texture
cache reads a lot more data than it should. This decreases
performance.
(Todo, find image sample of why it looks bad)
To solve this, mipmaps are created. Mipmaps are versions of the image
shrunk by half in both axis, recursively, until the image is 1 pixel of
size. When the 3D hardware needs to shrink the image, it finds the
largest mipmap it can scale from, and scales from there. This improves
performance and image quality.
.. image:: /img/mipmaps.png
Godot automatically creates mipmaps upon load for standard image files.
This process is time consuming (although not much) and makes load times
a little worse. Pre-importing the textures allows the automatic
generation of mipmaps.
Unwanted MipMaps
----------------
Remember the previous point about mipmaps? Yes, they are cool, but
mobile GPUs only support them if the textures are in power of 2
dimensions (ie 256x256 or 512x128). In these platforms, Godot will
stretch and enlarge the texture to the closest power of 2 size and then
generate the mipmaps. This process takes more of a performance hit and
it might degrade the quality a little more.
Because of this, there are some scenarios when it may be desirable to
not use them, and just use a linear filter. One of them is when working
with graphical user interfaces (GUIs). Usually they are made of large
images and don't stretch much. Even if the screen resolution is in a
larger or smaller value than original art, the amount of stretch is not
as much and the art can retain the quality. Pre-importing the textures
also allows the disabling of mipmap generation.
Blending artifacts
------------------
The `blending
equation <http://en.wikipedia.org/wiki/Alpha_compositing>`__ used by
applications like Photoshop is too complex for realtime. There are
better approximations such as `pre-multiplied
alpha <http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx?Redirected=true>`__,
but they impose more stress in the asset pipeline. In the end, we are
left with textures that have artifacts in the edges, because apps such
as Photoshop store white pixels in completely transparent areas. Such
white pixels end up showing thanks to the texture filter.
Godot has an option to fix the edges of the image (by painting invisible
pixels the same color as the visible neighbours):
.. image:: /img/fixedborder.png
However, this must be done every time the image changes. Pre-Importing
the textures makes sure that every time the original file changes, this
artifact is fixed upon automatic re-import.
Texture flags
-------------
Textures have flags. The user can choose for them to repeat or clamp to
edges (when UVs exceed the 0,0,1,1 boundary). The magnifying filter can
also be turned off (for a Minecraft-like effect). Such values can not be
edited in standard file formats (png, jpg, etc), but can be edited and
saved in Godot .tex files. Then again, the user may not want to change
the values every time the texture changes. Pre-Importing the textures
also takes care of that.
Texture compression
-------------------
Asides from the typical texture compression, which saves space on disk
(.png, jpg, etc), there are also texture compression formats that save
space in memory (more specifically video memory. This allows to have
much better looking textures in games without running out of memory, and
decrease memory bandwidth when reading them so they are a big plus.
Video texture compression formats are several and non standard. Apple
uses PVRTC. PC GPUs, consoles and nVidia Android devices use S3TC (BC),
other chipsets use other formats. OpenGL ES 3.0 standardized on ETC
format, but we are still a few years away from that working everywhere.
Still, when using this option, Godot converts and compresses to the
relevant format depending on the target platform (as long as the user
pre-imported the texture and specified video ram compression!).
This kind of compression is often not desirable for many types 2D games
and UIs because it has visible visual artifacts. This is specially
noticeable on games that use the trendy vectory social game artwork.
However, again, the fact that it saves space and improves performance
may make up for it.
The 3D scene importer always imports textures with this option turned
on.
Atlases
-------
Remember how mobile GPUs have this limitation of textures having to be
in power of 2 sizes to be able to generate mimpmaps for optimum
stretching? What if we have a lot of images in different random sizes?
All will have to be scaled and mipmapped when loaded (using more CPU and
memory) or when imported (using more memory). This is probably still ok,
but there is a tool that can help improve this situation.
Atlases are big textures that fit a lot of small textures inside
efficiently. Godot supports creating atlases in the importer, and the
imported files are just small resources that reference a region of the
bigger texture.
Atlases can be a nice solution to save some space on GUI or 2D artwork
by packing everything together. The current importer is not as useful
for 3D though (3D Atlasses are created differently, and not all 3D
models can use them).
As a small plus, atlases can decrease the amount of "state changes" when
drawing. If a lot of objects that are drawn using several different
textures are converted to atlas, then the texture rebinds per object
will go from dozens or hundreds to one. This will give the performance a
small boost.
Artists use PSD
---------------
Still wondering whether to use the texture importer or not? Remember
that in the end, artists will often use Photoshop anyway, so it may be
wiser to just let the import subsystem to take care of importing and
converting the PSD files instead of asking the artist to save a png and
copy it to the project every time.
Texture importer
----------------
Finally! It's time to take a look at the texture importer. There are 3
options in the import menu. They are pretty much (almost) the same
dialog with a different set of defaults.
.. image:: /img/importtex.png
When selected, the texture import dialog will appear. This is the
default one for 2D textures:
.. image:: /img/import_images.png
Each import option has a function, explained as follows:
Source texture(s)
~~~~~~~~~~~~~~~~~
One or more source images can be selected from the same folder (this
importer can do batch-conversion). This can be from inside or outside
the project.
Target path
~~~~~~~~~~~
A destination folder must be provided. It must be inside the project, as
textures will be converted and saved to it. Extensions will be changed
to .tex (Godot resource file for textures), but names will be kept.
Texture format
~~~~~~~~~~~~~~
This combo allows to change the texture format (compression in this
case):
.. image:: /img/compressopts.png
Each of the four options described in this table together with their
advantages and disadvantages ( |image5| = Best, |image6| =Worst ):
+----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
| | Uncompressed | Compress Lossless (PNG) | Compress Lossy (WebP) | Compress VRAM |
+================+========================+===========================+=========================+======================================================+
| Description | Stored as raw pixels | Stored as PNG | Stored as WebP | Stored as S3TC/BC,PVRTC/ETC, depending on platform |
+----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
| Size on Disk | |image7| Large | |image8| Small | |image9| Very Small | |image10| Small |
+----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
| Memory Usage | |image11| Large | |image12| Large | |image13| Large | |image14| Small |
+----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
| Performance | |image15| Normal | |image16| Normal | |image17| Normal | |image18| Fast |
+----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
| Quality Loss | |image19| None | |image20| None | |image21| Slight | |image22| Moderate |
+----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
| Load Time | |image23| Normal | |image24| Slow | |image25| Slow | |image26| Fast |
+----------------+------------------------+---------------------------+-------------------------+------------------------------------------------------+
Texture options
~~~~~~~~~~~~~~~
Provided are a small amount of options for fine grained import control:
- **Streaming Format** - This does nothing as of yet, but a texture
format for streaming different mipmap levels is planned. Big engines
have support for this.
- **Fix Border Alpha** - This will fix texture borders to avoid the
white auras created by white invisible pixels (see the rant above).
- **Alpha Bit Hint** - Godot auto-detects if the texture needs alpha
bit support for transparency (instead of full range), which is useful
for compressed formats such as BC. This forces alpha to be 0 or 1.
- **Compress Extra** - Some VRAM compressions have alternate formats
that compress more at the expense of quality (PVRTC2 for example). If
this is ticked, texture will be smaller but look worse.
- **No MipMaps** - Force imported texture to NOT use mipmaps. This may
be desirable in some cases for 2D (as explained in the rant above),
though it's NEVER desirable for 3D.
- **Repeat** - Texture will repeat when UV coordinates go beyond 1 and
below 0. This is often desirable in 3D, but may generate artifacts in
2D.
- **Filter** - Enables linear filtering when a texture texel is larger
than a screen pixel. This is usually turned on, unless it's required
for artistic purposes (minecraft look, for example).
asset_pipeline/importing_translations.rst
+86
View File
@@ -0,0 +1,86 @@
Importing translations
======================
Games and internationalization
------------------------------
The world is full of different markets and cultures and, to maximize
profits™, nowadays games are released in several languages. To solve
this, internationalized text must be supported in any modern game
engine.
In regular desktop or mobile applications, internationalized text is
usually located in resource files (or .po files for GNU stuff). Games,
however, can use several orders of magnitude more text than
applications, so they must support efficient methods for dealing with
loads of multi-language text.
There are two approaches to generate multi language games and
applications. Both are based on a key:value system. The first is to use
one of the languages as key (usually english), the second is to use a
specific identifier. The first approach is probably easier for
development if a game is released first in english, later in other
languages, but a complete nightmare if working with many languages at
the same time.
In general, games use the second approach and a unique ID is used for
each string. This allows to revise the text while it's being translated
to others. the unique ID can be a number, a string, or a string with a
number (it's just a unique string anyway).
Translators also, most of the time prefer to work with spreadsheets
(either as a Microsoft Excel file or a shared Google Spreadsheet).
Translation format
------------------
To complete the picture and allow efficient support for translations,
Godot has a special importer that can read .csv files. Both Microsoft
Excel and Google Spreadsheet can export to this format, so the only
requirement is that the files have a special format. The csv files must
be saved in utf-8 encoding and the format is as follows:
+--------+----------+----------+----------+
| | | | |
+========+==========+==========+==========+
| KEY1 | string | string | string |
+--------+----------+----------+----------+
| KEY2 | string | string | string |
+--------+----------+----------+----------+
| KEYN | string | string | string |
+--------+----------+----------+----------+
The "lang" tags must represent a language, it must be one of the `valid
locales <locales>`__ supported by the engine. The "KEY" tags must be
unique and represent a string universally (they are usually in
uppercase, to differentiate from other strings). Here's an example:
+---------+------------------+----------------+--------------+
| id | en | es | ja |
+=========+==================+================+==============+
| GREET | Hello, friend! | Hola, Amigo! | こんにちは |
+---------+------------------+----------------+--------------+
| ASK | How are you? | Cómo esta? | 元気ですか |
+---------+------------------+----------------+--------------+
| BYE | Good Bye | Adiós | さようなら |
+---------+------------------+----------------+--------------+
Import dialog
-------------
The import dialog takes a .csv file in the previously described format
and generates several compressed translation resource files inside the
project.
Selecting a .csv file autodetects the languages from the first row. and
determines which column represents which language. It is possible to
change that manually, by selecting the language for each column.
.. image:: /img/trans.png
The import dialog also can add the translation to the list of
translations to load when the game runs, specified in engine.cfg (or the
project properties). Godot allows to load and remove translations at
runtime, too.
asset_pipeline/index.rst
+4 -1
View File
@@ -4,5 +4,8 @@ Asset pipeline
.. toctree::
:maxdepth: 2
:name: asset-pipeline
general
import
export
asset_pipeline/managing_image_files.rst
+5 -5
View File
@@ -61,11 +61,11 @@ excessively:
Alpha blending
~~~~~~~~~~~~~~
The \\\ `blending
equation\\ <http://en.wikipedia.org/wiki/Alpha_compositing>`__ used by
The `blending
equation <http://en.wikipedia.org/wiki/Alpha_compositing>`__ used by
applications like Photoshop is too complex for real-time. There are
better approximations such as \\\ `pre-multiplied
alpha\\ <http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx?Redirected=true>`__,
better approximations such as `pre-multiplied
alpha <http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx?Redirected=true>`__,
but they impose more stress in the asset pipeline. In the end, we are
left with textures that have artifacts in the edges, because apps such
as Photoshop store white pixels in completely transparent areas. Such
@@ -78,7 +78,7 @@ pixels the same color as the visible neighbours):
To do this, open the image from the resources tab, or edit it from the
property editor from another node or resource, then go to the object
options and select \\"Fix Border Alpha\\", then save it.
options and select "Fix Border Alpha", then save it.
.. image:: /img/imagefixalpha.png
asset_pipeline/one-click_deploy.rst
+33
View File
@@ -0,0 +1,33 @@
One-click deploy
================
Sounds Good, What is it?
------------------------
This feature will pop up automatically once a platform is properly
configured and a supported device is connected to the computer. Since
things can go wrong at many levels (platform may not be configured
correctly, SDK may incorrectly installed, device may be improperly
configured, kitty ate the USB cable, etc.), it's good to let the user
know that it exists.
Some platforms (at the time of this writing, only Android and Blackberry
10) can detect when a USB device is connected to the computer, and offer
the user to automatically export, install and run the project (in debug
mode) on the device. This feature is called, in industry buzz-words,
"One Click Deploy" (though, it's technically two clicks...).
Steps for One Click Deploy
--------------------------
#. Configure target platform.
#. Configure device (make sure it's in developer mode, likes the
computer, usb is recognized, usb cable is plugged, etc).
#. Connect the device..
#. And Voila!
.. image:: /img/oneclick.png
Click once.. and deploy!
contributing/bug_triage_guidelines.rst
+94
View File
@@ -0,0 +1,94 @@
This page describes the typical workflow of the bug triage team aka
bugsquad when handling issues and pull requests on Godot's GitHub
repository. It is bound to evolve together with the bugsquad, so do not
hesitate to propose modifications to the following guidelines.
Issues management
=================
GitHub proposes three features to manage issues:
- Set one or several labels from a predefined list
- Set one milestone from a predefined list
- Define one contributor as "assignee" among the Godot engine
organization members
As the Godot engine organization on GitHub currently has a restricted
number of contributors and we are not sure yet to what extent we will
use it or OpenProject instead, we will not use assignees extensively for
the time being.
Labels
------
The following labels are currently defined in the Godot repository:
**Categories:**
- *Archived*: either a duplicate of another issue, or invalid. Such an
issue would also be closed.
- *Bug*: describes something that is not working properly.
- *Confirmed*: has been confirmed by at least one other contributor
than the bug reporter (typically for *Bug* reports).
The purpose of this label is to let developers know which issues are
still reproducible when they want to select what to work on. It is
therefore a good practice to add in a comment on what platform and
what version or commit of Godot the issue could be reproduced; if a
developer looks at the issue one year later, the *Confirmed* label
may not be relevant anymore.
- *Enhancement*: describes a proposed enhancement to an existing
functionality.
- *Feature request*: describes a wish for a new feature to be
implemented.
- *High priority*: the issue should be treated in priority (typically
critical bugs).
- *Needs discussion*: the issue is not consensual and needs further
discussion to define what exactly should be done to address the
topic.
The categories are used for general triage of the issues. They can be
combined in some way when relevant, e.g. an issue can be labelled *Bug*,
*Confirmed* and *High priority* at the same time if it's a critical bug
that was confirmed by several users, or *Feature request* and *Needs
discussion* if it's a non-consensual feature request, or one that is not
precise enough to be worked on.
**Topics:**
- *Buildsystem*: relates to building issues, either linked to the SCons
buildsystem or to compiler peculiarities.
- *Core*: anything related to the core engine. It might be further
split later on as it's a pretty big topic.
- *Demos*: relates to the official demos.
- *GDScript*: relates to GDScript.
- *Porting*: relates to some specific platforms.
- *Rendering engine*: relates to the 2D and 3D rendering engines.
- *User interface*: relates to the UI design.
Issues would typically correspond to only one topic, though it's not
unthinkable to see issues that fit two bills. The general idea is that
there will be specialized contributors teams behind all topics, so they
can focus on the issues labelled with their team topic.
Bug reports concerning the website or the documentation should not be
filed in GitHub but in the appropriate tool in OpenProject, therefore
such issues should be closed and archived once they have been moved to
their rightful platform.
| **Platforms:** *Android*, *HTML5*, *iOS*, *Linux*, *OS X*, *Windows*
| By default, it is assumed that a given issue applies to all platforms.
If one of the platform labels is used, it is the exclusive and the
previous assumption doesn't stand anymore (so if it's a bug on e.g.
Android and Linux exclusively, select those two platforms).
Milestones
----------
Milestones correspond to planned future versions of Godot for which
there is an existing roadmap. Issues that fit in the said roadmap should
be filed under the corresponding milestone; if they don't correspond to
any current roadmap, they should be set to *Later*. As a rule of thumb,
an issue corresponds to a given milestone if it concerns a feature that
is new in the milestone, or a critical bug that can't be accepted in any
future stable release, or anything that Juan wants to work on right now
:)
contributing/documentation_guidelines.rst
+12
View File
@@ -0,0 +1,12 @@
Documentation guidelines
========================
The following page will give you the detailed guidelines for writing
documentation : [[Documentation writing and translating guidelines]].
Help needed
-----------
We need your help on the following tasks :
- [[Reference filling work]]
contributing/documentation_writing_and_translating_guidelines.rst
+119
View File
@@ -0,0 +1,119 @@
Documentation writing and translating guidelines
================================================
This page describes the rules to follow if you want to contribute Godot
Engine by writing documentation or translating existing documentation.
What is a good documentation ?
------------------------------
A good documentation is well written in plain English and well-formed
sentences. It is clear and objective.
A documentation page is not a tutorial page. We differentiate these
concepts by these definitions :
- tutorial : a page aiming at explaining how to use one or more
concepts in Godot Editor in order to achieve a specific goal with a
learning purpose (ie. "make a simple 2d Pong game", "apply forces to
an object"...)
- documentation : a page describing precisely one and only one concept
at the time, if possible exhaustively (ie. the list of methods of the
Sprite class for example).
You are free to write the kind of documentation you wish, as long as you
respect the following rules.
Create a new wiki page
----------------------
Creating a new documentation page or tutorial page is easy. The
following rules must be respected :
- Choose a short and explicit title
- Respect the grammar and orthography
- Make use of the [[Wiki syntax]]
| Try to structure your page in order to enable users to include a page
directly in another page or even forum posts using the include wiki
syntax. For example, the syntax to include the page you are reading is
:
| !{{include(Documentation writing and translating guidelines)}}.
Titles
~~~~~~
| Please always begin pages with their name:
| ``h1. <Insert your title here>``
Also, avoid American CamelCase titles: titles' first word should begin
with a capitalized letter, and every following word should not. Thus,
this is a good example:
- Insert your title here
And this is a bad example:
- Insert Your Title Here
Only project names (and people names) should have capitalized first
letter. This is good:
- Starting up with Godot Engine
and this is bad:
- Starting up with godot engine
Note for non-English authors
----------------------------
| If you intend to create a new page in your language, you are asked to
firstly create the corresponding English page if it doesn't already
exist. **Do it even if you will not write it yourself, just leave it
blank.** Only then, create the corresponding page in your own
language. Maybe later, another contributor will translate your new
page to English.
| **Remember** : even if Godot aims at being accessible to everyone,
English is the most frequent language for documentation.
Translating existing pages
--------------------------
You are very welcome to translate existing pages from English to your
language, or from your language to English. If these guidelines were
respected, an English page already exists for every page of this wiki,
even if it is empty. To translate an existing page, please follow these
few rules :
- Respect the grammar and orthography
- Make use of the [[wiki syntax]]
- Re-use images
- Always keep the structure of the English page (if it is written yet,
follow the structure of the original language page you are
translating from).
To translate an existing page, simply copy its original content. Then,
create the new page in the section of your language, copy the English
content in it and start translating.
| Please add a line at the very beginning of your translation, linking
to the English base page you translate from :
| Traduction de ![[Godot Engine:Creating 2D Games]]
The previous link is of the form ![[:]] which enables you to add a link
to a page located in an other project. Here, "Godot Engine" is the
English project.
Important changes and discussions
---------------------------------
You are welcome to correct mistakes or styles to respect these
guidelines. However, in case of important changes, please do not start a
discussion on this page : use the forum, create a new topic with a link
to the incriminated page and start discussing there about your remarks.
Licence
-------
This wiki and every page it contains is published under the terms of the
Creative Commons By-SA 4.0.
© Juan Linietsky, Ariel Mansur and contributors - License Creative
Commons By-SA 4.0.
contributing/index.rst
+12
View File
@@ -0,0 +1,12 @@
Contributing
============
.. toctree::
:maxdepth: 1
:name: contributing
bug_triage_guidelines
documentation_guidelines
documentation_writing_and_translating_guidelines
list_of_classes_and_documenters
wiki_syntax
contributing/list_of_classes_and_documenters.rst
+365
View File
@@ -0,0 +1,365 @@
List of classes and documenters
===============================
Status list : Not started, Started, Finished, Removed
| \| Class name \| Assigned to \| Status \| Start date \| Notes \|
| \| @GDScript \| \| \|
| \| @Global Scope \| \| \|
| \| AABB \| bojidar\_bg \| Finished \|
| \| AcceptDialog \| \| \|
| \| AnimatedSprite \| \| \|
| \| AnimatedSprite3D \| \| \|
| \| Animation \| \| \|
| \| AnimationPlayer \| \| \|
| \| AnimationTreePlayer \| \| \|
| \| Area \| \| \|
| \| Area2D \| Ovnuniarchos \| Finished \| 2015/12/22 \| \|
| \| Array \| vnen \| Started \| 10/10/2015 \|
| \| AtlasTexture \| \| \|
| \| AudioServer \| Akien \| Finished \|
| \| AudioServerSW \| Akien \| Finished \|
| \| AudioStream \| Akien \| Finished \|
| \| AudioStreamMPC \| Akien \| Finished \|
| \| AudioStreamOGGVorbis \| Akien \| Finished \|
| \| AudioStreamPlayback \| Akien \| Finished \|
| \| AudioStreamSpeex \| Akien \| Finished \|
| \| BackBufferCopy \| \| \|
| \| BakedLight \| \| \|
| \| BakedLightInstance \| \| \|
| \| BakedLightSampler \| \| \|
| \| BaseButton \| \| \|
| \| BitMap \| \| \|
| \| BoneAttachment \| \| \|
| \| BoxContainer \| \| \|
| \| BoxShape \| \| \|
| \| Button \| \| \|
| \| ButtonArray \| \| \|
| \| ButtonGroup \| \| \|
| \| Camera \| \| \|
| \| Camera2D \| \| \|
| \| CanvasItem \| \| \|
| \| CanvasItemMaterial \| \| \|
| \| CanvasItemShader \| \| \|
| \| CanvasItemShaderGraph \| \| \|
| \| CanvasLayer \| \| \|
| \| CanvasModulate \| \| \|
| \| CapsuleShape \| \| \|
| \| CapsuleShape2D \| Ovnuniarchos \| Finished \| \|
| \| CenterContainer \| \| \|
| \| CheckBox \| \| \|
| \| CheckButton \| \| \|
| \| CircleShape2D \| Ovnuniarchos \| Finished \| \|
| \| CollisionObject \| \| \|
| \| CollisionObject2D \| Ovnuniarchos \| Finished \| 2015/12/22 \| \|
| \| CollisionPolygon \| \| \| \|
| \| CollisionPolygon2D \| Ovnuniarchos \| Finished \| \|
| \| CollisionShape \| \| \|
| \| CollisionShape2D \| Ovnuniarchos \| Finished \| \|
| \| Color \| \| \|
| \| ColorArray \| \| \|
| \| ColorPicker \| \| \|
| \| ColorPickerButton \| \| \|
| \| ColorRamp \| \| \|
| \| ConcavePolygonShape \| \| \|
| \| ConcavePolygonShape2D \| Ovnuniarchos \| Finished \| \|
| \| ConeTwistJoint \| \| \|
| \| ConfigFile \| \| \|
| \| ConfirmationDialog \| \| \|
| \| Container \| \| \|
| \| Control \| \| \|
| \| ConvexPolygonShape \| \| \|
| \| ConvexPolygonShape2D \| Ovnuniarchos \| Finished \| \|
| \| CubeMap \| \| \|
| \| Curve2D \| Ovnuniarchos \| Finished \|
| \| Curve3D \| Ovnuniarchos \| Finished \|
| \| DampedSpringJoint2D \| \| \|
| \| Dictionary \| \| \|
| \| DirectionalLight \| \| \|
| \| Directory \| vnen \| Started \| 11/10/2015 \|
| \| EditorFileDialog \| \| \|
| \| EditorImportPlugin \| \| \|
| \| EditorPlugin \| \| \|
| \| EditorScenePostImport \| \| \|
| \| EditorScript \| \| \|
| \| Environment \| \| \|
| \| EventPlayer \| \| \|
| \| EventStream \| \| \|
| \| EventStreamChibi \| \| \|
| \| File \| \| \|
| \| FileDialog \| \| \|
| \| FixedMaterial \| \| \|
| \| Font \| \| \|
| \| FuncRef \| \| \|
| \| GDFunctionState \| \| \|
| \| GDNativeClass \| \| \|
| \| GDScript \| \| \|
| \| Generic6DOFJoint \| \| \|
| \| Geometry \| \| \|
| \| GeometryInstance \| \| \|
| \| Globals \| \| \|
| \| GraphEdit \| StraToN \| Finished \| \| may need a tutorial. I'll
think about it. \|
| \| GraphNode \| StraToN \| Finished \| \| may need a tutorial. I'll
think about it. \|
| \| GridContainer \| \| \|
| \| GridMap \| \| \|
| \| GrooveJoint2D \| \| \|
| \| HBoxContainer \| \| \|
| \| HButtonArray \| \| \|
| \| HScrollBar \| \| \|
| \| HSeparator \| \| \|
| \| HSlider \| \| \|
| \| HSplitContainer \| \| \|
| \| HTTPClient \| \| \|
| \| HingeJoint \| \| \|
| \| IP \| \| \|
| \| IP\_Unix \| \| \|
| \| Image \| \| \|
| \| ImageTexture \| \| \|
| \| ImmediateGeometry \| \| \|
| \| Input \| \| \|
| \| InputDefault \| \| \|
| \| InputEvent \| \| \|
| \| InputEventAction \| \| \|
| \| InputEventJoyButton \| \| \|
| \| InputEventJoyMotion \| \| \|
| \| InputEventKey \| \| \|
| \| InputEventMouseButton \| \| \|
| \| InputEventMouseMotion \| \| \|
| \| InputEventScreenDrag \| \| \|
| \| InputEventScreenTouch \| \| \|
| \| InputMap \| \| \|
| \| IntArray \| \| \|
| \| InterpolatedCamera \| \| \|
| \| ItemList \| \| \|
| \| Joint \| \| \|
| \| Joint2D \| \| \|
| \| KinematicBody \| \| \|
| \| KinematicBody2D \| Ovnuniarchos \| Started \| 2015/11/23 \| \|
| \| Label \| \| \|
| \| LargeTexture \| \| \|
| \| Light \| \| \|
| \| Light2D \| \| \|
| \| LightOccluder2D \| \| \|
| \| LineEdit \| \| \|
| \| LineShape2D \| Ovnuniarchos \| Finished \| \|
| \| MainLoop \| \| \|
| \| MarginContainer \| \| \|
| \| Marshalls \| \| \|
| \| Material \| \| \|
| \| MaterialShader \| \| \|
| \| MaterialShaderGraph \| \| \|
| \| Matrix3 \| \| \|
| \| Matrix32 \| \| \|
| \| MenuButton \| \| \|
| \| Mesh \| \| \|
| \| MeshDataTool \| \| \|
| \| MeshInstance \| \| \|
| \| MeshLibrary \| \| \|
| \| MultiMesh \| \| \|
| \| MultiMeshInstance \| \| \|
| \| Mutex \| \| \|
| \| Navigation \| \| \|
| \| Navigation2D \| \| \|
| \| NavigationMesh \| \| \|
| \| NavigationMeshInstance \| \| \|
| \| NavigationPolygon \| \| \|
| \| NavigationPolygonInstance \| \| \|
| \| Nil \| \| \|
| \| Node \| \| \|
| \| Node2D \| \| \|
| \| NodePath \| \| \|
| \| OS \| \| \|
| \| Object \| \| \|
| \| OccluderPolygon2D \| \| \|
| \| OmniLight \| \| \|
| \| OptionButton \| \| \|
| \| PCKPacker \| \| \|
| \| PHashTranslation \| \| \|
| \| PackedDataContainer \| \| \|
| \| PackedDataContainerRef \| \| \|
| \| PackedScene \| \| \|
| \| PacketPeer \| \| \|
| \| PacketPeerStream \| \| \|
| \| PacketPeerUDP \| \| \|
| \| Panel \| \| \|
| \| PanelContainer \| \| \|
| \| ParallaxBackground \| \| \|
| \| ParallaxLayer \| \| \|
| \| ParticleAttractor2D \| \| \|
| \| Particles \| \| \|
| \| Particles2D \| \| \|
| \| Patch9Frame \| \| \|
| \| Path \| Ovnuniarchos \| Finished \|
| \| Path2D \| Ovnuniarchos \| Finished \|
| \| PathFollow \| Ovnuniarchos \| Finished \|
| \| PathFollow2D \| Ovnuniarchos \| Finished \|
| \| PathRemap \| \| \|
| \| Performance \| \| \|
| \| Physics2DDirectBodyState \| \| \|
| \| Physics2DDirectBodyStateSW \| \| \|
| \| Physics2DDirectSpaceState \| \| \|
| \| Physics2DServer \| \| \|
| \| Physics2DServerSW \| \| \|
| \| Physics2DShapeQueryParameters \| \| \|
| \| Physics2DShapeQueryResult \| \| \|
| \| Physics2DTestMotionResult \| \| \|
| \| PhysicsBody \| \| \|
| \| PhysicsBody2D \| Ovnuniarchos \| Finished \| 2015/12/22 \| \|
| \| PhysicsDirectBodyState \| \| \|
| \| PhysicsDirectBodyStateSW \| \| \|
| \| PhysicsDirectSpaceState \| \| \|
| \| PhysicsServer \| \| \|
| \| PhysicsServerSW \| \| \|
| \| PhysicsShapeQueryParameters \| \| \|
| \| PhysicsShapeQueryResult \| \| \|
| \| PinJoint \| \| \|
| \| PinJoint2D \| \| \|
| \| Plane \| \| \|
| \| PlaneShape \| \| \|
| \| Polygon2D \| \| \|
| \| PolygonPathFinder \| \| \|
| \| Popup \| \| \|
| \| PopupDialog \| \| \|
| \| PopupMenu \| \| \|
| \| PopupPanel \| \| \|
| \| Portal \| \| \|
| \| Position2D \| \| \|
| \| Position3D \| \| \|
| \| ProgressBar \| \| \|
| \| ProximityGroup \| \| \|
| \| Quad \| \| \|
| \| Quat \| \| \|
| \| RID \| \| \|
| \| Range \| \| \|
| \| RawArray \| \| \|
| \| RayCast \| \| \|
| \| RayCast2D \| eska \| Started \| 2015-10-16 \|
| \| RayShape \| \| \|
| \| RayShape2D \| Ovnuniarchos \| Finished \| \|
| \| RealArray \| \| \|
| \| Rect2 \| bojidar\_bg \| Finished \|
| \| RectangleShape2D \| Ovnuniarchos \| Finished \| \|
| \| Reference \| \| \|
| \| ReferenceFrame \| \| \|
| \| RegEx \| Ovnuniarchos \| Finished \| 2015-11-03 \|
| \| RemoteTransform2D \| eska \| Started \| 2015-10-16 \|
| \| RenderTargetTexture \| \| \|
| \| Resource \| \| \|
| \| ResourceImportMetadata \| \| \|
| \| ResourceInteractiveLoader \| \| \|
| \| ResourceLoader \| \| \|
| \| ResourcePreloader \| \| \|
| \| ResourceSaver \| \| \|
| \| RichTextLabel \| \| \|
| \| RigidBody \| \| \|
| \| RigidBody2D \| Ovnuniarchos \| Started \| 2015/11/23 \| \|
| \| Room \| \| \|
| \| RoomBounds \| \| \|
| \| Sample \| Akien \| Finished \|
| \| SampleLibrary \| Akien \| Finished \|
| \| SamplePlayer \| Akien \| Finished \|
| \| SamplePlayer2D \| Akien \| Finished \|
| \| SceneTree \| \| \|
| \| Script \| \| \|
| \| ScrollBar \| \| \|
| \| ScrollContainer \| \| \|
| \| SegmentShape2D \| Ovnuniarchos \| Finished \| \|
| \| Semaphore \| \| \|
| \| Separator \| \| \|
| \| Shader \| \| \|
| \| ShaderGraph \| \| \|
| \| ShaderMaterial \| \| \|
| \| Shape \| \| \|
| \| Shape2D \| Ovnuniarchos \| Finished \| \|
| \| Skeleton \| \| \|
| \| Slider \| \| \|
| \| SliderJoint \| \| \|
| \| SoundPlayer2D \| Akien \| Not started \|
| \| SoundRoomParams \| Akien \| Not started \|
| \| Spatial \| Akien \| Not started \|
| \| SpatialPlayer \| Akien \| Not started \|
| \| SpatialSamplePlayer \| Akien \| Not started \|
| \| SpatialSound2DServer \| Akien \| Not started \|
| \| SpatialSound2DServerSW \| Akien \| Not started \|
| \| SpatialSoundServer \| Akien \| Not started \|
| \| SpatialSoundServerSW \| Akien \| Not started \|
| \| SpatialStreamPlayer \| Akien \| Not started \|
| \| SphereShape \| \| \|
| \| SpinBox \| \| \|
| \| SplitContainer \| \| \|
| \| SpotLight \| \| \|
| \| Sprite \| \| \|
| \| Sprite3D \| \| \|
| \| SpriteBase3D \| \| \|
| \| SpriteFrames \| \| \|
| \| StaticBody \| \| \|
| \| StaticBody2D \| Ovnuniarchos \| Started \| 2015/11/23 \| \|
| \| StreamPeer \| \| \|
| \| StreamPeerSSL \| \| \|
| \| StreamPeerTCP \| \| \|
| \| StreamPlayer \| \| \|
| \| String \| \| \|
| \| StringArray \| \| \|
| \| StyleBox \| \| \|
| \| StyleBoxEmpty \| \| \|
| \| StyleBoxFlat \| \| \|
| \| StyleBoxImageMask \| \| \|
| \| StyleBoxTexture \| \| \|
| \| SurfaceTool \| \| \|
| \| TCP\_Server \| \| \|
| \| TabContainer \| \| \|
| \| Tabs \| \| \|
| \| TestCube \| \| \|
| \| TextEdit \| \| \|
| \| Texture \| \| \|
| \| TextureButton \| \| \|
| \| TextureFrame \| \| \|
| \| TextureProgress \| \| \|
| \| Theme \| \| \|
| \| Thread \| \| \|
| \| TileMap \| Akien \| Finished \|
| \| TileSet \| Akien \| Finished \|
| \| Timer \| Akien \| Finished \|
| \| ToolButton \| \| \|
| \| TouchScreenButton \| \| \|
| \| Transform \| \| \|
| \| Translation \| \| \|
| \| TranslationServer \| \| \|
| \| Tree \| \| \|
| \| TreeItem \| \| \|
| \| Tween \| \| \|
| \| UndoRedo \| \| \|
| \| VBoxContainer \| \| \|
| \| VButtonArray \| \| \|
| \| VScrollBar \| \| \|
| \| VSeparator \| \| \|
| \| VSlider \| \| \|
| \| VSplitContainer \| \| \|
| \| Vector2 \| bojidar\_bg \| Finished \|
| \| Vector2Array \| bojidar\_bg \| Finished \|
| \| Vector3 \| bojidar\_bg \| Finished \|
| \| Vector3Array \| bojidar\_bg \| Finished \|
| \| VehicleBody \| \| \|
| \| VehicleWheel \| \| \|
| \| VideoPlayer \| \| \|
| \| VideoStream \| \| \|
| \| Viewport \| \| \|
| \| ViewportSprite \| \| \|
| \| VisibilityEnabler \| \| \|
| \| VisibilityEnabler2D \| \| \|
| \| VisibilityNotifier \| \| \|
| \| VisibilityNotifier2D \| \| \|
| \| VisualInstance \| \| \|
| \| VisualServer \| \| \|
| \| WeakRef \| \| \|
| \| WindowDialog \| \| \|
| \| World \| \| \|
| \| World2D \| \| \|
| \| WorldEnvironment \| \| \|
| \| XMLParser \| \| \|
| \| YSort \| eska \| Started \| 2015-10-16 \|
| \| bool \| \| \|
| \| float \| \| \|
| \| int \| \| \|
contributing/wiki_syntax.rst
+4
View File
@@ -0,0 +1,4 @@
Wiki Syntax
===========
This page is a helper for Wiki syntax. TODO.
img/3dimp_blender.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 34 KiB

img/3dimp_menu.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

img/3dimp_portal.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

img/3dmesh_instance.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

img/Control.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 95 KiB

img/Node2D.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 63 KiB

img/Object.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 127 KiB

img/Reference.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 195 KiB

img/Spatial.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 89 KiB

img/activescene.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

img/add_crt.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

img/addedlabel.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

img/addglobal.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

img/addscript.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.7 KiB

img/anchors.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 123 KiB

img/androidsdk.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

img/animation.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

img/animedit.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

img/animeditor.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

img/animnew.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.6 KiB

img/animpanel.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

img/animplayer.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

img/area2dcoin.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.7 KiB

img/autoplay.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.7 KiB

img/bitmapfont.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.0 KiB

img/brainslug.jpg
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

img/button_connections.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

img/canvaslayers.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

img/changed.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

img/changes.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.7 KiB

img/chef.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 83 KiB

img/clearcolor.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

img/collision_inheritance.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.8 KiB

img/compressopts.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.3 KiB

img/continst.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

img/continstanced.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 76 KiB

img/controot.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

img/createnode.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

img/ctrl_normal.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

img/ctrl_tapped.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

img/decomposed.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

img/edit_scheme.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 139 KiB

img/editor.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

img/editorsettings.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.2 KiB

img/export.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.6 KiB

img/export_dialog.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

img/export_error.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.4 KiB

img/exportimages.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

img/expres.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

img/expselected.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

img/exptemp.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.2 KiB

img/fixed_material_alpha.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

img/fixed_material_blend.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

img/fixed_material_colors.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 103 KiB

img/fixed_material_detail.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 269 KiB

img/fixed_material_glow.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

img/fixed_material_normal_depth.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 346 KiB

img/fixed_material_shader.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 109 KiB

img/fixed_material_vcols.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 79 KiB

img/fixed_materials.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

Some files were not shown because too many files have changed in this diff Show More