diff --git a/community/contributing/best_practices_for_engine_contributors.rst b/community/contributing/best_practices_for_engine_contributors.rst index d9fab93a9..60ccdb8ba 100644 --- a/community/contributing/best_practices_for_engine_contributors.rst +++ b/community/contributing/best_practices_for_engine_contributors.rst @@ -90,7 +90,7 @@ to work around it. This difficulty can be expressed as: If the problem is *too complex* for most users to solve, the software must offer a ready-made solution for it. Likewise, if the problem is easy for the user to -workaround, offering such a solution is unnecessary and it's up to the user to +work around, offering such a solution is unnecessary and it's up to the user to do it. The exception, however, is when the user stumbles into this problem *frequently @@ -148,7 +148,7 @@ problems (as described in #2) also make their appearance on stage. .. image:: img/best_practices5.png The main problem is that, in reality, it rarely works this way. Most of the -time, just writing an individual solution to each problem results in code that +time, writing an individual solution to each problem results in code that is simpler and more maintainable. Additionally, solutions that target individual problems are better for the @@ -157,7 +157,7 @@ to learn and remember a more complex system they will only need for simple tasks. Big and flexible solutions also have an additional drawback which is that, over -time, they are rarely flexible enough for all users, which keep requesting more +time, they are rarely flexible enough for all users, who keep requesting more functions added (and making the API and codebase more and more complex). #6: Cater to common use cases, leave the door open for the rare ones @@ -225,7 +225,7 @@ but this path is always the advised one. Not every problem has a simple solution and, many times, the right choice is to use a third party library to solve the problem. -As Godot requires to be shipped in a large amount of platforms, we just can't +As Godot requires to be shipped in a large amount of platforms, we can't link libraries dynamically. Instead, we bundle them in our source tree. .. image:: img/best_practices8.png diff --git a/community/contributing/docs_writing_guidelines.rst b/community/contributing/docs_writing_guidelines.rst index e40c20b93..b67ad594b 100644 --- a/community/contributing/docs_writing_guidelines.rst +++ b/community/contributing/docs_writing_guidelines.rst @@ -110,7 +110,7 @@ The progressive forms describe continuous actions. E.g. "is calling", Vector2 move ( Vector2 rel_vec ) Move the body in the given direction, **stopping** if there is an obstacle. [...] -**Do** use simple present, preterit or future. +**Do** use simple present, past, or future. :: diff --git a/development/cpp/binding_to_external_libraries.rst b/development/cpp/binding_to_external_libraries.rst index 9025a8b75..f9d6546dd 100644 --- a/development/cpp/binding_to_external_libraries.rst +++ b/development/cpp/binding_to_external_libraries.rst @@ -17,7 +17,7 @@ To bind to an external library, set up a module directory similar to the Summato godot/modules/tts/ -Next, you will create a header file with a simple TTS class: +Next, you will create a header file with a TTS class: .. code-block:: cpp diff --git a/development/cpp/core_types.rst b/development/cpp/core_types.rst index 5f4c367f0..cb7a9c5cd 100644 --- a/development/cpp/core_types.rst +++ b/development/cpp/core_types.rst @@ -144,7 +144,7 @@ Godot provides also a set of common containers: - Set - Map -They are simple and aim to be as minimal as possible, as templates +They aim to be as minimal as possible, as templates 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: diff --git a/development/cpp/custom_modules_in_cpp.rst b/development/cpp/custom_modules_in_cpp.rst index 72db09180..a9ac5ac2b 100644 --- a/development/cpp/custom_modules_in_cpp.rst +++ b/development/cpp/custom_modules_in_cpp.rst @@ -42,7 +42,7 @@ To create a new module, the first step is creating a directory inside 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: +Inside we will create a summator class: .. code-block:: cpp @@ -189,8 +189,8 @@ Example ``SCsub`` with custom flags: # - 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``: +And finally, the configuration file for the module, this is a +Python script that must be named ``config.py``: .. code-block:: python @@ -385,7 +385,7 @@ We now need to add this method to ``register_types`` header and source files: Improving the build system for development ------------------------------------------ -So far we defined a clean and simple SCsub that allows us to add the sources +So far we defined a clean SCsub that allows us to add the sources of our new module as part of the Godot binary. This static approach is fine when we want to build a release version of our diff --git a/development/cpp/custom_resource_format_loaders.rst b/development/cpp/custom_resource_format_loaders.rst index 59d18f4f4..2098c250b 100644 --- a/development/cpp/custom_resource_format_loaders.rst +++ b/development/cpp/custom_resource_format_loaders.rst @@ -46,7 +46,7 @@ Creating a ResourceFormatLoader Each file format consist of a data container and a ``ResourceFormatLoader``. -ResourceFormatLoaders are usually simple classes which return all the +ResourceFormatLoaders are classes which return all the necessary metadata for supporting new extensions in Godot. The class must return the format name and the extension string. diff --git a/getting_started/first_3d_game/index.rst b/getting_started/first_3d_game/index.rst index a2e628e9d..f8d71e1e5 100644 --- a/getting_started/first_3d_game/index.rst +++ b/getting_started/first_3d_game/index.rst @@ -23,7 +23,7 @@ You will learn to: - Code basic procedural gameplay by instancing monsters at regular time intervals. - Design a movement animation and change its speed at run-time. -- Draw a simple interface on a 3D game. +- Draw a user interface on a 3D game. And more. diff --git a/getting_started/introduction/godot_design_philosophy.rst b/getting_started/introduction/godot_design_philosophy.rst index 8ba0a3a58..f4ba3ff49 100644 --- a/getting_started/introduction/godot_design_philosophy.rst +++ b/getting_started/introduction/godot_design_philosophy.rst @@ -81,7 +81,7 @@ GDScript and VisualScript, along with C#. They're designed for the needs of game developers and game designers, and they're tightly integrated in the engine and the editor. -GDScript lets you write simple code using an indentation-based syntax, +GDScript lets you write code using an indentation-based syntax, yet it detects types and offers a static language's quality of auto-completion. It is also optimized for gameplay code with built-in types like Vectors and Colors. diff --git a/getting_started/step_by_step/instancing.rst b/getting_started/step_by_step/instancing.rst index 1bc472b42..cf0bc7317 100644 --- a/getting_started/step_by_step/instancing.rst +++ b/getting_started/step_by_step/instancing.rst @@ -170,7 +170,7 @@ Godot, such as Model-View-Controller (MVC) or Entity-Relationship diagrams. Instead, you can start by imagining the elements players will see in your game and structure your code around them. -For example, you could break down a simple shooter game like so: +For example, you could break down a shooter game like so: .. image:: img/instancing_diagram_shooter.png diff --git a/tutorials/2d/custom_drawing_in_2d.rst b/tutorials/2d/custom_drawing_in_2d.rst index fd568f56c..724f485cf 100644 --- a/tutorials/2d/custom_drawing_in_2d.rst +++ b/tutorials/2d/custom_drawing_in_2d.rst @@ -7,11 +7,9 @@ Why? ---- Godot has nodes to draw sprites, polygons, particles, and all sorts of -stuff. For most cases, this is enough; but not always. Before crying in fear, -angst, and rage because a node to draw that specific *something* does not exist... -it would be good to know that it is possible to easily make any 2D node (be it -:ref:`Control ` or :ref:`Node2D ` -based) draw custom commands. It is *really* easy to do it, too. +stuff. For most cases, this is enough. If there's no node to draw something specific +you need, you can make any 2D node (for example, :ref:`Control ` or +:ref:`Node2D ` based) draw custom commands. But... ------ @@ -111,7 +109,7 @@ redrawn if modified: } } -In some cases, it may be desired to draw every frame. For this, just +In some cases, it may be desired to draw every frame. For this, call ``update()`` from the ``_process()`` callback, like this: .. tabs:: @@ -209,7 +207,7 @@ We first determine the angle of each point, between the starting and ending angl The reason why each angle is decreased by 90° is that we will compute 2D positions out of each angle using trigonometry (you know, cosine and sine stuff...). However, -to be simple, ``cos()`` and ``sin()`` use radians, not degrees. The angle of 0° (0 radian) +``cos()`` and ``sin()`` use radians, not degrees. The angle of 0° (0 radian) starts at 3 o'clock, although we want to start counting at 12 o'clock. So we decrease each angle by 90° in order to start counting from 12 o'clock. diff --git a/tutorials/2d/particle_systems_2d.rst b/tutorials/2d/particle_systems_2d.rst index 40dad5bb3..3ec9e5dd2 100644 --- a/tutorials/2d/particle_systems_2d.rst +++ b/tutorials/2d/particle_systems_2d.rst @@ -6,8 +6,7 @@ Particle systems (2D) Intro ----- -A simple (but flexible enough for most uses) particle system is -provided. Particle systems are used to simulate complex physical effects, +Particle systems are used to simulate complex physical effects, such as sparks, fire, magic particles, smoke, mist, etc. The idea is that a "particle" is emitted at a fixed interval and with a diff --git a/tutorials/3d/csg_tools.rst b/tutorials/3d/csg_tools.rst index 522c50cd0..a654522ca 100644 --- a/tutorials/3d/csg_tools.rst +++ b/tutorials/3d/csg_tools.rst @@ -8,7 +8,7 @@ shapes or custom meshes to create more complex shapes. In 3D modelling software, CSG is mostly known as "Boolean Operators". Level prototyping is one of the main uses of CSG in Godot. This technique allows -users to create simple versions of most common shapes by combining primitives. +users to create the most common shapes by combining primitives. Interior environments can be created by using inverted primitives. .. note:: The CSG nodes in Godot are mainly intended for prototyping. There is @@ -100,7 +100,7 @@ Processing order ~~~~~~~~~~~~~~~~ Every CSG node will first process its children nodes and their operations: -union, intersection or subtraction, in tree order, and apply them to itself one +union, intersection, or subtraction, in tree order, and apply them to itself one after the other. .. note:: In the interest of performance, make sure CSG geometry remains diff --git a/tutorials/3d/environment_and_post_processing.rst b/tutorials/3d/environment_and_post_processing.rst index ba1042b16..801eada80 100644 --- a/tutorials/3d/environment_and_post_processing.rst +++ b/tutorials/3d/environment_and_post_processing.rst @@ -69,7 +69,7 @@ There are many ways to set the background: - **Clear Color** uses the default clear color defined by the project. The background will be a constant color. - **Custom Color** is like Clear Color, but with a custom color value. -- **Sky** lets you define a panorama sky (a 360 degree sphere texture) or a procedural sky (a simple sky featuring a gradient and an optional sun). Objects will reflect it and absorb ambient light from it. +- **Sky** lets you define a panorama sky (a 360 degree sphere texture) or a procedural sky (a basic sky featuring a gradient and an optional sun). Objects will reflect it and absorb ambient light from it. - **Color+Sky** lets you define a sky (as above), but uses a constant color value for drawing the background. The sky will only be used for reflection and ambient light. Ambient Light @@ -154,7 +154,7 @@ Auto Exposure (HDR) *This feature is only available when using the GLES3 backend.* Even though, in most cases, lighting and texturing are heavily artist controlled, -Godot supports a simple high dynamic range implementation with the auto exposure +Godot supports a basic high dynamic range implementation with the auto exposure mechanism. This is generally used for the sake of realism when combining interior areas with low light and outdoors. Auto exposure simulates the camera (or eye) in an effort to adapt between light and dark locations and their @@ -259,7 +259,7 @@ Tweaking SSAO is possible with several parameters: - **Light Affect:** SSAO only affects ambient light, but increasing this slider can make it also affect direct light. Some artists prefer this effect. - **Ao Channel Affect:** If a value of zero is used, only the material's AO texture will be used for ambient occlusion; SSAO will not be applied. Values greater than 0 multiply the AO texture by the SSAO effect to varying degrees. This does not affect materials without an AO texture. - **Quality:** Depending on quality, SSAO will take more samples over a sphere for every pixel. High quality only works well on modern GPUs. -- **Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that preserves local detail better, but is not as efficient (generally works better with the high quality setting above), while 3x3 will soften the image better (with a bit of dithering-like effect), but does not preserve local detail as well. +- **Blur:** Type of blur kernel used. The 1x1 kernel preserves local detail better, but is not as efficient (generally works better with the high quality setting above), while 3x3 softens the image better (with a bit of dithering-like effect), but does not preserve local detail as well. - **Edge Sharpness**: This can be used to preserve the sharpness of edges (avoids areas without AO on creases). Depth of Field / Far Blur @@ -320,10 +320,10 @@ Once glow is visible, it can be controlled with a few extra parameters: The **Blend Mode** of the effect can also be changed: -- **Additive** is the strongest one, as it just adds the glow effect over the image with no blending involved. In general, it's too strong to be used, but can look good with low intensity Bloom (produces a dream-like effect). -- **Screen** is the default one. It ensures glow never brights more than itself and works great as an all around. +- **Additive** is the strongest one, as it only adds the glow effect over the image with no blending involved. In general, it's too strong to be used, but can look good with low intensity Bloom (produces a dream-like effect). +- **Screen** is the default one. It ensures glow never brightens more than itself and it works great as an all around. - **Softlight** is the weakest one, producing only a subtle color disturbance around the objects. This mode works best on dark scenes. -- **Replace** can be used to blur the whole screen or debug the effect. It just shows the glow effect without the image below. +- **Replace** can be used to blur the whole screen or debug the effect. It only shows the glow effect without the image below. To change the glow effect size and shape, Godot provides **Levels**. Smaller levels are strong glows that appear around objects, while large levels are hazy diff --git a/tutorials/3d/high_dynamic_range.rst b/tutorials/3d/high_dynamic_range.rst index 5d9327e04..591f84686 100644 --- a/tutorials/3d/high_dynamic_range.rst +++ b/tutorials/3d/high_dynamic_range.rst @@ -74,7 +74,7 @@ is required. Scene linear & asset pipelines ------------------------------ -Working in scene-linear sRGB is not as simple as just pressing a switch. First, +Working in scene-linear sRGB is more complex than pressing a single switch. First, imported image assets must be converted to linear light ratios on import. Even when linearized, those assets may not be perfectly well-suited for use as textures, depending on how they were generated. diff --git a/tutorials/3d/introduction_to_3d.rst b/tutorials/3d/introduction_to_3d.rst index ed88fcfa0..51aca61b0 100644 --- a/tutorials/3d/introduction_to_3d.rst +++ b/tutorials/3d/introduction_to_3d.rst @@ -4,7 +4,7 @@ Introduction to 3D ================== Creating a 3D game can be challenging. That extra Z coordinate makes -many of the common techniques that helped to make 2D games simple no +many of the common techniques that helped to make 2D games simpler no longer work. To aid in this transition, it is worth mentioning that Godot uses similar APIs for 2D and 3D. Most nodes are the same and are present in both 2D and 3D versions. In fact, it is worth checking @@ -52,7 +52,7 @@ DCC-created models There are two pipelines to import 3D models in Godot. The first and most common one is by :ref:`doc_importing_3d_scenes`, which allows you to import -entire scenes (just as they look in the DCC), including animation, +entire scenes (exactly as they look in the DCC), including animation, skeletal rigs, blend shapes, etc. The second pipeline is by importing simple .OBJ files as mesh resources, @@ -76,7 +76,7 @@ submitting them to the 3D API has a significant performance cost. Immediate geometry ------------------ -If, instead, there is a requirement to generate simple geometry that +If, instead, you need to generate simple geometry that will be updated often, Godot provides a special node, :ref:`ImmediateGeometry `, which provides an OpenGL 1.x style immediate-mode API to create points, diff --git a/tutorials/3d/lights_and_shadows.rst b/tutorials/3d/lights_and_shadows.rst index 8ca477a38..a14bed8f3 100644 --- a/tutorials/3d/lights_and_shadows.rst +++ b/tutorials/3d/lights_and_shadows.rst @@ -80,8 +80,8 @@ does not affect the lighting at all and can be anywhere. .. image:: img/light_directional.png -Every face whose front-side is hit by the light rays is lit, while the others stay dark. Most light types -have specific parameters, but directional lights are pretty simple in nature, so they don't. +Every face whose front-side is hit by the light rays is lit, while the others stay dark. Unlike most +other light types directional lights, don't have specific parameters. Directional shadow mapping ^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -215,10 +215,10 @@ Each quadrant can be subdivided to allocate any number of shadow maps; the follo .. image:: img/shadow_quadrants2.png -The allocation logic is simple. The biggest shadow map size (when no subdivision is used) -represents a light the size of the screen (or bigger). -Subdivisions (smaller maps) represent shadows for lights that are further away -from view and proportionally smaller. +The shadow atlas allocates space as follows: + +- The biggest shadow map size (when no subdivision is used) represents a light the size of the screen (or bigger). +- Subdivisions (smaller maps) represent shadows for lights that are further away from view and proportionally smaller. Every frame, the following procedure is performed for all lights: @@ -240,6 +240,6 @@ Godot supports no filter, PCF5 and PCF13. .. image:: img/shadow_pcf1.png -It affects the blockyness of the shadow outline: +It affects the blockiness of the shadow outline: .. image:: img/shadow_pcf2.png diff --git a/tutorials/3d/procedural_geometry/index.rst b/tutorials/3d/procedural_geometry/index.rst index 4cc2535e7..68635272d 100644 --- a/tutorials/3d/procedural_geometry/index.rst +++ b/tutorials/3d/procedural_geometry/index.rst @@ -114,7 +114,7 @@ added to the scene tree and is drawn directly from the code. The SurfaceTool gen a MeshInstance to be seen. ImmediateGeometry is useful for prototyping because of the straightforward API, but it is slow because the geometry -is rebuilt every frame. It is most useful for quickly adding simple geometry to debug visually (e.g. by drawing lines to +is rebuilt every frame. It is most useful for adding simple geometry to debug visually (e.g. by drawing lines to visualize physics raycasts etc.). For more information about ImmediateGeometry, please see the :ref:`ImmediateGeometry tutorial `. diff --git a/tutorials/3d/reflection_probes.rst b/tutorials/3d/reflection_probes.rst index f5509a4d4..3169a6321 100644 --- a/tutorials/3d/reflection_probes.rst +++ b/tutorials/3d/reflection_probes.rst @@ -49,7 +49,7 @@ can be displaced to an empty place by moving the handles in the center: By default, shadow mapping is disabled when rendering probes (only in the rendered image inside the probe, not the actual scene). This is -a simple way to save on performance and memory. If you want shadows in the probe, +a way to save on performance and memory. If you want shadows in the probe, they can be toggled on/off with the *Enable Shadow* setting: .. image:: img/refprobe_shadows.png diff --git a/tutorials/3d/using_transforms.rst b/tutorials/3d/using_transforms.rst index bedafeed3..642292d54 100644 --- a/tutorials/3d/using_transforms.rst +++ b/tutorials/3d/using_transforms.rst @@ -9,7 +9,7 @@ Introduction If you have never made 3D games before, working with rotations in three dimensions can be confusing at first. Coming from 2D, the natural way of thinking is along the lines of *"Oh, it's just like rotating in 2D, except now rotations happen in X, Y and Z"*. -At first this seems easy and for simple games, this way of thinking may even be enough. Unfortunately, it's often incorrect. +At first this seems easy, and for simple games, this way of thinking may even be enough. Unfortunately, it's often incorrect. Angles in three dimensions are most commonly referred to as "Euler Angles". diff --git a/tutorials/animation/animation_tree.rst b/tutorials/animation/animation_tree.rst index 7eb947154..3b2f4e597 100644 --- a/tutorials/animation/animation_tree.rst +++ b/tutorials/animation/animation_tree.rst @@ -139,7 +139,7 @@ can be controlled to determine blending: .. image:: img/animtree7.gif -The ranges in X and Y can be controlled (and labeled for convenience). By default, points can be placed anywhere (just right-click on +The ranges in X and Y can be controlled (and labeled for convenience). By default, points can be placed anywhere (right-click on the coordinate system or use the *add point* button) and triangles will be generated automatically using Delaunay. .. image:: img/animtree8.gif diff --git a/tutorials/animation/introduction.rst b/tutorials/animation/introduction.rst index e4b86cee2..bdd2ee803 100644 --- a/tutorials/animation/introduction.rst +++ b/tutorials/animation/introduction.rst @@ -66,8 +66,8 @@ keyframes indicates that the value doesn't change between them. Keyframes in Godot -You set values of a node's properties and create animation keyframes for them. -When the animation runs, the engine will interpolate the values between the +You set values of a node's properties and create animation keyframes for them. +When the animation runs, the engine will interpolate the values between the keyframes, resulting in them gradually changing over time. .. figure:: img/animation_illustration.png @@ -75,18 +75,18 @@ keyframes, resulting in them gradually changing over time. Two keyframes are all it takes to obtain a smooth motion -The timeline defines how long the animation will take. You can insert keyframes -at various points, and change their timing. +The timeline defines how long the animation will take. You can insert keyframes +at various points, and change their timing. .. figure:: img/animation_timeline.png :alt: The timeline in the animation panel The timeline in the animation panel -Each line in the Animation Panel is an animation track that references a -Normal or Transform property of a node. Each track stores a path to -a node and its affected property. For example, the position track -in the illustration refers to to the ``position`` property of the Sprite +Each line in the Animation Panel is an animation track that references a +Normal or Transform property of a node. Each track stores a path to +a node and its affected property. For example, the position track +in the illustration refers to to the ``position`` property of the Sprite node. .. figure:: img/animation_normal_track.png @@ -107,8 +107,8 @@ Tutorial: Creating a simple animation Scene setup ~~~~~~~~~~~ -For this tutorial, we'll create an AnimationPlayer node with a sprite node as -its child. We will animate the sprite to move between two points on the screen. +For this tutorial, we'll create an AnimationPlayer node with a sprite node as +its child. We will animate the sprite to move between two points on the screen. .. figure:: img/animation_animation_player_tree.png :alt: Our scene setup @@ -126,10 +126,10 @@ its child. We will animate the sprite to move between two points on the screen. The sprite holds an image texture. For this tutorial, select the Sprite node, click Texture in the Inspector, and then click Load. Select the default Godot -icon for the sprite's texture. +icon for the sprite's texture. Select the AnimationPlayer node and click the "Animation" button in the -animation editor. From the list, select "New" (|Add Animation|) to add a new +animation editor. From the list, select "New" (|Add Animation|) to add a new animation. Enter a name for the animation in the dialog box. .. figure:: img/animation_create_new_animation.png @@ -149,13 +149,13 @@ toolbar: Convenience buttons These switches and buttons allow you to add keyframes for the selected -node's location, rotation, and scale. Since we are only animating the sprite's -position, make sure that only the location switch is selected. The selected +node's location, rotation, and scale. Since we are only animating the sprite's +position, make sure that only the location switch is selected. The selected switches are blue. -Click on the key button to create the first keyframe. Since we don't have a -track set up for the Position property yet, Godot will offer to -create it for us. Click **Create**. +Click on the key button to create the first keyframe. Since we don't have a +track set up for the Position property yet, Godot will offer to +create it for us. Click **Create**. Godot will create a new track and insert our first keyframe at the beginning of the timeline: @@ -171,8 +171,8 @@ The second keyframe We need to set our sprite's end location and how long it will take for it to get there. Let's say we want it to take two seconds to move between the points. By -default, the animation is set to last only one second, so change the animation -length to 2 in the controls on the right side of the animation panel's timeline +default, the animation is set to last only one second, so change the animation +length to 2 in the controls on the right side of the animation panel's timeline header. .. figure:: img/animation_set_length.png @@ -180,10 +180,10 @@ header. Animation length -Now, move the sprite right, to its final position. You can use the *Move tool* in the +Now, move the sprite right, to its final position. You can use the *Move tool* in the toolbar or set the *Position*'s X value in the *Inspector*. -Click on the timeline header near the two-second mark in the animation panel +Click on the timeline header near the two-second mark in the animation panel and then click the key button in the toolbar to create the second keyframe. Run the animation @@ -201,13 +201,13 @@ Yay! Our animation runs: Back and forth ~~~~~~~~~~~~~~ -Godot has an interesting feature that we can use in animations. When Animation -Looping is set but there's no keyframe specified at the end of the animation, +Godot has an interesting feature that we can use in animations. When Animation +Looping is set but there's no keyframe specified at the end of the animation, the first keyframe is also the last. -This means we can extend the animation length to four seconds now, and Godot -will also calculate the frames from the last keyframe to the first, moving -our sprite back and forth. +This means we can extend the animation length to four seconds now, and Godot +will also calculate the frames from the last keyframe to the first, moving +our sprite back and forth. .. figure:: img/animation_loop.png :alt: Animation loop @@ -234,7 +234,7 @@ values. This can be: - Continuous: Update the property on each frame - Discrete: Only update the property on keyframes - Trigger: Only update the property on keyframes or triggers -- Capture: Remember the current value of the property, and blend it with the +- Capture: Remember the current value of the property, and blend it with the first animation key .. figure:: img/animation_track_rate.png @@ -242,10 +242,10 @@ values. This can be: Track mode -You will usually use "Continuous" mode. The other types are used to +You will usually use "Continuous" mode. The other types are used to script complex animations. -Track interpolation tells Godot how to calculate the frame values between +Track interpolation tells Godot how to calculate the frame values between keyframes. These interpolation modes are supported: - Nearest: Set the nearest keyframe value @@ -259,9 +259,9 @@ keyframes. These interpolation modes are supported: Track interpolation -With Cubic interpolation, animation is slower at keyframes and faster between -them, which leads to more natural movement. Cubic interpolation is commonly -used for character animation. Linear interpolation animates changes at a fixed +With Cubic interpolation, animation is slower at keyframes and faster between +them, which leads to more natural movement. Cubic interpolation is commonly +used for character animation. Linear interpolation animates changes at a fixed pace, resulting in a more robotic effect. Godot supports two loop modes, which affect the animation when it's set to @@ -285,9 +285,9 @@ Keyframes for other properties Godot's animation system isn't restricted to position, rotation, and scale. You can animate any property. -If you select your sprite while the animation panel is visible, Godot will -display a small keyframe button in the *Inspector* for each of the sprite's -properties. Click on one of these buttons to add a track and keyframe to +If you select your sprite while the animation panel is visible, Godot will +display a small keyframe button in the *Inspector* for each of the sprite's +properties. Click on one of these buttons to add a track and keyframe to the current animation. .. figure:: img/animation_properties_keyframe.png @@ -298,7 +298,7 @@ the current animation. Edit keyframes -------------- -You can click on a keyframe in the animation timeline to display and +You can click on a keyframe in the animation timeline to display and edit its value in the *Inspector*. .. figure:: img/animation_keyframe_editor_key.png @@ -306,8 +306,8 @@ edit its value in the *Inspector*. Keyframe editor editing a key -You can also edit the easing value for a keyframe here by clicking and dragging -its easing curve. This tells Godot how to interpolate the animated property when it +You can also edit the easing value for a keyframe here by clicking and dragging +its easing curve. This tells Godot how to interpolate the animated property when it reaches this keyframe. You can tweak your animations this way until the movement "looks right." diff --git a/tutorials/assets_pipeline/import_process.rst b/tutorials/assets_pipeline/import_process.rst index 4291de2b9..f6cdcd2b1 100644 --- a/tutorials/assets_pipeline/import_process.rst +++ b/tutorials/assets_pipeline/import_process.rst @@ -106,7 +106,7 @@ the default setting can be saved and cleared too: Simplicity is key! ------------------ -This is a very simple workflow which should take very little time to get used to. It also enforces a more +This workflow is aimed to be simple and take very little time to get used to. It also enforces a more correct way to deal with resources. There are many types of assets available for import, so please continue reading to understand how to work diff --git a/tutorials/editor/command_line_tutorial.rst b/tutorials/editor/command_line_tutorial.rst index e1266e6ca..1c648f67c 100644 --- a/tutorials/editor/command_line_tutorial.rst +++ b/tutorials/editor/command_line_tutorial.rst @@ -259,8 +259,8 @@ Debugging --------- Catching errors in the command line can be a difficult task because they -just fly by. For this, a command line debugger is provided by adding -``-d``. It works for running either the game or a simple scene. +scroll quickly. For this, a command line debugger is provided by adding +``-d``. It works for running either the game or a single scene. :: @@ -307,13 +307,13 @@ The output path extension determines the package's format, either PCK or ZIP. Running a script ---------------- -It is possible to run a simple ``.gd`` script from the command line. +It is possible to run a ``.gd`` script from the command line. This feature is especially useful in large projects, e.g. for batch conversion of assets or custom import/export. The script must inherit from ``SceneTree`` or ``MainLoop``. -Here is a simple ``sayhello.gd`` example of how it works: +Here is an example ``sayhello.gd``, showing how it works: .. code-block:: python diff --git a/tutorials/inputs/custom_mouse_cursor.rst b/tutorials/inputs/custom_mouse_cursor.rst index c231d3610..5138f8943 100644 --- a/tutorials/inputs/custom_mouse_cursor.rst +++ b/tutorials/inputs/custom_mouse_cursor.rst @@ -8,7 +8,8 @@ You might want to change the appearance of the mouse cursor in your game in orde 1. Using project settings 2. Using a script -Using project settings is a simpler (but more limited) way to customize the mouse cursor. The second way is more customizable, but involves scripting. +Using project settings is a simpler (but more limited) way to customize the mouse cursor. +The second way is more customizable, but involves scripting: .. note:: diff --git a/tutorials/io/binary_serialization_api.rst b/tutorials/io/binary_serialization_api.rst index f9d602d55..565d97f9f 100644 --- a/tutorials/io/binary_serialization_api.rst +++ b/tutorials/io/binary_serialization_api.rst @@ -6,7 +6,7 @@ Binary serialization API Introduction ------------ -Godot has a simple serialization API based on Variant. It's used for +Godot has a serialization API based on Variant. It's used for converting data types to an array of bytes efficiently. This API is used in the functions ``get_var`` and ``store_var`` of :ref:`class_File` as well as the packet APIs for :ref:`class_PacketPeer`. This format diff --git a/tutorials/io/saving_games.rst b/tutorials/io/saving_games.rst index aa1796f86..f29d28a30 100644 --- a/tutorials/io/saving_games.rst +++ b/tutorials/io/saving_games.rst @@ -199,8 +199,8 @@ way to pull the data out of the file as well. } -Game saved! Loading is fairly simple as well. For that, we'll read each -line, use parse_json() to read it back to a dict, and then iterate over +Game saved! Now, to load, we'll read each +line, use ``parse_json()`` to read it back to a dict, and then iterate over the dict to read our values. But we'll need to first create the object and we can use the filename and parent values to achieve that. Here is our load function: diff --git a/tutorials/math/beziers_and_curves.rst b/tutorials/math/beziers_and_curves.rst index 28919abcd..6e1952160 100644 --- a/tutorials/math/beziers_and_curves.rst +++ b/tutorials/math/beziers_and_curves.rst @@ -151,9 +151,9 @@ Using them, however, may not be completely obvious, so following is a descriptio Evaluating ---------- -Just evaluating them may be an option, but in most cases it's not very useful. The big drawback with Bezier curves is that if you traverse them at constant speed, from ``t = 0`` to ``t = 1``, the actual interpolation will *not* move at constant speed. The speed is also an interpolation between the distances between points ``p0``, ``p1``, ``p2`` and ``p3`` and there is not a mathematically simple way to traverse the curve at constant speed. +Only evaluating them may be an option, but in most cases it's not very useful. The big drawback with Bezier curves is that if you traverse them at constant speed, from ``t = 0`` to ``t = 1``, the actual interpolation will *not* move at constant speed. The speed is also an interpolation between the distances between points ``p0``, ``p1``, ``p2`` and ``p3`` and there is not a mathematically simple way to traverse the curve at constant speed. -Let's do a simple example with the following pseudocode: +Let's do an example with the following pseudocode: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/math/interpolation.rst b/tutorials/math/interpolation.rst index d1ffa21bd..431f81c9b 100644 --- a/tutorials/math/interpolation.rst +++ b/tutorials/math/interpolation.rst @@ -7,9 +7,9 @@ Interpolation is a very basic operation in graphics programming. It's good to be The basic idea is that you want to transition from A to B. A value ``t``, represents the states in-between. -As an example if ``t`` is 0, then the state is A. If ``t`` is 1, then the state is B. Anything in-between is an *interpolation*. +For example, if ``t`` is 0, then the state is A. If ``t`` is 1, then the state is B. Anything in-between is an *interpolation*. -Between two real (floating-point) numbers, a simple interpolation is usually described as: +Between two real (floating-point) numbers, an interpolation can be described as: .. tabs:: .. code-tab:: gdscript GDScript @@ -23,7 +23,7 @@ And often simplified to: interpolation = A + (B - A) * t -The name of this type of interpolation, which transforms a value into another at *constant speed* is *"linear"*. So, when you hear about *Linear Interpolation*, you know they are referring to this simple formula. +The name of this type of interpolation, which transforms a value into another at *constant speed* is *"linear"*. So, when you hear about *Linear Interpolation*, you know they are referring to this formula. There are other types of interpolations, which will not be covered here. A recommended read afterwards is the :ref:`Bezier ` page. @@ -35,7 +35,7 @@ Vector types (:ref:`Vector2 ` and :ref:`Vector3 `) For cubic interpolation, there are also :ref:`Vector2.cubic_interpolate() ` and :ref:`Vector3.cubic_interpolate() `, which do a :ref:`Bezier ` style interpolation. -Here is simple pseudo-code for going from point A to B using interpolation: +Here is example pseudo-code for going from point A to B using interpolation: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/math/matrices_and_transforms.rst b/tutorials/math/matrices_and_transforms.rst index 318b7b2ce..77b975eff 100644 --- a/tutorials/math/matrices_and_transforms.rst +++ b/tutorials/math/matrices_and_transforms.rst @@ -235,7 +235,7 @@ Putting it all together ~~~~~~~~~~~~~~~~~~~~~~~ We're going to apply everything we mentioned so far onto one transform. -To follow along, create a simple project with a Sprite node and use the +To follow along, create a project with a Sprite node and use the Godot logo for the texture resource. Let's set the translation to (350, 150), rotate by -0.5 rad, and scale by 3. diff --git a/tutorials/math/vectors_advanced.rst b/tutorials/math/vectors_advanced.rst index b0c5bbab3..594617a30 100644 --- a/tutorials/math/vectors_advanced.rst +++ b/tutorials/math/vectors_advanced.rst @@ -21,7 +21,7 @@ planes, 3D geometry (to determine where each face or vertex is siding), etc. A **normal** *is* a **unit vector**, but it's called *normal* because of its usage. (Just like we call (0,0) the Origin!). -It's as simple as it looks. The plane passes by the origin and the +The plane passes by the origin and the surface of it is perpendicular to the unit vector (or *normal*). The side towards the vector points to is the positive half-space, while the other side is the negative half-space. In 3D this is exactly the same, @@ -130,8 +130,8 @@ inverted negative and positive half spaces: N = -N; D = -D; -Of course, Godot also implements this operator in :ref:`Plane `, -so doing: +Godot also implements this operator in :ref:`Plane `. +So, using the format below will work as expected: .. tabs:: .. code-tab:: gdscript GDScript @@ -142,12 +142,9 @@ so doing: var invertedPlane = -plane; -Will work as expected. - -So, remember, a plane is just that and its main practical use is -calculating the distance to it. So, why is it useful to calculate the -distance from a point to a plane? It's extremely useful! Let's see some -simple examples.. +So, remember, the plane's main practical use is that we can +calculate the distance to it. So, when is it useful to calculate the +distance from a point to a plane? Let's see some examples. Constructing a plane in 2D -------------------------- @@ -157,7 +154,7 @@ Constructing them in 2D is easy, this can be done from either a normal (unit vector) and a point, or from two points in space. In the case of a normal and a point, most of the work is done, as the -normal is already computed, so just calculate D from the dot product of +normal is already computed, so calculate D from the dot product of the normal and the point. .. tabs:: @@ -196,8 +193,8 @@ degrees to either side: // Alternatively (depending the desired side of the normal): // var normal = new Vector2(-dvec.y, dvec.x); -The rest is the same as the previous example, either point_a or -point_b will work since they are in the same plane: +The rest is the same as the previous example. Either point_a or +point_b will work, as they are in the same plane: .. tabs:: .. code-tab:: gdscript GDScript @@ -214,13 +211,13 @@ point_b will work since they are in the same plane: // this works the same // var D = normal.Dot(pointB); -Doing the same in 3D is a little more complex and will be explained +Doing the same in 3D is a little more complex and is explained further down. Some examples of planes ----------------------- -Here is a simple example of what planes are useful for. Imagine you have +Here is an example of what planes are useful for. Imagine you have a `convex `__ polygon. For example, a rectangle, a trapezoid, a triangle, or just any polygon where no faces bend inwards. diff --git a/tutorials/networking/webrtc.rst b/tutorials/networking/webrtc.rst index eb2b549b7..f253f2da0 100644 --- a/tutorials/networking/webrtc.rst +++ b/tutorials/networking/webrtc.rst @@ -13,7 +13,7 @@ This is a great opportunity for both demos and full games, but used to come with WebSocket ^^^^^^^^^ -When the WebSocket protocol was standardized in December 2011, it allowed browsers to create stable and bidirectional connections to a WebSocket server. The protocol is quite simple, but a very powerful tool to send push notifications to browsers, and has been used to implement chats, turn-based games, etc. +When the WebSocket protocol was standardized in December 2011, it allowed browsers to create stable and bidirectional connections to a WebSocket server. The protocol is a very powerful tool to send push notifications to browsers, and has been used to implement chats, turn-based games, etc. WebSockets, though, still use a TCP connection, which is good for reliability but not for latency, so not good for real-time applications like VoIP and fast-paced games. diff --git a/tutorials/networking/websocket.rst b/tutorials/networking/websocket.rst index 2021145d0..847ca0260 100644 --- a/tutorials/networking/websocket.rst +++ b/tutorials/networking/websocket.rst @@ -9,7 +9,7 @@ HTML5 and WebSocket The WebSocket protocol was standardized in 2011 with the original goal of allowing browsers to create stable and bidirectional connections with a server. Before that, browsers used to only support HTTPRequests, which is not well-suited for bidirectional communication. -The protocol is quite simple, message based, and a very powerful tool to send push notifications to browsers, and has been used to implement chats, turn-based games, etc. It still uses a TCP connection, which is good for reliability but not for latency, so not good for real-time applications like VoIP and fast-paced games (see :ref:`WebRTC ` for those use cases). +The protocol is message based and a very powerful tool to send push notifications to browsers, and has been used to implement chats, turn-based games, etc. It still uses a TCP connection, which is good for reliability but not for latency, so not good for real-time applications like VoIP and fast-paced games (see :ref:`WebRTC ` for those use cases). Due to its simplicity, its wide compatibility, and being easier to use than a raw TCP connection, WebSocket soon started to spread outside the browsers, in native applications as a mean to communicate with network servers. diff --git a/tutorials/performance/using_multiple_threads.rst b/tutorials/performance/using_multiple_threads.rst index 7cef8d8c6..b0c3288ea 100644 --- a/tutorials/performance/using_multiple_threads.rst +++ b/tutorials/performance/using_multiple_threads.rst @@ -17,7 +17,7 @@ Godot supports threads and provides many handy functions to use them. Creating a Thread ----------------- -Creating a thread is very simple, just use the following code: +To create a thread, use the following code: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/performance/using_servers.rst b/tutorials/performance/using_servers.rst index d4fba6162..413fda6b6 100644 --- a/tutorials/performance/using_servers.rst +++ b/tutorials/performance/using_servers.rst @@ -9,9 +9,9 @@ resources simplifies project organization and asset management in complex games. There are, of course, always drawbacks: -* There is an extra layer of complexity -* Performance is lower than using simple APIs directly -* It is not possible to use multiple threads to control them +* There is an extra layer of complexity. +* Performance is lower than when using simple APIs directly. +* It is not possible to use multiple threads to control them. * More memory is needed. In many cases, this is not really a problem (Godot is very optimized, and most operations are handled @@ -83,7 +83,7 @@ functions should always be used for creating and controlling new ones and intera Creating a sprite ----------------- -This is a simple example of how to create a sprite from code and move it using the low-level +This is an example of how to create a sprite from code and move it using the low-level :ref:`CanvasItem ` API. .. tabs:: diff --git a/tutorials/physics/kinematic_character_2d.rst b/tutorials/physics/kinematic_character_2d.rst index 093014827..936af697e 100644 --- a/tutorials/physics/kinematic_character_2d.rst +++ b/tutorials/physics/kinematic_character_2d.rst @@ -39,10 +39,9 @@ So, what is the difference?: program. However, as a downside, they can't directly interact with other physics objects, unless done by hand in code. -This short tutorial will focus on the kinematic character controller. -Basically, the old-school way of handling collisions (which is not -necessarily simpler under the hood, but well hidden and presented as a -nice and simple API). +This short tutorial focuses on the kinematic character controller. +It uses the old-school way of handling collisions, which is not +necessarily simpler under the hood, but well hidden and presented as an API. Physics process ~~~~~~~~~~~~~~~ @@ -184,7 +183,7 @@ Now the character falls smoothly. Let's make it walk to the sides, left and right when touching the directional keys. Remember that the values being used (for speed at least) are pixels/second. -This adds simple walking support by pressing left and right: +This adds basic support for walking when pressing left and right: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/physics/ray-casting.rst b/tutorials/physics/ray-casting.rst index 432b43cf9..27347de62 100644 --- a/tutorials/physics/ray-casting.rst +++ b/tutorials/physics/ray-casting.rst @@ -12,10 +12,10 @@ behaviors, AI, etc. to take place. This tutorial will explain how to do this in 2D and 3D. Godot stores all the low level game information in servers, while the -scene is just a frontend. As such, ray casting is generally a -lower-level task. For simple raycasts, node such as +scene is only a frontend. As such, ray casting is generally a +lower-level task. For simple raycasts, nodes like :ref:`RayCast ` and :ref:`RayCast2D ` -will work, as they will return every frame what the result of a raycast +will work, as they return every frame what the result of a raycast is. Many times, though, ray-casting needs to be a more interactive process diff --git a/tutorials/physics/using_kinematic_body_2d.rst b/tutorials/physics/using_kinematic_body_2d.rst index a985e6d9e..5bf93bac3 100644 --- a/tutorials/physics/using_kinematic_body_2d.rst +++ b/tutorials/physics/using_kinematic_body_2d.rst @@ -130,7 +130,7 @@ and ``get_slide_collision()``: var collision = get_slide_collision(i) print("I collided with ", collision.collider.name) -.. note:: `get_slide_count()` only counts times the body has collided and changed direction. +.. note:: `get_slide_count()` only counts times the body has collided and changed direction. See :ref:`KinematicCollision2D ` for details on what collision data is returned. @@ -140,7 +140,7 @@ Which movement method to use? A common question from new Godot users is: "How do you decide which movement function to use?" Often, the response is to use ``move_and_slide()`` because -it's "simpler," but this is not necessarily the case. One way to think of it +it seems simpler, but this is not necessarily the case. One way to think of it is that ``move_and_slide()`` is a special case, and ``move_and_collide()`` is more general. For example, the following two code snippets result in the same collision response: diff --git a/tutorials/plugins/editor/import_plugins.rst b/tutorials/plugins/editor/import_plugins.rst index 97c1d80da..57c9e59fa 100644 --- a/tutorials/plugins/editor/import_plugins.rst +++ b/tutorials/plugins/editor/import_plugins.rst @@ -15,11 +15,11 @@ to be imported by Godot and be treated as first-class resources. The editor itself comes bundled with a lot of import plugins to handle the common resources like PNG images, Collada and glTF models, Ogg Vorbis sounds, and many more. -This tutorial will show you how to create a simple import plugin to load a +This tutorial shows how to create an import plugin to load a custom text file as a material resource. This text file will contain three numeric values separated by comma, which represents the three channels of a color, and the resulting color will be used as the albedo (main color) of the -imported material. In this example it will contain the pure blue color +imported material. In this example it contains the pure blue color (zero red, zero green, and full blue): .. code-block:: none diff --git a/tutorials/plugins/editor/making_plugins.rst b/tutorials/plugins/editor/making_plugins.rst index c002b12e6..2a9a57664 100644 --- a/tutorials/plugins/editor/making_plugins.rst +++ b/tutorials/plugins/editor/making_plugins.rst @@ -13,10 +13,10 @@ While this makes plugins less powerful, there are still many things you can do with them. Note that a plugin is similar to any scene you can already make, except it is created using a script to add editor functionality. -This tutorial will guide you through the creation of two simple plugins so +This tutorial will guide you through the creation of two plugins so you can understand how they work and be able to develop your own. The first -will be a custom node that you can add to any scene in the project and the -other will be a custom dock added to the editor. +is a custom node that you can add to any scene in the project, and the +other is a custom dock added to the editor. Creating a plugin ~~~~~~~~~~~~~~~~~ @@ -56,7 +56,7 @@ You should end up with a directory structure like this: .. image:: img/making_plugins-my_custom_mode_folder.png -``plugin.cfg`` is a simple INI file with metadata about your plugin. +``plugin.cfg`` is an INI file with metadata about your plugin. The name and description help people understand what it does. Your name helps you get properly credited for your work. The version number helps others know if they have an outdated version; @@ -148,8 +148,8 @@ To create a new node type, you can use the function that will act as the logic for the type. While that script doesn't have to use the ``tool`` keyword, it can be added so the script runs in the editor. -For this tutorial, we'll create a simple button that prints a message when -clicked. For that, we'll need a simple script that extends from +For this tutorial, we'll create a button that prints a message when +clicked. For that, we'll need a script that extends from :ref:`class_Button`. It could also extend :ref:`class_BaseButton` if you prefer: diff --git a/tutorials/plugins/editor/spatial_gizmos.rst b/tutorials/plugins/editor/spatial_gizmos.rst index 191b734e2..e187dc22b 100644 --- a/tutorials/plugins/editor/spatial_gizmos.rst +++ b/tutorials/plugins/editor/spatial_gizmos.rst @@ -9,9 +9,9 @@ Introduction Spatial gizmo plugins are used by the editor and custom plugins to define the gizmos attached to any kind of Spatial node. -This tutorial will show you the two main approaches to defining your own custom +This tutorial shows the two main approaches to defining your own custom gizmos. The first option works well for simple gizmos and creates less clutter in -your plugin structure, while the second one will let you store some per-gizmo data. +your plugin structure, and the second one will let you store some per-gizmo data. .. note:: This tutorial assumes you already know how to make generic plugins. If in doubt, refer to the :ref:`doc_making_plugins` page. @@ -56,7 +56,7 @@ This would be a basic setup: remove_spatial_gizmo_plugin(gizmo_plugin) -For simple gizmos, just inheriting :ref:`EditorSpatialGizmoPlugin ` +For simple gizmos, inheriting :ref:`EditorSpatialGizmoPlugin ` is enough. If you want to store some per-gizmo data or you are porting a Godot 3.0 gizmo to 3.1+, you should go with the second approach. diff --git a/tutorials/rendering/multiple_resolutions.rst b/tutorials/rendering/multiple_resolutions.rst index 4eb02a539..7fa4160f9 100644 --- a/tutorials/rendering/multiple_resolutions.rst +++ b/tutorials/rendering/multiple_resolutions.rst @@ -98,7 +98,7 @@ of it, and it can always be accessed by calling In any case, while changing the root Viewport params is probably the most flexible way to deal with the problem, it can be a lot of work, -code and guessing, so Godot provides a simple set of parameters in the +code and guessing, so Godot provides a set of parameters in the project settings to handle multiple resolutions. Stretch settings diff --git a/tutorials/scripting/filesystem.rst b/tutorials/scripting/filesystem.rst index 6d1e5ffe4..84b58bcb7 100644 --- a/tutorials/scripting/filesystem.rst +++ b/tutorials/scripting/filesystem.rst @@ -90,7 +90,7 @@ tools in Godot. Drawbacks --------- -There are some drawbacks to this simple file system design. The first issue is that +There are some drawbacks to this file system design. The first issue is that moving assets around (renaming them or moving them from one path to another inside the project) will break existing references to these assets. These references will have to be re-defined to point at the new asset location. @@ -107,5 +107,5 @@ on other platforms, such as Linux, Android, etc. This may also apply to exported which use a compressed package to store all files. It is recommended that your team clearly define a naming convention for files when -working with Godot. One simple fool-proof convention is to only allow lowercase +working with Godot. One fool-proof convention is to only allow lowercase file and path names. diff --git a/tutorials/scripting/gdnative/gdnative_c_example.rst b/tutorials/scripting/gdnative/gdnative_c_example.rst index cc073daef..bbc224a18 100644 --- a/tutorials/scripting/gdnative/gdnative_c_example.rst +++ b/tutorials/scripting/gdnative/gdnative_c_example.rst @@ -6,7 +6,7 @@ GDNative C example Introduction ------------ -This tutorial will introduce you to the bare minimum required to create GDNative +This tutorial introduces the bare minimum required to create GDNative modules. This should be your starting point into the world of GDNative. Understanding the contents of this tutorial will help you in understanding all that is to come after this. @@ -515,7 +515,7 @@ select our ``.gdnlib`` file by clicking on *Library* and selecting *Load*: The *Class Name* must have the same spelling as the one given in ``godot_nativescript_init`` when registering the class. - + Finally, click on the save icon and save this as ``bin/simple.gdns``: .. image:: img/save_gdns.gif diff --git a/tutorials/scripting/gdnative/gdnative_cpp_example.rst b/tutorials/scripting/gdnative/gdnative_cpp_example.rst index 32053c3e4..9000b83c3 100644 --- a/tutorials/scripting/gdnative/gdnative_cpp_example.rst +++ b/tutorials/scripting/gdnative/gdnative_cpp_example.rst @@ -328,9 +328,9 @@ that we defined in our header file. Note that the ``register_method`` call it. However, we do not have to tell Godot about our constructor, destructor and ``_init`` functions. -The other method of note is our ``_process`` function, which simply keeps track +The other method of note is our ``_process`` function, which keeps track of how much time has passed and calculates a new position for our sprite using a -simple sine and cosine function. What stands out is calling +sine and cosine function. What stands out is calling ``owner->set_position`` to call one of the build in methods of our Sprite. This is because our class is a container class; ``owner`` points to the actual Sprite node our script relates to. In the upcoming NativeScript 1.1, ``set_position`` @@ -678,10 +678,9 @@ showing the methods that have changed so don't remove anything we're omitting: Now when the project is compiled we'll see another property called speed. Changing its value will make the animation go faster or slower. -For this example there is no obvious advantage of using a setter and getter. It -is just more code to write. For a simple example as this there may be a good -reason for a setter if you want to react on the variable being changed but in -many cases just binding the variable will be enough. +For this example there is no obvious advantage of using a setter and getter. +A good reason for a setter would be if you wanted to react on the variable being changed, but in +many cases binding the variable is enough. Getters and setters become far more useful in more complex scenarios where you need to make additional choices based on the state of your object. @@ -845,7 +844,7 @@ the old and new syntax. The class is defined slightly differently and we no longer use the ``owner`` member to call methods on the Godot side of our object. A lot of the improvements are hidden under the hood. -This example only deals with simple variables and simple methods. Especially +This example only deals with simple variables and methods. Especially once you start passing references to other objects or when you start calling methods that require more complex parameters, NativeScript 1.1 does start to show its benefits. @@ -853,9 +852,9 @@ show its benefits. Next steps ---------- -The above is only a simple example, but we hope it shows you the basics. You can +We hope the above example showed you the basics. You can build upon this example to create full-fledged scripts to control nodes in Godot using C++. -You should be able to edit and recompile the plugin while the Godot editor -remains open; just rerun the project after the library has finished building. +To edit and recompile the plugin while the Godot editor +remains open, rerun the project after the library has finished building. diff --git a/tutorials/scripting/gdscript/gdscript_advanced.rst b/tutorials/scripting/gdscript/gdscript_advanced.rst index 16730166d..cefb4916b 100644 --- a/tutorials/scripting/gdscript/gdscript_advanced.rst +++ b/tutorials/scripting/gdscript/gdscript_advanced.rst @@ -22,25 +22,25 @@ Pros & cons of dynamic typing GDScript is a Dynamically Typed language. As such, its main advantages are that: -- The language is simple and easy to learn. +- The language is easy to get started with. - Most code can be written and changed quickly and without hassle. - Less code written means less errors & mistakes to fix. -- Easier to read the code (less clutter). +- The code is easy to read (little clutter). - No compilation is required to test. - Runtime is tiny. -- Duck-typing and polymorphism by nature. +- It has duck-typing and polymorphism by nature. While the main disadvantages are: - Less performance than statically typed languages. -- More difficult to refactor (symbols can't be traced) +- More difficult to refactor (symbols can't be traced). - Some errors that would typically be detected at compile time in statically typed languages only appear while running the code (because expression parsing is more strict). - Less flexibility for code-completion (some variable types are only known at run-time). -This, translated to reality, means that Godot+GDScript are a combination +This, translated to reality, means that Godot used with GDScript is a combination designed to create games quickly and efficiently. For games that are very computationally intensive and can't benefit from the engine built-in tools (such as the Vector types, Physics Engine, Math library, etc), the @@ -204,7 +204,7 @@ And in GDScript: :: - var array = [10, "hello", 40, 60] # Simple, and can mix types. + var array = [10, "hello", 40, 60] # You can mix types. array.resize(3) # Can be resized. use_array(array) # Passed as reference. # Freed when no longer in use. @@ -246,7 +246,7 @@ Example of Dictionary: :: - var d = {"name": "John", "age": 22} # Simple syntax. + var d = {"name": "John", "age": 22} print("Name: ", d["name"], " Age: ", d["age"]) Dictionaries are also dynamic, keys can be added or removed at any point @@ -259,7 +259,7 @@ at little cost: d.erase("name") # Removal. In most cases, two-dimensional arrays can often be implemented more -easily with dictionaries. Here's a simple battleship game example: +easily with dictionaries. Here's a battleship game example: :: diff --git a/tutorials/scripting/gdscript/gdscript_basics.rst b/tutorials/scripting/gdscript/gdscript_basics.rst index 7cb5f192d..95310d478 100644 --- a/tutorials/scripting/gdscript/gdscript_basics.rst +++ b/tutorials/scripting/gdscript/gdscript_basics.rst @@ -28,7 +28,7 @@ Example of GDScript ------------------- Some people can learn better by taking a look at the syntax, so -here's a simple example of how GDScript looks. +here's an example of how GDScript looks. :: diff --git a/tutorials/scripting/pausing_games.rst b/tutorials/scripting/pausing_games.rst index b32e7b9f6..cd5b4db98 100644 --- a/tutorials/scripting/pausing_games.rst +++ b/tutorials/scripting/pausing_games.rst @@ -12,8 +12,8 @@ However, this is not as simple as it seems. The game might be stopped, but it might be desirable that some menus and animations continue working. -Implementing a fine-grained control for what can be paused (and what can -not) is a lot of work, so a simple framework for pausing is provided in +Implementing a fine-grained control for what can be paused (and what cannot) +is a lot of work, so a simple framework for pausing is provided in Godot. How pausing works @@ -91,7 +91,7 @@ and set its pause mode to "Process" then hide it: .. image:: img/pause_popup.png -Just by setting the root of the pause popup to "Process", all children +By setting the root of the pause popup to "Process", all children and grandchildren will inherit that state. This way, this branch of the scene tree will continue working when paused. diff --git a/tutorials/scripting/resources.rst b/tutorials/scripting/resources.rst index 716440589..850552667 100644 --- a/tutorials/scripting/resources.rst +++ b/tutorials/scripting/resources.rst @@ -316,11 +316,11 @@ Let's see some examples. } } - Instead of just inlining the Dictionary values, one could also, alternatively... + Instead of inlining the Dictionary values, one could also, alternatively: - 1. Import a table of values from a spreadsheet and generate these key-value pairs, or... + 1. Import a table of values from a spreadsheet and generate these key-value pairs. - 2. Design a visualization within the editor and create a simple plugin that adds it + 2. Design a visualization within the editor and create a plugin that adds it to the Inspector when you open these types of Resources. CurveTables are the same thing, except mapped to an Array of float values diff --git a/tutorials/scripting/scene_tree.rst b/tutorials/scripting/scene_tree.rst index 1ad1904d5..8433c8400 100644 --- a/tutorials/scripting/scene_tree.rst +++ b/tutorials/scripting/scene_tree.rst @@ -132,8 +132,8 @@ the current node. Changing current scene ---------------------- -After a scene is loaded, it is often desired to change this scene for -another one. The simple way to do this is to use the +After a scene is loaded, you may want to change this scene for +another one. One way to do this is to use the :ref:`SceneTree.change_scene() ` function: diff --git a/tutorials/scripting/visual_script/nodes_purposes.rst b/tutorials/scripting/visual_script/nodes_purposes.rst index a388d65df..a4f6d59ab 100644 --- a/tutorials/scripting/visual_script/nodes_purposes.rst +++ b/tutorials/scripting/visual_script/nodes_purposes.rst @@ -57,7 +57,7 @@ Pay special attention to colors and icons, as each type has a different represen Connections ~~~~~~~~~~~ -Connecting is a relatively simple process. Drag an *Output Port* towards an *Input Port*. +To make a connection, drag an *Output Port* towards an *Input Port*. .. image:: img/visual_script_connect.gif @@ -267,7 +267,7 @@ These are nodes you can use as temporary storage for your graphs. Make sure they .. image:: img/visual_script41.png -As it can be seen above, there are two nodes available: A simple getter, and a sequenced setter (setting requires a sequence port). +As you can see above, there are two nodes available: a simple getter, and a sequenced setter (setting requires a sequence port). Scene Node @@ -305,7 +305,7 @@ instancing the node, it's simpler to drag the desired resource from the filesyst Resource Path ^^^^^^^^^^^^^ -This node is a simple helper to get a string with a path to a resource you can pick. It's useful in functions that +This node is a helper to get a string with a path to a resource you can pick. It's useful in functions that load things from disk. @@ -330,7 +330,7 @@ given condition. Condition ^^^^^^^^^ -This is a simple node that checks a bool port. If ``true``, it will go via the "true" sequence port. If ``false``, +This is a node that checks a boolean port. If ``true``, it will go via the "true" sequence port. If ``false``, the second. After going for either of them, it goes via the "done" port. Leaving sequence ports disconnected is fine if not all of them are used. @@ -390,7 +390,7 @@ the condition in the "cond" data port is met. Functions ~~~~~~~~~ -Functions are simple helpers, most of the time deterministic. They take some arguments as +Functions are helpers, most of the time deterministic. They take some arguments as input and return an output. They are almost never sequenced. diff --git a/tutorials/shaders/making_trees.rst b/tutorials/shaders/making_trees.rst index 576963078..89b58a75c 100644 --- a/tutorials/shaders/making_trees.rst +++ b/tutorials/shaders/making_trees.rst @@ -34,7 +34,7 @@ This is a bit exaggerated, but the idea is that color indicates how much sway af Write a custom shader for the leaves ------------------------------------ -This is a simple example of a shader for leaves: +This is an example of a shader for leaves: .. code-block:: glsl diff --git a/tutorials/shaders/screen-reading_shaders.rst b/tutorials/shaders/screen-reading_shaders.rst index 2ef250f31..9bde71605 100644 --- a/tutorials/shaders/screen-reading_shaders.rst +++ b/tutorials/shaders/screen-reading_shaders.rst @@ -23,7 +23,8 @@ SCREEN_TEXTURE built-in texture Godot :ref:`doc_shading_language` has a special texture, ``SCREEN_TEXTURE`` (and ``DEPTH_TEXTURE`` for depth, in the case of 3D). It takes as argument the UV of the screen and returns a vec3 RGB with the color. A special built-in varying: SCREEN_UV can be used to obtain the UV for -the current fragment. As a result, this simple canvas_item fragment shader: +the current fragment. As a result, this canvas_item fragment shader results in an invisible object, +because it only shows what lies behind: .. code-block:: glsl @@ -31,8 +32,6 @@ the current fragment. As a result, this simple canvas_item fragment shader: COLOR = textureLod(SCREEN_TEXTURE, SCREEN_UV, 0.0); } -results in an invisible object, because it just shows what lies behind. - The reason why textureLod must be used is because, when Godot copies back a chunk of the screen, it also does an efficient separatable gaussian blur to its mipmaps. diff --git a/tutorials/shaders/shader_reference/shading_language.rst b/tutorials/shaders/shader_reference/shading_language.rst index 6fe5f0e5d..4ea7d32e5 100644 --- a/tutorials/shaders/shader_reference/shading_language.rst +++ b/tutorials/shaders/shader_reference/shading_language.rst @@ -264,11 +264,11 @@ return the array's size. .. note:: - If you use an index below 0 or greater than array size - the shader will + If you use an index either below 0 or greater than array size - the shader will crash and break rendering. To prevent this, use ``length()``, ``if``, or ``clamp()`` functions to ensure the index is between 0 and the array's length. Always carefully test and check your code. If you pass a constant - expression or a simple number, the editor will check its bounds to prevent + expression or a number, the editor will check its bounds to prevent this crash. Global arrays diff --git a/tutorials/shaders/your_first_shader/your_first_2d_shader.rst b/tutorials/shaders/your_first_shader/your_first_2d_shader.rst index e3da2e5fd..797c23397 100644 --- a/tutorials/shaders/your_first_shader/your_first_2d_shader.rst +++ b/tutorials/shaders/your_first_shader/your_first_2d_shader.rst @@ -226,7 +226,7 @@ You can offset the vertices by directly adding to ``VERTEX``. VERTEX += vec2(10.0, 0.0); } -Combined with the ``TIME`` built-in variable, this can be used for simple +Combined with the ``TIME`` built-in variable, this can be used for basic animation. .. code-block:: glsl diff --git a/tutorials/shaders/your_first_shader/your_first_3d_shader.rst b/tutorials/shaders/your_first_shader/your_first_3d_shader.rst index e0151ca06..f088e6599 100644 --- a/tutorials/shaders/your_first_shader/your_first_3d_shader.rst +++ b/tutorials/shaders/your_first_shader/your_first_3d_shader.rst @@ -18,10 +18,10 @@ functionality for common use cases and all the user needs to do in the shader is set the proper parameters. This is especially true for a PBR (physically based rendering) workflow. -This is a two-part tutorial. In this first part we are going to go through how -to make a simple terrain using vertex displacement from a heightmap in the +This is a two-part tutorial. In this first part we will create terrain using +vertex displacement from a heightmap in the vertex function. In the :ref:`second part ` we -are going to take the concepts from this tutorial and walk through how to set up +will take the concepts from this tutorial and set up custom materials in a fragment shader by writing an ocean water shader. .. note:: This tutorial assumes some basic shader knowledge such as types @@ -265,7 +265,7 @@ Now it looks much better. Using uniforms, we can even change the value every frame to animate the height of the terrain. Combined with :ref:`Tweens `, this can be -especially useful for simple animations. +especially useful for animations. Interacting with light ---------------------- diff --git a/tutorials/ui/gui_containers.rst b/tutorials/ui/gui_containers.rst index 9bbd570ef..622a43198 100644 --- a/tutorials/ui/gui_containers.rst +++ b/tutorials/ui/gui_containers.rst @@ -51,7 +51,7 @@ Size flags are independent for vertical and horizontal sizing and not all contai amount of space they take from each other is determined by the *Ratio* (see below). * **Shrink Center** When expanding (and if not filling), try to remain at the center of the expanded area (by default it remains at the left or top). -* **Ratio** Simple ratio of how much expanded controls take up the available space in relation to each +* **Ratio**: The ratio of how much expanded controls take up the available space in relation to each other. A control with "2", will take up twice as much available space as one with "1". Experimenting with these flags and different containers is recommended to get a better grasp on how they work. @@ -127,7 +127,7 @@ The divisor can be dragged around to change the size relation between both child PanelContainer ^^^^^^^^^^^^^^ -Simple container that draws a *StyleBox*, then expands children to cover its whole area +A container that draws a *StyleBox*, then expands children to cover its whole area (via :ref:`PanelContainer `, respecting the *StyleBox* margins). It respects both the horizontal and vertical size flags. @@ -161,7 +161,7 @@ it as if it was an image (via :ref:`ViewportContainer ` Creating custom Containers -------------------------- -It is possible to easily create a custom container using script. Here is an example of a simple container that fits children +It is possible to easily create a custom container using script. Here is an example of a container that fits children to its rect size: .. tabs:: diff --git a/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst b/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst index 9afe827e8..748fe784b 100644 --- a/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst +++ b/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst @@ -24,7 +24,7 @@ Throughout the course of this tutorial, we will cover: - How to make a teleportation locomotion system that uses the VR controllers. - How to make a artificial movement locomotion system that uses the VR controllers. - How to create a :ref:`RigidBody `-based system that allows for picking up, dropping, and throwing RigidBody nodes using the VR controllers. -- How to create simple destroyable target. +- How to create a destroyable target. - How to create some special :ref:`RigidBody `-based objects that can destroy the targets. .. tip:: While this tutorial can be completed by beginners, it is highly @@ -218,7 +218,7 @@ Next is a :ref:`Position3D ` node called ``Grab_Pos``. This is they are held by the VR controller. A large :ref:`Area ` node called ``Sleep_Area`` is used to disable sleeping for any RigidBody nodes within its :ref:`CollisionShape `, -simple called ``CollisionShape``. This is needed because if a :ref:`RigidBody ` node falls asleep, then the VR controller will be unable to grab it. +called ``CollisionShape``. This is needed because if a :ref:`RigidBody ` node falls asleep, then the VR controller will be unable to grab it. By using ``Sleep_Area``, we can write code that makes any :ref:`RigidBody ` node within it not able to sleep, therefore allowing the VR controller to grab it. An :ref:`AudioStreamPlayer3D ` node called ``AudioStreamPlayer3D`` has a sound loaded that we will use when an object has been picked up, dropped @@ -1041,7 +1041,7 @@ Reducing motion sickness To help reduce motion sickness while moving, we are going to add a vignette effect that will only be visible while the player moves. -First, quickly switch back to ``Game.tscn```. Under the :ref:`ARVROrigin ` node there is a child node called ``Movement_Vignette``. This node is going to apply a simple +First, quickly switch back to ``Game.tscn```. Under the :ref:`ARVROrigin ` node there is a child node called ``Movement_Vignette``. This node is going to apply a vignette to the VR headset when the player is moving using the VR controllers. This should help reduce motion sickness. Open up ``Movement_Vignette.tscn``, which you can find in the ``Scenes`` folder. The scene is just a :ref:`ColorRect ` node with a custom diff --git a/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst b/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst index 27efbe020..5ef872e73 100644 --- a/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst +++ b/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst @@ -19,10 +19,10 @@ class called ``VR_Interactable_Rigidbody``. Adding destroyable targets -------------------------- -Before we make any of the special :ref:`RigidBody `-based nodes, we need something for them to do. Let's make a simple sphere target that will break into a bunch of pieces +Before we make any of the special :ref:`RigidBody `-based nodes, we need something for them to do. Let's create a sphere target that will break into a bunch of pieces when destroyed. -Open up ``Sphere_Target.tscn``, which is in the ``Scenes`` folder. The scene is fairly simple, with just a :ref:`StaticBody ` with a sphere shaped +Open up ``Sphere_Target.tscn``, which is in the ``Scenes`` folder. The scene only has a :ref:`StaticBody ` with a sphere shaped :ref:`CollisionShape `, a :ref:`MeshInstance ` node displaying a sphere mesh, and an :ref:`AudioStreamPlayer3D ` node. The special :ref:`RigidBody ` nodes will handle damaging the sphere, which is why we are using a :ref:`StaticBody ` node instead of something like @@ -185,7 +185,7 @@ Let's quickly go over a few things of note in ``Pistol.tscn`` real quick before All of the nodes in ``Pistol.tscn`` expect the root node are rotated. This is so the pistol is in the correct rotation relative to the VR controller when it is picked up. The root node is a :ref:`RigidBody ` node, which we need because we're going to use the ``VR_Interactable_Rigidbody`` class we created in the last part of this tutorial series. -There is a :ref:`MeshInstance ` node called ``Pistol_Flash``, which is a simple mesh that we will be using to simulate the muzzle flash on the end of the pistol's barrel. +There is a :ref:`MeshInstance ` node called ``Pistol_Flash``, which is a mesh that we will be using to simulate the muzzle flash on the end of the pistol's barrel. A :ref:`MeshInstance ` node called ``LaserSight`` is used to as a guide for aiming the pistol, and it follows the direction of the :ref:`Raycast ` node, called ``Raycast``, that the pistol uses to detect if its 'bullet' hit something. Finally, there is an :ref:`AudioStreamPlayer3D ` node at the end of the pistol that we will use to play the sound of the pistol firing. @@ -299,7 +299,7 @@ muzzle flash timer just finished and so we need to make ``flash_mesh`` invisible """""""""""""""""""""""""""""""""""""""""""""" The interact function first checks to see if the pistol's muzzle flash is invisible by checking to see if ``flash_timer`` is less than or equal to zero. We do this so we -can limit the rate of fire of the pistol to the length of time the muzzle flash is visible, which is a simple solution for limiting how fast the player can fire. +can limit the rate of fire of the pistol to the length of time the muzzle flash is visible, which is a solution for limiting how fast the player can fire. If ``flash_timer`` is zero or less, we then set ``flash_timer`` to ``FLASH_TIME`` so there is a delay before the pistol can fire again. After that we set ``flash_mesh.visible`` to ``true`` so the muzzle flash at the end of the pistol is visible while ``flash_timer`` is more than zero. @@ -473,7 +473,7 @@ instead of just one. All of the other class variables are the same as ``Pistol.g """""""""""""""""""""""""""""""""""""""""""""" The interact function first checks to see if the shotgun's muzzle flash is invisible by checking to see if ``flash_timer`` is less than or equal to zero. We do this so we -can limit the rate of fire of the shotgun to the length of time the muzzle flash is visible, which is a simple solution for limiting how fast the player can fire. +can limit the rate of fire of the shotgun to the length of time the muzzle flash is visible, which is a solution for limiting how fast the player can fire. If ``flash_timer`` is zero or less, we then set ``flash_timer`` to ``FLASH_TIME`` so there is a delay before the shotgun can fire again. After that we set ``flash_mesh.visible`` to ``true`` so the muzzle flash at the end of the shotgun is visible while ``flash_timer`` is more than zero. @@ -531,7 +531,7 @@ we then set the ``rumble`` property of the VR controller to ``0.25``, so there i Shotgun finished ^^^^^^^^^^^^^^^^ -Everything else is exactly the same as the pistol, with at most just some simple name changes. +Everything else is exactly the same as the pistol, with at most some name changes. Now the shotgun is finished! You can find the shotgun in the sample scene by looking around the back of one of the walls (not in the building though!).