lotsa stuff
51
advanced.md
Normal file
@ -0,0 +1,51 @@
|
||||
# Advanced Topics
|
||||
|
||||
## Compiling & Running
|
||||
|
||||
|
||||
* [Windows](compiling_windows) Compiling under Windows.
|
||||
|
||||
* [Linux](compiling_linux) Compiling under Linux (or other Unix variants).
|
||||
|
||||
* [OSX](compiling_osx) Compiling under Apple OSX.
|
||||
|
||||
* [Android](compiling_android) Compiling for Android.
|
||||
|
||||
* [iOS](compiling_ios) Compiling for iOS.
|
||||
|
||||
* [QNX](compiling_qnx) Compiling for BlackBerry QNX.
|
||||
|
||||
* [NaCl](compiling_nacl) Compiling for Google Native Client.
|
||||
|
||||
* [Compiler Flags](compiling_flags) General Compiler Flags.
|
||||
|
||||
## File Formats
|
||||
|
||||
|
||||
* [XML File](xml_file) XML file format for resources.
|
||||
|
||||
* [Shader File](shader_file) External shader file (.shader).
|
||||
|
||||
* [Theme File](theme_file) External theme (skin) file format.
|
||||
|
||||
* [Config File](engine_cfg) Global engine and project settings file (engine.cfg).
|
||||
|
||||
## Extending the Engine in C++
|
||||
|
||||
|
||||
* [Custom Modules](custom_modules) Creating custom modules in C++.
|
||||
|
||||
* [Resource Loader](add_resource) Adding a new resource loader.
|
||||
|
||||
* [Script Language](add_script_lang) Adding a new scripting language.
|
||||
|
||||
* [Server](add_server) Adding a new server (physics engine, rendering backend, etc).
|
||||
|
||||
* [Platform](add_platform) Porting the engine to a new platform.
|
||||
|
||||
## Misc
|
||||
|
||||
|
||||
* [Command Line](command_line) Using the command line, for fans of doing everything in Unix/Windows shell.
|
||||
|
||||
* [External Editor](external_editor) Configuring an external editor for opening scripts.
|
81
command_line.md
Normal file
@ -0,0 +1,81 @@
|
||||
# Command Line Tutorial
|
||||
|
||||
Some developers like using the command line extensively. Godot is designed to be friendly to them, so here are the steps for working entirely from the command line. Given the engine relies on little to no external libraries, initialization times are pretty fast, making it suitable for this workflow.
|
||||
|
||||
### Path
|
||||
|
||||
It is recommended that your godot binary is in your path, so it can be executed easily from any place by typing "godot".
|
||||
|
||||
### Creating a Project
|
||||
|
||||
Creating a project from the command line is simple, just navigate the shell to the desired place and just make an engine.cfg file exist, even if empty.
|
||||
|
||||
```
|
||||
|
||||
user@host:~$ mkdir newgame
|
||||
user@host:~$ cd newgame
|
||||
user@host:~/newgame$ touch engine.cfg
|
||||
|
||||
```
|
||||
|
||||
That alone makes for an empty Godot project.
|
||||
|
||||
### Running the Editor
|
||||
|
||||
Running the editor is done by executing godot with the '-e' flag. This must be done from within the project directory, or a subdirectory, otherwise the command is ignored and the project manager appears.
|
||||
|
||||
```
|
||||
user@host:~/newgame$ godot -e
|
||||
```
|
||||
|
||||
If a scene has been created and saved, it can be edited later by running the same code with that scene as argument.
|
||||
|
||||
```
|
||||
user@host:~/newgame$ godot -e scene.xml
|
||||
```
|
||||
|
||||
### Erasing a Scene
|
||||
|
||||
Godot is friends with your filesystem, and will not create extra metadata files, simply use ´rm' to erase a file. Make sure nothing references that scene, or else an error will be thrown upon opening.
|
||||
|
||||
```
|
||||
user@host:~/newgame$ rm scene.xml
|
||||
```
|
||||
|
||||
### Running the Game
|
||||
|
||||
To run the game, simply execute Godot within the project directory or subdirectory.
|
||||
|
||||
```
|
||||
user@host:~/newgame$ godot
|
||||
```
|
||||
|
||||
When a specific scene needs to be tested, pass that scene to the command line.
|
||||
|
||||
```
|
||||
user@host:~/newgame$ godot scene.xml
|
||||
```
|
||||
|
||||
### Debugging
|
||||
|
||||
Catching errors in the command line can be a difficult task because they just fly by. For this, a command line debugger is provided by adding '-d'. It works for both running the game or a simple scene.
|
||||
|
||||
```
|
||||
user@host:~/newgame$ godot -d
|
||||
```
|
||||
|
||||
```
|
||||
user@host:~/newgame$ godot -d scene.xml
|
||||
```
|
||||
|
||||
### Exporting
|
||||
|
||||
Exporting the project from the command line is also supported. This is specially useful for continuous integration setups. The version of Godot that is headless (no video) is ideal for this.
|
||||
|
||||
```
|
||||
user@host:~/newgame$ godot -export Windows /var/builds/project.exe
|
||||
user@host:~/newgame$ godot -export Android /var/builds/project.apk
|
||||
```
|
||||
|
||||
|
||||
|
54
compiling_android.md
Normal file
@ -0,0 +1,54 @@
|
||||
# Note
|
||||
|
||||
For most cases, using the built in deployer and export templates is good enough. Compiling the Android APK manually is mostly useful for custom builds or custom packages for the deployer.
|
||||
|
||||
# Requirements
|
||||
|
||||
For compiling under Windows, the following is requiered:
|
||||
|
||||
|
||||
* Python 2.7+ (3.0 is untested as of now).
|
||||
|
||||
* SCons build system.
|
||||
|
||||
* Android SDK version 8 and 13
|
||||
|
||||
* Android NDK
|
||||
|
||||
# Setting Up SCons
|
||||
|
||||
Set the environment variable ANDROID_HOME to point to the Android SDK.
|
||||
Set the environment variable ANDROID_NDK_ROOT to point to the Android NDK.
|
||||
|
||||
# Compiling
|
||||
|
||||
Go to the root dir of the engine source code and type:
|
||||
```
|
||||
C:\godot> scons platform/android/libgodot_android.so
|
||||
```
|
||||
|
||||
Copy the .so to the libs Android folder (or symlink if you are in Linux or OSX)
|
||||
|
||||
```
|
||||
C:\godot> cp platform/android/libgodot_android.so platform/android/java/libs
|
||||
|
||||
alternatively:
|
||||
|
||||
user@host:~/godot$ ln -s platform/android/libgodot_android.so platform/android/java/libs
|
||||
|
||||
```
|
||||
|
||||
Go to the java folder and run ant
|
||||
|
||||
```
|
||||
C:\godot\platform\android\java> ant debug
|
||||
or
|
||||
C:\godot\platform\android\java> ant release
|
||||
|
||||
```
|
||||
|
||||
In the java/bin subfolder, the resulting apk can be used as a custom export template.
|
||||
|
||||
If you intend to simply build the game manually and not use export template, copy or symlink the game content into the java/assets/ folder, so engine.cfg is at the root of java/assets.
|
||||
|
||||
|
41
compiling_flags.md
Normal file
@ -0,0 +1,41 @@
|
||||
# General Compiler Flags
|
||||
|
||||
Godot is usually compiled by calling:
|
||||
|
||||
```
|
||||
|
||||
scons <binary>
|
||||
|
||||
```
|
||||
|
||||
There are a few extra flags that can be used which work in most platforms:
|
||||
|
||||
### Tools
|
||||
|
||||
Tools are added by default. Disabling tools produces a binary that can run projects but that does not include the editor or the project manager.
|
||||
|
||||
```
|
||||
|
||||
scons <binary> tools=yes/no
|
||||
|
||||
```
|
||||
|
||||
### Target
|
||||
|
||||
Target controls optimization and debug flags. Each mode means:
|
||||
|
||||
|
||||
* **debug**: Build with C++ debugging symbols, runtime checks (performs checks and reports error) and none to little optimization.
|
||||
|
||||
* **release_debug**: Build without C++ debugging symbols and optimization, but keep the runtime checks (performs checks and reports errors)
|
||||
|
||||
* **release**: Build without symbols, with optimization and with little to no runtime checks.
|
||||
|
||||
|
||||
```
|
||||
|
||||
scons <binary> target=debug/release_debug/release
|
||||
|
||||
```
|
||||
|
||||
|
29
compiling_linux.md
Normal file
@ -0,0 +1,29 @@
|
||||
# Requirements
|
||||
|
||||
For compiling under Linux or other Unix variants, the following is requiered:
|
||||
|
||||
|
||||
* GCC or LLVM
|
||||
|
||||
* Python 2.7+ (3.0 is untested as of now).
|
||||
|
||||
* SCons build system.
|
||||
|
||||
* X11 and MESA development Libraries
|
||||
|
||||
* ALSA development libraries
|
||||
|
||||
* Freetype (for the editor)
|
||||
|
||||
* pkg-config (used to detect the above three)
|
||||
|
||||
* **Ubuntu Users:** apt-get install scons pkg-config libx11-dev libxcursor-dev build-essential libasound2-dev libfreetype6-dev libgl1-mesa-dev libglu-dev
|
||||
|
||||
# Compiling
|
||||
|
||||
Start a terminal, go to the root dir of the engine source code and type:
|
||||
```
|
||||
user@host:~/godot$ scons bin/godot
|
||||
```
|
||||
|
||||
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.
|
20
compiling_osx.md
Normal file
@ -0,0 +1,20 @@
|
||||
# Requirements
|
||||
|
||||
For compiling under Linux or other Unix variants, the following is requiered:
|
||||
|
||||
|
||||
* Python 2.7+ (3.0 is untested as of now).
|
||||
|
||||
* SCons build system.
|
||||
|
||||
* XCode
|
||||
|
||||
# Compiling
|
||||
|
||||
Start a terminal, go to the root dir of the engine source code and type:
|
||||
```
|
||||
user@host:~/godot$ scons bin/godot_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 tools/Godot.app.
|
||||
|
16
compiling_server.md
Normal file
@ -0,0 +1,16 @@
|
||||
# Compiling for Unix (Headless)
|
||||
|
||||
### Use Case
|
||||
|
||||
|
||||
Godot is mainly used for creating client-side games and applications. However, there are many scenarios where a headless (no display or audio) version might be required, such as:
|
||||
|
||||
|
||||
* Automated Scripts (Running single scripts with a specific purpose)
|
||||
|
||||
* Automated Export (Exporting a project for a specific platform, useful for continuous integration)
|
||||
|
||||
* Running a server accepting connections (Godot is perfectly capable of running as a server).
|
||||
|
||||
### Compiling
|
||||
|
35
compiling_windows.md
Normal file
@ -0,0 +1,35 @@
|
||||
# Requirements
|
||||
|
||||
For compiling under Windows, the following is requiered:
|
||||
|
||||
|
||||
* [Visual C++](http://www.microsoft.com/visualstudio) Visual C++ or Visual C++ Express compiler.
|
||||
|
||||
* [Python 2.7+](http://www.python.org/getit/releases/2.7/) Python 2.7+ (3.0 is untested as of now). Using the 32-bits installer is recommended.
|
||||
|
||||
* [SCons](http://www.scons.org) SCons 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.
|
||||
|
||||
|
||||
# Compiling
|
||||
|
||||
Start a Visual Studio command prompt (it sets up environment variables needed by SCons to locate the compiler and SDK), go to the root dir of the engine source code and type:
|
||||
```
|
||||
C:\godot> scons bin/godot.exe
|
||||
```
|
||||
|
||||
If all goes well, the resulting binary executable will be placed in C:\godot\bin\godot_win.exe. This executable file contains the whole engine and runs without any dependencies. Executing it will bring up the project manager.
|
||||
|
||||
# Development in Visual Studio or other IDEs
|
||||
|
||||
For most projects, using only scripting is enough but when development in C++ is needed, for creating modules or extending the engine, working with an IDE is usually desirable. The visual studio command prompt calls a .bat file that sets up environment variables (vcvarsall.bat). To build the whole engine from a single command outside the command prompt, the following should be called in a .bat file:
|
||||
```
|
||||
C:\path_to_sdk\vcvarsall.bat && scons bin/godot_win.exe
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
1
editor_plugin.md
Normal file
@ -0,0 +1 @@
|
||||
la clase y como hacer undo y redo
|
86
export.md
Normal file
@ -0,0 +1,86 @@
|
||||
## 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:
|
||||
|
||||
<p align="center"><img src="images/export.png"></p>
|
||||
|
||||
The dialog will open, showing all the supported export platforms:
|
||||
|
||||
<p align="center"><img src="images/export_dialog.png"></p>
|
||||
|
||||
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:
|
||||
|
||||
<p align="center"><img src="images/export_error.png"></p>
|
||||
|
||||
At thas 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 .zip file from the wiki.
|
||||
|
||||
Once downloaded, they can be installed using the "Install Export Templates" option in the editor:
|
||||
|
||||
|
||||
<p align="center"><img src="images/exptemp.png"></p>
|
||||
|
||||
### 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)
|
||||
|
||||
<p align="center"><img src="images/expres.png"></p>
|
||||
|
||||
#### Export every single file
|
||||
|
||||
This mode exports every single file in the project. This is good to test if something is being forgotten, but developers often have a lot of unrelated stuff around in the dev dir, which makes it a bad idea.
|
||||
|
||||
#### Export only resources
|
||||
|
||||
Only resources are exported. For most projects, this is enough. However many developers like to use custom datafiles in their games. To compensate for this, filters can be added for extra extensions (like, *.txt, *.csv, etc).
|
||||
|
||||
#### Export only selected resources
|
||||
|
||||
Only select resources from a list are exported. This is probably overkill for most projects, but in some cases it is justified (usually huge projects). This mode offers total control of what is exported. Individual resources can be selected and dependency detection is performed to ensure that everything needed is added. As a plus, this mode allows to "Bundle" scenes and dependencies into a single file, which is *really* useful for games distributed on optical media.
|
||||
|
||||
|
||||
<p align="center"><img src="images/expselected.png"></p>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
47
export_android.md
Normal file
@ -0,0 +1,47 @@
|
||||
## 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).
|
||||
|
||||
<p align="center"><img src="images/editorsettings.png"></p>
|
||||
|
||||
Scroll down to the section where the Android settings are located:
|
||||
|
||||
<p align="center"><img src="images/androidsdk.png"></p>
|
||||
|
||||
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!
|
||||
|
41
export_ios.md
Normal file
@ -0,0 +1,41 @@
|
||||
## 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 XCode project template: http://www.godotengine.org/builds/release/GodotiOSXCode.zip
|
||||
|
||||
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, [export your project for Windows](export_pc), to obtain the "data.pck" file. Replace the empty data.pck on 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 the Info.plist, with the name of your directory as its value.
|
||||
|
||||
{{: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 right-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).
|
||||
|
||||
{{: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.
|
||||
|
||||
{{: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.
|
||||
|
15
export_pc.md
Normal 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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
505
gdscript.md
Normal file
@ -0,0 +1,505 @@
|
||||
# Introduction
|
||||
|
||||
GDScript is a high level, dynamically typed programming language used to create content. It uses a syntax that is very similar to the Python language (blocks are indent-based) and it’s goal is to be very optimal and tigthly integrated with the engine, allowing great flexibility for content creation and integration.
|
||||
|
||||
# History
|
||||
|
||||
Initially, Godot was designed to support multiple scripting languages (this ability still exists today). However, only GDScript is in use right now. There is a little history behind this.
|
||||
|
||||
In the early days, the engine used the [Lua](http://www.lua.org/) scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with [Python](http://www.python.org/), it also proved difficult to embed.
|
||||
|
||||
The last third party scripting language that was used for shipped games was [Squirrel](http://squirrel-lang.org/), but it was also dropped too. At that point, it became evident that Godot would work more optimally by using a built-in scripting language, as the following barriers were met:
|
||||
|
||||
|
||||
* Godot embeds scripts in nodes, most languages are not designed with this in mind.
|
||||
|
||||
* Godot uses several built-in datatypes for 2D and 3D math, script languages do not provide this, and binding them is inefficient.
|
||||
|
||||
* Godot uses threads heavily for lifting and initializing data from the net or disk, script interpreters for common languages are not friendly to this.
|
||||
|
||||
* Godot already has a memory management model for resources, most script languages provide their own, which resulted in duplicate effort and bugs.
|
||||
|
||||
* Binding code is always messy and results in several failure points, unexpected bugs and general unmaintaniability.
|
||||
|
||||
Finally, GDScript was written. The language and interpreter for it ended up being smaller than the binding code itself for Lua and Squirrel, and equally as functional. With time, having a built in language ended up being a huge advantage.
|
||||
|
||||
# Example
|
||||
|
||||
Some people can learn better by just taking a look at the syntax, so here’s a simple example of how it looks.
|
||||
|
||||
```python#a file is a class!
|
||||
|
||||
# inheritance
|
||||
|
||||
extends BaseClass
|
||||
|
||||
# member variables
|
||||
|
||||
var a=5
|
||||
var s="Hello"
|
||||
var arr=[1,2,3]
|
||||
var dict={"key":"value", 2:3}
|
||||
|
||||
# constants
|
||||
|
||||
const answer=42
|
||||
const thename="Charly"
|
||||
|
||||
# built-in vector types
|
||||
|
||||
var v2 = Vector2(1,2)
|
||||
var v3 = Vector3(1,2,3)
|
||||
|
||||
# function
|
||||
|
||||
func some_function(param1,param2):
|
||||
var local_var=5
|
||||
|
||||
if param1 < local_var:
|
||||
print(param1)
|
||||
elif param2 > 5:
|
||||
print(param2)
|
||||
else:
|
||||
print("fail!")
|
||||
|
||||
for i in range(20):
|
||||
print(i)
|
||||
|
||||
while(param2!=0):
|
||||
param2-=1
|
||||
|
||||
var local_var2 = param1+3
|
||||
return local_var2
|
||||
|
||||
|
||||
# subclass
|
||||
|
||||
class Something:
|
||||
var a=10
|
||||
|
||||
# constructor
|
||||
|
||||
func _init():
|
||||
print("constructed!")
|
||||
var lv = Something.new()
|
||||
print(lv.a)
|
||||
|
||||
#pass
|
||||
|
||||
|
||||
func emptyfunc():
|
||||
pass # pass does nothing, allows an empty function
|
||||
|
||||
```
|
||||
|
||||
# Language
|
||||
|
||||
## Identifiers
|
||||
|
||||
Any string that restricts itself to alphabetic characters (’a’ to ’z’ and ’A’ to ’Z’), digits (’0’ to ’9’) and ’_’ qualifies as an identifier. As an extra restriction, identifiers must not begin with a digit. Identifiers are case-sensitive (’foo’ is different to ’FOO’).
|
||||
|
||||
## Keywords
|
||||
|
||||
The following is the list of keywords supported by the language. Since keywords are reserved words (tokens), they can’t be used as identifiers:
|
||||
|
||||
**and break class const continue elif else enum export extends false for func if in null or pass return self tool true var while**
|
||||
|
||||
## Operators
|
||||
|
||||
The following is the list of supported operators and their precedence (TODO, change since this was made to reflect python operators)
|
||||
|
||||
| Operator | Description |
|
||||
| -------- | ----------- |
|
||||
| %%x[index]%% | Subscription, Highest Priority |
|
||||
| x.attribute | Attribute Reference |
|
||||
| extends | Instance Type Checker |
|
||||
| %%~%% | Bitwise NOT |
|
||||
| -x | Negative |
|
||||
| * / % | Mult / Div / Remainder |
|
||||
| + - | Addition / Substraction |
|
||||
| %%<< >>%% | Bit Shifting |
|
||||
| & | Bitwise AND |
|
||||
| %%^%% | Bitwise XOR |
|
||||
| %% | %% | Bitwise OR |
|
||||
| %%< > == != >= <=%% | Comparisons |
|
||||
| in | Content Test |
|
||||
| %%! not%% | Boolean NOT |
|
||||
| and && | Boolean AND |
|
||||
| or %% | | %% | Boolean OR |
|
||||
| %%= += -= *= /= %= &= | =%% | Assignment, Lowest Priority |
|
||||
|
||||
## Literals
|
||||
|
||||
| Literal | Name |
|
||||
| ------- | ---- |
|
||||
| 45 | Base 10 Integer |
|
||||
| 0x8F51 | Base 16 (hex) Integer |
|
||||
| 3.14, 58.1e-10 | Floating Point Number (real) |
|
||||
| ’Hello’, “Hi” | Strings |
|
||||
| @"Node/Label" | Node Path or StringName |
|
||||
|
||||
## Comments
|
||||
|
||||
Anything from a ’#’ to the end of the line is ignored and is considered a comment.
|
||||
|
||||
```python
|
||||
# This is a comment```
|
||||
|
||||
# Built-in Types
|
||||
|
||||
## Basic Bult-In Types
|
||||
|
||||
A variable in GDScript can be assigned many of several built-in types.
|
||||
|
||||
### null
|
||||
|
||||
’null’ is a data type that contains no information, nothing assigned, and it’s just empy. It can only be set to one value: ’null’.
|
||||
|
||||
### bool
|
||||
|
||||
Boolean data type, can only contain ’true’ or ’false’.
|
||||
|
||||
### int
|
||||
|
||||
Integer data type, can only contain integer numbers, negative and positive.
|
||||
|
||||
### float
|
||||
|
||||
contains a floating point value (real).
|
||||
|
||||
### String
|
||||
|
||||
Sequence of characters in unicode format. Strings can contain the standard C escape sequences.
|
||||
|
||||
## Vector Built-In Types
|
||||
|
||||
### Vector2/Size2
|
||||
|
||||
2D vector type, containing x and y fields. Can alternatively access fields as width and height for readability. Can also be accessed as array.
|
||||
|
||||
### Rect2
|
||||
|
||||
2D Rectangle type. Contains 2 vectors fields, “pos” and size’’. Alternatively contains an “end” field which is “pos+size”.
|
||||
|
||||
### Vector3
|
||||
|
||||
3D vector type. Contains x, y and z fields. Can also be accessed as array.
|
||||
|
||||
### Matrix32
|
||||
|
||||
3x2 matrix used for 2D transforms.
|
||||
|
||||
### Plane
|
||||
|
||||
3D Plane type in normalized form. Contains a “normal” vector field and a “d” scalar distance.
|
||||
|
||||
### Quat
|
||||
|
||||
Quaternion, datatype used for representing a 3D rotation. It’s useful for interpolating rotations.
|
||||
|
||||
### AABB/Box3
|
||||
|
||||
Axis Aligned bounding box (or alternatively, 3D box). Contains 2 vectors fields, “pos” and size’’. Alternatively contains an “end” field which is “pos+size”.
|
||||
|
||||
### Matrix3
|
||||
|
||||
3x3 matrix used for 3D rotation and scale. Contains 3 vector fields x,y and z. Can also be accessed as array of 3D vectors.
|
||||
|
||||
### Transform
|
||||
|
||||
3D Transform, contains a Matrix3 field “basis” and a Vector3 field “origin”.
|
||||
|
||||
## Engine Built-In Types
|
||||
|
||||
### Color
|
||||
|
||||
Color datatype, contains r,g,b,a fields. Can also be accessed as h,s,v for hue/saturation/value.
|
||||
|
||||
### Image
|
||||
|
||||
Contains a 2D Image of custom format and allows direct access to the pixels.
|
||||
|
||||
### NodePath
|
||||
|
||||
Compiled path to a node, used mainly in the scene system. Can be easily asigned from/to a String.
|
||||
|
||||
### RID
|
||||
|
||||
Resource ID (RID). Servers use generic RIDs to reference opaque data.
|
||||
|
||||
### Object
|
||||
|
||||
Base class for anything not a built-in type.
|
||||
|
||||
### InputEvent
|
||||
|
||||
Events from input devices are contained in very compact form in InputEvent objects. Due to fact they can be received in high amounts from frame to frame, they are optimized in their own datatype.
|
||||
|
||||
## Container Built-In Types
|
||||
|
||||
### Array
|
||||
|
||||
Generic sequence of objects. It’s size can be changed to anything and starts from index 0.
|
||||
|
||||
```pythonvar arr=[]
|
||||
arr=[1,2,3]
|
||||
arr[0]="Hi!"```
|
||||
Arrays are allocated linearly in memory, so they are fast, but very large arrays (more than tens of thousands of elements) may cause fragmentation.
|
||||
|
||||
There are specialized arrays (listed below) for some built-in datatypes which do not suffer from this and use less memory, but they are atomic and generally run a little slower, so they are only justified for very large amount of data.
|
||||
|
||||
### Dictionary
|
||||
|
||||
Associative container which contains values referenced by unique keys.
|
||||
|
||||
```pythonvar d={4:5, "a key":"a value", 28:[1,2,3]}
|
||||
d["Hi!"]=0
|
||||
```
|
||||
|
||||
Lua-style table syntax is also supported, given it's easier to write and read:
|
||||
|
||||
```python
|
||||
|
||||
var d= {
|
||||
somekey=2,
|
||||
otherkey=[2,3,4],
|
||||
morekey="Hello"
|
||||
}
|
||||
```
|
||||
|
||||
### ByteArray
|
||||
|
||||
Array of bytes. Can only contains bytes (integers from 0 to 255). Optimized for memory usage, can’t fragment the memory.
|
||||
|
||||
### IntArray
|
||||
|
||||
Array of integers. Can only contain integers. Optimized for memory usage, can’t fragment the memory.
|
||||
|
||||
### FloatArray
|
||||
|
||||
Array of floats, can only contain floats. Optimized for memory usage, can’t fragment the memory.
|
||||
|
||||
### StringArray
|
||||
|
||||
Array of strings, can only contain strings. Optimized for memory usage, can’t fragment the memory.
|
||||
|
||||
### Vector2Array
|
||||
|
||||
Array of Vector2, can only contain 2D Vectors. Optimized for memory usage, can’t fragment the memory.
|
||||
|
||||
### Vector3Array
|
||||
|
||||
Array of Vector3, can only contain 3D Vectors. Optimized for memory usage, can’t fragment the memory.
|
||||
|
||||
### ColorArray
|
||||
|
||||
Array of Color, can only contains colors. Optimized for memory usage, can’t fragment the memory.
|
||||
|
||||
# Data
|
||||
|
||||
## Variables
|
||||
|
||||
Variables can exist as class members or local to functions. They are created with the “var” keyword and may be, optionally, be assigned a value upon initialization.
|
||||
|
||||
```pythonvar a # datatype is null by default
|
||||
var b = 5
|
||||
var c = 3.8
|
||||
var d = b+c # variables are always initialized in order```
|
||||
## Constants
|
||||
|
||||
Constants are similar to variables, but must be constants or constant expressions and must be assigned on initialization.
|
||||
|
||||
```pythonconst a = 5
|
||||
const b = Vector2(20,20)
|
||||
const c = 10+20 # constant expression
|
||||
const d = Vector2(20,30).x # constant expression: 20
|
||||
const e = [1,2,3,4][0] # constant expression: 1
|
||||
const f = sin(20) # sin() can be used in constant expression
|
||||
const g = x+20 # invalid, not a constant expression!```
|
||||
## Functions
|
||||
|
||||
Functions always belong to a class. The scope priority for variable look-up is: local -> class member -> global. “self” is provided as an option for accessing class members but is not required always (and must *not* be defined as first parameter, like in Python). For performance reasons, functions are not considered class members, so they can’t be referenced directly. A function can return at any point. The default return value is null.
|
||||
|
||||
```pythonfunc myfunction(a,b):
|
||||
print(a)
|
||||
print(b)
|
||||
return a+b # return is optional, otherwise null is returned```
|
||||
### Statements and Control Flow
|
||||
|
||||
Statements are standard, and can be assignments, function calls, control flow structures, etc (see below). “;” as separator is entirely optional.
|
||||
|
||||
### if/else/elif
|
||||
|
||||
Simple conditions are created by using the *if/else/elif* syntax. Parenthesis around statements is allowed but not requiered. Given the nature of the tab-based indentation, elif can be used instead of else:/if: to mantain a level of indentation.
|
||||
|
||||
```pythonif [expression]:
|
||||
statement(s)
|
||||
elif [expression]:
|
||||
statement(s)
|
||||
else:
|
||||
statement(s)```
|
||||
### while
|
||||
|
||||
Simple loops are created by using *while* syntax. Loops can be broken using *break*, or continued using *continue*:
|
||||
|
||||
```pythonwhile [expression]:
|
||||
statement(s)```
|
||||
### for
|
||||
|
||||
To iterate a range, array or table a *for* loop is used. For loops store the index in the loop variable on each iteration.
|
||||
|
||||
```pythonfor i in [0,1,2]:
|
||||
statement # loop iterates 3 times, i being 0,1 and 2
|
||||
|
||||
var dict = {"a":0, "b":1, "c": 2}
|
||||
for i in dict:
|
||||
print(dict[i]) # loop iterates the keys, i being "a","b" and c". It prints 0, 1 and 2.
|
||||
|
||||
for i in range(3):
|
||||
statement # similar to [0,1,2] but does not allocate an array
|
||||
|
||||
for i in range(1,3):
|
||||
statement # similar to [1,2] but does not allocate an array
|
||||
|
||||
for i in range(2,8,2):
|
||||
statement # similar to [2,4,6] but does not allocate an array```
|
||||
# Classes
|
||||
|
||||
By default, the body of a script file is an unnamed class, and it can only be referenced externally as a resource or file. Class syntax is meant to be very compact and can only contain member variables or functions. Static functions are allowed, but not static members (in the spirit of thread safety, since scripts can be initialized in separate threads without the user knowing). In the same way, member variables (including arrays and dictionaries) are initialized every time an instance is created.
|
||||
|
||||
## Class File Example
|
||||
|
||||
Example of a class file, imagine it being stored in a file like myclass.gd.
|
||||
|
||||
```pythonvar a=5
|
||||
|
||||
func print_value_of_a():
|
||||
print(a)```
|
||||
## Inheritance
|
||||
|
||||
A class-file can inherit from a global class, another file or a subclass inside another file. Multiple inheritance is not allowed. The “extends” syntax is used:
|
||||
|
||||
```python# extend from some class (global)
|
||||
extends SomeClass
|
||||
|
||||
# optionally, extend from another file
|
||||
|
||||
extends "somefile.gd"
|
||||
|
||||
# extend from a subclass in another file
|
||||
|
||||
extends "somefile.gd".Subclass ```
|
||||
## Inheritance Testing
|
||||
|
||||
It is possible to check if an instance inherits from a given class. For this the “extends” keyword can be used as an operator instead:
|
||||
|
||||
```pythonconst enemy_class = preload("enemy.gd") # cache the enemy class
|
||||
|
||||
[..]
|
||||
|
||||
if ( entity extends enemy_class ):
|
||||
entity.apply_damage()```
|
||||
## Constructor
|
||||
|
||||
A class can have an optional constructor, a function named “_init” that is called when the class is instanced.
|
||||
|
||||
## Sub Classes
|
||||
|
||||
A class file can have subclasses. Syntax should be straightforward:
|
||||
|
||||
```pythonclass SomeSubClass:
|
||||
var a=5
|
||||
func print_value_of_a():
|
||||
print(a)
|
||||
|
||||
func _init():
|
||||
var sc = SomeSubClass.new() #instance by calling built-in new
|
||||
sc.print_value_of_a()```
|
||||
## Classes as Objects
|
||||
|
||||
It may be desired at some point to load a class from a file and then instance it. Since the global scope does not exist, classes must be loaded as a resource. Instancing is done by calling the “new” function in a class object:
|
||||
|
||||
```python#load the class (loaded every time the script is instanced)
|
||||
var MyClass = load("myclass.gd")
|
||||
|
||||
# alternatively, using the preload() function preloads the class at compile time
|
||||
|
||||
var MyClass2 = preload("myclass.gd")
|
||||
|
||||
func _init():
|
||||
var a = MyClass.new()
|
||||
a.somefunction()```
|
||||
## Exports
|
||||
|
||||
Class members can be exported. This means their value gets saved along with a scene. If class members have initializers to constant expressions, they will be available for editing in the property editor. Exporting is done by using the export keyword:
|
||||
|
||||
```pythonextends Button
|
||||
|
||||
export var data # value will be saved
|
||||
export var number=5 # also available to the property editor```
|
||||
One of the fundamental benefits of exporting member variables is to have them visible in the property editor. This way artists and game designers can modify values that later influence how the program runs. For this, a special export syntax is provided for more detail in the exported variables:
|
||||
|
||||
```python#if the exported value assigns a constant or constant expression, the type will be infered and used in the editor
|
||||
|
||||
export var number=5
|
||||
|
||||
# export can take a basic datatype as argument, which will be used in the editor
|
||||
|
||||
export(int) var number
|
||||
|
||||
# export can also take a resource type as hint
|
||||
|
||||
export(Texture) var character_face
|
||||
|
||||
# integers and strings hint enumerated values
|
||||
|
||||
export(int,"Warrior","Magician","Thief") var character_class # (editor will set them as 0,1 and 2)
|
||||
export(String,"Rebecca","Mary","Leah") var character_name
|
||||
|
||||
# strings as paths
|
||||
|
||||
export(String,FILE) var f # string is a path to a file
|
||||
export(String,DIR) var f # string is a path to a directory
|
||||
export(String,FILE,"*.txt") var f # string is a path to a file, custom filter provided as hint
|
||||
|
||||
# integers and floats hint ranges
|
||||
|
||||
export(int,20) var i # 0 to 20 allowed
|
||||
export(int,-10,20) var j # -10 to 20 allowed
|
||||
export(float,-10,20,0.2) var k # -10 to 20 allowed, with stepping of 0.2
|
||||
|
||||
# color can hint availability of alpha
|
||||
|
||||
export(Color,RGB) var col # Color is RGB
|
||||
export(Color,RGBA) var col # Color is RGBA```
|
||||
It must be noted that even if the script is not being run while at the editor, the exported properties are still editable (see below for “tool”).
|
||||
|
||||
## Static Functions
|
||||
|
||||
A function can be declared static. When static, it has no access to the instance member variables or “self”. This is mainly useful to make libraries of helper functions:
|
||||
|
||||
```pythonstatic func sum2(a,b):
|
||||
return a+b```
|
||||
## Tool Mode
|
||||
|
||||
Scripts by default don’t run inside the editor, and only the exported properties can be changed. In some cases it is desired that they do (as long as they don’t execute game code or manually avoid doing so). For this, the “tool” keyword exists, and must be placed at the top of the file:
|
||||
|
||||
```pythontool
|
||||
extends Button
|
||||
|
||||
func _init():
|
||||
print("Hello")```
|
||||
## Memory Management
|
||||
|
||||
If a class inherits from *Reference*, then instances will be freed when no longer in use. No garbage collector exists, just simple reference counting. By default, all classes that don’t define inheritance extend *Reference*. If this is not desired, then a class must inherit *Object* manually and must call instance.free(). To avoid reference cycles that can’t be freed, a weakref() function is provided for creating weak references.
|
||||
|
||||
## Function References
|
||||
|
||||
Functions can’t be referenced because they are not treated as class members. There are two alternatives to this, though. The “call” function or the funcref() helper.
|
||||
|
||||
```pythoninstance.call("funcname",args) # call a function by bane
|
||||
|
||||
var fr = funcref(instance,"funcname") #create a function ref
|
||||
fr.exec(args)```
|
||||
|
||||
--- //[Juan Linietsky](reduzio@gmail.com) 2013/11/10 18:09//
|
BIN
images/activescene.png
Normal file
After Width: | Height: | Size: 15 KiB |
BIN
images/addedlabel.png
Normal file
After Width: | Height: | Size: 61 KiB |
BIN
images/addglobal.png
Normal file
After Width: | Height: | Size: 18 KiB |
BIN
images/addscript.png
Normal file
After Width: | Height: | Size: 6.7 KiB |
BIN
images/addtrack.png
Normal file
After Width: | Height: | Size: 9.0 KiB |
BIN
images/anchors.png
Normal file
After Width: | Height: | Size: 123 KiB |
BIN
images/androidsdk.png
Normal file
After Width: | Height: | Size: 52 KiB |
BIN
images/animation.png
Normal file
After Width: | Height: | Size: 20 KiB |
BIN
images/animedit.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/animeditor.png
Normal file
After Width: | Height: | Size: 18 KiB |
BIN
images/animnew.png
Normal file
After Width: | Height: | Size: 5.6 KiB |
BIN
images/animpanel.png
Normal file
After Width: | Height: | Size: 10 KiB |
BIN
images/animplayer.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/autoplay.png
Normal file
After Width: | Height: | Size: 5.7 KiB |
BIN
images/bad.png
Normal file
After Width: | Height: | Size: 437 B |
BIN
images/bitmapfont.png
Normal file
After Width: | Height: | Size: 9.0 KiB |
BIN
images/button_connections.png
Normal file
After Width: | Height: | Size: 26 KiB |
BIN
images/changed.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/changes.png
Normal file
After Width: | Height: | Size: 4.7 KiB |
BIN
images/chef.png
Normal file
After Width: | Height: | Size: 83 KiB |
BIN
images/compressopts.png
Normal file
After Width: | Height: | Size: 5.3 KiB |
BIN
images/createnode.png
Normal file
After Width: | Height: | Size: 33 KiB |
BIN
images/ctrl_normal.png
Normal file
After Width: | Height: | Size: 2.5 KiB |
BIN
images/ctrl_tapped.png
Normal file
After Width: | Height: | Size: 2.5 KiB |
BIN
images/edit_scheme.png
Normal file
After Width: | Height: | Size: 139 KiB |
BIN
images/editor.png
Normal file
After Width: | Height: | Size: 47 KiB |
BIN
images/editorsettings.png
Normal file
After Width: | Height: | Size: 7.2 KiB |
BIN
images/export.png
Normal file
After Width: | Height: | Size: 2.6 KiB |
BIN
images/export_dialog.png
Normal file
After Width: | Height: | Size: 54 KiB |
BIN
images/export_error.png
Normal file
After Width: | Height: | Size: 4.4 KiB |
BIN
images/expres.png
Normal file
After Width: | Height: | Size: 21 KiB |
BIN
images/expselected.png
Normal file
After Width: | Height: | Size: 42 KiB |
BIN
images/exptemp.png
Normal file
After Width: | Height: | Size: 7.2 KiB |
BIN
images/fixedborder.png
Normal file
After Width: | Height: | Size: 10 KiB |
BIN
images/fontgradients.png
Normal file
After Width: | Height: | Size: 6.6 KiB |
BIN
images/fontimport.png
Normal file
After Width: | Height: | Size: 48 KiB |
BIN
images/fontspacing.png
Normal file
After Width: | Height: | Size: 12 KiB |
BIN
images/godot_path.png
Normal file
After Width: | Height: | Size: 144 KiB |
BIN
images/good.png
Normal file
After Width: | Height: | Size: 444 B |
BIN
images/groups.png
Normal file
After Width: | Height: | Size: 5.0 KiB |
BIN
images/helloworld.png
Normal file
After Width: | Height: | Size: 5.8 KiB |
BIN
images/hw.png
Normal file
After Width: | Height: | Size: 18 KiB |
BIN
images/import.png
Normal file
After Width: | Height: | Size: 18 KiB |
BIN
images/import_images.png
Normal file
After Width: | Height: | Size: 42 KiB |
BIN
images/importaudio.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
images/importdialogs.png
Normal file
After Width: | Height: | Size: 104 KiB |
BIN
images/importtex.png
Normal file
After Width: | Height: | Size: 14 KiB |
BIN
images/inputmap.png
Normal file
After Width: | Height: | Size: 37 KiB |
BIN
images/isettings.png
Normal file
After Width: | Height: | Size: 18 KiB |
BIN
images/keyadded.png
Normal file
After Width: | Height: | Size: 20 KiB |
BIN
images/keypress.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
images/label.png
Normal file
After Width: | Height: | Size: 22 KiB |
BIN
images/logo.png
Normal file
After Width: | Height: | Size: 3.9 KiB |
BIN
images/main_scene.png
Normal file
After Width: | Height: | Size: 51 KiB |
BIN
images/margin.png
Normal file
After Width: | Height: | Size: 30 KiB |
BIN
images/marginaround.png
Normal file
After Width: | Height: | Size: 34 KiB |
BIN
images/marginend.png
Normal file
After Width: | Height: | Size: 18 KiB |
BIN
images/mipmaps.png
Normal file
After Width: | Height: | Size: 55 KiB |
BIN
images/move_cursor.png
Normal file
After Width: | Height: | Size: 21 KiB |
BIN
images/neversaved.png
Normal file
After Width: | Height: | Size: 5.9 KiB |
BIN
images/newnode.png
Normal file
After Width: | Height: | Size: 9.0 KiB |
BIN
images/newproj.png
Normal file
After Width: | Height: | Size: 13 KiB |
BIN
images/newproject.png
Normal file
After Width: | Height: | Size: 22 KiB |
BIN
images/newscript.png
Normal file
After Width: | Height: | Size: 40 KiB |
BIN
images/nodes_resources.png
Normal file
After Width: | Height: | Size: 17 KiB |
BIN
images/nodesearch.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/oneclick.png
Normal file
After Width: | Height: | Size: 5.3 KiB |
BIN
images/playscene.png
Normal file
After Width: | Height: | Size: 2.3 KiB |
BIN
images/pong_layout.png
Normal file
After Width: | Height: | Size: 9.8 KiB |
BIN
images/pong_nodes.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/propertykeys.png
Normal file
After Width: | Height: | Size: 26 KiB |
BIN
images/regular.png
Normal file
After Width: | Height: | Size: 450 B |
BIN
images/reimported.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/resourcerobi.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
images/reverb.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/rfs_server.png
Normal file
After Width: | Height: | Size: 84 KiB |
BIN
images/robisplashpreview.png
Normal file
After Width: | Height: | Size: 175 KiB |
BIN
images/robisplashscene.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/saveasscript.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
images/savescene.png
Normal file
After Width: | Height: | Size: 20 KiB |
BIN
images/scene.png
Normal file
After Width: | Height: | Size: 17 KiB |
BIN
images/script_template.png
Normal file
After Width: | Height: | Size: 23 KiB |
BIN
images/scriptadded.png
Normal file
After Width: | Height: | Size: 28 KiB |
BIN
images/scriptcreate.png
Normal file
After Width: | Height: | Size: 17 KiB |
BIN
images/scripthello.png
Normal file
After Width: | Height: | Size: 4.8 KiB |
BIN
images/scriptscene.png
Normal file
After Width: | Height: | Size: 4.0 KiB |