mirror of
https://github.com/Relintai/pandemonium_engine_docs.git
synced 2025-01-21 15:07:22 +01:00
More code block cleanups.
This commit is contained in:
parent
f77227608c
commit
8e5258c966
@ -81,11 +81,11 @@ The commit hash is written inside that file.
|
||||
If you're using a stable release as the "good" or "bad" build, use one of the
|
||||
following commit hashes depending on the version:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
3.2-stable
|
||||
3.1-stable
|
||||
3.0-stable
|
||||
```
|
||||
|
||||
To refer to the latest state of the master branch, you can use `master`
|
||||
instead of a commit hash.
|
||||
@ -94,21 +94,21 @@ instead of a commit hash.
|
||||
is done, in the terminal window, use `cd` to reach the Godot repository
|
||||
folder and enter the following command:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
# <good commit hash> is hash of the build that works as expected.
|
||||
# <bad commit hash> is hash of the build exhibiting the bug.
|
||||
$ git bisect start
|
||||
$ git bisect good <good commit hash>
|
||||
$ git bisect bad <bad commit hash>
|
||||
```
|
||||
|
||||
Compile Godot. This assumes you've set up a build environment:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
# <platform> is the platform you're targeting for regression testing,
|
||||
# like "windows", "x11" or "osx".
|
||||
$ scons platform=<platform> -j4
|
||||
```
|
||||
|
||||
Since building Godot takes a while, you want to dedicate as many CPU threads as
|
||||
possible to the task. This is what the `-j` parameter does. Here, the command
|
||||
@ -118,15 +118,15 @@ Run the binary located in the `bin/` folder and try to reproduce the bug.
|
||||
|
||||
If the build **still** exhibits the bug, run the following command:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
$ git bisect bad
|
||||
```
|
||||
|
||||
If the build **does not** exhibit the bug, run the following command:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
$ git bisect good
|
||||
```
|
||||
|
||||
After entering one of the commands above, Git will switch to a different commit.
|
||||
You should now build Godot again, try to reproduce the bug, then enter `git
|
||||
|
@ -25,40 +25,39 @@ Note:
|
||||
You may need to write `python3 -m pip` (Unix) or `py -m pip` (Windows) instead of `pip3`.
|
||||
If both approaches fail, `check that you have pip3 installed ( https://pip.pypa.io/en/stable/installation/ )`.
|
||||
|
||||
.. code:: sh
|
||||
|
||||
```
|
||||
git clone https://github.com/godotengine/godot-docs.git
|
||||
pip3 install -r requirements.txt
|
||||
|
||||
```
|
||||
|
||||
With the programs installed, you can build the HTML documentation from the root
|
||||
folder of this repository with the following command:
|
||||
|
||||
.. code:: sh
|
||||
|
||||
```
|
||||
# On Linux and macOS
|
||||
make html
|
||||
|
||||
# On Windows, you need to execute the `make.bat` file instead.
|
||||
make.bat html
|
||||
```
|
||||
|
||||
If you run into errors, you may try the following command:
|
||||
|
||||
.. code:: sh
|
||||
|
||||
```
|
||||
make SPHINXBUILD=~/.local/bin/sphinx-build html
|
||||
```
|
||||
|
||||
Building the documentation requires at least 8 GB of RAM to run without disk
|
||||
swapping, which slows it down. If you have at least 16 GB of RAM, you can speed
|
||||
up compilation by running:
|
||||
|
||||
.. code:: sh
|
||||
|
||||
```
|
||||
# On Linux/macOS
|
||||
make html SPHINXOPTS=-j2
|
||||
|
||||
# On Windows
|
||||
set SPHINXOPTS=-j2 && make html
|
||||
```
|
||||
|
||||
The compilation will take some time as the `classes/` folder contains hundreds
|
||||
of files.
|
||||
|
@ -15,8 +15,7 @@ See also:
|
||||
|
||||
The reference for each class is contained in an XML file like the one below:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
```
|
||||
<class name="Node2D" inherits="CanvasItem" version="4.0">
|
||||
<brief_description>
|
||||
A 2D game object, inherited by all 2D-related nodes. Has a position, rotation, scale, and Z index.
|
||||
@ -61,7 +60,7 @@ The reference for each class is contained in an XML file like the one below:
|
||||
<constants>
|
||||
</constants>
|
||||
</class>
|
||||
|
||||
```
|
||||
|
||||
It starts with brief and long descriptions. In the generated docs, the brief
|
||||
description is always at the top of the page, while the long description lies
|
||||
@ -71,14 +70,14 @@ member variables, constants, and signals in separate XML nodes.
|
||||
For each, you want to learn how they work in Godot's source code. Then, fill
|
||||
their documentation by completing or improving the text in these tags:
|
||||
|
||||
- `<brief_description )`
|
||||
- `<description )`
|
||||
- `<constant )`
|
||||
- `<method )` (in its `<description )` tag; return types and arguments don't take separate
|
||||
- `<brief_description>`
|
||||
- `<description>`
|
||||
- `<constant>`
|
||||
- `<method>` (in its `<description>` tag; return types and arguments don't take separate
|
||||
documentation strings)
|
||||
- `<member )`
|
||||
- `<signal )` (in its `<description )` tag; arguments don't take separate documentation strings)
|
||||
- `<constant )`
|
||||
- `<member>`
|
||||
- `<signal>` (in its `<description>` tag; arguments don't take separate documentation strings)
|
||||
- `<constant>`
|
||||
|
||||
Write in a clear and simple language. Always follow the `writing guidelines
|
||||
( doc_docs_writing_guidelines )` to keep your descriptions short and easy to read.
|
||||
@ -110,7 +109,7 @@ errors if anything's wrong.
|
||||
|
||||
Alternatively, you can build Godot and open the modified page in the built-in
|
||||
code reference. To learn how to compile the engine, read the `compilation
|
||||
guide <toc-devel-compiling )`.
|
||||
guide ( toc-devel-compiling )`.
|
||||
|
||||
We recommend using a code editor that supports XML files like Vim, Atom, Visual Studio Code,
|
||||
Notepad++, or another to comfortably edit the file. You can also use their
|
||||
@ -162,21 +161,21 @@ Use `[codeblock]` for pre-formatted code blocks. Inside `[codeblock]`,
|
||||
always use **four spaces** for indentation. The parser will delete tabs. For
|
||||
example:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
[codeblock]
|
||||
func _ready():
|
||||
var sprite = get_node("Sprite")
|
||||
print(sprite.get_pos())
|
||||
[/codeblock]
|
||||
```
|
||||
|
||||
Will display as:
|
||||
|
||||
.. code-block:: gdscript
|
||||
|
||||
```
|
||||
func _ready():
|
||||
var sprite = get_node("Sprite")
|
||||
print(sprite.get_pos())
|
||||
```
|
||||
|
||||
If you need to have different code version in GDScript and C#, use
|
||||
`[codeblocks]` instead. If you use `[codeblocks]`, you also need to have at
|
||||
@ -186,8 +185,7 @@ Always write GDScript code examples first! You can use this `experimental code
|
||||
translation tool ( https://github.com/HaSa1002/codetranslator )` to speed up your
|
||||
workflow.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
[codeblocks]
|
||||
[gdscript]
|
||||
func _ready():
|
||||
@ -202,6 +200,7 @@ workflow.
|
||||
}
|
||||
[/csharp]
|
||||
[/codeblocks]
|
||||
```
|
||||
|
||||
The above will display as:
|
||||
|
||||
@ -215,24 +214,24 @@ gdscript GDScript
|
||||
To denote important information, add a paragraph starting with "[b]Note:[/b]" at
|
||||
the end of the description:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
[b]Note:[/b] Only available when using the Vulkan renderer.
|
||||
```
|
||||
|
||||
To denote crucial information that could cause security issues or loss of data
|
||||
if not followed carefully, add a paragraph starting with "[b]Warning:[/b]" at
|
||||
the end of the description:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
[b]Warning:[/b] If this property is set to [code]true[/code], it allows clients to execute arbitrary code on the server.
|
||||
```
|
||||
|
||||
For deprecated properties, add a paragraph starting with "[i]Deprecated.[/i]".
|
||||
Notice the use of italics instead of bold:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
[i]Deprecated.[/i] This property has been replaced by [member other_property].
|
||||
```
|
||||
|
||||
In all the paragraphs described above, make sure the punctuation is part of the
|
||||
BBCode tags for consistency.
|
||||
|
@ -85,9 +85,9 @@ Manual usage
|
||||
You can apply clang-format manually one or more files with the following
|
||||
command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
clang-format -i <path/to/file(s)>
|
||||
```
|
||||
|
||||
- `-i` means that the changes should be written directly to the file (by
|
||||
default clang-format would only output the fixed version to the terminal).
|
||||
@ -159,8 +159,7 @@ ones, the following rules should be followed:
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/*************************************************************************/
|
||||
/* my_new_file.h */
|
||||
/*************************************************************************/
|
||||
@ -203,9 +202,9 @@ Example:
|
||||
...
|
||||
|
||||
#endif // MY_NEW_FILE_H
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/*************************************************************************/
|
||||
/* my_new_file.cpp */
|
||||
/*************************************************************************/
|
||||
@ -243,6 +242,7 @@ Example:
|
||||
|
||||
#include <zlib.h>
|
||||
#include <zstd.h>
|
||||
```
|
||||
|
||||
Java
|
||||
----
|
||||
@ -272,10 +272,9 @@ Installation
|
||||
|
||||
Here's how to install black:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
pip3 install black --user
|
||||
|
||||
```
|
||||
|
||||
You then have different possibilities to apply black to your changes:
|
||||
|
||||
@ -285,9 +284,9 @@ Manual usage
|
||||
You can apply `black` manually to one or more files with the following
|
||||
command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
black -l 120 <path/to/file(s)>
|
||||
```
|
||||
|
||||
- `-l 120` means that the allowed number of characters per line is 120.
|
||||
This number was agreed upon by the developers.
|
||||
@ -328,20 +327,20 @@ Godot's codebase.
|
||||
|
||||
**Example:**
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Compute the first 10,000 decimals of Pi.
|
||||
// FIXME: Don't crash when computing the 1,337th decimal due to `increment`
|
||||
// being negative.
|
||||
```
|
||||
|
||||
Don't repeat what the code says in a comment. Explain the *why* rather than *how*.
|
||||
|
||||
**Bad:**
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Draw loading screen.
|
||||
draw_load_screen();
|
||||
```
|
||||
|
||||
You can use Javadoc-style comments above function or macro definitions. It's
|
||||
recommended to use Javadoc-style comments *only* for methods which are not
|
||||
@ -351,8 +350,7 @@ instead.
|
||||
|
||||
**Example:**
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/**
|
||||
* Returns the number of nodes in the universe.
|
||||
* This can potentially be a very large number, hence the 64-bit return type.
|
||||
@ -360,14 +358,15 @@ instead.
|
||||
uint64_t Universe::get_node_count() {
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
For member variables, don't use Javadoc-style comments but use single-line comments instead:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
class Universe {
|
||||
// The cached number of nodes in the universe.
|
||||
// This value may not always be up-to-date with the current number of nodes
|
||||
// in the universe.
|
||||
uint64_t node_count_cached = 0;
|
||||
};
|
||||
```
|
||||
|
@ -125,12 +125,10 @@ Titles
|
||||
|
||||
Always begin pages with their title and a Sphinx reference name:
|
||||
|
||||
::
|
||||
|
||||
|
||||
|
||||
```
|
||||
Insert your title here
|
||||
======================
|
||||
```
|
||||
|
||||
The reference `doc_insert_your_title_here` and the title should match.
|
||||
|
||||
@ -169,18 +167,17 @@ Adding images and attachments
|
||||
To add images, please put them in an `img/` folder next to the `.rst` file with
|
||||
a meaningful name and include them in your page with:
|
||||
|
||||
.. code:: rst
|
||||
|
||||
```
|
||||
![](img/image_name.png)
|
||||
```
|
||||
|
||||
Similarly, you can include attachments, like assets as support material for a
|
||||
tutorial, by placing them into a `files/` folder next to the `.rst` file, and
|
||||
using this inline markup:
|
||||
|
||||
.. code:: rst
|
||||
|
||||
```
|
||||
:download:`myfilename.zip ( files/myfilename.zip )`
|
||||
|
||||
```
|
||||
|
||||
License
|
||||
-------
|
||||
|
@ -75,13 +75,13 @@ Note:
|
||||
Please don't use the `auto` keyword for type inference. While it can avoid
|
||||
repetition, it can also lead to confusing code:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Not so confusing...
|
||||
auto button = memnew(Button);
|
||||
|
||||
// ...but what about this?
|
||||
auto result = EditorNode::get_singleton()->get_complex_result();
|
||||
```
|
||||
|
||||
Keep in mind hover documentation often isn't readily available for pull request
|
||||
reviewers. Most of the time, reviewers will use GitHub's online viewer to review
|
||||
|
@ -49,33 +49,31 @@ Use the active voice when possible. Take the classes, methods, and
|
||||
constants you describe as the subject. It's natural to write using the
|
||||
passive voice, but it's harder to read and produces longer sentences.
|
||||
|
||||
.. highlight:: none
|
||||
|
||||
Passive:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
The man **was bitten** by the dog.
|
||||
```
|
||||
|
||||
Active:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
The dog bit the man.
|
||||
```
|
||||
|
||||
**Don't** use the passive voice:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
void edit_set_pivot ( Vector2 pivot )
|
||||
[...] This method **is implemented** only in some nodes that inherit Node2D.
|
||||
```
|
||||
|
||||
**Do** use the node's name as a noun:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
void edit_set_pivot ( Vector2 pivot )
|
||||
[...] Only some Node2Ds **implement** this method.
|
||||
```
|
||||
|
||||
Use precise action verbs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -86,18 +84,18 @@ and any expression you can replace with a single word.
|
||||
**Don't** repeat the method's name. It already states it sets the pivot
|
||||
value to a new one:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
void edit_set_pivot ( Vector2 pivot )
|
||||
Set the pivot position of the 2D node to [code]pivot[/code] value. [...]
|
||||
```
|
||||
|
||||
**Do** explain what's the consequence of this "set": use precise verbs
|
||||
like `place`, `position`, `rotate`, `fade`, etc.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
void edit_set_pivot ( Vector2 pivot )
|
||||
Position the node's pivot to the [code]pivot[/code] value. [...]
|
||||
```
|
||||
|
||||
Avoid verbs that end in -ing
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -107,17 +105,17 @@ The progressive forms describe continuous actions. E.g. "is calling",
|
||||
|
||||
**Don't** use the progressive form for instant changes.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
Vector2 move ( Vector2 rel_vec )
|
||||
Move the body in the given direction, **stopping** if there is an obstacle. [...]
|
||||
```
|
||||
|
||||
**Do** use simple present, past, or future.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
Vector2 move ( Vector2 rel_vec )
|
||||
Moves the body in the vector's direction. The body **stops** if it collides with an obstacle. [...]
|
||||
```
|
||||
|
||||
Exception: If the subject is not clear, replacing "ing" verbs is not an
|
||||
improvement. For example, in the previous sentence, "it replaces"
|
||||
@ -128,7 +126,6 @@ continuous in time. Anything like animation or coroutines.
|
||||
|
||||
Tip:
|
||||
|
||||
|
||||
Verbs can turn into adjectival nouns with -ing. This is not a
|
||||
conjugation, so you may use them: `the remaining movement`,
|
||||
`the missing file`, etc.
|
||||
@ -142,15 +139,15 @@ add key information to the description.
|
||||
**Don't** use redundant or meaningless adverbs. Words that lengthen the
|
||||
documentation but don't add any information:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**Basically** a big texture [...]
|
||||
```
|
||||
|
||||
**Do** write short sentences in a simple, descriptive language:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
A big texture [...]
|
||||
```
|
||||
|
||||
Ban these 8 words
|
||||
~~~~~~~~~~~~~~~~~
|
||||
@ -175,48 +172,48 @@ easily, actually, clearly.
|
||||
**Don't** example. The banned words lengthen the description and take
|
||||
attention away from the most important info:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**TextureRect**
|
||||
Control frame that **simply** draws an assigned texture. It can stretch or not. It's a **simple** way to **just** show an image in a UI.
|
||||
```
|
||||
|
||||
**Do** remove them:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**TextureRect**
|
||||
[Control] node that displays a texture. The texture can stretch to the node's bounding box or stay in the center. Useful to display sprites in your UIs.
|
||||
```
|
||||
|
||||
"Simple" never helps. Remember, for other users, anything could be
|
||||
complex or frustrate them. There's nothing like a good old *it's simple*
|
||||
to make you cringe. Here's the old brief description, the first sentence
|
||||
on the Timer node's page:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**Timer**
|
||||
A **simple** Timer node.
|
||||
```
|
||||
|
||||
**Do** explain what the node does instead:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**Timer**
|
||||
Calls a function of your choice after a certain duration.
|
||||
```
|
||||
|
||||
**Don't** use "basic", it is too vague:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**Vector3**
|
||||
Vector class, which performs **basic** 3D vector math operations.
|
||||
```
|
||||
|
||||
**Do** use the brief description to offer an overview of the node:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**Vector3**
|
||||
Provides essential math functions to manipulate 3D vectors: cross product, normalize, rotate, etc.
|
||||
```
|
||||
|
||||
Use explicit references
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -226,15 +223,15 @@ Favor explicit references over implicit ones.
|
||||
**Don't** use words like "the former", "the latter", etc. They're not
|
||||
the most common in English, and they require you to check the reference.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[code]w[/code] and [code]h[/code] define right and bottom margins. The **latter** two resize the texture so it fits in the defined margin.
|
||||
```
|
||||
|
||||
**Do** repeat words. They remove all ambiguity:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[code]w[/code] and [code]h[/code] define right and bottom margins. **[code]w[/code] and [code]h[/code]** resize the texture so it fits the margin.
|
||||
```
|
||||
|
||||
If you need to repeat the same variable name 3 or 4 times, you probably
|
||||
need to rephrase your description.
|
||||
@ -247,16 +244,16 @@ milk" instead.
|
||||
|
||||
**Don't** write "of the X":
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
The region **of the AtlasTexture that is** used.
|
||||
```
|
||||
|
||||
**Do** use `'s`. It lets you put the main subject at the start of the
|
||||
sentence, and keep it short:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
The **AtlasTexture's** used region.
|
||||
```
|
||||
|
||||
Use the Oxford comma to enumerate anything
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -271,17 +268,16 @@ From the Oxford dictionary:
|
||||
|
||||
**Don't** leave the last element of a list without a comma:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
Create a KinematicBody2D node, a CollisionShape2D node and a sprite node.
|
||||
```
|
||||
|
||||
**Do** add a comma before `and` or `or`, for the last
|
||||
element of a list with more than two elements.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
Create a KinematicBody2D node, a CollisionShape2D node, and a sprite node.
|
||||
|
||||
```
|
||||
|
||||
How to write methods and classes
|
||||
--------------------------------
|
||||
@ -298,45 +294,43 @@ The exception is topics that explain static typing concepts to users.
|
||||
|
||||
**Don't** add a type hint with a colon or by casting:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
const MainAttack := preload("res://fire_attack.gd")
|
||||
var hit_points := 5
|
||||
var name: String = "Bob"
|
||||
var body_sprite := $Sprite as Sprite
|
||||
|
||||
```
|
||||
|
||||
**Do** write constants and variables with dynamic typing:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
const MainAttack = preload("res://fire_attack.gd")
|
||||
var hit_points = 5
|
||||
var name = "Bob"
|
||||
var body_sprite = $Sprite
|
||||
|
||||
```
|
||||
|
||||
**Don't** write functions with inferred arguments or return types:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
func choose(arguments: PackedStringArray) -> String:
|
||||
# Chooses one of the arguments from array with equal chances
|
||||
randomize()
|
||||
var size := arguments.size()
|
||||
var choice: int = randi() % size
|
||||
return arguments[choice]
|
||||
```
|
||||
|
||||
**Do** write functions using dynamic typing:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
func choose(arguments):
|
||||
# Chooses one of the arguments from array with equal chances
|
||||
randomize()
|
||||
var size = arguments.size()
|
||||
var choice = randi() % size
|
||||
return arguments[choice]
|
||||
```
|
||||
|
||||
Use real-world code examples where appropriate
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -351,19 +345,18 @@ could use the code snippets in a live project.
|
||||
|
||||
**Don't** write made-up examples:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
onready var a = preload("res://MyPath")
|
||||
onready var my_node = $MyNode
|
||||
|
||||
|
||||
func foo():
|
||||
# Do stuff
|
||||
```
|
||||
|
||||
**Do** write concrete examples:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
onready var sfx_player_gun = preload("res://Assets/Sound/SFXPlayerGun.ogg")
|
||||
onready var audio_player = $Audio/AudioStreamPlayer
|
||||
|
||||
@ -371,6 +364,7 @@ could use the code snippets in a live project.
|
||||
func play_shooting_sound():
|
||||
audio_player.stream = sfx_player_gun
|
||||
audio_player.play()
|
||||
```
|
||||
|
||||
Of course, there are times when using real-world examples is impractical. In
|
||||
those situations, you should still avoid using names such as `my_var`,
|
||||
@ -390,17 +384,17 @@ functionality, in up to 200 characters.
|
||||
|
||||
**Don't** write tiny and vague summaries:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**Node2D**
|
||||
Base node for 2D system.
|
||||
```
|
||||
|
||||
**Do** give an overview of the node's functionality:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
**Node2D**
|
||||
A 2D game object, inherited by all 2D-related nodes. Has a position, rotation, scale, and Z index.
|
||||
```
|
||||
|
||||
Use the node's full description to provide more information, and a code
|
||||
example, if possible.
|
||||
@ -414,17 +408,17 @@ for any method whose name starts with `set` or `get`.
|
||||
|
||||
**Don't** use the passive voice:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
Vector2 move ( Vector2 rel_vec )
|
||||
[...] The returned vector is how much movement was remaining before being stopped.
|
||||
```
|
||||
|
||||
**Do** always use "Returns".
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
Vector2 move ( Vector2 rel_vec )
|
||||
[...] Returns the remaining movement before the body was stopped.
|
||||
```
|
||||
|
||||
Notice the exception to the "direct voice" rule: with the move method,
|
||||
an external collider can influence the method and the body that calls
|
||||
@ -441,11 +435,10 @@ Also, surround boolean values, variable names and methods with `[code][/code]`.
|
||||
|
||||
**Do** start with "if true":
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
Timer.autostart
|
||||
If [code]true[/code], the timer will automatically start when entering the scene tree.
|
||||
|
||||
```
|
||||
|
||||
Use `[code]` around arguments
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -94,12 +94,10 @@ Titles
|
||||
|
||||
Always begin pages with their title and a Sphinx reference name:
|
||||
|
||||
::
|
||||
|
||||
|
||||
|
||||
```
|
||||
Insert your title here
|
||||
======================
|
||||
```
|
||||
|
||||
The reference allows linking to this page using the ``` format, e.g.
|
||||
```doc_insert_your_title_here``` would link to the above example page
|
||||
|
@ -3,8 +3,6 @@
|
||||
Editor and docs localization
|
||||
============================
|
||||
|
||||
.. highlight:: none
|
||||
|
||||
Godot aims to make game development available to everyone, including people who
|
||||
may not know or be comfortable with English. Therefore, we do our best to make
|
||||
the most important resources available in many languages, thanks to the
|
||||
@ -222,7 +220,7 @@ The editor translations originate from C++ strings, and may use:
|
||||
placed in your translation where necessary for it to be meaningful after
|
||||
substitution. You may need to refer to the source string location to
|
||||
understand what kind of content will be substituted if it's not clear from the
|
||||
sentence. Example (`%s` will be substituted with a file name or path)::
|
||||
sentence. Example (`%s` will be substituted with a file name or path):
|
||||
|
||||
# PO file:
|
||||
"There is no '%s' file."
|
||||
@ -236,7 +234,7 @@ The editor translations originate from C++ strings, and may use:
|
||||
breaks in the same way as the original English string (Weblate will issue a
|
||||
warning if you don't). Line breaks might sometimes be used for vertical
|
||||
spacing, or manual wrapping of long lines which would otherwise be too long
|
||||
especially in the editor translation). Example::
|
||||
especially in the editor translation). Example:
|
||||
|
||||
# PO file:
|
||||
"Scene '%s' is currently being edited.\n"
|
||||
@ -256,8 +254,9 @@ Online documentation (RST)
|
||||
|
||||
The documentation translations originate from reStructuredText (RST) files,
|
||||
which also use their own markup syntax to style text, create internal and
|
||||
external links, etc. Here are some examples::
|
||||
external links, etc. Here are some examples:
|
||||
|
||||
```
|
||||
# "development" is styled bold.
|
||||
# "Have a look here" is a link pointing to https://docs.godotengine.org/en/latest.
|
||||
# You should translate "Have a look here", but not the URL, unless there is
|
||||
@ -293,6 +292,7 @@ external links, etc. Here are some examples::
|
||||
|
||||
Save the scene. Click Scene -> Save, or press :kbd:`Ctrl + S` on Windows/Linux
|
||||
or :kbd:`Cmd + S` on macOS.
|
||||
```
|
||||
|
||||
See also:
|
||||
|
||||
@ -312,13 +312,15 @@ Some of the tags used are from the original BBCode (e.g. `[b]Bold[/b]` and
|
||||
`[i]Italics[/i]`), while others are Godot-specific and used for advanced
|
||||
features such as inline code (e.g. `[code]true[/code]`), linking to another
|
||||
class (e.g. `[Node2D]`) or to a property in a given class (e.g.
|
||||
`[member Node2D.position]`), or for multiline code blocks. Example::
|
||||
`[member Node2D.position]`), or for multiline code blocks. Example:
|
||||
|
||||
```
|
||||
Returns a color according to the standardized [code]name[/code] with [code]alpha[/code] ranging from 0 to 1.
|
||||
[codeblock]
|
||||
red = ColorN("red", 1)
|
||||
[/codeblock]
|
||||
Supported color names are the same as the constants defined in [Color].
|
||||
```
|
||||
|
||||
In the above example, `[code]name[/code]`, `[code]alpha[/code]`, and
|
||||
`[Color]` should *not* be translated, as they refer respectively to argument
|
||||
|
@ -95,9 +95,9 @@ Note:
|
||||
|
||||
To clone your fork from GitHub, use the following command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git clone https://github.com/USERNAME/godot
|
||||
```
|
||||
|
||||
Note:
|
||||
In our examples, the "$" character denotes the command line prompt
|
||||
@ -107,16 +107,16 @@ Note:
|
||||
After a little while, you should have a `godot` directory in your current
|
||||
working directory. Move into it using the `cd` command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ cd godot
|
||||
```
|
||||
|
||||
We will start by setting up a reference to the original repository that we forked:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git remote add upstream https://github.com/godotengine/godot
|
||||
$ git fetch upstream
|
||||
```
|
||||
|
||||
This will create a reference named `upstream` pointing to the original
|
||||
`godotengine/godot` repository. This will be useful when you want to pull new
|
||||
@ -150,44 +150,44 @@ By default, the `git clone` should have put you on the `master` branch of
|
||||
your fork (`origin`). To start your own feature development, we will create
|
||||
a feature branch:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# Create the branch based on the current branch (master)
|
||||
$ git branch better-project-manager
|
||||
|
||||
# Change the current branch to the new one
|
||||
$ git checkout better-project-manager
|
||||
```
|
||||
|
||||
This command is equivalent:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# Change the current branch to a new named one, based on the current branch
|
||||
$ git checkout -b better-project-manager
|
||||
```
|
||||
|
||||
If you want to go back to the `master` branch, you'd use:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git checkout master
|
||||
```
|
||||
|
||||
You can see which branch you are currently on with the `git branch`
|
||||
command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git branch
|
||||
2.1
|
||||
* better-project-manager
|
||||
master
|
||||
```
|
||||
|
||||
Be sure to always go back to the `master` branch before creating a new branch,
|
||||
as your current branch will be used as the base for the new one. Alternatively,
|
||||
you can specify a custom base branch after the new branch's name:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git checkout -b my-new-feature master
|
||||
```
|
||||
|
||||
Updating your branch
|
||||
--------------------
|
||||
@ -202,9 +202,9 @@ To ensure there won't be conflicts between the feature you develop and the
|
||||
current upstream `master` branch, you will have to update your branch by
|
||||
*pulling* the upstream branch.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git pull --rebase upstream master
|
||||
```
|
||||
|
||||
The `--rebase` argument will ensure that any local changes that you committed
|
||||
will be re-applied *on top* of the pulled branch, which is usually what we want
|
||||
@ -299,8 +299,7 @@ need to make changes, and learn by doing.
|
||||
|
||||
Here's how the shell history could look like on our example:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# It's nice to know where you're starting from
|
||||
$ git log
|
||||
|
||||
@ -328,6 +327,7 @@ Here's how the shell history could look like on our example:
|
||||
$ git add editor/project_manager.cpp
|
||||
$ git commit -m "Add a pretty banner to the project manager"
|
||||
$ git log
|
||||
```
|
||||
|
||||
With this, we should have two new commits in our `better-project-manager`
|
||||
branch which were not in the `master` branch. They are still only local
|
||||
@ -341,17 +341,17 @@ done in the local repository (unlike Subversion where a commit will modify
|
||||
the remote repository directly). You need to *push* the new commits to a
|
||||
remote branch to share them with the world. The syntax for this is:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git push ( remote> ( local branch>[:( remote branch>]
|
||||
```
|
||||
|
||||
The part about the remote branch can be omitted if you want it to have the
|
||||
same name as the local branch, which is our case in this example, so we will
|
||||
do:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git push origin better-project-manager
|
||||
```
|
||||
|
||||
Git will ask you for your username and password, and the changes will be sent
|
||||
to your remote. If you check the fork's page on GitHub, you should see a new
|
||||
@ -390,8 +390,7 @@ The good news is that you can modify a pull request simply by acting on the
|
||||
branch you made the pull request from. You can e.g. make a new commit on that
|
||||
branch, push it to your fork, and the PR will be updated automatically:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# Check out your branch again if you had changed in the meantime
|
||||
$ git checkout better-project-manager
|
||||
|
||||
@ -400,6 +399,7 @@ branch, push it to your fork, and the PR will be updated automatically:
|
||||
$ git add editor/project_manager.cpp
|
||||
$ git commit -m "Fix a typo in the banner's title"
|
||||
$ git push origin better-project-manager
|
||||
```
|
||||
|
||||
However, be aware that in our PR workflow, we favor commits that bring the
|
||||
codebase from one functional state to another functional state, without having
|
||||
@ -409,8 +409,7 @@ reason to keep the changes separate). Instead of authoring a new commit,
|
||||
consider using `git commit --amend` to amend the previous commit with your
|
||||
fixes. The above example would then become:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# Check out your branch again if you had changed in the meantime
|
||||
$ git checkout better-project-manager
|
||||
|
||||
@ -423,6 +422,7 @@ fixes. The above example would then become:
|
||||
# As we modified the last commit, it no longer matches the one from your
|
||||
# remote branch, so we need to force push to overwrite that branch.
|
||||
$ git push --force origin better-project-manager
|
||||
```
|
||||
|
||||
.. Kept for compatibility with the previous title, linked in many PRs.
|
||||
|
||||
@ -457,9 +457,9 @@ While you can give any commit ID to `git rebase -i` and review everything in
|
||||
between, the most common and convenient workflow involves rebasing on the
|
||||
upstream `master` branch, which you can do with:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git rebase -i upstream/master
|
||||
```
|
||||
|
||||
Note:
|
||||
Referencing branches in Git is a bit tricky due to the distinction
|
||||
@ -481,10 +481,10 @@ This will open a text editor (`vi` by default, see
|
||||
`Git docs ( https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_core_editor )`
|
||||
to configure your favorite one) with something which may look like this:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
```
|
||||
pick 1b4aad7 Add a pretty banner to the project manager
|
||||
pick e07077e Fix a typo in the banner's title
|
||||
```
|
||||
|
||||
The editor will also show instructions regarding how you can act on those
|
||||
commits. In particular, it should tell you that "pick" means to use that
|
||||
@ -494,10 +494,10 @@ that "fixup" will discard the commit log from the squashed commit. In our
|
||||
example, we are not interested in keeping the log of the "Fix a typo" commit,
|
||||
so we use:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
```
|
||||
pick 1b4aad7 Add a pretty banner to the project manager
|
||||
fixup e07077e Fix a typo in the banner's title
|
||||
```
|
||||
|
||||
Upon saving and quitting the editor, the rebase will occur. The second commit
|
||||
will be melded into the first one, and `git log` and `git show` should
|
||||
@ -509,22 +509,22 @@ diverged. Indeed, commit 1b4aad7 in the above example will have changed, and
|
||||
therefore got a new commit hash. If you try to push to your remote branch, it
|
||||
will raise an error:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git push origin better-project-manager
|
||||
To https://github.com/akien-mga/godot
|
||||
! [rejected] better-project-manager -> better-project-manager (non-fast-forward)
|
||||
error: failed to push some refs to 'https://akien-mga@github.com/akien-mga/godot'
|
||||
hint: Updates were rejected because the tip of your current branch is behind
|
||||
hint: its remote counterpart.
|
||||
```
|
||||
|
||||
This is a sane behavior, Git will not let you push changes that would
|
||||
override remote content. But that's actually what we want to do here, so we
|
||||
will have to *force* it:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git push --force origin better-project-manager
|
||||
```
|
||||
|
||||
And tadaa! Git will happily *replace* your remote branch with what you had
|
||||
locally (so make sure that's what you wanted, using `git log`). This will
|
||||
@ -540,18 +540,18 @@ for the remote branch on GitHub.
|
||||
|
||||
To delete our better project manager branch locally, use this command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git branch -d better-project-manager
|
||||
```
|
||||
|
||||
Alternatively, if the branch hadn't been merged yet and we wanted to delete it anyway, instead
|
||||
of `-d` you would use `-D`.
|
||||
|
||||
Next, to delete the remote branch on GitHub use this command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git push origin -d better-project-manager
|
||||
```
|
||||
|
||||
You can also delete the remote branch from the GitHub PR itself, a button should appear once
|
||||
it has been merged or closed.
|
||||
|
@ -70,9 +70,11 @@ When you create a new class or modify the engine's API, you need to re-generate
|
||||
To do so, you first need to compile Godot. See the
|
||||
`doc_introduction_to_the_buildsystem` page to learn how. Then, execute the
|
||||
compiled Godot binary from the Godot root directory with the `--doctool` option.
|
||||
For example, if you're on 64-bit Linux, the command is::
|
||||
For example, if you're on 64-bit Linux, the command is:
|
||||
|
||||
```
|
||||
./bin/godot.linuxbsd.tools.64 --doctool
|
||||
```
|
||||
|
||||
The XML files in doc/classes should then be up-to-date with current Godot Engine
|
||||
features. You can then check what changed using the `git diff` command. Please
|
||||
|
@ -61,15 +61,15 @@ Setting up the buildsystem
|
||||
- Accept the SDK component licenses by running the following command
|
||||
where `android_sdk_path` is the path to the Android SDK, then answering all the prompts with `y`:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
tools/bin/sdkmanager --sdk_root=( android_sdk_path> --licenses
|
||||
```
|
||||
|
||||
- Complete setup by running the following command where `android_sdk_path` is the path to the Android SDK.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
tools/bin/sdkmanager --sdk_root=( android_sdk_path> "platform-tools" "build-tools;30.0.3" "platforms;android-29" "cmdline-tools;latest" "cmake;3.10.2.4988404"
|
||||
```
|
||||
|
||||
See also:
|
||||
To set the environment variable on Windows, press :kbd:`Windows + R`, type
|
||||
@ -95,8 +95,7 @@ root directory with the following arguments:
|
||||
|
||||
- Release template (used when exporting with **Debugging Enabled** unchecked)
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=android target=release android_arch=armv7
|
||||
scons platform=android target=release android_arch=arm64v8
|
||||
cd platform/android/java
|
||||
@ -104,14 +103,13 @@ root directory with the following arguments:
|
||||
.\gradlew generateGodotTemplates
|
||||
# On Linux and macOS
|
||||
./gradlew generateGodotTemplates
|
||||
|
||||
```
|
||||
|
||||
The resulting APK will be located at `bin/android_release.apk`.
|
||||
|
||||
- Debug template (used when exporting with **Debugging Enabled** checked)
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=android target=release_debug android_arch=armv7
|
||||
scons platform=android target=release_debug android_arch=arm64v8
|
||||
cd platform/android/java
|
||||
@ -119,7 +117,7 @@ The resulting APK will be located at `bin/android_release.apk`.
|
||||
.\gradlew generateGodotTemplates
|
||||
# On Linux and macOS
|
||||
./gradlew generateGodotTemplates
|
||||
|
||||
```
|
||||
|
||||
The resulting APK will be located at `bin/android_debug.apk`.
|
||||
|
||||
@ -131,8 +129,7 @@ command a third and fourth time with the `android_arch=x86`, and
|
||||
`android_arch=x86_64` arguments before building the APK with Gradle. For
|
||||
example, for the release template:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=android target=release android_arch=armv7
|
||||
scons platform=android target=release android_arch=arm64v8
|
||||
scons platform=android target=release android_arch=x86
|
||||
@ -142,7 +139,7 @@ example, for the release template:
|
||||
.\gradlew generateGodotTemplates
|
||||
# On Linux and macOS
|
||||
./gradlew generateGodotTemplates
|
||||
|
||||
```
|
||||
|
||||
This will create a fat binary that works on all platforms.
|
||||
The final APK size of exported projects will depend on the platforms you choose
|
||||
@ -154,14 +151,13 @@ Cleaning the generated export templates
|
||||
|
||||
You can use the following commands to remove the generated export templates:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
cd platform/android/java
|
||||
# On Windows
|
||||
.\gradlew cleanGodotTemplates
|
||||
# On Linux and macOS
|
||||
./gradlew cleanGodotTemplates
|
||||
|
||||
```
|
||||
|
||||
Using the export templates
|
||||
--------------------------
|
||||
@ -226,9 +222,9 @@ If so:
|
||||
|
||||
If it still fails, open a command line and run `logcat ( https://developer.android.com/studio/command-line/logcat )`:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
adb logcat
|
||||
```
|
||||
|
||||
Then check the output while the application is installed;
|
||||
the error message should be presented there.
|
||||
|
@ -30,24 +30,24 @@ Compiling
|
||||
|
||||
Open a Terminal, go to the root dir of the engine source code and type:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ scons p=iphone target=debug
|
||||
```
|
||||
|
||||
for a debug build, or:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ scons p=iphone target=release
|
||||
```
|
||||
|
||||
for a release build (check `platform/iphone/detect.py` for the compiler
|
||||
flags used for each configuration).
|
||||
|
||||
Alternatively, you can run
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ scons p=iphone arch=x86_64 target=debug
|
||||
```
|
||||
|
||||
for a Simulator executable.
|
||||
|
||||
@ -57,24 +57,24 @@ The best way to provide these is to create a bundle in which there are both 32-b
|
||||
It can be done in three steps: first compile the 32-bit version, then compile the 64-bit version and then use `lipo` to bundle them into one "universal" binary.
|
||||
All those steps can be performed with following commands:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ scons p=iphone tools=no target=release arch=arm
|
||||
$ scons p=iphone tools=no target=release arch=arm64
|
||||
$ lipo -create bin/libgodot.iphone.opt.arm.a bin/libgodot.iphone.opt.arm64.a -output bin/libgodot.iphone.release.fat.a
|
||||
$ lipo -create bin/libgodot_camera_module.iphone.opt.arm.a bin/libgodot_camera_module.iphone.opt.arm64.a -output bin/libgodot_camera_module.iphone.release.fat.a
|
||||
$ lipo -create bin/libgodot_arkit_module.iphone.opt.arm.a bin/libgodot_arkit_module.iphone.opt.arm64.a -output bin/libgodot_arkit_module.iphone.release.fat.a
|
||||
```
|
||||
|
||||
If you also want to provide a simulator build (reduces the chance of any linker errors with dependencies), you'll need to build and lipo the `x86_64` architecture as well.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ scons p=iphone tools=no target=release arch=arm
|
||||
$ scons p=iphone tools=no target=release arch=arm64
|
||||
$ scons p=iphone tools=no target=release arch=x86_64
|
||||
$ lipo -create bin/libgodot.iphone.opt.arm.a bin/libgodot.iphone.opt.arm64.a bin/libgodot.iphone.opt.x86_64.a -output bin/libgodot.iphone.release.fat.a
|
||||
$ lipo -create bin/libgodot_camera_module.iphone.opt.arm.a bin/libgodot_camera_module.iphone.opt.arm64.a bin/libgodot_camera_module.iphone.opt.x86_64.a -output bin/libgodot_camera_module.iphone.release.fat.a
|
||||
$ lipo -create bin/libgodot_arkit_module.iphone.opt.arm.a bin/libgodot_arkit_module.iphone.opt.arm64.a bin/libgodot_arkit_module.iphone.opt.x86_64.a -output bin/libgodot_arkit_module.iphone.release.fat.a
|
||||
```
|
||||
|
||||
Run
|
||||
---
|
||||
|
@ -23,18 +23,22 @@ For compiling under macOS, the following is required:
|
||||
|
||||
Note:
|
||||
If you have `Homebrew ( https://brew.sh/ )` installed, you can easily
|
||||
install SCons and yasm using the following command::
|
||||
install SCons and yasm using the following command:
|
||||
|
||||
```
|
||||
brew install scons yasm
|
||||
```
|
||||
|
||||
Installing Homebrew will also fetch the Command Line Tools
|
||||
for Xcode automatically if you don't have them already.
|
||||
|
||||
Similarly, if you have `MacPorts ( https://www.macports.org/ )`
|
||||
installed, you can easily install SCons and yasm using the
|
||||
following command::
|
||||
following command:
|
||||
|
||||
```
|
||||
sudo port install scons yasm
|
||||
```
|
||||
|
||||
See also:
|
||||
To get the Godot source code for compiling, see
|
||||
@ -48,17 +52,23 @@ Compiling
|
||||
|
||||
Start a terminal, go to the root directory of the engine source code.
|
||||
|
||||
To compile for Intel (x86-64) powered Macs, use::
|
||||
To compile for Intel (x86-64) powered Macs, use
|
||||
|
||||
```
|
||||
scons platform=osx arch=x86_64 --jobs=$(sysctl -n hw.logicalcpu)
|
||||
```
|
||||
|
||||
To compile for Apple Silicon (ARM64) powered Macs, use::
|
||||
To compile for Apple Silicon (ARM64) powered Macs, use:
|
||||
|
||||
```
|
||||
scons platform=osx arch=arm64 --jobs=$(sysctl -n hw.logicalcpu)
|
||||
```
|
||||
|
||||
To support both architectures in a single "Universal 2" binary, run the above two commands and then use `lipo` to bundle them together::
|
||||
To support both architectures in a single "Universal 2" binary, run the above two commands and then use `lipo` to bundle them together:
|
||||
|
||||
```
|
||||
lipo -create bin/godot.osx.tools.x86_64 bin/godot.osx.tools.arm64 -output bin/godot.osx.tools.universal
|
||||
```
|
||||
|
||||
If all goes well, the resulting binary executable will be placed in the
|
||||
`bin/` subdirectory. This executable file contains the whole engine and
|
||||
@ -73,30 +83,38 @@ Note:
|
||||
|
||||
To create an `.app` bundle like in the official builds, you need to use the
|
||||
template located in `misc/dist/osx_tools.app`. Typically, for an optimized
|
||||
editor binary built with `target=release_debug`::
|
||||
editor binary built with `target=release_debug`:
|
||||
|
||||
```
|
||||
cp -r misc/dist/osx_tools.app ./Godot.app
|
||||
mkdir -p Godot.app/Contents/MacOS
|
||||
cp bin/godot.osx.opt.tools.universal Godot.app/Contents/MacOS/Godot
|
||||
chmod +x Godot.app/Contents/MacOS/Godot
|
||||
```
|
||||
|
||||
Compiling a headless/server build
|
||||
---------------------------------
|
||||
|
||||
To compile a *headless* build which provides editor functionality to export
|
||||
projects in an automated manner, use::
|
||||
projects in an automated manner, use:
|
||||
|
||||
```
|
||||
scons platform=server tools=yes target=release_debug --jobs=$(sysctl -n hw.logicalcpu)
|
||||
```
|
||||
|
||||
To compile a debug *server* build which can be used with
|
||||
`remote debugging tools ( doc_command_line_tutorial )`, use::
|
||||
`remote debugging tools ( doc_command_line_tutorial )`, use:
|
||||
|
||||
```
|
||||
scons platform=server tools=no target=release_debug --jobs=$(sysctl -n hw.logicalcpu)
|
||||
```
|
||||
|
||||
To compile a release *server* build which is optimized to run dedicated game servers,
|
||||
use::
|
||||
use:
|
||||
|
||||
```
|
||||
scons platform=server tools=no target=release --jobs=$(sysctl -n hw.logicalcpu)
|
||||
```
|
||||
|
||||
Building export templates
|
||||
-------------------------
|
||||
@ -109,39 +127,49 @@ Official templates are universal binaries which support both Intel x86_64 and
|
||||
ARM64 architectures. You can also create export templates that support only one
|
||||
of those two architectures by leaving out the `lipo` step below.
|
||||
|
||||
- For Intel x86_64::
|
||||
- For Intel x86_64:
|
||||
|
||||
```
|
||||
scons platform=osx tools=no target=release arch=x86_64 --jobs=$(sysctl -n hw.logicalcpu)
|
||||
scons platform=osx tools=no target=release_debug arch=x86_64 --jobs=$(sysctl -n hw.logicalcpu)
|
||||
```
|
||||
|
||||
- For ARM64 (Apple M1)::
|
||||
- For ARM64 (Apple M1):
|
||||
|
||||
```
|
||||
scons platform=osx tools=no target=release arch=arm64 --jobs=$(sysctl -n hw.logicalcpu)
|
||||
scons platform=osx tools=no target=release_debug arch=arm64 --jobs=$(sysctl -n hw.logicalcpu)
|
||||
```
|
||||
|
||||
To support both architectures in a single "Universal 2" binary, run the above
|
||||
two commands blocks and then use `lipo` to bundle them together::
|
||||
two commands blocks and then use `lipo` to bundle them together:
|
||||
|
||||
```
|
||||
lipo -create bin/godot.osx.opt.x86_64 bin/godot.osx.opt.arm64 -output bin/godot.osx.opt.universal
|
||||
lipo -create bin/godot.osx.opt.debug.x86_64 bin/godot.osx.opt.debug.arm64 -output bin/godot.osx.opt.debug.universal
|
||||
```
|
||||
|
||||
To create an `.app` bundle like in the official builds, you need to use the
|
||||
template located in `misc/dist/osx_template.app`. The release and debug
|
||||
builds should be placed in `osx_template.app/Contents/MacOS` with the names
|
||||
`godot_osx_release.64` and `godot_osx_debug.64` respectively. You can do so
|
||||
with the following commands (assuming a universal build, otherwise replace the
|
||||
`.universal` extension with the one of your arch-specific binaries)::
|
||||
`.universal` extension with the one of your arch-specific binaries):
|
||||
|
||||
```
|
||||
cp -r misc/dist/osx_template.app .
|
||||
mkdir -p osx_template.app/Contents/MacOS
|
||||
cp bin/godot.osx.opt.universal osx_template.app/Contents/MacOS/godot_osx_release.64
|
||||
cp bin/godot.osx.opt.debug.universal osx_template.app/Contents/MacOS/godot_osx_debug.64
|
||||
chmod +x osx_template.app/Contents/MacOS/godot_osx*
|
||||
```
|
||||
|
||||
You can then zip the `osx_template.app` folder to reproduce the `osx.zip`
|
||||
template from the official Godot distribution::
|
||||
template from the official Godot distribution:
|
||||
|
||||
```
|
||||
zip -q -9 -r osx.zip osx_template.app
|
||||
```
|
||||
|
||||
Cross-compiling for macOS from Linux
|
||||
------------------------------------
|
||||
@ -153,9 +181,11 @@ as a target. First, follow the instructions to install it:
|
||||
|
||||
Clone the `OSXCross repository ( https://github.com/tpoechtrager/osxcross )`
|
||||
somewhere on your machine (or download a ZIP file and extract it somewhere),
|
||||
e.g.::
|
||||
e.g.:
|
||||
|
||||
```
|
||||
git clone --depth=1 https://github.com/tpoechtrager/osxcross.git "$HOME/osxcross"
|
||||
```
|
||||
|
||||
1. Follow the instructions to package the SDK:
|
||||
https://github.com/tpoechtrager/osxcross#packaging-the-sdk
|
||||
@ -164,14 +194,20 @@ e.g.::
|
||||
|
||||
After that, you will need to define the `OSXCROSS_ROOT` as the path to
|
||||
the OSXCross installation (the same place where you cloned the
|
||||
repository/extracted the zip), e.g.::
|
||||
repository/extracted the zip), e.g.:
|
||||
|
||||
```
|
||||
export OSXCROSS_ROOT="$HOME/osxcross"
|
||||
```
|
||||
|
||||
Now you can compile with SCons like you normally would::
|
||||
Now you can compile with SCons like you normally would:
|
||||
|
||||
```
|
||||
scons platform=osx
|
||||
```
|
||||
|
||||
If you have an OSXCross SDK version different from the one expected by the SCons buildsystem, you can specify a custom one with the `osxcross_sdk` argument::
|
||||
If you have an OSXCross SDK version different from the one expected by the SCons buildsystem, you can specify a custom one with the `osxcross_sdk` argument:
|
||||
|
||||
```
|
||||
scons platform=osx osxcross_sdk=darwin15
|
||||
```
|
@ -54,9 +54,11 @@ Set the `ANGLE_SRC_PATH` to the directory where you downloaded the ANGLE
|
||||
source code. The build process will also build ANGLE to produce the
|
||||
required DLLs for the selected architecture.
|
||||
|
||||
Once you're set, run the SCons command similarly to the other platforms::
|
||||
Once you're set, run the SCons command similarly to the other platforms:
|
||||
|
||||
```
|
||||
C:\godot>scons platform=uwp
|
||||
```
|
||||
|
||||
Creating UWP export templates
|
||||
-----------------------------
|
||||
@ -66,10 +68,12 @@ You need all three architectures with `debug` and `release` templates to
|
||||
be able to export.
|
||||
|
||||
Open the command prompt for one architecture and run SCons twice (once for
|
||||
each target)::
|
||||
each target):
|
||||
|
||||
```
|
||||
C:\godot>scons platform=uwp target=release_debug
|
||||
C:\godot>scons platform=uwp target=release
|
||||
```
|
||||
|
||||
Repeat for the other architectures.
|
||||
|
||||
@ -84,14 +88,16 @@ under `winrt/10/src/Release_%arch%` (where `%arch%` can be `Win32`,
|
||||
putting them along with the executable.
|
||||
|
||||
Add the files in the `uwp_template` folder to a ZIP. Rename the resulting
|
||||
Zip according to the target/architecture of the template::
|
||||
Zip according to the target/architecture of the template:
|
||||
|
||||
```
|
||||
uwp_x86_debug.zip
|
||||
uwp_x86_release.zip
|
||||
uwp_x64_debug.zip
|
||||
uwp_x64_release.zip
|
||||
uwp_arm_debug.zip
|
||||
uwp_arm_release.zip
|
||||
```
|
||||
|
||||
Move those templates to the `[versionstring]\templates` folder in Godot
|
||||
settings path, where `versionstring` is the version of Godot you have compiled
|
||||
|
@ -35,18 +35,22 @@ and `source ./emsdk_env.sh`/`emsdk_env.bat`.
|
||||
|
||||
Open a terminal and navigate to the root directory of the engine source code.
|
||||
Then instruct SCons to build the JavaScript platform. Specify `target` as
|
||||
either `release` for a release build or `release_debug` for a debug build::
|
||||
either `release` for a release build or `release_debug` for a debug build:
|
||||
|
||||
```
|
||||
scons platform=javascript tools=no target=release
|
||||
scons platform=javascript tools=no target=release_debug
|
||||
```
|
||||
|
||||
By default, the `JavaScript singleton ( doc_javascript_eval )` will be built
|
||||
into the engine. Official export templates also have the JavaScript singleton
|
||||
enabled. Since `eval()` calls can be a security concern, the
|
||||
`javascript_eval` option can be used to build without the singleton::
|
||||
`javascript_eval` option can be used to build without the singleton:
|
||||
|
||||
```
|
||||
scons platform=javascript tools=no target=release javascript_eval=no
|
||||
scons platform=javascript tools=no target=release_debug javascript_eval=no
|
||||
```
|
||||
|
||||
The engine will now be compiled to WebAssembly by Emscripten. Once finished,
|
||||
the resulting file will be placed in the `bin` subdirectory. Its name is
|
||||
@ -54,13 +58,17 @@ the resulting file will be placed in the `bin` subdirectory. Its name is
|
||||
for debug.
|
||||
|
||||
Finally, rename the zip archive to `webassembly_release.zip` for the
|
||||
release template::
|
||||
release template:
|
||||
|
||||
```
|
||||
mv bin/godot.javascript.opt.zip bin/webassembly_release.zip
|
||||
```
|
||||
|
||||
And `webassembly_debug.zip` for the debug template::
|
||||
And `webassembly_debug.zip` for the debug template:
|
||||
|
||||
```
|
||||
mv bin/godot.javascript.opt.debug.zip bin/webassembly_debug.zip
|
||||
```
|
||||
|
||||
Threads and GDNative
|
||||
--------------------
|
||||
@ -70,37 +78,45 @@ performance and compatibility reasons. See the
|
||||
`export page ( doc_javascript_export_options )` for more info.
|
||||
|
||||
You can build the export templates using the option `threads_enabled=yes` or
|
||||
`gdnative_enabled=yes` to enable threads or GDNative support::
|
||||
`gdnative_enabled=yes` to enable threads or GDNative support:
|
||||
|
||||
```
|
||||
scons platform=javascript tools=no threads_enabled=yes target=release
|
||||
scons platform=javascript tools=no threads_enabled=yes target=release_debug
|
||||
|
||||
scons platform=javascript tools=no gdnative_enabled=yes target=release
|
||||
scons platform=javascript tools=no gdnative_enabled=yes target=release_debug
|
||||
```
|
||||
|
||||
Once finished, the resulting file will be placed in the `bin` subdirectory.
|
||||
Its name will have either the `.threads` or `.gdnative` suffix.
|
||||
|
||||
Finally, rename the zip archives to `webassembly_release_threads.zip` and
|
||||
`webassembly_release_gdnative.zip` for the release template::
|
||||
`webassembly_release_gdnative.zip` for the release template:
|
||||
|
||||
```
|
||||
mv bin/godot.javascript.opt.threads.zip bin/webassembly_threads_release.zip
|
||||
mv bin/godot.javascript.opt.gdnative.zip bin/webassembly_gdnative_release.zip
|
||||
```
|
||||
|
||||
And `webassembly_debug_threads.zip` and `webassembly_debug_gdnative.zip` for
|
||||
the debug template::
|
||||
the debug template:
|
||||
|
||||
```
|
||||
mv bin/godot.javascript.opt.debug.threads.zip bin/webassembly_threads_debug.zip
|
||||
mv bin/godot.javascript.opt.debug.gdnative.zip bin/webassembly_gdnative_debug.zip
|
||||
```
|
||||
|
||||
Building the Editor
|
||||
-------------------
|
||||
|
||||
It is also possible to build a version of the Godot editor that can run in the
|
||||
browser. The editor version requires threads support and is not recommended
|
||||
over the native build. You can build the editor with::
|
||||
over the native build. You can build the editor with:
|
||||
|
||||
```
|
||||
scons platform=javascript tools=yes threads_enabled=yes target=release_debug
|
||||
```
|
||||
|
||||
Once finished, the resulting file will be placed in the `bin` subdirectory.
|
||||
Its name will be `godot.javascript.opt.tools.threads.zip`. You can upload the
|
||||
|
@ -28,16 +28,20 @@ For compiling under Windows, the following is required:
|
||||
|
||||
Note:
|
||||
If you have `Scoop ( https://scoop.sh/ )` installed, you can easily
|
||||
install MinGW and other dependencies using the following command::
|
||||
install MinGW and other dependencies using the following command:
|
||||
|
||||
```
|
||||
scoop install gcc python scons make
|
||||
```
|
||||
|
||||
Note:
|
||||
If you have `MSYS2 ( https://www.msys2.org/ )` installed, you can easily
|
||||
install MinGW and other dependencies using the following command::
|
||||
install MinGW and other dependencies using the following command:
|
||||
|
||||
```
|
||||
pacman -S mingw-w64-x86_64-python3-pip mingw-w64-x86_64-gcc \
|
||||
mingw-w64-i686-python3-pip mingw-w64-i686-gcc make
|
||||
```
|
||||
|
||||
For each MSYS2 MinGW subsystem, you should then run
|
||||
`pip3 install scons` in its shell.
|
||||
@ -52,9 +56,11 @@ See also:
|
||||
Setting up SCons
|
||||
----------------
|
||||
|
||||
To install SCons, open the command prompt and run the following command::
|
||||
To install SCons, open the command prompt and run the following command:
|
||||
|
||||
```
|
||||
python -m pip install scons
|
||||
```
|
||||
|
||||
If you are prompted with the message
|
||||
`Defaulting to user installation because normal site-packages is not
|
||||
@ -134,13 +140,17 @@ Running SCons
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
After opening a command prompt, change to the root directory of
|
||||
the engine source code (using `cd`) and type::
|
||||
the engine source code (using `cd`) and type:
|
||||
|
||||
```
|
||||
C:\godot> scons platform=windows
|
||||
```
|
||||
|
||||
You can specify a number of CPU threads to use to speed up the build::
|
||||
You can specify a number of CPU threads to use to speed up the build:
|
||||
|
||||
```
|
||||
C:\godot> scons -j6 platform=windows
|
||||
```
|
||||
|
||||
In general, it is OK to have at least as many threads compiling Godot as you
|
||||
have cores in your CPU, if not one or two more. Feel free to add the `-j`
|
||||
@ -186,9 +196,11 @@ Folder-based editors don't require any particular setup to start working with Go
|
||||
codebase. To edit projects with Visual Studio they need to be set up as a solution.
|
||||
|
||||
You can create a Visual Studio solution via SCons by running SCons with
|
||||
the `vsproj=yes` parameter, like this::
|
||||
the `vsproj=yes` parameter, like this:
|
||||
|
||||
```
|
||||
scons p=windows vsproj=yes
|
||||
```
|
||||
|
||||
You will be able to open Godot's source in a Visual Studio solution now,
|
||||
and able to build Godot using Visual Studio's **Build** button.
|
||||
@ -207,20 +219,20 @@ here are some known ones:
|
||||
+----------------+--------------------------------------------------------------+
|
||||
| **Arch Linux** | Install `mingw-w64-gcc from the AUR`. |
|
||||
+----------------+--------------------------------------------------------------+
|
||||
| **Debian** / | :: |
|
||||
| **Debian** / | |
|
||||
| **Ubuntu** | |
|
||||
| | apt install mingw-w64 |
|
||||
+----------------+--------------------------------------------------------------+
|
||||
| **Fedora** | :: |
|
||||
| **Fedora** | |
|
||||
| | |
|
||||
| | dnf install mingw64-gcc-c++ mingw64-winpthreads-static \ |
|
||||
| | mingw32-gcc-c++ mingw32-winpthreads-static |
|
||||
+----------------+--------------------------------------------------------------+
|
||||
| **macOS** | :: |
|
||||
| **macOS** | |
|
||||
| | |
|
||||
| | brew install mingw-w64 |
|
||||
+----------------+--------------------------------------------------------------+
|
||||
| **Mageia** | :: |
|
||||
| **Mageia** | |
|
||||
| | |
|
||||
| | urpmi mingw64-gcc-c++ mingw64-winpthreads-static \ |
|
||||
| | mingw32-gcc-c++ mingw32-winpthreads-static |
|
||||
@ -229,24 +241,30 @@ here are some known ones:
|
||||
.. _mingw-w64-gcc from the AUR: https://aur.archlinux.org/packages/mingw-w64-gcc/
|
||||
|
||||
Before attempting the compilation, SCons will check for
|
||||
the following binaries in your `PATH` environment variable::
|
||||
the following binaries in your `PATH` environment variable:
|
||||
|
||||
```
|
||||
i686-w64-mingw32-gcc
|
||||
x86_64-w64-mingw32-gcc
|
||||
```
|
||||
|
||||
If the binaries are not located in the `PATH` (e.g. `/usr/bin`),
|
||||
you can define the following environment variables to give a hint to
|
||||
the build system::
|
||||
the build system:
|
||||
|
||||
```
|
||||
export MINGW32_PREFIX="/path/to/i686-w64-mingw32-"
|
||||
export MINGW64_PREFIX="/path/to/x86_64-w64-mingw32-"
|
||||
```
|
||||
|
||||
To make sure you are doing things correctly, executing the following in
|
||||
the shell should result in a working compiler (the version output may
|
||||
differ based on your system)::
|
||||
differ based on your system):
|
||||
|
||||
```
|
||||
${MINGW32_PREFIX}gcc --version
|
||||
# i686-w64-mingw32-gcc (GCC) 6.1.0 20160427 (Mageia MinGW 6.1.0-1.mga6)
|
||||
```
|
||||
|
||||
Troubleshooting
|
||||
~~~~~~~~~~~~~~~
|
||||
@ -256,43 +274,53 @@ Cross-compiling from some Ubuntu versions may lead to
|
||||
due to a default configuration lacking support for POSIX threading.
|
||||
|
||||
You can change that configuration following those instructions,
|
||||
for 64-bit::
|
||||
for 64-bit:
|
||||
|
||||
```
|
||||
sudo update-alternatives --config x86_64-w64-mingw32-gcc
|
||||
<choose x86_64-w64-mingw32-gcc-posix from the list>
|
||||
sudo update-alternatives --config x86_64-w64-mingw32-g++
|
||||
<choose x86_64-w64-mingw32-g++-posix from the list>
|
||||
```
|
||||
|
||||
And for 32-bit::
|
||||
And for 32-bit:
|
||||
|
||||
```
|
||||
sudo update-alternatives --config i686-w64-mingw32-gcc
|
||||
<choose i686-w64-mingw32-gcc-posix from the list>
|
||||
sudo update-alternatives --config i686-w64-mingw32-g++
|
||||
<choose i686-w64-mingw32-g++-posix from the list>
|
||||
```
|
||||
|
||||
Creating Windows export templates
|
||||
---------------------------------
|
||||
|
||||
Windows export templates are created by compiling Godot without the editor,
|
||||
with the following flags::
|
||||
with the following flags:
|
||||
|
||||
```
|
||||
C:\godot> scons platform=windows tools=no target=release_debug bits=32
|
||||
C:\godot> scons platform=windows tools=no target=release bits=32
|
||||
C:\godot> scons platform=windows tools=no target=release_debug bits=64
|
||||
C:\godot> scons platform=windows tools=no target=release bits=64
|
||||
```
|
||||
|
||||
If you plan on replacing the standard export templates, copy these to the
|
||||
following location, replacing `( version )` with the version identifier
|
||||
(such as `3.1.1.stable` or `3.2.dev`)::
|
||||
(such as `3.1.1.stable` or `3.2.dev`):
|
||||
|
||||
```
|
||||
%USERPROFILE%\AppData\Roaming\Godot\templates\<version>\
|
||||
```
|
||||
|
||||
With the following names::
|
||||
With the following names:
|
||||
|
||||
```
|
||||
windows_32_debug.exe
|
||||
windows_32_release.exe
|
||||
windows_64_debug.exe
|
||||
windows_64_release.exe
|
||||
```
|
||||
|
||||
However, if you are using custom modules or custom engine code, you
|
||||
may instead want to configure your binaries as custom export templates
|
||||
|
@ -41,60 +41,60 @@ See also:
|
||||
Distro-specific one-liners
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **Alpine Linux** | :: |
|
||||
| **Alpine Linux** | |
|
||||
| | |
|
||||
| | apk add scons pkgconf gcc g++ libx11-dev libxcursor-dev libxinerama-dev libxi-dev libxrandr-dev \ |
|
||||
| | mesa-dev libexecinfo-dev eudev-dev alsa-lib-dev pulseaudio-dev |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **Arch Linux** | :: |
|
||||
| **Arch Linux** | |
|
||||
| | |
|
||||
| | pacman -S --needed scons pkgconf gcc libxcursor libxinerama libxi libxrandr mesa glu libglvnd \ |
|
||||
| | alsa-lib pulseaudio yasm |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **Debian** / | :: |
|
||||
| **Debian** / | |
|
||||
| **Ubuntu** | |
|
||||
| | sudo apt-get install build-essential scons pkg-config libx11-dev libxcursor-dev libxinerama-dev \ |
|
||||
| | libgl1-mesa-dev libglu-dev libasound2-dev libpulse-dev libudev-dev libxi-dev libxrandr-dev yasm |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **Fedora** | :: |
|
||||
| **Fedora** | |
|
||||
| | |
|
||||
| | sudo dnf install scons pkgconfig libX11-devel libXcursor-devel libXrandr-devel libXinerama-devel \ |
|
||||
| | libXi-devel mesa-libGL-devel mesa-libGLU-devel alsa-lib-devel pulseaudio-libs-devel \ |
|
||||
| | libudev-devel yasm gcc-c++ libstdc++-static libatomic-static |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **FreeBSD** | :: |
|
||||
| **FreeBSD** | |
|
||||
| | |
|
||||
| | sudo pkg install py37-scons pkgconf xorg-libraries libXcursor libXrandr libXi xorgproto libGLU \ |
|
||||
| | alsa-lib pulseaudio yasm |
|
||||
| | |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **Gentoo** | :: |
|
||||
| **Gentoo** | |
|
||||
| | |
|
||||
| | emerge -an dev-util/scons x11-libs/libX11 x11-libs/libXcursor x11-libs/libXinerama x11-libs/libXi \ |
|
||||
| | media-libs/mesa media-libs/glu media-libs/alsa-lib media-sound/pulseaudio dev-lang/yasm |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **Mageia** | :: |
|
||||
| **Mageia** | |
|
||||
| | |
|
||||
| | urpmi scons task-c++-devel pkgconfig "pkgconfig(alsa)" "pkgconfig(glu)" "pkgconfig(libpulse)" \ |
|
||||
| | "pkgconfig(udev)" "pkgconfig(x11)" "pkgconfig(xcursor)" "pkgconfig(xinerama)" "pkgconfig(xi)" \ |
|
||||
| | "pkgconfig(xrandr)" yasm |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **OpenBSD** | :: |
|
||||
| **OpenBSD** | |
|
||||
| | |
|
||||
| | pkg_add python scons llvm yasm |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **openSUSE** | :: |
|
||||
| **openSUSE** | |
|
||||
| | |
|
||||
| | sudo zypper install scons pkgconfig libX11-devel libXcursor-devel libXrandr-devel libXinerama-devel \ |
|
||||
| | libXi-devel Mesa-libGL-devel alsa-devel libpulse-devel libudev-devel libGLU1 yasm |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **NetBSD** | :: |
|
||||
| **NetBSD** | |
|
||||
| | |
|
||||
| | pkg_add pkg-config py37-scons yasm |
|
||||
| | |
|
||||
| | For audio support, you can optionally install `pulseaudio`. |
|
||||
+------------------+-----------------------------------------------------------------------------------------------------------+
|
||||
| **Solus** | :: |
|
||||
| **Solus** | |
|
||||
| | |
|
||||
| | sudo eopkg install -c system.devel scons libxcursor-devel libxinerama-devel libxi-devel \ |
|
||||
| | libxrandr-devel mesalib-devel libglu alsa-lib-devel pulseaudio-devel yasm |
|
||||
@ -105,9 +105,9 @@ Compiling
|
||||
|
||||
Start a terminal, go to the root dir of the engine source code and type:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons -j8 platform=x11
|
||||
```
|
||||
|
||||
A good rule of thumb for the `-j` (*jobs*) flag, is to have at least as many
|
||||
threads compiling Godot as you have cores in your CPU, if not one or two more.
|
||||
@ -123,9 +123,9 @@ Note:
|
||||
|
||||
If you wish to compile using Clang rather than GCC, use this command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=x11 use_llvm=yes
|
||||
```
|
||||
|
||||
Using Clang appears to be a requirement for OpenBSD, otherwise fonts
|
||||
would not build.
|
||||
@ -150,19 +150,25 @@ Compiling a headless/server build
|
||||
---------------------------------
|
||||
|
||||
To compile a *headless* build which provides editor functionality to export
|
||||
projects in an automated manner, use::
|
||||
projects in an automated manner, use:
|
||||
|
||||
```
|
||||
scons -j8 platform=server tools=yes target=release_debug
|
||||
```
|
||||
|
||||
To compile a debug *server* build which can be used with
|
||||
`remote debugging tools ( doc_command_line_tutorial )`, use::
|
||||
`remote debugging tools ( doc_command_line_tutorial )`, use:
|
||||
|
||||
```
|
||||
scons -j8 platform=server tools=no target=release_debug
|
||||
```
|
||||
|
||||
To compile a *server* build which is optimized to run dedicated game servers,
|
||||
use::
|
||||
use:
|
||||
|
||||
```
|
||||
scons -j8 platform=server tools=no target=release
|
||||
```
|
||||
|
||||
Building export templates
|
||||
-------------------------
|
||||
@ -181,35 +187,35 @@ following parameters:
|
||||
|
||||
- (32 bits)
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=x11 tools=no target=release bits=32
|
||||
scons platform=x11 tools=no target=release_debug bits=32
|
||||
```
|
||||
|
||||
- (64 bits)
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=x11 tools=no target=release bits=64
|
||||
scons platform=x11 tools=no target=release_debug bits=64
|
||||
```
|
||||
|
||||
Note that cross-compiling for the opposite bits (64/32) as your host
|
||||
platform is not always straight-forward and might need a chroot environment.
|
||||
|
||||
To create standard export templates, the resulting files must be copied to:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$HOME/.local/share/godot/templates/[gd-version]/
|
||||
```
|
||||
|
||||
and named like this (even for \*BSD which is seen as "Linux X11" by Godot):
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
linux_x11_32_debug
|
||||
linux_x11_32_release
|
||||
linux_x11_64_debug
|
||||
linux_x11_64_release
|
||||
```
|
||||
|
||||
However, if you are writing your custom modules or custom C++ code, you
|
||||
might instead want to configure your binaries as custom export templates
|
||||
@ -232,9 +238,11 @@ the default GCC + GNU ld setup:
|
||||
- Clang tends to give more useful error messages compared to GCC.
|
||||
|
||||
To do so, install Clang and the `lld` package from your distribution's package manager
|
||||
then use the following SCons command::
|
||||
then use the following SCons command:
|
||||
|
||||
```
|
||||
scons platform=x11 use_llvm=yes use_lld=yes
|
||||
```
|
||||
|
||||
After the build is completed, a new binary with a `.llvm` suffix will be
|
||||
created in the `bin/` folder.
|
||||
@ -256,9 +264,11 @@ to get even faster builds.
|
||||
- Use `cd` to reach the extracted Pyston folder from a terminal,
|
||||
then run `./pyston -m pip install scons` to install SCons within Pyston.
|
||||
- To make SCons via Pyston easier to run, create a symbolic link of its wrapper
|
||||
script to a location in your `PATH` environment variable::
|
||||
script to a location in your `PATH` environment variable:
|
||||
|
||||
```
|
||||
ln -s ~/.local/opt/pyston/bin/scons ~/.local/bin/pyston-scons
|
||||
```
|
||||
|
||||
- Instead of running `scons ( build arguments )`, run `pyston-scons ( build arguments )`
|
||||
to compile Godot.
|
||||
|
@ -30,16 +30,16 @@ Step by step
|
||||
Alternatively, you can generate it yourself using
|
||||
`OpenSSL ( https://www.openssl.org/ )` command-line tools:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
openssl rand -hex 32 > godot.gdkey
|
||||
```
|
||||
|
||||
The output in `godot.gdkey` should be similar to:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# NOTE: Do not use the key below! Generate your own key instead.
|
||||
aeb1bc56aaf580cc31784e9c41551e9ed976ecba10d315db591e749f3f64890f
|
||||
```
|
||||
|
||||
You can generate the key without redirecting the output to a file, but
|
||||
that way you can minimize the risk of exposing the key.
|
||||
@ -76,8 +76,7 @@ If you get an error like below, it means the key wasn't properly included in
|
||||
your Godot build. Godot is encrypting the scripts during export, but can't read
|
||||
them at runtime.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
ERROR: open_and_parse: Condition "String::md5(md5.digest) != String::md5(md5d)" is true. Returning: ERR_FILE_CORRUPT
|
||||
At: core/io/file_access_encrypted.cpp:103
|
||||
ERROR: load_byte_code: Condition ' err ' is true. returned: err
|
||||
@ -98,3 +97,4 @@ them at runtime.
|
||||
At: core/object.cpp:2081
|
||||
ERROR: clear: Resources Still in use at Exit!
|
||||
At: core/resource.cpp:425
|
||||
```
|
@ -53,69 +53,69 @@ darling-dmg
|
||||
|
||||
Clone the repository on your machine:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git clone https://github.com/darlinghq/darling-dmg.git
|
||||
```
|
||||
|
||||
Build it:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ cd darling-dmg
|
||||
$ mkdir build
|
||||
$ cd build
|
||||
$ cmake .. -DCMAKE_BUILD_TYPE=Release
|
||||
$ make -j 4 # The number is the amount of cores your processor has, for faster build
|
||||
$ cd ../..
|
||||
```
|
||||
|
||||
Preparing the SDK
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Mount the XCode image:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ mkdir xcode
|
||||
$ ./darling-dmg/build/darling-dmg /path/to/Xcode_7.1.1.dmg xcode
|
||||
[...]
|
||||
Everything looks OK, disk mounted
|
||||
```
|
||||
|
||||
Extract the iOS SDK:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ mkdir -p iPhoneSDK/iPhoneOS9.1.sdk
|
||||
$ cp -r xcode/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/* iPhoneSDK/iPhoneOS9.1.sdk
|
||||
$ cp -r xcode/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/* iPhoneSDK/iPhoneOS9.1.sdk/usr/include/c++
|
||||
$ fusermount -u xcode # unmount the image
|
||||
```
|
||||
|
||||
Pack the SDK:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ cd iPhoneSDK
|
||||
$ tar -cf - * | xz -9 -c - > iPhoneOS9.1.sdk.tar.xz
|
||||
```
|
||||
|
||||
Toolchain
|
||||
~~~~~~~~~
|
||||
|
||||
Build cctools:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ git clone https://github.com/tpoechtrager/cctools-port.git
|
||||
$ cd cctools-port/usage_examples/ios_toolchain
|
||||
$ ./build.sh /path/iPhoneOS9.1.sdk.tar.xz arm64
|
||||
```
|
||||
|
||||
Copy the tools to a nicer place. Note that the SCons scripts for
|
||||
building will look under `usr/bin` inside the directory you provide
|
||||
for the toolchain binaries, so you must copy to such subdirectory, akin
|
||||
to the following commands:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ mkdir -p /home/user/iostoolchain/usr
|
||||
$ cp -r target/bin /home/user/iostoolchain/usr/
|
||||
```
|
||||
|
||||
Now you should have the iOS toolchain binaries in
|
||||
`/home/user/iostoolchain/usr/bin`.
|
||||
@ -131,17 +131,17 @@ SCons build command.
|
||||
For the iPhone platform to be detected, you need the `OSXCROSS_IOS`
|
||||
environment variable defined to anything.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ export OSXCROSS_IOS=anything
|
||||
```
|
||||
|
||||
Now you can compile for iPhone using SCons like the standard Godot
|
||||
way, with some additional arguments to provide the correct paths:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ scons -j 4 platform=iphone arch=arm target=release_debug IPHONESDK="/path/to/iPhoneSDK" IPHONEPATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"
|
||||
$ scons -j 4 platform=iphone arch=arm64 target=release_debug IPHONESDK="/path/to/iPhoneSDK" IPHONEPATH="/path/to/iostoolchain" ios_triple="arm-apple-darwin11-"
|
||||
```
|
||||
|
||||
Producing fat binaries
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -151,11 +151,10 @@ Apple requires a fat binary with both architectures (`armv7` and
|
||||
`arm-apple-darwin11-lipo` executable. The following example assumes
|
||||
you are in the root Godot source directory:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
$ /path/to/iostoolchain/usr/bin/arm-apple-darwin11-lipo -create bin/libgodot.iphone.opt.debug.arm.a bin/libgodot.iphone.opt.debug.arm64.a -output bin/libgodot.iphone.debug.fat.a
|
||||
$ /path/to/iostoolchain/usr/bin/arm-apple-darwin11-lipo -create bin/libgodot_camera_module.iphone.opt.debug.arm.a bin/libgodot_camera_module.iphone.opt.debug.arm64.a -output bin/libgodot_camera_module.iphone.debug.fat.a
|
||||
$ /path/to/iostoolchain/usr/bin/arm-apple-darwin11-lipo -create bin/libgodot_arkit_module.iphone.opt.debug.arm.a bin/libgodot_arkit_module.iphone.opt.debug.arm64.a -output bin/libgodot_arkit_module.iphone.debug.fat.a
|
||||
|
||||
```
|
||||
|
||||
Then you will have iOS fat binaries in `bin` directory.
|
||||
|
@ -28,24 +28,26 @@ Afterwards, to get the latest development version of the Godot source code
|
||||
If you are using the `git` command line client, this is done by entering
|
||||
the following in a terminal:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
git clone https://github.com/godotengine/godot.git
|
||||
# You can add the --depth 1 argument to omit the commit history.
|
||||
# Faster, but not all Git operations (like blame) will work.
|
||||
```
|
||||
|
||||
For any stable release, visit the `release page ( https://github.com/godotengine/godot/releases )`
|
||||
and click on the link for the release you want.
|
||||
You can then download and extract the source from the download link on the page.
|
||||
|
||||
With `git`, you can also clone a stable release by specifying its branch or tag
|
||||
after the `--branch` (or just `-b`) argument::
|
||||
after the `--branch` (or just `-b`) argument:
|
||||
|
||||
```
|
||||
# Clone the continuously maintained stable branch (`3.x` as of writing).
|
||||
git clone https://github.com/godotengine/godot.git -b 3.x
|
||||
|
||||
# Clone the `3.2.3-stable` tag. This is a fixed revision that will never change.
|
||||
git clone https://github.com/godotengine/godot.git -b 3.2.3-stable
|
||||
```
|
||||
|
||||
There are also generally branches besides `master` for each major version.
|
||||
|
||||
|
@ -59,8 +59,9 @@ SCons is invoked by just calling `scons`. If no platform is specified,
|
||||
SCons will detect the target platform automatically based on the host platform.
|
||||
It will then start building for the target platform right away.
|
||||
|
||||
To list the available target platforms, use `scons platform=list`::
|
||||
To list the available target platforms, use `scons platform=list`:
|
||||
|
||||
```
|
||||
scons platform=list
|
||||
scons: Reading SConscript files ...
|
||||
The following platforms are available:
|
||||
@ -72,13 +73,14 @@ To list the available target platforms, use `scons platform=list`::
|
||||
x11
|
||||
|
||||
Please run SCons again and select a valid platform: platform=<string>
|
||||
```
|
||||
|
||||
To build for a platform (for example, x11), run with the `platform=` (or
|
||||
`p=` to make it short) argument:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=x11
|
||||
```
|
||||
|
||||
This will start the build process, which will take a while. If you want
|
||||
SCons to build faster, use the `-j <cores )` parameter to specify how many
|
||||
@ -87,32 +89,36 @@ can use your computer for something else :)
|
||||
|
||||
Example for using 4 cores:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=x11 -j 4
|
||||
```
|
||||
|
||||
Resulting binary
|
||||
----------------
|
||||
|
||||
The resulting binaries will be placed in the `bin/` subdirectory,
|
||||
generally with this naming convention::
|
||||
generally with this naming convention:
|
||||
|
||||
```
|
||||
godot.<platform>.[opt].[tools/debug].<architecture>[extension]
|
||||
```
|
||||
|
||||
For the previous build attempt, the result would look like this::
|
||||
For the previous build attempt, the result would look like this:
|
||||
|
||||
```
|
||||
ls bin
|
||||
bin/godot.x11.tools.64
|
||||
```
|
||||
|
||||
This means that the binary is for X11, is not optimized, has tools (the
|
||||
whole editor) compiled in, and is meant for 64 bits.
|
||||
|
||||
A Windows binary with the same configuration will look like this:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
```
|
||||
C:\godot> dir bin/
|
||||
godot.windows.tools.64.exe
|
||||
```
|
||||
|
||||
Copy that binary to any location you like, as it contains the project manager,
|
||||
editor and all means to execute the game. However, it lacks the data to export
|
||||
@ -133,10 +139,9 @@ disabled for everything else. Disabling tools produces a binary that can
|
||||
run projects but that does not include the editor or the project
|
||||
manager.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=<platform> tools=yes/no
|
||||
|
||||
```
|
||||
|
||||
|
||||
Target
|
||||
@ -154,9 +159,9 @@ Target controls optimization and debug flags. Each mode means:
|
||||
`tools=yes`, as the editor requires some debug functionality and run-time
|
||||
checks to run.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=<platform> target=debug/release_debug/release
|
||||
```
|
||||
|
||||
This flag appends the `.debug` suffix (for debug), or `.tools` (for debug
|
||||
with tools enabled). When optimization is enabled (release), it appends
|
||||
@ -173,9 +178,9 @@ else.
|
||||
- **64**: Build binaries for 64-bit platforms.
|
||||
- **default**: Build for the architecture that matches the host platform.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons platform=<platform> bits=default/32/64
|
||||
```
|
||||
|
||||
This flag appends `.32` or `.64` suffixes to resulting binaries when
|
||||
relevant. If `bits=default` is used, the suffix will match the detected
|
||||
@ -197,9 +202,9 @@ packages, just like the built-in `modules/` directory.
|
||||
For instance, it's possible to provide both relative, absolute, and user
|
||||
directory paths containing such modules:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons custom_modules="../modules,/abs/path/to/modules,~/src/godot_modules"
|
||||
```
|
||||
|
||||
Note:
|
||||
|
||||
@ -246,14 +251,14 @@ Using a file
|
||||
The default `custom.py` file can be created at the root of the Godot Engine
|
||||
source to initialize any SCons build options passed via the command line:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# custom.py
|
||||
|
||||
optimize = "size"
|
||||
module_mono_enabled = "yes"
|
||||
use_llvm = "yes"
|
||||
extra_suffix = "game_title"
|
||||
```
|
||||
|
||||
You can also disable some of the builtin modules before compiling, saving some
|
||||
time it takes to build the engine. See `doc_optimizing_for_size` page for more details.
|
||||
@ -269,9 +274,9 @@ See also:
|
||||
Another custom file can be specified explicitly with the `profile` command
|
||||
line option, both overriding the default build configuration:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
scons profile=path/to/custom.py
|
||||
```
|
||||
|
||||
Note:
|
||||
Build options set from the file can be overridden by the command line
|
||||
@ -279,8 +284,7 @@ Note:
|
||||
|
||||
It's also possible to override the options conditionally:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# custom.py
|
||||
|
||||
import version
|
||||
@ -290,6 +294,7 @@ It's also possible to override the options conditionally:
|
||||
pass
|
||||
elif version.major == 4:
|
||||
pass
|
||||
```
|
||||
|
||||
Using the SCONSFLAGS
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
@ -324,8 +329,7 @@ If you download the official export templates package and unzip it, you
|
||||
will notice that most files are optimized binaries or packages for each
|
||||
platform:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
android_debug.apk
|
||||
android_release.apk
|
||||
webassembly_debug.zip
|
||||
@ -342,6 +346,7 @@ platform:
|
||||
windows_32_release.exe
|
||||
windows_64_debug.exe
|
||||
windows_64_release.exe
|
||||
```
|
||||
|
||||
To create those yourself, follow the instructions detailed for each
|
||||
platform in this same tutorial section. Each platform explains how to
|
||||
|
@ -30,9 +30,9 @@ If you build Windows (MinGW), Linux or macOS binaries from source, remember to
|
||||
strip debug symbols from binaries by installing the `strip` package from your
|
||||
distribution then running:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
strip path/to/godot.binary
|
||||
```
|
||||
|
||||
On Windows, `strip.exe` is included in most MinGW toolchain setups.
|
||||
|
||||
@ -59,9 +59,9 @@ Optimizing for size instead of speed
|
||||
Godot 3.1 onwards allows compiling using size optimizations (instead of speed).
|
||||
To enable this, set the `optimize` flag to `size`:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons p=windows target=release tools=no optimize=size
|
||||
```
|
||||
|
||||
Some platforms such as WebAssembly already use this mode by default.
|
||||
|
||||
@ -77,9 +77,9 @@ terms of performance and file size. It works by eliminating duplicate
|
||||
template functions and unused code. It can currently be used with the GCC
|
||||
and MSVC compilers:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons p=windows target=release tools=no use_lto=yes
|
||||
```
|
||||
|
||||
Linking becomes much slower and more RAM-consuming with this option,
|
||||
so it should be used only for release builds:
|
||||
@ -98,9 +98,9 @@ Disabling 3D
|
||||
|
||||
For 2D games, having the whole 3D engine available usually makes no sense. Because of this, there is a build flag to disable it:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons p=windows target=release tools=no disable_3d=yes
|
||||
```
|
||||
|
||||
Tools must be disabled in order to use this flag, as the editor is not designed
|
||||
to operate without 3D support. Without it, the binary size can be reduced
|
||||
@ -116,9 +116,9 @@ Disabling advanced GUI objects
|
||||
Most small games don't require complex GUI controls such as Tree, ItemList,
|
||||
TextEdit or GraphEdit. They can be disabled using a build flag:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons p=windows target=release tools=no disable_advanced_gui=yes
|
||||
```
|
||||
|
||||
This is everything that will be disabled:
|
||||
|
||||
@ -155,17 +155,17 @@ Disabling unwanted modules
|
||||
A lot of Godot's functions are offered as modules.
|
||||
You can see a list of modules with the following command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons --help
|
||||
```
|
||||
|
||||
The list of modules that can be disabled will appear, together with all
|
||||
build options. If you are working on a simple 2D game, you could disable
|
||||
a lot of them:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
scons p=windows target=release tools=no module_arkit_enabled=no module_assimp_enabled=no module_bmp_enabled=no module_bullet_enabled=no module_camera_enabled=no module_csg_enabled=no module_dds_enabled=no module_enet_enabled=no module_etc_enabled=no module_gdnative_enabled=no module_gridmap_enabled=no module_hdr_enabled=no module_jsonrpc_enabled=no module_mbedtls_enabled=no module_mobile_vr_enabled=no module_opensimplex_enabled=no module_opus_enabled=no module_pvr_enabled=no module_recast_enabled=no module_regex_enabled=no module_squish_enabled=no module_svg_enabled=no module_tga_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_upnp_enabled=no module_vhacd_enabled=no module_vorbis_enabled=no module_webm_enabled=no module_webrtc_enabled=no module_websocket_enabled=no module_xatlas_unwrap_enabled=no
|
||||
```
|
||||
|
||||
If this proves not to work for your use case, you should review the list of
|
||||
modules and see which ones you actually still need for your game (e.g. you
|
||||
@ -176,8 +176,7 @@ Alternatively, you can supply a list of disabled modules by creating
|
||||
`custom.py` at the root of the source, with the contents similar to the
|
||||
following:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# custom.py
|
||||
|
||||
module_arkit_enabled = "no"
|
||||
@ -212,6 +211,7 @@ following:
|
||||
module_webrtc_enabled = "no"
|
||||
module_websocket_enabled = "no"
|
||||
module_xatlas_unwrap_enabled = "no"
|
||||
```
|
||||
|
||||
See also:
|
||||
|
||||
|
@ -13,14 +13,13 @@ a speech synthesis (text-to-speech) library written in C++.
|
||||
|
||||
To bind to an external library, set up a module directory similar to the Summator example:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
godot/modules/tts/
|
||||
```
|
||||
|
||||
Next, you will create a header file with a simple TTS class:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* tts.h */
|
||||
|
||||
#ifndef GODOT_TTS_H
|
||||
@ -41,11 +40,11 @@ Next, you will create a header file with a simple TTS class:
|
||||
};
|
||||
|
||||
#endif // GODOT_TTS_H
|
||||
```
|
||||
|
||||
And then you'll add the cpp file.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* tts.cpp */
|
||||
|
||||
#include "tts.h"
|
||||
@ -66,14 +65,15 @@ And then you'll add the cpp file.
|
||||
TTS::TTS() {
|
||||
festival_initialize(true, 210000); //not the best way to do it as this should only ever be called once.
|
||||
}
|
||||
```
|
||||
|
||||
Just as before, the new class needs to be registered somehow, so two more files
|
||||
need to be created:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
register_types.h
|
||||
register_types.cpp
|
||||
```
|
||||
|
||||
.. important::
|
||||
These files must be in the top-level folder of your module (next to your
|
||||
@ -81,16 +81,15 @@ need to be created:
|
||||
|
||||
These files should contain the following:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.h */
|
||||
|
||||
void register_tts_types();
|
||||
void unregister_tts_types();
|
||||
/* yes, the word in the middle must be the same as the module folder name */
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.cpp */
|
||||
|
||||
#include "register_types.h"
|
||||
@ -105,28 +104,29 @@ These files should contain the following:
|
||||
void unregister_tts_types() {
|
||||
// Nothing to do here in this example.
|
||||
}
|
||||
```
|
||||
|
||||
Next, you need to create a `SCsub` file so the build system compiles
|
||||
this module:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# SCsub
|
||||
|
||||
Import('env')
|
||||
|
||||
env_tts = env.Clone()
|
||||
env_tts.add_source_files(env.modules_sources, "*.cpp") # Add all cpp files to the build
|
||||
```
|
||||
|
||||
You'll need to install the external library on your machine to get the .a library files. See the library's official
|
||||
documentation for specific instructions on how to do this for your operation system. We've included the
|
||||
installation commands for Linux below, for reference.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
sudo apt-get install festival festival-dev <-- Installs festival and speech_tools libraries
|
||||
apt-cache search festvox-* <-- Displays list of voice packages
|
||||
sudo apt-get install festvox-don festvox-rablpc16k festvox-kallpc16k festvox-kdlpc16k <-- Installs voices
|
||||
```
|
||||
|
||||
.. important::
|
||||
The voices that Festival uses (and any other potential external/3rd-party
|
||||
@ -139,18 +139,18 @@ files accessible to the compiler, while also keeping the module code self-contai
|
||||
festival and speech_tools libraries can be installed from the modules/tts/ directory via
|
||||
git using the following commands:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
git clone https://github.com/festvox/festival
|
||||
git clone https://github.com/festvox/speech_tools
|
||||
```
|
||||
|
||||
If you don't want the external repository source files committed to your repository, you
|
||||
can link to them instead by adding them as submodules (from within the modules/tts/ directory), as seen below:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
git submodule add https://github.com/festvox/festival
|
||||
git submodule add https://github.com/festvox/speech_tools
|
||||
```
|
||||
|
||||
.. important::
|
||||
Please note that Git submodules are not used in the Godot repository. If
|
||||
@ -161,8 +161,7 @@ can link to them instead by adding them as submodules (from within the modules/t
|
||||
To add include directories for the compiler to look at you can append it to the
|
||||
environment's paths:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# These paths are relative to /modules/tts/
|
||||
env_tts.Append(CPPPATH=["speech_tools/include", "festival/src/include"])
|
||||
|
||||
@ -177,13 +176,13 @@ environment's paths:
|
||||
# Check with the documentation of the external library to see which library
|
||||
# files should be included/linked.
|
||||
env.Append(LIBS=['Festival', 'estools', 'estbase', 'eststring'])
|
||||
```
|
||||
|
||||
If you want to add custom compiler flags when building your module, you need to clone
|
||||
`env` first, so it won't add those flags to whole Godot build (which can cause errors).
|
||||
Example `SCsub` with custom flags:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# SCsub
|
||||
|
||||
Import('env')
|
||||
@ -195,11 +194,11 @@ Example `SCsub` with custom flags:
|
||||
# If you need to, you can:
|
||||
# - Append CFLAGS for C code only.
|
||||
# - Append CXXFLAGS for C++ code only.
|
||||
```
|
||||
|
||||
The final module should look like this:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
godot/modules/tts/festival/
|
||||
godot/modules/tts/libpath/libestbase.a
|
||||
godot/modules/tts/libpath/libestools.a
|
||||
@ -212,17 +211,18 @@ The final module should look like this:
|
||||
godot/modules/tts/register_types.h
|
||||
godot/modules/tts/register_types.cpp
|
||||
godot/modules/tts/SCsub
|
||||
```
|
||||
|
||||
Using the module
|
||||
----------------
|
||||
|
||||
You can now use your newly created module from any script:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
var t = TTS.new()
|
||||
var script = "Hello world. This is a test!"
|
||||
var is_spoken = t.say_text(script)
|
||||
print('is_spoken: ', is_spoken)
|
||||
```
|
||||
|
||||
And the output will be `is_spoken: True` if the text is spoken.
|
||||
|
@ -10,8 +10,7 @@ but it can also be useful for those writing custom C++ modules.
|
||||
Print text
|
||||
----------
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Prints a message to standard output.
|
||||
print_line("Message");
|
||||
|
||||
@ -27,6 +26,7 @@ Print text
|
||||
// This can be used to avoid spamming the console output.
|
||||
ERR_PRINT_ONCE("Message");
|
||||
WARN_PRINT_ONCE("Message");
|
||||
```
|
||||
|
||||
If you need to add placeholders in your messages, use format strings as
|
||||
described below.
|
||||
@ -37,8 +37,7 @@ Format a string
|
||||
The `vformat()` function returns a formatted `String`. It behaves
|
||||
in a way similar to C's `sprintf()`:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
vformat("My name is %s.", "Godette");
|
||||
vformat("%d bugs on the wall!", 1234);
|
||||
vformat("Pi is approximately %f.", 3.1416);
|
||||
@ -47,6 +46,7 @@ in a way similar to C's `sprintf()`:
|
||||
// You may need to do this if passing the result as an argument
|
||||
// to a method that expects a `const char *` instead of a String.
|
||||
vformat("My name is %s.", "Godette").c_str();
|
||||
```
|
||||
|
||||
In most cases, try to use `vformat()` instead of string concatenation as it
|
||||
makes for more readable code.
|
||||
@ -56,13 +56,13 @@ Convert an integer or float to a string
|
||||
|
||||
This is mainly useful when printing numbers directly.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Prints "42" using integer-to-string conversion.
|
||||
print_line(itos(42));
|
||||
|
||||
// Prints "123.45" using real-to-string conversion.
|
||||
print_line(rtos(123.45));
|
||||
```
|
||||
|
||||
Internationalize a string
|
||||
-------------------------
|
||||
@ -77,20 +77,20 @@ There are two types of internationalization in Godot's codebase:
|
||||
projects if they provide a translation for the given string. This kind of
|
||||
translation shouldn't be used in editor-only code.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Returns the translated string that matches the user's locale settings.
|
||||
// Translations are located in `editor/translations`.
|
||||
// The localization template is generated automatically; don't modify it.
|
||||
TTR("Exit the editor?");
|
||||
```
|
||||
|
||||
To insert placeholders in localizable strings, wrap the localization macro in a
|
||||
`vformat()` call as follows:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
String file_path = "example.txt";
|
||||
vformat(TTR("Couldn't open \"%s\" for reading."), file_path);
|
||||
```
|
||||
|
||||
Note:
|
||||
|
||||
@ -106,14 +106,14 @@ Clamp a value
|
||||
Godot provides macros for clamping a value with a lower bound (`MAX`), an
|
||||
upper bound (`MIN`) or both (`CLAMP`):
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
int a = 3;
|
||||
int b = 5;
|
||||
|
||||
MAX(b, 6); // 6
|
||||
MIN(2, a); // 2
|
||||
CLAMP(a, 10, 30); // 10
|
||||
```
|
||||
|
||||
This works with any type that can be compared to other values (like `int` and
|
||||
`float`).
|
||||
@ -124,14 +124,14 @@ Microbenchmarking
|
||||
If you want to benchmark a piece of code but don't know how to use a profiler,
|
||||
use this snippet:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
uint64_t begin = OS::get_singleton()->get_ticks_usec();
|
||||
|
||||
// Your code here...
|
||||
|
||||
uint64_t end = OS::get_singleton()->get_ticks_usec();
|
||||
print_line(vformat("Snippet took %d microseconds", end - begin));
|
||||
```
|
||||
|
||||
This will print the time spent between the `begin` declaration and the `end`
|
||||
declaration.
|
||||
@ -149,8 +149,7 @@ Get project/editor settings
|
||||
|
||||
There are four macros available for this:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Returns the specified project setting's value,
|
||||
// defaulting to `false` if it doesn't exist.
|
||||
GLOBAL_DEF("section/subsection/value", false);
|
||||
@ -158,16 +157,17 @@ There are four macros available for this:
|
||||
// Returns the specified editor setting's value,
|
||||
// defaulting to "Untitled" if it doesn't exist.
|
||||
EDITOR_DEF("section/subsection/value", "Untitled");
|
||||
```
|
||||
|
||||
If a default value has been specified elsewhere, don't specify it again to avoid
|
||||
repetition:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Returns the value of the project setting.
|
||||
GLOBAL_GET("section/subsection/value");
|
||||
// Returns the value of the editor setting.
|
||||
EDITOR_GET("section/subsection/value");
|
||||
```
|
||||
|
||||
It's recommended to use `GLOBAL_DEF`/`EDITOR_DEF` only once per setting and
|
||||
use `GLOBAL_GET`/`EDITOR_GET` in all other places where it's referenced.
|
||||
@ -200,8 +200,7 @@ Note:
|
||||
Also, always try to return processable data so the engine can keep running
|
||||
well.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
// Conditionally prints an error message and returns from the function.
|
||||
// Use this in methods which don't return a value.
|
||||
ERR_FAIL_COND_MSG(!mesh.is_valid(), vformat("Couldn't load mesh at: %s", path));
|
||||
@ -237,7 +236,7 @@ Note:
|
||||
// except for testing crash handling code. Godot's philosophy
|
||||
// is to never crash, both in the editor and in exported projects.
|
||||
CRASH_NOW_MSG("Can't predict the future! Aborting.");
|
||||
|
||||
```
|
||||
|
||||
See also:
|
||||
|
||||
|
@ -32,8 +32,7 @@ Importing the project
|
||||
|
||||
- Under **Language Support** open the **Includes/Imports** tab and add the following paths:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
. // A dot, to indicate the root of the Godot project
|
||||
core/
|
||||
core/os/
|
||||
@ -41,6 +40,7 @@ Importing the project
|
||||
drivers/
|
||||
platform/<your_platform>/ // Replace <your_platform> with a folder
|
||||
corresponding to your current platform
|
||||
```
|
||||
|
||||
.. figure:: img/kdevelop_addincludes.png)
|
||||
:figclass: figure-w480
|
||||
|
@ -81,9 +81,9 @@ To enable debugging support you need to edit the external build target's build a
|
||||
the project directory within the script.
|
||||
- Create a script that will give the binary a name that Xcode can recognize, e.g.:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
ln -f ${PROJECT_DIR}/godot/bin/godot.osx.tools.64 ${PROJECT_DIR}/godot/bin/godot
|
||||
```
|
||||
|
||||
.. figure:: img/xcode_7_setup_build_post_action.png)
|
||||
:figclass: figure-w480
|
||||
|
@ -79,24 +79,24 @@ should not be used. Instead, a few other ones are provided.
|
||||
|
||||
For C-style allocation, Godot provides a few macros:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
memalloc()
|
||||
memrealloc()
|
||||
memfree()
|
||||
```
|
||||
|
||||
These are equivalent to the usual malloc, realloc, free of the standard C
|
||||
library.
|
||||
|
||||
For C++-style allocation, special macros are provided:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
memnew( Class / Class(args) )
|
||||
memdelete( instance )
|
||||
|
||||
memnew_arr( Class , amount )
|
||||
memdelete_arr( pointer to array )
|
||||
```
|
||||
|
||||
which are equivalent to new, delete, new[] and delete[].
|
||||
|
||||
@ -107,21 +107,21 @@ For dynamic memory, the PoolVector<> template is provided. PoolVector is a
|
||||
standard vector class, and is very similar to vector in the C++ standard library.
|
||||
To create a PoolVector buffer, use this:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
PoolVector<int> data;
|
||||
```
|
||||
|
||||
PoolVector can be accessed using the [] operator and a few helpers exist for this:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
PoolVector<int>::Read r = data.read()
|
||||
int someint = r[4]
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
PoolVector<int>::Write w = data.write()
|
||||
w[4] = 22;
|
||||
```
|
||||
|
||||
These operations allow fast read/write from PoolVectors and keep it
|
||||
locked until they go out of scope. However, PoolVectors should be used
|
||||
@ -149,11 +149,11 @@ in C++ are often inlined and make the binary size much fatter, both in
|
||||
debug symbols and code. List, Set and Map can be iterated using
|
||||
pointers, like this:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
for(List<int>::Element *E=somelist.front();E;E=E->next()) {
|
||||
print_line(E->get()); // print the element
|
||||
}
|
||||
```
|
||||
|
||||
The Vector<> class also has a few nice features:
|
||||
|
||||
|
@ -45,8 +45,7 @@ ResourceLoader. ResourceLoader loads once and references the same
|
||||
object regardless how many times `load` is called on a specific resource.
|
||||
Therefore, playback state must be self-contained in AudioStreamPlayback.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* audiostream_mytone.h */
|
||||
|
||||
#include "core/reference.h"
|
||||
@ -75,9 +74,9 @@ Therefore, playback state must be self-contained in AudioStreamPlayback.
|
||||
protected:
|
||||
static void _bind_methods();
|
||||
};
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* audiostream_mytone.cpp */
|
||||
|
||||
#include "audiostream_mytone.h"
|
||||
@ -112,6 +111,7 @@ Therefore, playback state must be self-contained in AudioStreamPlayback.
|
||||
ClassDB::bind_method(D_METHOD("reset"), &AudioStreamMyTone::reset);
|
||||
ClassDB::bind_method(D_METHOD("get_stream_name"), &AudioStreamMyTone::get_stream_name);
|
||||
}
|
||||
```
|
||||
|
||||
References:
|
||||
~~~~~~~~~~~
|
||||
@ -126,8 +126,7 @@ AudioStreamPlayer uses `mix` callback to obtain PCM data. The callback must matc
|
||||
|
||||
Since AudioStreamPlayback is controlled by the audio thread, i/o and dynamic memory allocation are forbidden.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* audiostreamplayer_mytone.h */
|
||||
|
||||
#include "core/reference.h"
|
||||
@ -163,9 +162,9 @@ Since AudioStreamPlayback is controlled by the audio thread, i/o and dynamic mem
|
||||
AudioStreamPlaybackMyTone();
|
||||
~AudioStreamPlaybackMyTone();
|
||||
};
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* audiostreamplayer_mytone.cpp */
|
||||
|
||||
#include "audiostreamplayer_mytone.h"
|
||||
@ -227,6 +226,7 @@ Since AudioStreamPlayback is controlled by the audio thread, i/o and dynamic mem
|
||||
bool AudioStreamPlaybackMyTone::is_playing() const {
|
||||
return active;
|
||||
}
|
||||
```
|
||||
|
||||
Resampling
|
||||
~~~~~~~~~~
|
||||
@ -238,8 +238,7 @@ Godot provides cubic interpolation for audio resampling.
|
||||
Instead of overloading `mix`, AudioStreamPlaybackResampled uses `mix_internal` to
|
||||
query AudioFrames and `get_stream_sampling_rate` to query current mix rate.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
#include "core/reference.h"
|
||||
#include "core/resource.h"
|
||||
#include "servers/audio/audio_stream.h"
|
||||
@ -279,8 +278,7 @@ query AudioFrames and `get_stream_sampling_rate` to query current mix rate.
|
||||
~AudioStreamPlaybackResampledMyTone();
|
||||
};
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
#include "mytone_audiostream_resampled.h"
|
||||
|
||||
#include "core/math/math_funcs.h"
|
||||
@ -343,6 +341,7 @@ query AudioFrames and `get_stream_sampling_rate` to query current mix rate.
|
||||
bool AudioStreamPlaybackResampledMyTone::is_playing() const {
|
||||
return active;
|
||||
}
|
||||
```
|
||||
|
||||
References:
|
||||
~~~~~~~~~~~
|
||||
|
@ -38,8 +38,7 @@ Creating a Godot server
|
||||
At minimum, a server must have a static instance, a sleep timer, a thread loop,
|
||||
an initialization state and a cleanup procedure.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
#ifndef HILBERT_HOTEL_H
|
||||
#define HILBERT_HOTEL_H
|
||||
|
||||
@ -91,9 +90,9 @@ an initialization state and a cleanup procedure.
|
||||
};
|
||||
|
||||
#endif
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
#include "hilbert_hotel.h"
|
||||
|
||||
#include "core/dictionary.h"
|
||||
@ -235,9 +234,9 @@ an initialization state and a cleanup procedure.
|
||||
HilbertHotel::HilbertHotel() {
|
||||
singleton = this;
|
||||
}
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* prime_225.h */
|
||||
|
||||
#include "core/int_types.h"
|
||||
@ -269,6 +268,7 @@ an initialization state and a cleanup procedure.
|
||||
1283,1289,1291,1297,1301,1303,1307,1319,1321,
|
||||
1327,1361,1367,1373,1381,1399,1409,1423,1427
|
||||
};
|
||||
```
|
||||
|
||||
Custom managed resource data
|
||||
----------------------------
|
||||
@ -278,8 +278,7 @@ Godot servers implement a mediator pattern. All data types inherit `RID_Data`.
|
||||
RID_Owner maintains a list of RIDs. In practice, RIDs are similar to writing
|
||||
object-oriented C code.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
class InfiniteBus : public RID_Data {
|
||||
RID self;
|
||||
|
||||
@ -311,6 +310,7 @@ object-oriented C code.
|
||||
InfiniteBus(uint64_t prime) : prime_num(prime), num(1) {};
|
||||
~InfiniteBus() {};
|
||||
}
|
||||
```
|
||||
|
||||
References
|
||||
~~~~~~~~~~~
|
||||
@ -332,8 +332,7 @@ class must be created to reference the proper Godot server.
|
||||
In `register_server_types()`, `Engine::get_singleton()->add_singleton`
|
||||
is used to register the dummy class in GDScript.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.cpp */
|
||||
|
||||
#include "register_types.h"
|
||||
@ -364,14 +363,15 @@ is used to register the dummy class in GDScript.
|
||||
memdelete(_hilbert_hotel);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.h */
|
||||
|
||||
/* Yes, the word in the middle must be the same as the module folder name */
|
||||
void register_hilbert_hotel_types();
|
||||
void unregister_hilbert_hotel_types();
|
||||
```
|
||||
|
||||
- `servers/register_server_types.cpp ( https://github.com/godotengine/godot/blob/master/servers/register_server_types.cpp )`
|
||||
|
||||
@ -380,24 +380,23 @@ Bind methods
|
||||
|
||||
The dummy class binds singleton methods to GDScript. In most cases, the dummy class methods wraps around.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
Variant _HilbertHotel::get_bus_info(RID id) {
|
||||
return HilbertHotel::get_singleton()->get_bus_info(id);
|
||||
}
|
||||
```
|
||||
|
||||
Binding Signals
|
||||
|
||||
It is possible to emit signals to GDScript by calling the GDScript dummy object.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
void HilbertHotel::_emit_occupy_room(uint64_t room, RID rid) {
|
||||
_HilbertHotel::get_singleton()->_occupy_room(room, rid);
|
||||
}
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
class _HilbertHotel : public Object {
|
||||
GDCLASS(_HilbertHotel, Object);
|
||||
|
||||
@ -422,9 +421,9 @@ It is possible to emit signals to GDScript by calling the GDScript dummy object.
|
||||
};
|
||||
|
||||
#endif
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
_HilbertHotel *_HilbertHotel::singleton = NULL;
|
||||
_HilbertHotel *_HilbertHotel::get_singleton() { return singleton; }
|
||||
|
||||
@ -461,6 +460,7 @@ It is possible to emit signals to GDScript by calling the GDScript dummy object.
|
||||
|
||||
_HilbertHotel::~_HilbertHotel() {
|
||||
}
|
||||
```
|
||||
|
||||
MessageQueue
|
||||
------------
|
||||
@ -481,8 +481,7 @@ Summing it up
|
||||
|
||||
Here is the GDScript sample code:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
extends Node
|
||||
|
||||
func _ready():
|
||||
@ -501,6 +500,7 @@ Here is the GDScript sample code:
|
||||
func _print_occupy_room(room_number, r_id):
|
||||
print("Room number: " + str(room_number) + ", RID: " + str(r_id))
|
||||
print(HilbertHotel.get_bus_info(r_id))
|
||||
```
|
||||
|
||||
Notes
|
||||
~~~~~
|
||||
|
@ -44,8 +44,7 @@ a different VCS into modules and use it.
|
||||
The example module will be called "summator" (`godot/modules/summator`).
|
||||
Inside we will create a simple summator class:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* summator.h */
|
||||
|
||||
#ifndef SUMMATOR_H
|
||||
@ -70,11 +69,11 @@ Inside we will create a simple summator class:
|
||||
};
|
||||
|
||||
#endif // SUMMATOR_H
|
||||
```
|
||||
|
||||
And then the cpp file.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* summator.cpp */
|
||||
|
||||
#include "summator.h"
|
||||
@ -104,27 +103,26 @@ And then the cpp file.
|
||||
Then, the new class needs to be registered somehow, so two more files
|
||||
need to be created:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
register_types.h
|
||||
register_types.cpp
|
||||
```
|
||||
|
||||
.. important::
|
||||
.. important:
|
||||
These files must be in the top-level folder of your module (next to your
|
||||
`SCsub` and `config.py` files) for the module to be registered properly.
|
||||
|
||||
These files should contain the following:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.h */
|
||||
|
||||
void register_summator_types();
|
||||
void unregister_summator_types();
|
||||
/* yes, the word in the middle must be the same as the module folder name */
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.cpp */
|
||||
|
||||
#include "register_types.h"
|
||||
@ -139,25 +137,26 @@ These files should contain the following:
|
||||
void unregister_summator_types() {
|
||||
// Nothing to do here in this example.
|
||||
}
|
||||
```
|
||||
|
||||
Next, we need to create a `SCsub` file so the build system compiles
|
||||
this module:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# SCsub
|
||||
|
||||
Import('env')
|
||||
|
||||
env.add_source_files(env.modules_sources, "*.cpp") # Add all cpp files to the build
|
||||
```
|
||||
|
||||
With multiple sources, you can also add each file individually to a Python
|
||||
string list:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
src_list = ["summator.cpp", "other.cpp", "etc.cpp"]
|
||||
env.add_source_files(env.modules_sources, src_list)
|
||||
```
|
||||
|
||||
This allows for powerful possibilities using Python to construct the file list
|
||||
using loops and logic statements. Look at some modules that ship with Godot by
|
||||
@ -166,17 +165,16 @@ default for examples.
|
||||
To add include directories for the compiler to look at you can append it to the
|
||||
environment's paths:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
env.Append(CPPPATH=["mylib/include"]) # this is a relative path
|
||||
env.Append(CPPPATH=["#myotherlib/include"]) # this is an 'absolute' path
|
||||
```
|
||||
|
||||
If you want to add custom compiler flags when building your module, you need to clone
|
||||
`env` first, so it won't add those flags to whole Godot build (which can cause errors).
|
||||
Example `SCsub` with custom flags:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# SCsub
|
||||
|
||||
Import('env')
|
||||
@ -188,12 +186,12 @@ Example `SCsub` with custom flags:
|
||||
# If you need to, you can:
|
||||
# - Append CFLAGS for C code only.
|
||||
# - Append CXXFLAGS for C++ code only.
|
||||
```
|
||||
|
||||
And finally, the configuration file for the module, this is a simple
|
||||
python script that must be named `config.py`:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# config.py
|
||||
|
||||
def can_build(env, platform):
|
||||
@ -201,6 +199,7 @@ python script that must be named `config.py`:
|
||||
|
||||
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).
|
||||
@ -208,14 +207,14 @@ this case, `True` means it will build for every platform).
|
||||
And that's it. Hope it was not too complex! Your module should look like
|
||||
this:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
godot/modules/summator/config.py
|
||||
godot/modules/summator/summator.h
|
||||
godot/modules/summator/summator.cpp
|
||||
godot/modules/summator/register_types.h
|
||||
godot/modules/summator/register_types.cpp
|
||||
godot/modules/summator/SCsub
|
||||
```
|
||||
|
||||
You can then zip it and share the module with everyone else. When
|
||||
building for every platform (instructions in the previous sections),
|
||||
@ -281,18 +280,18 @@ practical thing to do:
|
||||
So if you feel like the independent structure of custom modules is needed, lets
|
||||
take our "summator" module and move it to the engine's parent directory:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
mkdir ../modules
|
||||
mv modules/summator ../modules
|
||||
```
|
||||
|
||||
Compile the engine with our module by providing `custom_modules` build option
|
||||
which accepts a comma-separated list of directory paths containing custom C++
|
||||
modules, similar to the following:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
scons custom_modules=../modules
|
||||
```
|
||||
|
||||
The build system shall detect all modules under the `../modules` directory
|
||||
and compile them accordingly, including our "summator" module.
|
||||
@ -333,8 +332,7 @@ changed, finding such files and eventually linking the final binary takes a long
|
||||
The solution to avoid such a cost is to build our own module as a shared
|
||||
library that will be dynamically loaded when starting our game's binary.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# SCsub
|
||||
|
||||
Import('env')
|
||||
@ -370,16 +368,17 @@ library that will be dynamically loaded when starting our game's binary.
|
||||
# (e.g. ".x11.tools.64") but without the final ".so".
|
||||
shared_lib_shim = shared_lib[0].name.rsplit('.', 1)[0]
|
||||
env.Append(LIBS=[shared_lib_shim])
|
||||
```
|
||||
|
||||
Once compiled, we should end up with a `bin` directory containing both the
|
||||
`godot*` binary and our `libsummator*.so`. However given the .so is not in
|
||||
a standard directory (like `/usr/lib`), we have to help our binary find it
|
||||
during runtime with the `LD_LIBRARY_PATH` environment variable:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
export LD_LIBRARY_PATH="$PWD/bin/"
|
||||
./bin/godot*
|
||||
```
|
||||
|
||||
Note:
|
||||
|
||||
@ -391,8 +390,7 @@ module as shared library (for development) or as a part of the Godot binary
|
||||
(for release). To do that we can define a custom flag to be passed to SCons
|
||||
using the `ARGUMENT` command:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
# SCsub
|
||||
|
||||
Import('env')
|
||||
@ -416,6 +414,7 @@ using the `ARGUMENT` command:
|
||||
else:
|
||||
# Static compilation
|
||||
module_env.add_source_files(env.modules_sources, sources)
|
||||
```
|
||||
|
||||
Now by default `scons` command will build our module as part of Godot's binary
|
||||
and as a shared library when passing `summator_shared=yes`.
|
||||
@ -423,9 +422,9 @@ and as a shared library when passing `summator_shared=yes`.
|
||||
Finally, you can even speed up the build further by explicitly specifying your
|
||||
shared module as target in the SCons command:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
scons summator_shared=yes platform=x11 bin/libsummator.x11.tools.64.so
|
||||
```
|
||||
|
||||
Writing custom documentation
|
||||
----------------------------
|
||||
@ -443,8 +442,7 @@ There are several steps in order to setup custom docs for the module:
|
||||
|
||||
2. Now, we need to edit `config.py`, add the following snippet:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
def get_doc_path():
|
||||
return "doc_classes"
|
||||
|
||||
@ -452,6 +450,7 @@ There are several steps in order to setup custom docs for the module:
|
||||
return [
|
||||
"Summator",
|
||||
]
|
||||
```
|
||||
|
||||
The `get_doc_path()` function is used by the build system to determine
|
||||
the location of the docs. In this case, they will be located in the
|
||||
@ -468,12 +467,15 @@ Tip:
|
||||
|
||||
|
||||
You can use Git to check if you have missed some of your classes by checking the
|
||||
untracked files with `git status`. For example::
|
||||
untracked files with `git status`. For example:
|
||||
|
||||
```
|
||||
user@host:~/godot$ git status
|
||||
```
|
||||
|
||||
Example output::
|
||||
Example output:
|
||||
|
||||
```
|
||||
Untracked files:
|
||||
(use "git add <file>..." to include in what will be committed)
|
||||
|
||||
@ -482,7 +484,7 @@ Tip:
|
||||
doc/classes/MyClass5D.xml
|
||||
doc/classes/MyClass6D.xml
|
||||
...
|
||||
|
||||
```
|
||||
|
||||
3. Now we can generate the documentation:
|
||||
|
||||
@ -494,9 +496,9 @@ to an another folder, and just copy over the files that you need.
|
||||
|
||||
Run command:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
user@host:~/godot/bin$ ./bin/<godot_binary> --doctool .
|
||||
```
|
||||
|
||||
Now if you go to the `godot/modules/summator/doc_classes` folder, you will see
|
||||
that it contains a `Summator.xml` file, or any other classes, that you referenced
|
||||
@ -518,11 +520,10 @@ on top of the newer ones.
|
||||
Note that if you don't have write access rights to your supplied `<path )`,
|
||||
you might encounter an error similar to the following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
```
|
||||
ERROR: Can't write doc file: docs/doc/classes/@GDScript.xml
|
||||
At: editor/doc/doc_data.cpp:956
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
@ -548,10 +549,10 @@ Once you've created your icon(s), proceed with the following steps:
|
||||
If you'd like to store your icons somewhere else within your module,
|
||||
add the following code snippet to `config.py` to override the default path:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
def get_icons_path():
|
||||
return "path/to/icons"
|
||||
```
|
||||
|
||||
Summing up
|
||||
----------
|
||||
|
@ -55,8 +55,7 @@ resources with the `load` function. To load a resource, `load` must
|
||||
read and handle data serialization.
|
||||
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* resource_loader_json.h */
|
||||
|
||||
#ifndef RESOURCE_LOADER_JSON_H
|
||||
@ -73,9 +72,9 @@ read and handle data serialization.
|
||||
virtual String get_resource_type(const String &p_path) const;
|
||||
};
|
||||
#endif // RESOURCE_LOADER_JSON_H
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* resource_loader_json.cpp */
|
||||
|
||||
#include "resource_loader_json.h"
|
||||
@ -104,6 +103,7 @@ read and handle data serialization.
|
||||
bool ResourceFormatLoaderJson::handles_type(const String &p_type) const {
|
||||
return ClassDB::is_parent_class(p_type, "Resource");
|
||||
}
|
||||
```
|
||||
|
||||
Creating a ResourceFormatSaver
|
||||
------------------------------
|
||||
@ -111,8 +111,7 @@ Creating a ResourceFormatSaver
|
||||
If you'd like to be able to edit and save a resource, you can implement a
|
||||
`ResourceFormatSaver`:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* resource_saver_json.h */
|
||||
|
||||
#ifndef RESOURCE_SAVER_JSON_H
|
||||
@ -128,9 +127,9 @@ If you'd like to be able to edit and save a resource, you can implement a
|
||||
virtual void get_recognized_extensions(const RES &p_resource, List<String> *r_extensions) const;
|
||||
};
|
||||
#endif // RESOURCE_SAVER_JSON_H
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* resource_saver_json.cpp */
|
||||
|
||||
#include "resource_saver_json.h"
|
||||
@ -153,6 +152,7 @@ If you'd like to be able to edit and save a resource, you can implement a
|
||||
r_extensions->push_back("json");
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Creating custom data types
|
||||
--------------------------
|
||||
@ -163,8 +163,7 @@ understand additional binary formats such as machine learning models.
|
||||
|
||||
Here is an example of creating a custom datatype:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* resource_json.h */
|
||||
|
||||
#ifndef RESOURCE_JSON_H
|
||||
@ -195,9 +194,9 @@ Here is an example of creating a custom datatype:
|
||||
Dictionary get_dict();
|
||||
};
|
||||
#endif // RESOURCE_JSON_H
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* resource_json.cpp */
|
||||
|
||||
#include "resource_json.h"
|
||||
@ -257,6 +256,7 @@ Here is an example of creating a custom datatype:
|
||||
Dictionary JsonResource::get_dict() {
|
||||
return content;
|
||||
}
|
||||
```
|
||||
|
||||
Considerations
|
||||
~~~~~~~~~~~~~~
|
||||
@ -267,8 +267,7 @@ Therefore, Godot call translations are required.
|
||||
For example, here is the code for translating `FileAccess`
|
||||
calls into `std::istream`.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
#include "core/os/file_access.h"
|
||||
|
||||
#include <istream>
|
||||
@ -297,7 +296,7 @@ calls into `std::istream`.
|
||||
private:
|
||||
FileAccess *_file;
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
References
|
||||
~~~~~~~~~~
|
||||
@ -313,15 +312,14 @@ Godot registers `ResourcesFormatLoader` with a `ResourceLoader`
|
||||
handler. The handler selects the proper loader automatically
|
||||
when `load` is called.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.h */
|
||||
|
||||
void register_json_types();
|
||||
void unregister_json_types();
|
||||
```
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
/* register_types.cpp */
|
||||
|
||||
#include "register_types.h"
|
||||
@ -351,6 +349,7 @@ when `load` is called.
|
||||
ResourceSaver::remove_resource_format_saver(json_saver);
|
||||
json_saver.unref();
|
||||
}
|
||||
```
|
||||
|
||||
References
|
||||
~~~~~~~~~~
|
||||
@ -363,8 +362,7 @@ Loading it on GDScript
|
||||
Save a file called `demo.json` with the following contents and place it in the
|
||||
project's root folder:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
```
|
||||
{
|
||||
"savefilename": "demo.json",
|
||||
"demo": [
|
||||
@ -375,12 +373,15 @@ project's root folder:
|
||||
"loaders"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Then attach the following script to any node::
|
||||
|
||||
```
|
||||
extends Node
|
||||
|
||||
onready var json_resource = load("res://demo.json")
|
||||
|
||||
func _ready():
|
||||
print(json_resource.get_dict())
|
||||
```
|
@ -26,15 +26,15 @@ project. To launch a project directly, you need to run the editor by
|
||||
passing the `-e` argument to Godot Engine's binary from within your
|
||||
project's folder. Typically:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
$ cd ~/myproject
|
||||
$ gdb godot
|
||||
> run -e
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
$ gdb godot
|
||||
> run -e --path ~/myproject
|
||||
```
|
||||
|
@ -9,8 +9,7 @@ If you want to debug an official build of the editor it should be re-signed with
|
||||
|
||||
Create an `editor.entitlements` text file with the following contents:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
@ -31,10 +30,13 @@ Create an `editor.entitlements` text file with the following contents:
|
||||
<true/>
|
||||
</dict>
|
||||
</plist>
|
||||
```
|
||||
|
||||
Then use the following command to re-sign the editor::
|
||||
Then use the following command to re-sign the editor:
|
||||
|
||||
```
|
||||
codesign -s - --deep --force --options=runtime --entitlements ./editor.entitlements ./path/to/Godot.app
|
||||
```
|
||||
|
||||
Debugging exported project
|
||||
--------------------------
|
||||
|
@ -17,21 +17,21 @@ 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.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
class CustomObject : public Object {
|
||||
|
||||
GDCLASS(CustomObject, Object); // this is required to inherit
|
||||
};
|
||||
```
|
||||
|
||||
This makes Objects gain a lot of functionality, like for example
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
obj = memnew(CustomObject);
|
||||
print_line("Object class: ", obj->get_class()); // print object class
|
||||
|
||||
obj2 = Object::cast_to<OtherClass>(obj); // converting between classes, this also works without RTTI enabled.
|
||||
```
|
||||
|
||||
References:
|
||||
~~~~~~~~~~~
|
||||
@ -47,18 +47,18 @@ their methods properties and integer constants.
|
||||
|
||||
Classes are registered by calling:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
ClassDB::register_class<MyCustomClass>()
|
||||
```
|
||||
|
||||
Registering it will allow the class to be instanced by scripts, code, or
|
||||
creating them again when deserializing.
|
||||
|
||||
Registering as virtual is the same but it can't be instanced.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
ClassDB::register_virtual_class<MyCustomClass>()
|
||||
```
|
||||
|
||||
Object-derived classes can override the static function
|
||||
`static void _bind_methods()`. When one class is registered, this
|
||||
@ -70,15 +70,15 @@ virtual automatically.
|
||||
Inside `bind_methods`, there are a couple of things that can be done.
|
||||
Registering functions is one:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
ClassDB::bind_method(D_METHOD("methodname", "arg1name", "arg2name"), &MyCustomMethod);
|
||||
```
|
||||
|
||||
Default values for arguments can be passed in reverse order:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
ClassDB::bind_method(D_METHOD("methodname", "arg1name", "arg2name"), &MyCustomType::method, DEFVAL(-1)); // default value for arg2name
|
||||
```
|
||||
|
||||
`D_METHOD` is a macro that converts "methodname" to a StringName for more
|
||||
efficiency. Argument names are used for introspection, but when
|
||||
@ -101,26 +101,26 @@ Constants
|
||||
|
||||
Classes often have enums such as:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
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:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
VARIANT_ENUM_CAST(MyClass::SomeMode); // now functions that take SomeMode can be bound.
|
||||
```
|
||||
|
||||
The constants can also be bound inside `bind_methods`, by using:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
BIND_CONSTANT(MODE_FIRST);
|
||||
BIND_CONSTANT(MODE_SECOND);
|
||||
```
|
||||
|
||||
Properties (set/get)
|
||||
--------------------
|
||||
@ -133,15 +133,15 @@ Objects export properties, properties are useful for the following:
|
||||
Properties are usually defined by the PropertyInfo() class. Usually
|
||||
constructed as:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
PropertyInfo(type, name, hint, hint_string, usage_flags)
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
PropertyInfo(Variant::INT, "amount", PROPERTY_HINT_RANGE, "0,49,1", PROPERTY_USAGE_EDITOR)
|
||||
```
|
||||
|
||||
This is an integer property, named "amount", hint is a range, range goes
|
||||
from 0 to 49 in steps of 1 (integers). It is only usable for the editor
|
||||
@ -149,9 +149,9 @@ from 0 to 49 in steps of 1 (integers). It is only usable for the editor
|
||||
|
||||
Another example:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
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 usage flags were specified, the
|
||||
@ -169,9 +169,9 @@ impossible unless using operator [].
|
||||
From `bind_methods()`, properties can be created and bound as long as
|
||||
set/get functions exist. Example:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
ADD_PROPERTY(PropertyInfo(Variant::INT, "amount"), "set_amount", "get_amount")
|
||||
```
|
||||
|
||||
This creates the property using the setter and the getter.
|
||||
|
||||
@ -188,12 +188,12 @@ they are NOT virtual, DO NOT make them virtual, they are called for
|
||||
every override and the previous ones are not invalidated (multilevel
|
||||
call).
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
protected:
|
||||
void _get_property_list(List<PropertyInfo> *r_props) const; // return list of properties
|
||||
bool _get(const StringName &p_property, Variant &r_value) const; // return true if property was found
|
||||
bool _set(const StringName &p_property, const Variant &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.
|
||||
@ -204,12 +204,12 @@ Dynamic casting
|
||||
Godot provides dynamic casting between Object-derived classes, for
|
||||
example:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
void somefunc(Object *some_obj) {
|
||||
|
||||
Button *button = Object::cast_to<Button>(some_obj);
|
||||
}
|
||||
```
|
||||
|
||||
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
|
||||
@ -222,11 +222,11 @@ Signals
|
||||
Objects can have a set of signals defined (similar to Delegates in other
|
||||
languages). Connecting to them is rather easy:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
obj->connect(<signal>, 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
|
||||
`ClassDB::bind_method` (explained before).
|
||||
@ -234,9 +234,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:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
ADD_SIGNAL(MethodInfo("been_killed"))
|
||||
```
|
||||
|
||||
Notifications
|
||||
-------------
|
||||
@ -252,13 +252,13 @@ References
|
||||
reference count. It is the base for reference counted object types.
|
||||
Declaring them must be done using Ref<> template. For example:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
class MyReference: public Reference {
|
||||
GDCLASS(MyReference, Reference);
|
||||
};
|
||||
|
||||
Ref<MyReference> myref(memnew(MyReference));
|
||||
```
|
||||
|
||||
`myref` is reference counted. It will be freed when no more Ref<>
|
||||
templates point to it.
|
||||
@ -289,9 +289,9 @@ Resource loading
|
||||
|
||||
Resources can be loaded with the ResourceLoader API, like this:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
Ref<Resource> 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
|
||||
@ -310,9 +310,9 @@ Resource saving
|
||||
|
||||
Saving a resource can be done with the resource saver API:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
```
|
||||
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
|
||||
|
@ -16,9 +16,9 @@ For instance, you can use the open source `Inkscape ( https://inkscape.org/ )` e
|
||||
|
||||
Clone the `godot` repository containing all the editor icons:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
```
|
||||
git clone https://github.com/godotengine/godot.git
|
||||
```
|
||||
|
||||
The icons must be created in a vector graphics editor in SVG format. There are
|
||||
two main requirements to follow:
|
||||
@ -58,9 +58,9 @@ optimized before being added to the engine, to do so:
|
||||
2. Run the command below, replacing `svg_source.svg` with the path to your
|
||||
SVG file (which can be a relative or absolute path):
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
```
|
||||
svgcleaner --multipass svg_source.svg svg_optimized.svg
|
||||
```
|
||||
|
||||
The `--multipass` switch improves compression, so make sure to include it.
|
||||
The optimized icon will be saved to `svg_optimized.svg`. You can also change
|
||||
|
@ -61,11 +61,10 @@ Below every heading comes zero or more `key = value` pairs. The
|
||||
values can be complex datatypes such as Arrays, Transforms, Colors, and
|
||||
so on. For example, a spatial node looks like:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[node name="Cube" type="Spatial" parent="."]
|
||||
transform=Transform( 1.0, 0.0, 0.0 ,0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0 )
|
||||
|
||||
```
|
||||
|
||||
The scene tree
|
||||
--------------
|
||||
@ -90,20 +89,18 @@ the scene root's name. If the node is a direct child of the scene root,
|
||||
the path should be `"."`. Here is an example scene tree
|
||||
(but without any node content):
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[node name="Player" type="Spatial"] ; The scene root
|
||||
[node name="Arm" parent="." type="Spatial"] ; Parented to the scene root
|
||||
[node name="Hand" parent="Arm" type="Spatial"]
|
||||
[node name="Finger" parent="Arm/Hand" type="Spatial"]
|
||||
|
||||
```
|
||||
|
||||
Similar to the internal resource, the document for each node is currently
|
||||
incomplete. Fortunately, it is easy to find out because you can simply
|
||||
save a file with that node in it. Some example nodes are:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[node type="CollisionShape" name="SphereCollision" parent="SpherePhysics"]
|
||||
|
||||
shape = SubResource(8)
|
||||
@ -134,7 +131,7 @@ save a file with that node in it. Some example nodes are:
|
||||
fov = 50
|
||||
transform = Transform( 0.6859206557273865 , -0.32401350140571594 , 0.6515582203865051 , 0.0 , 0.8953956365585327 , 0.44527143239974976 , -0.7276763319969177 , -0.3054208755493164 , 0.6141703724861145 ,14.430776596069336 ,10.093015670776367 ,13.058500289916992 )
|
||||
far = 100.0
|
||||
|
||||
```
|
||||
|
||||
NodePath
|
||||
~~~~~~~~
|
||||
@ -145,23 +142,21 @@ the node anywhere in the scene tree. For instance, MeshInstance uses
|
||||
`NodePath()` to point to its skeleton. Likewise, Animation tracks use
|
||||
`NodePath()` to point to node properties to animate.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[node name="mesh" type="MeshInstance" parent="Armature001"]
|
||||
|
||||
mesh = SubResource(1)
|
||||
skeleton = NodePath("..:")
|
||||
```
|
||||
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[sub_resource id=3 type="Animation"]
|
||||
|
||||
...
|
||||
tracks/0/type = "transform
|
||||
tracks/0/path = NodePath("Cube:")
|
||||
...
|
||||
|
||||
```
|
||||
|
||||
Skeleton
|
||||
~~~~~~~~
|
||||
@ -187,8 +182,7 @@ bone attributes consist of:
|
||||
|
||||
Here's an example of a skeleton node with two bones:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[node name="Skeleton" type="Skeleton" parent="Armature001" index="0"]
|
||||
|
||||
bones/0/name = "Bone.001"
|
||||
@ -203,7 +197,7 @@ Here's an example of a skeleton node with two bones:
|
||||
bones/1/pose = Transform( 1.0, 0.0, -0.0, 0.0, 1.0, -0.0, -0.0, -0.0, 1.0, 0.0, 0.0, -0.0 )
|
||||
bones/1/enabled = true
|
||||
bones/1/bound_children = [ ]
|
||||
|
||||
```
|
||||
|
||||
BoneAttachment
|
||||
~~~~~~~~~~~~~~
|
||||
@ -215,8 +209,7 @@ BoneAttachment node in its `bound_children` list.
|
||||
|
||||
An example of one MeshInstance parented to a bone in Skeleton:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[node name="Armature" type="Skeleton" parent="."]
|
||||
|
||||
transform = Transform(1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, -0.0219986, 0.0125825, 0.0343127)
|
||||
@ -235,7 +228,7 @@ An example of one MeshInstance parented to a bone in Skeleton:
|
||||
|
||||
mesh = SubResource(1)
|
||||
transform = Transform(1.0, 0.0, 0.0, 0.0, 1.86265e-09, 1.0, 0.0, -1.0, 0.0, 0.0219986, -0.0343127, 2.25595)
|
||||
|
||||
```
|
||||
|
||||
AnimationPlayer
|
||||
~~~~~~~~~~~~~~~
|
||||
@ -246,8 +239,7 @@ Animation resource. All the animation resources use the root node of
|
||||
AnimationPlayer. The root node is stored as
|
||||
`root_node=NodePath(Path/To/Node)`.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[node name="AnimationPlayer" type="AnimationPlayer" parent="." index="1"]
|
||||
|
||||
root_node = NodePath("..")
|
||||
@ -257,7 +249,7 @@ AnimationPlayer. The root node is stored as
|
||||
playback_speed = 1.0
|
||||
anims/default = SubResource( 2 )
|
||||
blend_times = [ ]
|
||||
|
||||
```
|
||||
|
||||
Resources
|
||||
---------
|
||||
@ -287,11 +279,10 @@ are also valid.
|
||||
|
||||
Some example external resources are:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[ext_resource path="res://characters/player.dae" type="PackedScene" id=1]
|
||||
[ext_resource path="metal.tres" type="Material" id=2]
|
||||
|
||||
```
|
||||
|
||||
Like TSCN files, a TRES file may contain single-line comments starting with a
|
||||
semicolon (`;`). However, comments will be discarded when saving the resource
|
||||
@ -306,13 +297,12 @@ resource looks similar to those of external resources, except that it doesn't
|
||||
have a path. Internal resources also have `key=value` pairs under each
|
||||
heading. For example, a capsule collision shape looks like:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[sub_resource type="CapsuleShape" id=2]
|
||||
|
||||
radius = 0.5
|
||||
height = 3.0
|
||||
|
||||
```
|
||||
|
||||
Some internal resources contain links to other internal resources (such as a
|
||||
mesh having a material). In this case, the referring resource must appear
|
||||
@ -357,8 +347,7 @@ TSCN files support two surface formats:
|
||||
|
||||
An example of ArrayMesh:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[sub_resource id=1 type="ArrayMesh"]
|
||||
|
||||
surfaces/0 = {
|
||||
@ -376,7 +365,7 @@ An example of ArrayMesh:
|
||||
],
|
||||
"morph_arrays":[]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Animation
|
||||
~~~~~~~~~
|
||||
@ -424,8 +413,7 @@ Each track is described by a list of key-value pairs in the format
|
||||
4-number rotation quaternion (X, Y, Z, W) and finally a 3-number
|
||||
scale vector. The default transition in a Transform track is 1.0.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[sub_resource type="Animation" id=2]
|
||||
|
||||
length = 4.95833
|
||||
@ -445,3 +433,4 @@ Each track is described by a list of key-value pairs in the format
|
||||
tracks/1/imported = true
|
||||
tracks/1/enabled = false
|
||||
tracks/1/keys = PoolRealArray( 0, 1, 0, 5.96046e-08, 0, 0, 0, 0, 1, 1, 1, 1, 4.95833, 1, 0, 5.96046e-08, 0, 0, 0, 0, 1, 1, 1, 1 )
|
||||
```
|
@ -121,9 +121,9 @@ Randomness
|
||||
All physics parameters can be randomized. Random values range from `0` to
|
||||
`1`. The formula to randomize a parameter is:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
initial_value = param_value + param_value * randomness
|
||||
```
|
||||
|
||||
Fixed FPS
|
||||
~~~~~~~~~
|
||||
|
@ -23,14 +23,14 @@ You can choose to either receive these callbacks as `signals`, or as `notificati
|
||||
|
||||
Notifications can be handled in GDScript or other scripting languages:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
func _notification(what):
|
||||
match what:
|
||||
NOTIFICATION_ENTER_GAMEPLAY:
|
||||
print("notification enter gameplay")
|
||||
NOTIFICATION_EXIT_GAMEPLAY:
|
||||
print("notification exit gameplay")
|
||||
```
|
||||
|
||||
Signals are sent just as any other signal. They can be attached to functions using the editor inspector. The signals are called `gameplay_entered` and `gameplay_exited`.
|
||||
|
||||
|
@ -221,9 +221,9 @@ The video and audio's bitrate will be variable to maximize quality while saving
|
||||
space in parts of the video/audio that don't require a high bitrate (such as
|
||||
static scenes).
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
ffmpeg -i input.mp4 -q:v 6 -q:a 6 output.ogv
|
||||
```
|
||||
|
||||
FFmpeg: Resize the video then convert it
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -232,6 +232,6 @@ The following command resizes a video to be 720 pixels tall (720p), while
|
||||
preserving its existing aspect ratio. This helps decrease the file size
|
||||
significantly if the source is recorded at a higher resolution than 720p:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
ffmpeg -i input.mp4 -vf "scale=-1:720" -q:v 6 -q:a 6 output.ogv
|
||||
```
|
||||
|
@ -174,8 +174,7 @@ with the geometry etc.
|
||||
|
||||
Create a script like this:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
tool # Needed so it runs in the editor.
|
||||
extends EditorScenePostImport
|
||||
|
||||
@ -183,6 +182,7 @@ Create a script like this:
|
||||
func post_import(scene):
|
||||
# Do your stuff here.
|
||||
return scene # remember to return the imported scene
|
||||
```
|
||||
|
||||
The `post_import` function takes the imported scene as argument (the
|
||||
parameter is actually the root node of the scene). The scene that
|
||||
@ -339,15 +339,19 @@ hood).
|
||||
|
||||
The script must start with an animation filter statement (as denoted by the line beginning with an
|
||||
`@`). For example, if we would like to apply filters to all imported animations which have a name
|
||||
ending in `"_Loop"`::
|
||||
ending in `"_Loop"`:
|
||||
|
||||
```
|
||||
@+*_Loop
|
||||
```
|
||||
|
||||
Similarly, additional patterns can be added to the same line, separated by commas. Here is a
|
||||
modified example to additionally *include* all animations with names that begin with `"Arm_Left"`,
|
||||
but also *exclude* all animations which have names ending in `"Attack"`::
|
||||
but also *exclude* all animations which have names ending in `"Attack"`:
|
||||
|
||||
```
|
||||
@+*_Loop, +Arm_Left*, -*Attack
|
||||
```
|
||||
|
||||
Following the animation selection filter statement, we add track filtering patterns to indicate
|
||||
which animation tracks should be kept or discarded. If no track filter patterns are specified, then
|
||||
@ -360,12 +364,14 @@ further down in the filter script.
|
||||
|
||||
For example: include all tracks in animations with names ending in `"_Loop"`, but discard any
|
||||
tracks affecting a `"Skeleton"` which end in `"Control"`, unless they have `"Arm"` in their
|
||||
name::
|
||||
name:
|
||||
|
||||
```
|
||||
@+*_Loop
|
||||
+*
|
||||
-Skeleton:*Control
|
||||
+*Arm*
|
||||
```
|
||||
|
||||
In the above example, tracks like `"Skeleton:Leg_Control"` would be discarded, while tracks such
|
||||
as `"Skeleton:Head"` or `"Skeleton:Arm_Left_Control"` would be retained.
|
||||
|
@ -96,13 +96,13 @@ to escape any double quotes a message may contain by preceding them with
|
||||
another double quote. Alternatively, you can select another delimiter than
|
||||
comma in the import options.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
keys,en,es,ja
|
||||
GREET,"Hello, friend!","Hola, amigo!",こんにちは
|
||||
ASK,How are you?,Cómo está?,元気ですか
|
||||
BYE,Goodbye,Adiós,さようなら
|
||||
QUOTE,"""Hello"" said the man.","""Hola"" dijo el hombre.",「こんにちは」男は言いました
|
||||
```
|
||||
|
||||
CSV importer
|
||||
------------
|
||||
|
@ -28,8 +28,7 @@ As an example, one can usually place into a single folder their basic assets,
|
||||
such as sprite images, 3D model meshes, materials, and music, etc.
|
||||
They can then use a separate folder to store built levels that use them.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
/project.godot
|
||||
/docs/.gdignore # See "Ignoring specific folders" below
|
||||
/docs/learning.html
|
||||
@ -43,6 +42,7 @@ They can then use a separate folder to store built levels that use them.
|
||||
/characters/npcs/suzanne/suzanne.dae
|
||||
/characters/npcs/suzanne/suzanne.png)
|
||||
/levels/riverdale/riverdale.scn
|
||||
```
|
||||
|
||||
Style guide
|
||||
-----------
|
||||
@ -112,16 +112,20 @@ Note:
|
||||
|
||||
On Windows 10, to further avoid mistakes related to case sensitivity,
|
||||
you can also make the project folder case-sensitive. After enabling the Windows
|
||||
Subsystem for Linux feature, run the following command in a PowerShell window::
|
||||
Subsystem for Linux feature, run the following command in a PowerShell window:
|
||||
|
||||
```
|
||||
# To enable case-sensitivity:
|
||||
fsutil file setcasesensitiveinfo <path to project folder> enable
|
||||
|
||||
# To disable case-sensitivity:
|
||||
fsutil file setcasesensitiveinfo <path to project folder> disable
|
||||
```
|
||||
|
||||
If you haven't enabled the Windows Subsystem for Linux, you can enter the
|
||||
following line in a PowerShell window *running as Administrator* then reboot
|
||||
when asked::
|
||||
when asked:
|
||||
|
||||
```
|
||||
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
|
||||
```
|
||||
|
@ -40,6 +40,8 @@ Working with Git on Windows
|
||||
|
||||
Most Git for Windows clients are configured with the `core.autocrlf` set to `true`.
|
||||
This can lead to files unnecessarily being marked as modified by Git due to their line endings being converted automatically.
|
||||
It is better to set this option as::
|
||||
It is better to set this option as:
|
||||
|
||||
```
|
||||
git config --global core.autocrlf input
|
||||
```
|
||||
|
@ -173,21 +173,21 @@ for any of the following commands to work correctly.
|
||||
This can be done by giving the path to the `project.godot` file
|
||||
of your project as either the first argument, like this:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot path_to_your_project/project.godot [other] [commands] [and] [args]
|
||||
```
|
||||
|
||||
Or by using the `--path` argument:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot --path path_to_your_project [other] [commands] [and] [args]
|
||||
```
|
||||
|
||||
For example, the full command for exporting your game (as explained below) might look like this:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot --path path_to_your_project --export my_export_preset_name game.exe
|
||||
```
|
||||
|
||||
Creating a project
|
||||
------------------
|
||||
@ -197,11 +197,11 @@ Creating a project from the command line can be done by navigating the
|
||||
shell to the desired place and making a project.godot file.
|
||||
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
mkdir newgame
|
||||
cd newgame
|
||||
touch project.godot
|
||||
```
|
||||
|
||||
|
||||
The project can now be opened with Godot.
|
||||
@ -214,16 +214,16 @@ 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.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot -e scene.tscn
|
||||
```
|
||||
|
||||
Erasing a scene
|
||||
---------------
|
||||
@ -232,9 +232,9 @@ Godot is friends with your filesystem and will not create extra
|
||||
metadata files. Use `rm` to erase a scene file. Make sure nothing
|
||||
references that scene or else an error will be thrown upon opening.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
rm scene.tscn
|
||||
```
|
||||
|
||||
Running the game
|
||||
----------------
|
||||
@ -242,16 +242,16 @@ Running the game
|
||||
To run the game, simply execute Godot within the project directory or
|
||||
subdirectory.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot
|
||||
```
|
||||
|
||||
When a specific scene needs to be tested, pass that scene to the command
|
||||
line.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot scene.tscn
|
||||
```
|
||||
|
||||
Debugging
|
||||
---------
|
||||
@ -260,14 +260,13 @@ 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 running either the game or a simple scene.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot -d
|
||||
```
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot -d scene.tscn
|
||||
|
||||
```
|
||||
|
||||
|
||||
Exporting
|
||||
@ -277,10 +276,10 @@ Exporting the project from the command line is also supported. This is
|
||||
especially useful for continuous integration setups. The version of Godot
|
||||
that is headless (server build, no video) is ideal for this.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
godot --export "Linux/X11" /var/builds/project
|
||||
godot --export Android /var/builds/project.apk
|
||||
```
|
||||
|
||||
The preset name must match the name of an export preset defined in the
|
||||
project's `export_presets.cfg` file. If the preset name contains spaces or
|
||||
@ -311,21 +310,21 @@ The script must inherit from `SceneTree` or `MainLoop`.
|
||||
|
||||
Here is a simple `sayhello.gd` example of how it works:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
```
|
||||
#!/usr/bin/env -S godot -s
|
||||
extends SceneTree
|
||||
|
||||
func _init():
|
||||
print("Hello!")
|
||||
quit()
|
||||
```
|
||||
|
||||
And how to run it:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# Prints "Hello!" to standard output.
|
||||
godot -s sayhello.gd
|
||||
```
|
||||
|
||||
If no `project.godot` exists at the path, current path is assumed to be the
|
||||
current working directory (unless `--path` is specified).
|
||||
@ -335,16 +334,16 @@ a *shebang*. If the Godot binary is in your `PATH` as `godot`,
|
||||
it allows you to run the script as follows in modern Linux
|
||||
distributions, as well as macOS:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# Mark script as executable.
|
||||
chmod +x sayhello.gd
|
||||
# Prints "Hello!" to standard output.
|
||||
./sayhello.gd
|
||||
```
|
||||
|
||||
If the above doesn't work in your current version of Linux or macOS, you can
|
||||
always have the shebang run Godot straight from where it is located as follows:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
#!/usr/bin/godot -s
|
||||
```
|
||||
|
@ -1,6 +1,3 @@
|
||||
.. meta::
|
||||
:keywords: cheatsheet, cheat sheet, shortcut
|
||||
|
||||
|
||||
|
||||
Default editor shortcuts
|
||||
|
@ -21,15 +21,15 @@ export an ICO file with GIMP.
|
||||
It is also possible to convert a PNG image to an hiDPI-friendly ICO file
|
||||
using this `ImageMagick ( https://www.imagemagick.org/ )` command:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
magick convert icon.png) -define icon:auto-resize=256,128,64,48,32,16 icon.ico
|
||||
```
|
||||
|
||||
Depending on which version of ImageMagick you installed, you might need to leave out the `magick` and run this command instead:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
convert icon.png) -define icon:auto-resize=256,128,64,48,32,16 icon.ico
|
||||
```
|
||||
|
||||
Warning:
|
||||
|
||||
|
@ -239,9 +239,9 @@ command-line tool that Godot uses to communicate with your device.
|
||||
Next, create a debug keystore by running the following command on your
|
||||
system's command line:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
keytool -keyalg RSA -genkeypair -alias androiddebugkey -keypass android -keystore debug.keystore -storepass android -dname "CN=Android Debug,O=Android,C=US" -validity 9999
|
||||
```
|
||||
|
||||
Click on *Editor -> Editor Settings* in Godot and select the *Export/Android*
|
||||
section. Here, you need to set the paths to the Android SDK applications on
|
||||
@ -258,9 +258,9 @@ leave this on **Landscape**.
|
||||
Click the **Export Project** button and Godot will build an APK you can download
|
||||
on your device. To do this on the command line, use the following:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
adb install dodge.apk
|
||||
```
|
||||
|
||||
Note:
|
||||
Your device may need to be in *developer mode*. Consult your
|
||||
|
@ -40,9 +40,9 @@ Download and install the Android SDK.
|
||||
|
||||
- Once the command line tools are installed, run the `sdkmanager ( https://developer.android.com/studio/command-line/sdkmanager )` command to complete the setup process:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
sdkmanager --sdk_root=<android_sdk_path> "platform-tools" "build-tools;30.0.3" "platforms;android-31" "cmdline-tools;latest" "cmake;3.10.2.4988404" "ndk;21.4.7075529"
|
||||
```
|
||||
|
||||
Note:
|
||||
|
||||
@ -60,9 +60,11 @@ projects, ant or eclipse probably generated one for you (in the `~/.android` dir
|
||||
macOS, in the `C:\Users\<user>\.android\` directory on Windows).
|
||||
|
||||
If you can't find it or need to generate one, the keytool command from
|
||||
the JDK can be used for this purpose::
|
||||
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 -deststoretype pkcs12
|
||||
```
|
||||
|
||||
This will create a `debug.keystore` file in your current directory. You should move it to a memorable location such as `%USERPROFILE%\.android\`, because you will need its location in a later step. For more information on `keytool` usage, see `this Q&A article ( https://godotengine.org/qa/21349/jdk-android-file-missing )`.
|
||||
|
||||
@ -131,9 +133,9 @@ Exporting for Google Play Store
|
||||
Uploading an APK to Google's Play Store requires you to sign using a non-debug
|
||||
keystore file; such file can be generated like this:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
keytool -v -genkey -keystore mygame.keystore -alias mygame -keyalg RSA -validity 10000
|
||||
```
|
||||
|
||||
This keystore and key are used to verify your developer identity, remember the password and keep it in a safe place!
|
||||
Use Google's Android Developer guides to learn more about `APK signing ( https://developer.android.com/studio/publish/app-signing )`.
|
||||
|
@ -80,9 +80,11 @@ same folder as the PCK file you've exported. The server binary should have the
|
||||
same name as the PCK (excluding the extension). This lets Godot detect and use
|
||||
the PCK file automatically. If you want to start a server with a PCK that has a
|
||||
different name, you can specify the path to the PCK file using the
|
||||
`--main-pack` command-line argument::
|
||||
`--main-pack` command-line argument:
|
||||
|
||||
```
|
||||
./godot-server --main-pack my_project.pck
|
||||
```
|
||||
|
||||
Starting the dedicated server
|
||||
-----------------------------
|
||||
@ -90,23 +92,27 @@ Starting the dedicated server
|
||||
If both your client and server are part of the same Godot project, you will have
|
||||
to add a way to start the server directly using a command-line argument. This
|
||||
can be done by adding the following code snippet in your main scene (or a
|
||||
singleton)'s `ready()` method::
|
||||
singleton)'s `ready()` method:
|
||||
|
||||
```
|
||||
if "--server" in OS.get_cmdline_args():
|
||||
# Run your server startup code here...
|
||||
# Using this check, you can start a dedicated server by running
|
||||
# a Godot binary (headless or not) with the `--server` command-line argument.
|
||||
pass
|
||||
```
|
||||
|
||||
Alternatively, you can make the dedicated server always start up if a headless
|
||||
or server binary is detected::
|
||||
or server binary is detected:
|
||||
|
||||
```
|
||||
# Note: Feature tags are case-sensitive! It's "Server", not "server".
|
||||
if OS.has_feature("Server"):
|
||||
# Run your server startup code here...
|
||||
# Note that using this check may break unit testing scripts when
|
||||
# running them with headless or server binaries.
|
||||
pass
|
||||
```
|
||||
|
||||
If your client and server are separate Godot projects, your server should most
|
||||
likely be configured in a way where running the main scene starts a server
|
||||
|
@ -48,24 +48,30 @@ Prompts, since it comes with these tools and they can be located in the path.
|
||||
You can get more detailed instructions from `Microsoft's documentation
|
||||
( https://msdn.microsoft.com/en-us/library/windows/desktop/jj835832(v=vs.85).aspx )`.
|
||||
|
||||
First, run `MakeCert` to create a private key::
|
||||
First, run `MakeCert` to create a private key:
|
||||
|
||||
```
|
||||
MakeCert /n publisherName /r /h 0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /e expirationDate /sv MyKey.pvk MyKey.cer
|
||||
```
|
||||
|
||||
Where `publisherName` matches the Publisher Name of your package and
|
||||
`expirationDate` is in the `mm/dd/yyyy` format.
|
||||
|
||||
Next, create a Personal Information Exchange (.pfx) file using `Pvk2Pfx.exe`::
|
||||
Next, create a Personal Information Exchange (.pfx) file using `Pvk2Pfx.exe`:
|
||||
|
||||
```
|
||||
Pvk2Pfx /pvk MyKey.pvk /pi pvkPassword /spc MyKey.cer /pfx MyKey.pfx [/po pfxPassword]
|
||||
```
|
||||
|
||||
If you don't specify a password with `/po` argument, the PFX will have the
|
||||
same password as the private key.
|
||||
|
||||
You will also need to trust this certificate in order to be able to install your
|
||||
app. Open the Command Prompt as Administrator and run the following command::
|
||||
app. Open the Command Prompt as Administrator and run the following command:
|
||||
|
||||
```
|
||||
Certutil -addStore TrustedPeople MyKey.cer
|
||||
```
|
||||
|
||||
Setting up automatic signing
|
||||
----------------------------
|
||||
|
@ -288,10 +288,10 @@ same name. It takes a string as an argument and executes it as JavaScript code.
|
||||
This allows interacting with the browser in ways not possible with script
|
||||
languages integrated into Godot.
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
func my_func():
|
||||
JavaScript.eval("alert('Calling JavaScript per GDScript!');")
|
||||
```
|
||||
|
||||
The value of the last JavaScript statement is converted to a GDScript value and
|
||||
returned by `eval()` under certain circumstances:
|
||||
@ -302,11 +302,11 @@ returned by `eval()` under certain circumstances:
|
||||
* JavaScript `ArrayBuffer`, `TypedArray` and `DataView` are returned as
|
||||
GDScript `PoolByteArray`
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
func my_func2():
|
||||
var js_return = JavaScript.eval("var myNumber = 1; myNumber + 2;")
|
||||
print(js_return) # prints '3.0'
|
||||
```
|
||||
|
||||
Any other JavaScript value is returned as `null`.
|
||||
|
||||
@ -314,8 +314,9 @@ HTML5 export templates may be `built ( doc_compiling_for_web )` without
|
||||
support for the singleton to improve security. With such templates, and on
|
||||
platforms other than HTML5, calling `JavaScript.eval` will also return
|
||||
`null`. The availability of the singleton can be checked with the
|
||||
`JavaScript` `feature tag ( doc_feature_tags )`::
|
||||
`JavaScript` `feature tag ( doc_feature_tags )`:
|
||||
|
||||
```
|
||||
func my_func3():
|
||||
if OS.has_feature('JavaScript'):
|
||||
JavaScript.eval("""
|
||||
@ -323,6 +324,7 @@ platforms other than HTML5, calling `JavaScript.eval` will also return
|
||||
""")
|
||||
else:
|
||||
print("The JavaScript singleton is NOT available")
|
||||
```
|
||||
|
||||
Tip:
|
||||
GDScript's multi-line strings, surrounded by 3 quotes `"""` as in
|
||||
@ -330,9 +332,11 @@ Tip:
|
||||
|
||||
The `eval` method also accepts a second, optional Boolean argument, which
|
||||
specifies whether to execute the code in the global execution context,
|
||||
defaulting to `false` to prevent polluting the global namespace::
|
||||
defaulting to `false` to prevent polluting the global namespace:
|
||||
|
||||
```
|
||||
func my_func4():
|
||||
# execute in global execution context,
|
||||
# thus adding a new JavaScript global variable `SomeGlobal`
|
||||
JavaScript.eval("var SomeGlobal = {};", true)
|
||||
```
|
||||
|
@ -3,8 +3,6 @@
|
||||
Exporting projects
|
||||
==================
|
||||
|
||||
.. highlight:: none
|
||||
|
||||
Why export?
|
||||
-----------
|
||||
|
||||
@ -142,9 +140,9 @@ with the `--export` and `--export-debug` command line parameters.
|
||||
Exporting from the command line still requires an export preset to define
|
||||
the export parameters. A basic invocation of the command would be:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
godot --export "Windows Desktop" some_name.exe
|
||||
```
|
||||
|
||||
This will export to `some_name.exe`, assuming there is a preset
|
||||
called "Windows Desktop" and the template can be found. (The export preset name
|
||||
@ -166,17 +164,17 @@ You can also configure it to export *only* the PCK or ZIP file, allowing
|
||||
a single exported main pack file to be used with multiple Godot executables.
|
||||
When doing so, the export preset name must still be specified on the command line:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
godot --export-pack "Windows Desktop" some_name.pck
|
||||
```
|
||||
|
||||
It is often useful to combine the `--export` flag with the `--path`
|
||||
flag, so that you do not need to `cd` to the project folder before running
|
||||
the command:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
godot --path /path/to/project --export "Windows Desktop" some_name.exe
|
||||
```
|
||||
|
||||
See also:
|
||||
|
||||
@ -211,14 +209,16 @@ Warning:
|
||||
Due to a `known bug ( https://github.com/godotengine/godot/pull/42123 )`,
|
||||
when using a ZIP file as a pack file, the exported binary will not try to use
|
||||
it automatically. Therefore, you have to create a *launcher script* that
|
||||
the player can double-click or run from a terminal to launch the project::
|
||||
the player can double-click or run from a terminal to launch the project:
|
||||
|
||||
:: launch.bat (Windows)
|
||||
```
|
||||
launch.bat (Windows)
|
||||
@echo off
|
||||
my_project.exe --main-pack my_project.zip
|
||||
|
||||
# launch.sh (Linux)
|
||||
./my_project.x86_64 --main-pack my_project.zip
|
||||
```
|
||||
|
||||
Save the launcher script and place it in the same folder as the exported binary.
|
||||
On Linux, make sure to give executable permissions to the launcher script using
|
||||
|
@ -19,10 +19,9 @@ Each *feature* is represented as a string, which can refer to many of the follow
|
||||
|
||||
Features can be queried at run-time from the singleton API by calling:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
OS.has_feature(name)
|
||||
|
||||
```
|
||||
|
||||
Default features
|
||||
----------------
|
||||
|
@ -63,32 +63,36 @@ want the player's name to be translated if it matches a translation key. To
|
||||
disable automatic translation on a specific node, use
|
||||
`Object.set_message_translation( Object_method_set_message_translation )`
|
||||
and send a `Object.notification( Object_method_notification )` to update the
|
||||
translation::
|
||||
translation:
|
||||
|
||||
```
|
||||
func _ready():
|
||||
# This assumes you have a node called "Label" as a child of the node
|
||||
# that has the script attached.
|
||||
var label = get_node("Label")
|
||||
label.set_message_translation(false)
|
||||
label.notification(NOTIFICATION_TRANSLATION_CHANGED)
|
||||
```
|
||||
|
||||
For more complex UI nodes such as OptionButtons, you may have to use this instead::
|
||||
For more complex UI nodes such as OptionButtons, you may have to use this instead:
|
||||
|
||||
```
|
||||
func _ready():
|
||||
var option_button = get_node("OptionButton")
|
||||
option_button.set_message_translation(false)
|
||||
option_button.notification(NOTIFICATION_TRANSLATION_CHANGED)
|
||||
option_button.get_popup().set_message_translation(false)
|
||||
option_button.get_popup().notification(NOTIFICATION_TRANSLATION_CHANGED)
|
||||
```
|
||||
|
||||
In code, the `Object.tr()`
|
||||
function can be used. This will just look up the text in the
|
||||
translations and convert it if found:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
level.set_text(tr("LEVEL_5_NAME"))
|
||||
status.set_text(tr("GAME_STATUS_" + str(status_index)))
|
||||
```
|
||||
|
||||
Making controls resizable
|
||||
--------------------------
|
||||
@ -128,9 +132,9 @@ Translations can also be tested when running Godot from the command line.
|
||||
For example, to test a game in French, the following argument can be
|
||||
supplied:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
godot --language fr
|
||||
```
|
||||
|
||||
Translating the project name
|
||||
----------------------------
|
||||
|
@ -71,14 +71,14 @@ each locale will be defined in its own file.
|
||||
Create a directory named `locale` in the project directory. In this directory,
|
||||
save a file named `messages.pot` with the following contents:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
# Don't remove the two lines below, they're required for gettext to work correctly.
|
||||
msgid ""
|
||||
msgstr ""
|
||||
|
||||
msgid "Hello world!"
|
||||
msgstr ""
|
||||
```
|
||||
|
||||
Messages in gettext are made of `msgid` and `msgstr` pairs.
|
||||
`msgid` is the source string (usually in English), `msgstr` will be
|
||||
@ -95,27 +95,27 @@ create and update the POT file from your scene files and scripts.
|
||||
|
||||
After installing `babel` and `babel-godot`, for example using pip:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
pip3 install babel babel-godot
|
||||
```
|
||||
|
||||
Write a mapping file (for example `babelrc`) which will indicate which files
|
||||
pybabel needs to process (note that we process GDScript as Python, which is
|
||||
generally sufficient):
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
```
|
||||
[python: **.gd]
|
||||
encoding = utf-8
|
||||
|
||||
[godot_scene: **.tscn]
|
||||
encoding = utf-8
|
||||
```
|
||||
|
||||
You can then run pybabel like so:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
pybabel extract -F babelrc -k text -k LineEdit/placeholder_text -k tr -o godot-l10n.pot .
|
||||
```
|
||||
|
||||
Use the `-k` option to specify what needs to be extracted. In this case,
|
||||
arguments to `tr()` will be translated, as well
|
||||
@ -129,9 +129,9 @@ The `msginit` command is used to turn a PO template into a messages file.
|
||||
For instance, to create a French localization file, use the following command
|
||||
while in the `locale` directory:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
msginit --no-translator --input=messages.pot --locale=fr
|
||||
```
|
||||
|
||||
The command above will create a file named `fr.po` in the same directory
|
||||
as the PO template.
|
||||
@ -160,10 +160,10 @@ that they contain new strings, while removing strings that are no longer
|
||||
present in the PO template. This can be done automatically using the
|
||||
`msgmerge` tool:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
# The order matters: specify the message file *then* the PO template!
|
||||
msgmerge --update --backup=none fr.po messages.pot
|
||||
```
|
||||
|
||||
If you want to keep a backup of the original message file (which would be
|
||||
saved as `fr.po~` in this example), remove the `--backup=none` argument.
|
||||
@ -185,9 +185,9 @@ Checking the validity of a PO file or template
|
||||
It is possible to check whether a gettext file's syntax is valid by running
|
||||
the command below:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
msgfmt fr.po --check
|
||||
```
|
||||
|
||||
If there are syntax errors or warnings, they will be displayed in the console.
|
||||
Otherwise, `msgfmt` won't output anything.
|
||||
@ -202,9 +202,9 @@ PO files.
|
||||
|
||||
You can generate a MO file with the command below:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
msgfmt fr.po --no-hash -o fr.mo
|
||||
```
|
||||
|
||||
If the PO file is valid, this command will create a `fr.mo` file besides
|
||||
the PO file. This MO file can then be loaded in Godot as described below.
|
||||
@ -213,9 +213,9 @@ The original PO file should be kept in version control so you can update
|
||||
your translation in the future. In case you lose the original PO file and
|
||||
wish to decompile a MO file into a text-based PO file, you can do so with:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
```
|
||||
msgunfmt fr.mo > fr.po
|
||||
```
|
||||
|
||||
The decompiled file will not include comments or fuzzy strings, as these are
|
||||
never compiled in the MO file in the first place.
|
||||
|
@ -70,8 +70,7 @@ gdscript GDScript
|
||||
As you press keys, move the mouse, and perform other inputs, you'll see each
|
||||
event scroll by in the output window. Here's an example of the output:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
A
|
||||
InputEventMouseMotion : button_mask=0, position=(108, 108), relative=(26, 1), speed=(164.152496, 159.119843), pressure=(0), tilt=(0, 0)
|
||||
InputEventMouseButton : button_index=BUTTON_LEFT, pressed=true, position=(108, 107), button_mask=1, doubleclick=false
|
||||
@ -80,6 +79,7 @@ event scroll by in the output window. Here's an example of the output:
|
||||
F
|
||||
Alt
|
||||
InputEventMouseMotion : button_mask=0, position=(108, 107), relative=(0, -1), speed=(164.152496, 159.119843), pressure=(0), tilt=(0, 0)
|
||||
```
|
||||
|
||||
As you can see, the results are very different for the different types of
|
||||
input. Key events are even printed as their key symbols. For example, let's
|
||||
|
@ -33,17 +33,17 @@ functionality you want the built-in aspects of the shader to have.
|
||||
For example, if you do not want to have lights affect an object, set the render
|
||||
mode to `unshaded`:
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
render_mode unshaded;
|
||||
```
|
||||
|
||||
You can also stack multiple render modes together. For example, if you want to
|
||||
use toon shading instead of more-realistic PBR shading, set the diffuse mode and
|
||||
specular mode to toon:
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
render_mode diffuse_toon, specular_toon;
|
||||
```
|
||||
|
||||
This model of built-in functionality allows you to write complex custom shaders
|
||||
by changing only a few parameters.
|
||||
@ -60,11 +60,11 @@ First let's set the color of the water. We do that by setting `ALBEDO`.
|
||||
|
||||
Let's set it to a nice shade of blue.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
void fragment() {
|
||||
ALBEDO = vec3(0.1, 0.3, 0.5);
|
||||
}
|
||||
```
|
||||
|
||||
![](img/albedo.png)
|
||||
|
||||
@ -97,13 +97,13 @@ Water is not a metal, so we will set its `METALLIC` property to `0.0`. Water
|
||||
is also highly reflective, so we will set its `ROUGHNESS` property to be quite
|
||||
low as well.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
void fragment() {
|
||||
METALLIC = 0.0;
|
||||
ROUGHNESS = 0.01;
|
||||
ALBEDO = vec3(0.1, 0.3, 0.5);
|
||||
}
|
||||
```
|
||||
|
||||
![](img/plastic.png)
|
||||
|
||||
@ -120,9 +120,9 @@ In order to increase the specular reflections, we will do two things. First, we
|
||||
will change the render mode for specular to toon because the toon render mode
|
||||
has larger specular highlights.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
render_mode specular_toon;
|
||||
```
|
||||
|
||||
![](img/specular-toon.png)
|
||||
|
||||
@ -131,14 +131,14 @@ glancing angles. Usually it is used to emulate the way light passes through
|
||||
fabric on the edges of an object, but we will use it here to help achieve a nice
|
||||
watery effect.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
void fragment() {
|
||||
RIM = 0.2;
|
||||
METALLIC = 0.0;
|
||||
ROUGHNESS = 0.01;
|
||||
ALBEDO = vec3(0.1, 0.3, 0.5);
|
||||
}
|
||||
```
|
||||
|
||||
![](img/rim.png)
|
||||
|
||||
@ -150,9 +150,9 @@ mesh's surface, while the `VIEW` vector is the direction between your eye and
|
||||
that point on the surface. The dot product between them is a handy way to tell
|
||||
when you are looking at the surface head-on or at a glancing angle.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float fresnel = sqrt(1.0 - dot(NORMAL, VIEW));
|
||||
```
|
||||
|
||||
And mix it into both `ROUGHNESS` and `ALBEDO`. This is the benefit of
|
||||
ShaderMaterials over SpatialMaterials. With SpatialMaterial, we could set
|
||||
@ -160,8 +160,7 @@ these properties with a texture, or to a flat number. But with shaders we can
|
||||
set them based on any mathematical function that we can dream up.
|
||||
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
void fragment() {
|
||||
float fresnel = sqrt(1.0 - dot(NORMAL, VIEW));
|
||||
RIM = 0.2;
|
||||
@ -169,6 +168,7 @@ set them based on any mathematical function that we can dream up.
|
||||
ROUGHNESS = 0.01 * (1.0 - fresnel);
|
||||
ALBEDO = vec3(0.1, 0.3, 0.5) + (0.1 * fresnel);
|
||||
}
|
||||
```
|
||||
|
||||
![](img/fresnel.png)
|
||||
|
||||
@ -193,35 +193,35 @@ In the last tutorial we calculated height by reading from a heightmap. For this
|
||||
tutorial, we will do the same. Put the heightmap code in a function called
|
||||
`height()`.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float height(vec2 position) {
|
||||
return texture(noise, position / 10.0).x; // Scaling factor is based on mesh size (this PlaneMesh is 10×10).
|
||||
}
|
||||
```
|
||||
|
||||
In order to use `TIME` in the `height()` function, we need to pass it in.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float height(vec2 position, float time) {
|
||||
}
|
||||
```
|
||||
|
||||
And make sure to correctly pass it in inside the vertex function.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
void vertex() {
|
||||
vec2 pos = VERTEX.xz;
|
||||
float k = height(pos, TIME);
|
||||
VERTEX.y = k;
|
||||
}
|
||||
```
|
||||
|
||||
Instead of using a normalmap to calculate normals. We are going to compute them
|
||||
manually in the `vertex()` function. To do so use the following line of code.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
NORMAL = normalize(vec3(k - height(pos + vec2(0.1, 0.0), TIME), 0.1, k - height(pos + vec2(0.0, 0.1), TIME)));
|
||||
```
|
||||
|
||||
We need to compute `NORMAL` manually because in the next section we will be
|
||||
using math to create complex-looking waves.
|
||||
@ -229,12 +229,12 @@ using math to create complex-looking waves.
|
||||
Now, we are going to make the `height()` function a little more complicated by
|
||||
offsetting `position` by the cosine of `TIME`.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float height(vec2 position, float time) {
|
||||
vec2 offset = 0.01 * cos(position + time);
|
||||
return texture(noise, (position / 10.0) - offset).x;
|
||||
}
|
||||
```
|
||||
|
||||
This results in waves that move slowly, but not in a very natural way. The next
|
||||
section will dig deeper into using shaders to create more complex effects, in
|
||||
@ -254,35 +254,35 @@ modifying the `height()` function and by introducing a new function called
|
||||
We are going to call `wave()` multiple times in `height()` in order to fake
|
||||
the way waves look.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float wave(vec2 position){
|
||||
position += texture(noise, position / 10.0).x * 2.0 - 1.0;
|
||||
vec2 wv = 1.0 - abs(sin(position));
|
||||
return pow(1.0 - pow(wv.x * wv.y, 0.65), 4.0);
|
||||
}
|
||||
```
|
||||
|
||||
At first this looks complicated. So let's go through it line-by-line.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
position += texture(noise, position / 10.0).x * 2.0 - 1.0;
|
||||
```
|
||||
|
||||
Offset the position by the `noise` texture. This will make the waves curve, so
|
||||
they won't be straight lines completely aligned with the grid.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
vec2 wv = 1.0 - abs(sin(position));
|
||||
```
|
||||
|
||||
Define a wave-like function using `sin()` and `position`. Normally `sin()`
|
||||
waves are very round. We use `abs()` to absolute to give them a sharp ridge
|
||||
and constrain them to the 0-1 range. And then we subtract it from `1.0` to put
|
||||
the peak on top.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
return pow(1.0 - pow(wv.x * wv.y, 0.65), 4.0);
|
||||
```
|
||||
|
||||
Multiply the x-directional wave by the y-directional wave and raise it to a
|
||||
power to sharpen the peaks. Then subtract that from `1.0` so that the ridges
|
||||
@ -290,12 +290,12 @@ become peaks and raise that to a power to sharpen the ridges.
|
||||
|
||||
We can now replace the contents of our `height()` function with `wave()`.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float height(vec2 position, float time) {
|
||||
float h = wave(position);
|
||||
return h;
|
||||
}
|
||||
```
|
||||
|
||||
Using this, you get:
|
||||
|
||||
@ -304,12 +304,12 @@ Using this, you get:
|
||||
The shape of the sin wave is too obvious. So let's spread the waves out a bit.
|
||||
We do this by scaling `position`.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float height(vec2 position, float time) {
|
||||
float h = wave(position * 0.4);
|
||||
return h;
|
||||
}
|
||||
```
|
||||
|
||||
Now it looks much better.
|
||||
|
||||
@ -324,8 +324,7 @@ going to multiply the output of the wave to make them shorter or taller
|
||||
Here is an example for how you could layer the four waves to achieve nicer
|
||||
looking waves.
|
||||
|
||||
.. code-block:: glsl
|
||||
|
||||
```
|
||||
float height(vec2 position, float time) {
|
||||
float d = wave((position + time) * 0.4) * 0.3;
|
||||
d += wave((position - time) * 0.3) * 0.3;
|
||||
@ -333,6 +332,7 @@ looking waves.
|
||||
d += wave((position - time) * 0.6) * 0.2;
|
||||
return d;
|
||||
}
|
||||
```
|
||||
|
||||
Note that we add time to two and subtract it from the other two. This makes the
|
||||
waves move in different directions creating a complex effect. Also note that the
|
||||
|
@ -137,14 +137,16 @@ To handle clicked `[url]` tags, connect the RichTextLabel node's
|
||||
`meta_clicked` signal to a script function.
|
||||
|
||||
For example, the following method can be connected to `meta_clicked` to open
|
||||
clicked URLs using the user's default web browser::
|
||||
clicked URLs using the user's default web browser:
|
||||
|
||||
```
|
||||
# This assumes RichTextLabel's `meta_clicked` signal was connected to
|
||||
# the function below using the signal connection dialog.
|
||||
func _richtextlabel_on_meta_clicked(meta):
|
||||
# `meta` is not guaranteed to be a String, so convert it to a String
|
||||
# to avoid script errors at run-time.
|
||||
OS.shell_open(str(meta))
|
||||
```
|
||||
|
||||
For more advanced use cases, it's also possible to store JSON in an `[url]`
|
||||
tag's option and parse it in the function that handles the `meta_clicked` signal.
|
||||
@ -270,8 +272,7 @@ Here are some examples of custom effects:
|
||||
Ghost
|
||||
~~~~~
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
tool
|
||||
extends RichTextEffect
|
||||
class_name RichTextGhost
|
||||
@ -289,12 +290,12 @@ Ghost
|
||||
var alpha = sin(char_fx.elapsed_time * speed + (char_fx.absolute_index / span)) * 0.5 + 0.5
|
||||
char_fx.color.a = alpha
|
||||
return true
|
||||
```
|
||||
|
||||
Pulse
|
||||
~~~~~
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
tool
|
||||
extends RichTextEffect
|
||||
class_name RichTextPulse
|
||||
@ -316,12 +317,12 @@ Pulse
|
||||
char_fx.color = char_fx.color.linear_interpolate(color, sined_time)
|
||||
char_fx.offset = Vector2(0, -1) * y_off
|
||||
return true
|
||||
```
|
||||
|
||||
Matrix
|
||||
~~~~~~
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
tool
|
||||
extends RichTextEffect
|
||||
class_name RichTextMatrix
|
||||
@ -352,10 +353,11 @@ Matrix
|
||||
value += 65
|
||||
char_fx.character = value
|
||||
return true
|
||||
```
|
||||
|
||||
This will add a few new BBCode commands, which can be used like so:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
[center][ghost]This is a custom [matrix]effect[/matrix][/ghost] made in
|
||||
[pulse freq=5.0 height=2.0][pulse color=#00FFAA freq=2.0]GDScript[/pulse][/pulse].[/center]
|
||||
```
|
@ -45,8 +45,7 @@ To center a control in its parent, set its anchors to 0.5 and each margin
|
||||
to half of its relevant dimension. For example, the code below shows how
|
||||
a TextureRect can be centered in its parent:
|
||||
|
||||
::
|
||||
|
||||
```
|
||||
var rect = TextureRect.new()
|
||||
rect.texture = load("res://icon.png)")
|
||||
rect.anchor_left = 0.5
|
||||
@ -59,6 +58,7 @@ a TextureRect can be centered in its parent:
|
||||
rect.margin_top = -texture_size.y / 2
|
||||
rect.margin_bottom = -texture_size.y / 2
|
||||
add_child(rect)
|
||||
```
|
||||
|
||||
Setting each anchor to 0.5 moves the reference point for the margins to
|
||||
the center of its parent. From there, we set negative margins so that
|
||||
|
Loading…
Reference in New Issue
Block a user