mirror of
https://github.com/godotengine/godot.git
synced 2024-11-21 19:42:43 +00:00
changes
parent
426a5cef16
commit
e45f3d49d3
6
Home.md
6
Home.md
@ -90,9 +90,9 @@ Welcome to the Godot Engine documentation center. The aim of these pages is to p
|
||||
#### Class List
|
||||
|
||||
|
||||
* [Alphabetical Class List](class_list/class_list) List of classes in alphabetical order.
|
||||
* [Categorized Class List](class_list/category) List of classes organized by category.
|
||||
* [Inheritance Class Tree](class_list/inheritance) List of classes organized by inheritance.
|
||||
* [Alphabetical Class List](class_class_list) List of classes in alphabetical order.
|
||||
* [Categorized Class List](class_category) List of classes organized by category.
|
||||
* [Inheritance Class Tree](class_inheritance) List of classes organized by inheritance.
|
||||
* [Relevant Classes](relevant_classes) List of the most relevant classes to learn first.
|
||||
|
||||
#### Languages
|
||||
|
6
start.md
6
start.md
@ -105,11 +105,11 @@ Welcome to the Godot Engine documentation center. The aim of these pages is to p
|
||||
#### Class List
|
||||
|
||||
|
||||
* [Alphabetical Class List](class_list/class_list) List of classes in alphabetical order.
|
||||
* [Alphabetical Class List](class_class_list) List of classes in alphabetical order.
|
||||
|
||||
* [Categorized Class List](class_list/category) List of classes organized by category.
|
||||
* [Categorized Class List](class_category) List of classes organized by category.
|
||||
|
||||
* [Inheritance Class Tree](class_list/inheritance) List of classes organized by inheritance.
|
||||
* [Inheritance Class Tree](class_inheritance) List of classes organized by inheritance.
|
||||
|
||||
* [Relevant Classes](relevant_classes) List of the most relevant classes to learn first.
|
||||
|
||||
|
@ -14,7 +14,7 @@ For the sake of the old times, the game will be in 640x400 pixels resolution. Th
|
||||
|
||||
<p align="center"><img src="images/clearcolor.png"></p>
|
||||
|
||||
Create a [Node2D](class_list/node2d) node for the project root. Node2D is the base type for the 2D engine. After this, add some sprites ([Sprite](class_list/sprite) node) and set each to the corresponding texture. The final scene layour should look similar to this (note: the ball is in the middle!):
|
||||
Create a [Node2D](class_node2d) node for the project root. Node2D is the base type for the 2D engine. After this, add some sprites ([Sprite](class_sprite) node) and set each to the corresponding texture. The final scene layour should look similar to this (note: the ball is in the middle!):
|
||||
|
||||
<p align="center"><img src="images/pong_layout.png"></p>
|
||||
|
||||
|
@ -9,7 +9,7 @@ To begin, let's just use the scene from the previous tutorial (splash screen). T
|
||||
|
||||
### Creating the Animation
|
||||
|
||||
First of all, add an [AnimationPlayer](class_list/animationplayer) node to the scene, make it a child of bg (the root node):
|
||||
First of all, add an [AnimationPlayer](class_animationplayer) node to the scene, make it a child of bg (the root node):
|
||||
|
||||
<p align="center"><img src="images/animplayer.png"></p>
|
||||
|
||||
|
@ -19,19 +19,19 @@ In the end, the resulting UI subsystem in Godot is an efficient solution to this
|
||||
|
||||
### Control
|
||||
|
||||
The basic node for UI elements is [Control](class_list/control) (sometimes called "Widget" or "Box" in other toolkits). Every node that provides user interface functionality descends from it.
|
||||
The basic node for UI elements is [Control](class_control) (sometimes called "Widget" or "Box" in other toolkits). Every node that provides user interface functionality descends from it.
|
||||
|
||||
When controls are put in a scene tree as a child of another control, it's coordinates (position, size) are always relative to the parent. This sets the basis for editing complex user interface quickly and visually.
|
||||
|
||||
### Input and Drawing
|
||||
|
||||
Controls receive input events by means of the [_input_event](class_list/control#_input_event)() callback. Only one control, the one in focus, will receive keyboard/joypad events (see [set_focus_mode](class_list/control#set_focus_mode)() and [grab_focus](class_list/control#grab_focus)().
|
||||
Controls receive input events by means of the [_input_event](class_control#_input_event)() callback. Only one control, the one in focus, will receive keyboard/joypad events (see [set_focus_mode](class_control#set_focus_mode)() and [grab_focus](class_control#grab_focus)().
|
||||
|
||||
Mouse Motion events are received by the control directly below the mouse pointer. When a control receives a mouse button pressed event, all subsequent motion events are received by the pressed control until that button is released, even if the pointer moves outside the control boundary.
|
||||
|
||||
Like any class that inherits from [CanvasItem](class_list/canvasitem) (Control does), a [_draw](class_list/canvasitem#draw)() callback will be received at the begining and every time the control needs to be redrawn (programmer needs to call [update](class_list/canvasitem#update)() to enqueue the CanvasItem for redraw). If the control is not visible (yet aother CanvasItem property), the control does not receive any input.
|
||||
Like any class that inherits from [CanvasItem](class_canvasitem) (Control does), a [_draw](class_canvasitem#draw)() callback will be received at the begining and every time the control needs to be redrawn (programmer needs to call [update](class_canvasitem#update)() to enqueue the CanvasItem for redraw). If the control is not visible (yet aother CanvasItem property), the control does not receive any input.
|
||||
|
||||
In general though, the programmer does not need to deal with drawing and input events directly when building UIs, (that is more useful when creating custom controls). Instead, controls emit different kinds of signals with contextural information for when action occurs. For example, a [Button](class_list/button) emits a "pressed" signal when pressed, a [Slider](class_list/slider) will emit a "value_changed" when dragged, etc.
|
||||
In general though, the programmer does not need to deal with drawing and input events directly when building UIs, (that is more useful when creating custom controls). Instead, controls emit different kinds of signals with contextural information for when action occurs. For example, a [Button](class_button) emits a "pressed" signal when pressed, a [Slider](class_slider) will emit a "value_changed" when dragged, etc.
|
||||
|
||||
### Custom Control Mini Tutorial
|
||||
|
||||
@ -80,18 +80,18 @@ As mentioned before, Godot includes dozens of controls ready for using in a user
|
||||
This set of controls is enough for most games, where complex interactions or ways to present information are not necessary. The can be skinned easily with regular textures.
|
||||
|
||||
|
||||
* [Label](class_list/label) : Node used for showing text.
|
||||
* [Label](class_label) : Node used for showing text.
|
||||
|
||||
* [TextureFrame](class_list/textureframe) : Displays a single texture, which can be scaled or kept fixed.
|
||||
* [TextureFrame](class_textureframe) : Displays a single texture, which can be scaled or kept fixed.
|
||||
|
||||
* [TextureButton](class_list/texturebutton) : Displays a simple texture buttons, states such as pressed, hover, disabled, etc can be set.
|
||||
* [TextureButton](class_texturebutton) : Displays a simple texture buttons, states such as pressed, hover, disabled, etc can be set.
|
||||
|
||||
* [TextureProgress](class_list/textureprogress) : Displays a single textured progress bar.
|
||||
* [TextureProgress](class_textureprogress) : Displays a single textured progress bar.
|
||||
|
||||
|
||||
Additionally, re-positioning of controls is most efficiently done with anchors in this case (see the [Size and Anchors](tutorial_gui_repositioning) tutorial for more info).
|
||||
|
||||
In any case, it will happen often that even for simple games, more complex UI behaviors will be required. An example of this is a scrolling list of elements (for a high score table, for example), which needs a [ScrollContainer](class_list/scrollcontainer) and a [VBoxContainer](class_list/vboxcontainer). These kind of more advanced controls can be mixed with the regular ones seamlessly (they are all controls anyway).
|
||||
In any case, it will happen often that even for simple games, more complex UI behaviors will be required. An example of this is a scrolling list of elements (for a high score table, for example), which needs a [ScrollContainer](class_scrollcontainer) and a [VBoxContainer](class_vboxcontainer). These kind of more advanced controls can be mixed with the regular ones seamlessly (they are all controls anyway).
|
||||
|
||||
#### Complex UI Controls
|
||||
|
||||
|
@ -2,12 +2,12 @@
|
||||
|
||||
### Nodes AND Resources
|
||||
|
||||
So far, [Node](class_list/node) have been the most important datatype in Godot, as most of the behaviors and features of the engine are implemented through them. There is, though, another datatype that is equally as important. That is [Resource](class_list/resource)..
|
||||
So far, [Node](class_node) have been the most important datatype in Godot, as most of the behaviors and features of the engine are implemented through them. There is, though, another datatype that is equally as important. That is [Resource](class_resource)..
|
||||
|
||||
Where *Nodes* focus on behaviors, such as drawing a sprite, drawing a 3D model, physics, GUI controls, etc,
|
||||
*Resources* are mere *data containers*. This means that they don't do any action nor process any information. Resources just contain data.
|
||||
|
||||
Examples of resources are [Texture](class_list/texture), [Script](class_list/script), [Mesh](class_list/mesh), [Animation](class_list/animation), [Sample](class_list/sample), [AudioStream](class_list/audiostream), [Font](class_list/font), [Translation](class_list/translation), etc.
|
||||
Examples of resources are [Texture](class_texture), [Script](class_script), [Mesh](class_mesh), [Animation](class_animation), [Sample](class_sample), [AudioStream](class_audiostream), [Font](class_font), [Translation](class_translation), etc.
|
||||
|
||||
When Godot saves o loads (from disk) a scene (.scn or .xml), an image (png, jpg), a scrit (.gd) or pretty much anything, that file is considered a resource.
|
||||
|
||||
@ -20,7 +20,7 @@ Typically, every object in Godot (Node, Resource, or anything else) can export p
|
||||
### External vs Built-In
|
||||
|
||||
The resource properties can reference resources in two ways, *external* (on disk) or *built-in*.
|
||||
To be more specific, here's a [Texture](class_list/texture) in a [Sprite](class_list/sprite) node:
|
||||
To be more specific, here's a [Texture](class_texture) in a [Sprite](class_sprite) node:
|
||||
|
||||
<p align="center"><img src="images/spriteprop.png"></p>
|
||||
|
||||
@ -57,9 +57,9 @@ func _ready():
|
||||
|
||||
### Loading Scenes
|
||||
|
||||
Scenes are also resources, but there is a catch. Scenes saved to disk are resources of type [PackedScene](class_list/packedscene), this means that the scene is packed inside a resource.
|
||||
Scenes are also resources, but there is a catch. Scenes saved to disk are resources of type [PackedScene](class_packedscene), this means that the scene is packed inside a resource.
|
||||
|
||||
To obtain an instance of the scene, the method [instance](class_list/packedscene#instance)() must be used.
|
||||
To obtain an instance of the scene, the method [instance](class_packedscene#instance)() must be used.
|
||||
```python
|
||||
func _on_shoot():
|
||||
|
||||
@ -68,11 +68,11 @@ func _on_shoot():
|
||||
```
|
||||
|
||||
This method creates the nodes in hierarchy, configures them (sets all the properties) and returns the root node of the scene, which can be added to any other node.
|
||||
The approach has several advantages. As the [instance](class_list/packedscene#instance)() function is pretty fast, adding extra content to the scene can be done efficiently. New enemies, bullets, effects, etc can be added or removed quickly, without having to load them again from disk each time. It is important to remember that, as always, images, meshes, etc are all shared between the scene instances.
|
||||
The approach has several advantages. As the [instance](class_packedscene#instance)() function is pretty fast, adding extra content to the scene can be done efficiently. New enemies, bullets, effects, etc can be added or removed quickly, without having to load them again from disk each time. It is important to remember that, as always, images, meshes, etc are all shared between the scene instances.
|
||||
|
||||
### Freeing Resources
|
||||
|
||||
Resource extends from [Reference](class_list/reference). As such, when a resource is no longer in use, it will automatically free itelf. Since, in most cases, Resources are contained in Nodes, scripts or other resources, when a node is removed or freed, all the children resources are freed too.
|
||||
Resource extends from [Reference](class_reference). As such, when a resource is no longer in use, it will automatically free itelf. Since, in most cases, Resources are contained in Nodes, scripts or other resources, when a node is removed or freed, all the children resources are freed too.
|
||||
|
||||
### Scripting
|
||||
|
||||
|
@ -134,7 +134,7 @@ With this change, pressing the regular Play button (or F5) will run the project,
|
||||
Going back to the project settings dialog. This dialog provides a lot of options that can be added to engine.cfg and show their default values. If the default value is ok, then there isn't any need to change it.
|
||||
When a value is changed, a tick is marked to the left of the name. This means that the property will be saved to the engine.cfg file and remembered.
|
||||
|
||||
As a side note, for future reference and a little out of context (this is the first tutorial after all!), it is also possible to add custom configuration options and read them in run-time using the [Globals](class_list/globals) singleton.
|
||||
As a side note, for future reference and a little out of context (this is the first tutorial after all!), it is also possible to add custom configuration options and read them in run-time using the [Globals](class_globals) singleton.
|
||||
|
||||
### To Be Continued...
|
||||
|
||||
|
@ -9,40 +9,40 @@ This deserves going a little more into depth. In fact, the scene system is not e
|
||||
|
||||
### MainLoop
|
||||
|
||||
The way Godot works internally is as follows. There is the the [OS](class_list/os) class, which is the only instance that runs at the beginning. Afterwards, all drivers, servers, scripting languages, scene system, etc are loaded.
|
||||
When initialization is complete, [OS](class_list/os) needs to be supplied a [MainLoop](class_list/mainloop) to run. Up to this point, all this is internals working (you can check main/main.cpp file in the source code if you are ever interested to see how this works internally).
|
||||
The way Godot works internally is as follows. There is the the [OS](class_os) class, which is the only instance that runs at the beginning. Afterwards, all drivers, servers, scripting languages, scene system, etc are loaded.
|
||||
When initialization is complete, [OS](class_os) needs to be supplied a [MainLoop](class_mainloop) to run. Up to this point, all this is internals working (you can check main/main.cpp file in the source code if you are ever interested to see how this works internally).
|
||||
|
||||
The user program, or game, starts in the MainLoop. This class has a few methods, for initialization, idle (frame-syncronized callback), fixed (physics-synchronized callback), and input. Again, this is really low level and when making games in Godot, writing your own MainLoop does not even make sense.
|
||||
|
||||
### SceneMainLoop
|
||||
|
||||
One of the ways to explain how Godot works, is that it's a high level game engine over a low level middleware.
|
||||
The scene system is the game engine, while the [OS](class_list/os) and servers are the low level API.
|
||||
The scene system is the game engine, while the [OS](class_os) and servers are the low level API.
|
||||
|
||||
In any case, the scene system provides it's own main loop to OS, [SceneMainLoop](class_list/scenemainloop).
|
||||
In any case, the scene system provides it's own main loop to OS, [SceneMainLoop](class_scenemainloop).
|
||||
This is automatically instanced and set when running a scene, no need to do any extra work.
|
||||
|
||||
It's important to know that this class exists because it has a few important uses:
|
||||
|
||||
|
||||
* It contains the root [Viewport](class_list/viewport), when a scene is first opened, it's added as a child of it to become part of the active scene (more on that next)
|
||||
* It contains the root [Viewport](class_viewport), when a scene is first opened, it's added as a child of it to become part of the active scene (more on that next)
|
||||
|
||||
* It contains information about the groups, and has means to call all nodes in a group, or get a list of them.
|
||||
|
||||
* It contains some global state functionality, such as setting pause mode, or quitting the process.
|
||||
|
||||
When a node is part of the active scene, the [SceneMainLoop](class_list/scenemainloop) can be obtained by simply calling [Node.get_scene](class_list/node#get_scene)().
|
||||
When a node is part of the active scene, the [SceneMainLoop](class_scenemainloop) can be obtained by simply calling [Node.get_scene](class_node#get_scene)().
|
||||
|
||||
### Root Viewport
|
||||
|
||||
The root [Viewport](class_list/viewport) is always a top of the scene. From a node, it can be obtained in two different ways:
|
||||
The root [Viewport](class_viewport) is always a top of the scene. From a node, it can be obtained in two different ways:
|
||||
|
||||
```python
|
||||
get_scene().get_root() # access via scenemainloop
|
||||
get_node("/root") # access via absolute path
|
||||
```
|
||||
|
||||
This node contains the main viewport, anything that is a child of a [Viewport](class_list/viewport) is drawn inside of it by default, so it makes sense that the top of all nodes is always a node of this type, otherwise nothing would be seen!
|
||||
This node contains the main viewport, anything that is a child of a [Viewport](class_viewport) is drawn inside of it by default, so it makes sense that the top of all nodes is always a node of this type, otherwise nothing would be seen!
|
||||
|
||||
While other viewports can be created in the scene (for split-screen effects and such), this one is the only one that is never created by the user. It's created automatically inside SceneMainLoop.
|
||||
|
||||
|
@ -91,7 +91,7 @@ Which will show the list of signals a Button can emit.
|
||||
But this example will not use it. We don't want to make things *too* easy. So please close that screen!
|
||||
In any case, at this point it is clear that that we are interested in the "pressed" signal, so instead of doing it with the visual interface, the connection will be done using code.
|
||||
|
||||
For this, there is a function that is probably the one that Godot programmers will use the most, this is [get_node](class_list/node#get_node)(). This function uses paths to fetch nodes in the current tree or anywhere in the scene, relative to the node holding the script.
|
||||
For this, there is a function that is probably the one that Godot programmers will use the most, this is [get_node](class_node#get_node)(). This function uses paths to fetch nodes in the current tree or anywhere in the scene, relative to the node holding the script.
|
||||
|
||||
To fetch the button, the following must be used:
|
||||
|
||||
@ -110,7 +110,7 @@ func _on_button_pressed():
|
||||
|
||||
```
|
||||
|
||||
Finally, the button "pressed" signal will be connected to that callback in _ready(), by using [connect](class_list/object#connect)().
|
||||
Finally, the button "pressed" signal will be connected to that callback in _ready(), by using [connect](class_object#connect)().
|
||||
|
||||
```python
|
||||
|
||||
|
@ -6,7 +6,7 @@ Several actions in Godot are triggered by callbacks or virtual functions, so the
|
||||
|
||||
However,it is still a very common case to have a script process on every frame. There are two types of processing, idle processing and fixed processing.
|
||||
|
||||
Idle processing is activated with the [Node.set_process](class_list/node#set_process)() function. Once active, the [Node._process](class_list/node#set_process)() callback will be called every frame. Example:
|
||||
Idle processing is activated with the [Node.set_process](class_node#set_process)() function. Once active, the [Node._process](class_node#set_process)() callback will be called every frame. Example:
|
||||
|
||||
```python
|
||||
|
||||
@ -53,7 +53,7 @@ func _ready():
|
||||
|
||||
```
|
||||
|
||||
This way, if the player, sneaking into the secret base, is discovered, all enemies can be notified about the alarm sounding, by using [SceneMainLoop.call_group](class_list/scenemainloop#call_group)():
|
||||
This way, if the player, sneaking into the secret base, is discovered, all enemies can be notified about the alarm sounding, by using [SceneMainLoop.call_group](class_scenemainloop#call_group)():
|
||||
|
||||
```python
|
||||
|
||||
@ -64,7 +64,7 @@ func _on_discovered():
|
||||
```
|
||||
|
||||
The above code calls the function "player_was_discovered" on every member of the group "guards".
|
||||
Optionally, it is possible to get the full list of "guards" nodes by calling [SceneMainLoop.get_nodes_in_group](class_list/scenemainloop#get_nodes_in_group)():
|
||||
Optionally, it is possible to get the full list of "guards" nodes by calling [SceneMainLoop.get_nodes_in_group](class_scenemainloop#get_nodes_in_group)():
|
||||
|
||||
```python
|
||||
|
||||
@ -72,12 +72,12 @@ var guards = get_scene().get_nodes_in_group("guards")
|
||||
|
||||
```
|
||||
|
||||
More will be added about [SceneMainLoop](class_list/scenemainloop) later.
|
||||
More will be added about [SceneMainLoop](class_scenemainloop) later.
|
||||
|
||||
|
||||
### Notifications
|
||||
|
||||
Godot has a system of notifications. This is usually not needed to be used from scripting, as it's too low level and virtual functions are provided for most of them. It's just good to know they exists. Simply add a [Object._notification](class_list/object#_notification)() function in your script:
|
||||
Godot has a system of notifications. This is usually not needed to be used from scripting, as it's too low level and virtual functions are provided for most of them. It's just good to know they exists. Simply add a [Object._notification](class_object#_notification)() function in your script:
|
||||
|
||||
```python
|
||||
|
||||
@ -90,7 +90,7 @@ func _notification(what):
|
||||
|
||||
```
|
||||
|
||||
The documentation of each class in the [class list](class_list/class_list) shows the notifications it can receive. However, again, for most cases script provides simpler overrideable functions.
|
||||
The documentation of each class in the [class list](class_class_list) shows the notifications it can receive. However, again, for most cases script provides simpler overrideable functions.
|
||||
|
||||
### Overrideable Functions
|
||||
|
||||
|
@ -16,15 +16,15 @@ Create a scene with screen resolution 800x450, and set it up like this:
|
||||
<p align="center"><img src="images/robisplashscene.png"></p>
|
||||
<p align="center"><img src="images/robisplashpreview.png"></p>
|
||||
|
||||
The nodes 'background" and "logo" are of [TextureFrame](class_list/textureframe) type. These have a special property for setting the texture to be displayed, just load the corresponding file.
|
||||
The nodes 'background" and "logo" are of [TextureFrame](class_textureframe) type. These have a special property for setting the texture to be displayed, just load the corresponding file.
|
||||
|
||||
<p align="center"><img src="images/texframe.png"></p>
|
||||
|
||||
The node "start" is a [TextureButton](class_list/texturebutton), it takes several images for different states, but only the normal and pressed will be supplied in this example:
|
||||
The node "start" is a [TextureButton](class_texturebutton), it takes several images for different states, but only the normal and pressed will be supplied in this example:
|
||||
|
||||
<p align="center"><img src="images/texbutton.png"></p>
|
||||
|
||||
Finally, the node "copyright" is a [Label](class_list/label). Labels can be set a custom font by editing the following property:
|
||||
Finally, the node "copyright" is a [Label](class_label). Labels can be set a custom font by editing the following property:
|
||||
|
||||
<p align="center"><img src="images/label.png"></p>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user