More code block cleanups.

This commit is contained in:
Relintai 2023-01-12 22:00:14 +01:00
parent f77227608c
commit 8e5258c966
60 changed files with 906 additions and 797 deletions

View File

@ -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

View File

@ -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.

View File

@ -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.

View File

@ -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;
};
```

View File

@ -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
-------

View File

@ -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

View File

@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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.

View File

@ -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
---

View File

@ -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
```

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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
```

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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:

View File

@ -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.

View File

@ -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:

View File

@ -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

View File

@ -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

View File

@ -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:

View File

@ -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:
~~~~~~~~~~~

View File

@ -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
~~~~~

View File

@ -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
----------

View File

@ -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())
```

View File

@ -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
```

View File

@ -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
--------------------------

View File

@ -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

View File

@ -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

View File

@ -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 )
```

View File

@ -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
~~~~~~~~~

View File

@ -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`.

View File

@ -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
```

View File

@ -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.

View File

@ -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
------------

View File

@ -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
```

View File

@ -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
```

View File

@ -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
```

View File

@ -1,6 +1,3 @@
.. meta::
:keywords: cheatsheet, cheat sheet, shortcut
Default editor shortcuts

View File

@ -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:

View File

@ -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

View File

@ -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 )`.

View File

@ -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

View File

@ -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
----------------------------

View File

@ -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)
```

View File

@ -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

View File

@ -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
----------------

View File

@ -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
----------------------------

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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]
```

View File

@ -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