diff --git a/about/faq.rst b/about/faq.rst index 5cabca4a6..cc130e98d 100644 --- a/about/faq.rst +++ b/about/faq.rst @@ -147,8 +147,8 @@ The main reasons for creating a custom scripting language for Godot were: 5. Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.). 6. Difficulty to integrate with the code editor for providing code - completion, live editing, etc. (all of them). This is well - supported by GDScript. + completion, live editing, etc. (all of them). This is well-supported + by GDScript. GDScript was designed to curtail the issues above, and more. @@ -259,7 +259,7 @@ I have a great idea for Godot. How can I share it? It might be tempting to want to bring ideas to Godot, like ones that result in massive core changes, some sort of mimicry of what another game engine does, or alternative workflows that you'd like built into -the editor. These are great and we are thankful to have such motivated +the editor. These are great, and we are thankful to have such motivated people want to contribute, but Godot's focus is and always will be the core functionality as outlined in the `Roadmap `_, `squashing bugs and addressing issues `_, @@ -325,7 +325,7 @@ Why does Godot not force users to implement DoD (Data oriented Design)? ----------------------------------------------------------------------- While Godot internally for a lot of the heavy performance tasks attempts -to use cache coherency as best as possible, we believe most users don't +to use cache coherency as well as possible, we believe most users don't really need to be forced to use DoD practices. DoD is mostly a cache coherency optimization that can only gain you diff --git a/community/contributing/best_practices_for_engine_contributors.rst b/community/contributing/best_practices_for_engine_contributors.rst index d738b7241..5063afa9b 100644 --- a/community/contributing/best_practices_for_engine_contributors.rst +++ b/community/contributing/best_practices_for_engine_contributors.rst @@ -57,7 +57,7 @@ Whether a problem is worth solving is determined by the difficulty the user has - The complexity of the problem - The frequency the problem -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 do it. +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 do it. The exception, however, is when the user stumbles into this problem *frequently enough* that having to do the simple solution every time becomes an annoyance. In this case, the software must offer a solution to simplify this use case. @@ -72,7 +72,7 @@ Because of this, user proposed solutions don't always contemplate other use case .. image:: img/best_practices4.png -For developers, the perspective is different. They may find the user's problem too unique to justify a solution (instead of an user workaround), or maybe they will suggest a partial (usually simpler or lower level) solution that applies to a wider range of known problems, and leave the rest of the solution up to the user. +For developers, the perspective is different. They may find the user's problem too unique to justify a solution (instead of a user workaround), or maybe they will suggest a partial (usually simpler or lower level) solution that applies to a wider range of known problems, and leave the rest of the solution up to the user. In any case, before attempting a contribution, it is important to discuss the actual problems with the other developers or contributors, so a better agreement on implementation can be reached. @@ -91,7 +91,7 @@ The main problem is that, in reality, it rarely works this way. Most of the time Additionally, solutions that target individual problems are better for the users, as they find something that does exactly what they need, without having 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 rarely are flexible enough for all users, which keep requesting more functions added (and making the API and codebase more and more complex). +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 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -106,7 +106,7 @@ The question is then, how to design software that gives users what *we know they .. image:: img/best_practices6.png -The answer to this question is that, to ensure users still can do what they want to do, we need to give them access to a *low level API* that they can use to achieve what they want, even if it's more work for them because it means reimplementing some of the logic that already exists. +The answer to this question is that, to ensure users still can do what they want to do, we need to give them access to a *low level API* that they can use to achieve what they want, even if it's more work for them because it means reimplementing some logic that already exists. In real-life scenarios, these use cases will be at most rare and uncommon anyway, so it makes sense a custom solution needs to be written. This is why it's important to still provide users the basic building blocks to do it. @@ -117,7 +117,7 @@ When looking for a solution to a problem, be it implementing a new feature or fi The main problem here is, adding something to the core layers that will only be used from a single location far away will not only make the code more difficult to follow (split in two), but also make the core API larger, more complex, more difficult to understand in general. -This is bad, because readability and cleanness of core APIs is always of extreme importance given how much code relies from it, and because it's key for new contributors as a starting point to learning the codebase. +This is bad, because readability and cleanness of core APIs is always of extreme importance given how much code relies on it, and because it's key for new contributors as a starting point to learning the codebase. .. image:: img/best_practices7.png diff --git a/community/contributing/docs_writing_guidelines.rst b/community/contributing/docs_writing_guidelines.rst index e6be37efb..970d4c43b 100644 --- a/community/contributing/docs_writing_guidelines.rst +++ b/community/contributing/docs_writing_guidelines.rst @@ -425,7 +425,7 @@ For boolean member variables, always use ``if true`` and/or ``if false``, to stay explicit. ``Controls whether or not`` may be ambiguous and won't work for every member variable. -Also surround boolean values, variable names and methods with ``[code][/code]``. +Also, surround boolean values, variable names and methods with ``[code][/code]``. **Do** start with "if true": diff --git a/community/contributing/documentation_guidelines.rst b/community/contributing/documentation_guidelines.rst index da686d53d..de9e357bc 100644 --- a/community/contributing/documentation_guidelines.rst +++ b/community/contributing/documentation_guidelines.rst @@ -5,7 +5,7 @@ Documentation guidelines This page describes the rules to follow if you want to contribute to Godot Engine by writing or reviewing documentation, or by translating existing -documentation. Also have a look at README of the +documentation. Also, have a look at README of the `godot-docs GitHub repository `_ and the `docs front page `_ on what steps to follow and how to contact the docs team. @@ -67,7 +67,7 @@ What makes good documentation? Documentation should be well written in plain English, using well-formed sentences and various levels of sections and subsections. It should be clear -and objective. Also have a look at the :ref:`doc_docs_writing_guidelines`. +and objective. Also, have a look at the :ref:`doc_docs_writing_guidelines`. We differentiate tutorial pages from other documentation pages by these definitions: @@ -95,7 +95,7 @@ Always begin pages with their title and a Sphinx reference name: Insert your title here ====================== -The reference allows to link to this page using the ``:ref:`` format, e.g. +The reference allows linking to this page using the ``:ref:`` format, e.g. ``:ref:`doc_insert_your_title_here``` would link to the above example page (note the lack of leading underscore in the reference). @@ -122,7 +122,9 @@ You can help to translate the official Godot documentation on our `Hosted Weblat :align: center :target: https://hosted.weblate.org/engage/godot-engine/?utm_source=widget -There also is the official `Godot I18N repository `_. where you can see when the data was last synced. +There also is the official +`Godot i18N repository `_ +where you can see when the data was last synchronized. License ------- diff --git a/community/contributing/updating_the_class_reference.rst b/community/contributing/updating_the_class_reference.rst index b9e9aaf00..1be8b064b 100644 --- a/community/contributing/updating_the_class_reference.rst +++ b/community/contributing/updating_the_class_reference.rst @@ -54,7 +54,7 @@ Clone the repository on your computer: git clone https://github.com/your_name/godot.git -Create a new branch to make your changes. It makes it a lot easier to sync your improvements with other docs writers, and it's easier to cleanup your repository clean if you have any issues with git. +Create a new branch to make your changes. It makes it a lot easier to sync your improvements with other docs writers. It's also easier to clean up your repository if you run into any issues with Git. :: @@ -106,7 +106,7 @@ If you made changes you don't want to keep in your local branch, use the followi **Warning:** The above command will reset your branch to the state of the ``upstream master`` branch. It will discard all local changes. Make sure to only run this *before* you make important changes. -Another option is to delete the branch you're working on, synchronize the master branch with the Godot repository, and create a brand new branch: +Another option is to delete the branch you're working on, synchronize the master branch with the Godot repository, and create a new branch: :: diff --git a/community/tutorials.rst b/community/tutorials.rst index b49ba30a0..93d306a0e 100644 --- a/community/tutorials.rst +++ b/community/tutorials.rst @@ -3,7 +3,7 @@ Tutorials and resources ======================= -This is a list of third-party tutorials and resources created by the Godot community. For resources, remember that there is the official `Godot Asset Library `_ full of official and community resources too! Also have a look at this `huge list over at Reddit `_. +This is a list of third-party tutorials and resources created by the Godot community. For resources, remember that there is the official `Godot Asset Library `_ full of official and community resources too! Also, have a look at this `huge list over at Reddit `_. Think there is something missing here? Feel free to submit a `Pull Request `_ as always. @@ -14,7 +14,7 @@ The Godot video tutorials by `GDQuest `_ may be worth a look. -Some of the others mentioned below provide more advanced tutorials, e.g. on 3D or shaders. +Some tutorials mentioned below provide more advanced tutorials, e.g. on 3D or shaders. Video tutorials --------------- diff --git a/development/compiling/optimizing_for_size.rst b/development/compiling/optimizing_for_size.rst index 7c095187c..e76d6995a 100644 --- a/development/compiling/optimizing_for_size.rst +++ b/development/compiling/optimizing_for_size.rst @@ -66,8 +66,8 @@ to play videos). Optimizing for size instead of speed ------------------------------------ -Godot 3.1 onwards allows to compile using size optimizations. -To enable this, just set the ``optimize`` flag to ``size``: +Godot 3.1 onwards allows compiling using size optimizations (instead of speed). +To enable this, set the ``optimize`` flag to ``size``: :: diff --git a/development/cpp/configuring_an_ide.rst b/development/cpp/configuring_an_ide.rst index 1408d067d..8a87e15b7 100644 --- a/development/cpp/configuring_an_ide.rst +++ b/development/cpp/configuring_an_ide.rst @@ -81,9 +81,9 @@ Updating sources after pulling latest commits ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ As a developer you usually want to frequently pull the latest commits -from the upstream git repository or a specific fork etc. However this +from the upstream git repository or a specific fork etc. However, this brings a little problem with it: as the development continues, source files -(and folders) are added or removed. These changes needs to be reflected in +(and folders) are added or removed. These changes need to be reflected in your project files for Qt Creator too, so you continue to have a nice experience coding in it. A simple way to check is to right click at your root folder in the "Projects View" and click on "Edit files..." @@ -92,7 +92,7 @@ at your root folder in the "Projects View" and click on "Edit files..." Now a new dialog should appear that is similar in functionality to the one in the third step of the "Importing the project" section. Here you can check whether you want to add/remove -specific files and/or folders. You can chose by clicking with your mouse or just simply by +specific files and/or folders. You can choose by clicking with your mouse or just simply by clicking the "Apply Filter" button. A simple click on "Ok" and you're ready to continue your work. .. image:: img/qtcreator-edit-files-dialog.png diff --git a/development/cpp/custom_audiostreams.rst b/development/cpp/custom_audiostreams.rst index 641fd7ed3..21598a80b 100644 --- a/development/cpp/custom_audiostreams.rst +++ b/development/cpp/custom_audiostreams.rst @@ -43,7 +43,7 @@ internal/external buffer, or a file reference. Some AudioStreams need to be stateless such as objects loaded from ResourceLoader. ResourceLoader loads once and references the same object regardless how many times ``load`` is called on a specific resource. -Therefore, playback state must be self contained in AudioStreamPlayback. +Therefore, playback state must be self-contained in AudioStreamPlayback. .. code-block:: cpp diff --git a/development/cpp/custom_modules_in_cpp.rst b/development/cpp/custom_modules_in_cpp.rst index 92b766b89..dfbe81ff5 100644 --- a/development/cpp/custom_modules_in_cpp.rst +++ b/development/cpp/custom_modules_in_cpp.rst @@ -12,10 +12,10 @@ functionality at every level without modifying the core, which can be split for use and reuse in different modules. Modules are located in the ``modules/`` subdirectory of the build system. -By default, many different modules exist, such as GDScript (which, yes, +By default, dozens of modules are enabled, such as GDScript (which, yes, is not part of the base engine), the Mono runtime, a regular expressions module, and others. As many new modules as desired can be -created and combined, and the SCons build system will take care of it +created and combined. The SCons build system will take care of it transparently. What for? @@ -166,8 +166,8 @@ string list: env.add_source_files(env.modules_sources, src_list) This allows for powerful possibilities using Python to construct the file list -using loops and logic statements. Look at some of the other modules that ship -with Godot by default for examples. +using loops and logic statements. Look at some modules that ship with Godot by +default for examples. To add include directories for the compiler to look at you can append it to the environment's paths: @@ -342,7 +342,7 @@ 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 game given we want all the modules in a single binary. -However the trade-off is every single change means a full recompilation of the +However, the trade-off is every single change means a full recompilation of the game. Even if SCons is able to detect and recompile only the file that have changed, finding such files and eventually linking the final binary is a long and costly part. @@ -372,7 +372,7 @@ library that will be dynamically loaded when starting our game's binary. # next to the Godot binary. shared_lib = module_env.SharedLibrary(target='#bin/summator', source=sources) - # Finally notify the main env it has our shared lirary as a new dependency. + # Finally, notify the main env it has our shared lirary as a new dependency. # To do so, SCons wants the name of the lib with it custom suffixes # (e.g. ".linuxbsd.tools.64") but without the final ".so". # We pass this along with the directory of our library to the main env. @@ -428,8 +428,8 @@ using the `ARGUMENT` command: Now by default ``scons`` command will build our module as part of Godot's binary and as a shared library when passing ``summator_shared=yes``. -Finally you can even speedup build further by explicitly specifying your -shared module as target in the scons command: +Finally, you can even speed up the build further by explicitly specifying your +shared module as target in the SCons command: .. code-block:: shell diff --git a/development/file_formats/tscn.rst b/development/file_formats/tscn.rst index ed280c0a0..703956d7c 100644 --- a/development/file_formats/tscn.rst +++ b/development/file_formats/tscn.rst @@ -400,13 +400,13 @@ Each track is described by a list of key-value pairs in the format 2. The ``path`` has the format ``NodePath(Path/To/Node:attribute)``. It's the path to the animated node or attribute, relative to the root node defined in the AnimationPlayer. - +I 3. The ``interp`` is the method to interpolate frames from the keyframes. - it is a enum variable and can has value: + It is an enum variable with one of the following values: - - 0 (constant) - - 1 (linear) - - 2 (cubic) + - ``0`` (constant) + - ``1`` (linear) + - ``2`` (cubic) 4. The ``keys`` correspond to the keyframes. It appears as a ``PackedFloat32Array()``, but may have a different structure for tracks with different types. diff --git a/getting_started/scripting/gdscript/gdscript_basics.rst b/getting_started/scripting/gdscript/gdscript_basics.rst index 4d3580fc8..e2755cbd1 100644 --- a/getting_started/scripting/gdscript/gdscript_basics.rst +++ b/getting_started/scripting/gdscript/gdscript_basics.rst @@ -494,8 +494,8 @@ Associative container which contains values referenced by unique keys. Lua-style table syntax is also supported. Lua-style uses ``=`` instead of ``:`` and doesn't use quotes to mark string keys (making for slightly less to write). -Note however that like any GDScript identifier, keys written in this form cannot -start with a digit. +However, keys written in this form can't start with a digit (like any GDScript +identifier). :: diff --git a/getting_started/step_by_step/intro_to_the_editor_interface.rst b/getting_started/step_by_step/intro_to_the_editor_interface.rst index 40a87dbf6..78b44cb2c 100644 --- a/getting_started/step_by_step/intro_to_the_editor_interface.rst +++ b/getting_started/step_by_step/intro_to_the_editor_interface.rst @@ -155,7 +155,7 @@ item will be displayed in the script workspace. .. image:: img/editor_ui_intro_script_class_documentation.png -Finally the **AssetLib** is a library of free and open source add-ons, scripts +Finally, the **AssetLib** is a library of free and open source add-ons, scripts and assets to use in your projects. Modify the interface diff --git a/getting_started/step_by_step/scripting.rst b/getting_started/step_by_step/scripting.rst index b81f192ea..73605ab10 100644 --- a/getting_started/step_by_step/scripting.rst +++ b/getting_started/step_by_step/scripting.rst @@ -80,7 +80,7 @@ API Bridge. This language is the best choice for performance and does not need to be used throughout an entire game, as other parts can be written in GDScript or Visual -Script. However the API is clear and easy to use as it resembles, mostly, +Script. However, the API is clear and easy to use as it resembles, mostly, Godot's actual C++ API. More languages can be made available through the GDNative interface, but keep in mind diff --git a/getting_started/step_by_step/scripting_continued.rst b/getting_started/step_by_step/scripting_continued.rst index 24a5ef0d5..45fd98629 100644 --- a/getting_started/step_by_step/scripting_continued.rst +++ b/getting_started/step_by_step/scripting_continued.rst @@ -37,14 +37,14 @@ It's important to bear in mind that the frequency with which ``_process()`` will be called depends on how many frames per second (FPS) your application is running at. This rate can vary over time and devices. -To help manage this variability the ``delta`` parameter contains the time -elapsed in seconds, as a floating point, since the previous call to ``_process()``. +To help manage this variability, the ``delta`` parameter contains the time +elapsed in seconds as a floating-point number since the previous call to ``_process()``. This parameter can be used to make sure things always take the same amount of time, regardless of the game's FPS. For example, movement is often multiplied with a time delta to make movement -speed both constant and independent from the frame rate. +speed both constant and independent of the frame rate. Physics processing with ``_physics_process()`` is similar, but it should be used for processes that must happen before each physics step, such as controlling a character. diff --git a/getting_started/step_by_step/ui_game_user_interface.rst b/getting_started/step_by_step/ui_game_user_interface.rst index abe4437ce..f985626e8 100644 --- a/getting_started/step_by_step/ui_game_user_interface.rst +++ b/getting_started/step_by_step/ui_game_user_interface.rst @@ -287,7 +287,7 @@ the size of the ``Background``. Let's change the ``Number``'s align properties to move it to the left and center of the ``Background``. Select the ``Number`` node, change its ``Align`` property to left and the ``Valign`` property to centre. Then -resize its left edge a little bit to add some padding between the left +resize its left edge a bit to add some padding between the left edge of the ``Background`` and the text. .. figure:: ./img/ui_gui_step_tutorial_counter_design_3.png @@ -535,7 +535,7 @@ with the emerald icon. In the FileSystem tab, drag the ``emeralds_icon.png`` onto the ``Icon`` node's ``Texture`` slot. ``Icon`` already anchors to the right edge of the ``Background`` node so we can change its position and it will scale and reposition with the ``EmeraldCounter`` container. -Shift the emerald icon a little bit to the right and down. Use the Arrow +Shift the emerald icon a bit to the right and down. Use the Arrow Keys on the keyboard to nudge its position. Save, and we're done with all the UI elements. diff --git a/getting_started/step_by_step/your_first_game.rst b/getting_started/step_by_step/your_first_game.rst index 10165f2fb..cc9107edf 100644 --- a/getting_started/step_by_step/your_first_game.rst +++ b/getting_started/step_by_step/your_first_game.rst @@ -287,7 +287,7 @@ or ``false`` if it isn't. } } -We start by setting the ``velocity`` to ``(0, 0)`` - by default the player +We start by setting the ``velocity`` to ``(0, 0)`` - by default, the player should not be moving. Then we check each input and add/subtract from the ``velocity`` to obtain a total direction. For example, if you hold ``right`` and ``down`` at the same time, the resulting ``velocity`` vector will be @@ -1033,8 +1033,8 @@ show the "Start" button. .. note:: When you need to pause for a brief time, an alternative to using a Timer node is to use the SceneTree's ``create_timer()`` function. This - can be very useful to delay, such as in the above code, where we want - to wait a little bit of time before showing the "Start" button. + can be very useful to add delays such as in the above code, where we want + to wait some time before showing the "Start" button. .. tabs:: .. code-tab:: gdscript GDScript diff --git a/getting_started/workflow/assets/escn_exporter/physics.rst b/getting_started/workflow/assets/escn_exporter/physics.rst index c8ca29319..637bd2d2f 100644 --- a/getting_started/workflow/assets/escn_exporter/physics.rst +++ b/getting_started/workflow/assets/escn_exporter/physics.rst @@ -47,7 +47,7 @@ Collision geometry only ----------------------- Frequently you want different geometry for your collision meshes and your -graphical meshes, but by default the exporter will export a mesh along with the +graphical meshes, but by default, the exporter will export a mesh along with the collision shape. To only export the collision shape, set the object's maximum draw type to Wire: diff --git a/getting_started/workflow/assets/importing_scenes.rst b/getting_started/workflow/assets/importing_scenes.rst index 5f1790638..dc84bdfd2 100644 --- a/getting_started/workflow/assets/importing_scenes.rst +++ b/getting_started/workflow/assets/importing_scenes.rst @@ -17,7 +17,7 @@ Godot supports the following 3D *scene file formats*: * DAE (COLLADA), an older format that is fully supported. * OBJ (Wavefront) formats. It is also fully supported, but pretty limited (no support for pivots, skeletons, etc). * ESCN, a Godot specific format that Blender can export with a plugin. -* FBX, supported via the Open Asset Import library. However, FBX is proprietary so we recommend using other formats +* FBX, supported via the Open Asset Import library. However, FBX is proprietary, so we recommend using other formats listed above, if suitable for your workflow. Just copy the scene file together with the texture to the project repository, and Godot will do a full import. diff --git a/getting_started/workflow/export/exporting_for_android.rst b/getting_started/workflow/export/exporting_for_android.rst index 5342ee471..5781ab8f4 100644 --- a/getting_started/workflow/export/exporting_for_android.rst +++ b/getting_started/workflow/export/exporting_for_android.rst @@ -47,7 +47,7 @@ Setting it up in Godot ---------------------- Enter the Editor Settings screen. This screen contains the editor -settings for the user account in the computer (it's independent from the +settings for the user account in the computer (it's independent of the project). .. image:: img/editorsettings.png @@ -89,7 +89,7 @@ If you don't provide some of the requested icons, Godot will replace them using - **Adaptive Icon Foreground:** Provided foreground icon -> Provided main icon -> Project icon -> Default Godot foreground icon. - **Adaptive Icon Background:** Provided background icon -> Default Godot background icon. -It's highly recommended to provide all of the requested icons, and at least with the specified resolutions. Only this way your application will look great on all the Android devices and versions. +It's highly recommended to provide all requested icons, and at least with the specified resolutions. Only this way your application will look great on all Android devices and versions. Exporting for Google Play Store ------------------------------- diff --git a/tutorials/2d/2d_meshes.rst b/tutorials/2d/2d_meshes.rst index 92c397f81..b63b75f0f 100644 --- a/tutorials/2d/2d_meshes.rst +++ b/tutorials/2d/2d_meshes.rst @@ -7,12 +7,12 @@ Introduction ------------ In 3D, meshes are used to display the world. In 2D, they are rare as images are used more often. -Godot's 2D engine is a pure two dimensional engine, so it can't really display 3D meshes directly (although it can be done +Godot's 2D engine is a pure two-dimensional engine, so it can't really display 3D meshes directly (although it can be done via ``Viewport`` and ``ViewportTexture``). .. seealso:: If you are interested in displaying 3D meshes on a 2D viewport, see the :ref:`doc_viewport_as_texture` tutorial. -2D meshes are meshes that contain two dimensional geometry (Z can be omitted or ignored) instead of 3D. +2D meshes are meshes that contain two-dimensional geometry (Z can be omitted or ignored) instead of 3D. You can experiment creating them yourself using ``SurfaceTool`` from code and displaying them in a ``MeshInstance2D`` node. Currently, the only way to generate a 2D mesh within the editor is by either importing an OBJ file as a mesh, or converting it from a Sprite. diff --git a/tutorials/3d/environment_and_post_processing.rst b/tutorials/3d/environment_and_post_processing.rst index 768611197..b8d7212dc 100644 --- a/tutorials/3d/environment_and_post_processing.rst +++ b/tutorials/3d/environment_and_post_processing.rst @@ -3,7 +3,7 @@ Environment and post-processing =============================== -Godot 3 provides a redesigned Environment resource, as well as a brand new +Godot 3 provides a redesigned Environment resource, as well as a new post-processing system with many available effects right out of the box. Environment @@ -94,7 +94,8 @@ Here is a comparison of how different ambient light affects a scene: .. image:: img/environment_ambient2.png -Finally there is an **Energy** setting, which is a multiplier, useful when working with HDR. +Finally, there is an **Energy** setting, which is a multiplier. It's useful when +working with HDR. In general, ambient light should only be used for simple scenes, large exteriors, or for performance reasons (ambient light is cheap), as it does not provide the diff --git a/tutorials/3d/fps_tutorial/part_four.rst b/tutorials/3d/fps_tutorial/part_four.rst index f0dd067a3..b3fd5478a 100644 --- a/tutorials/3d/fps_tutorial/part_four.rst +++ b/tutorials/3d/fps_tutorial/part_four.rst @@ -303,7 +303,7 @@ We then check to see if the player is changing weapons or reloading. If the play we would get an error when we tried to run the project. Next, we check to see if the weapon name at ``round_mouse_scroll_value`` is not equal to the current weapon name using ``WEAPON_NUMBER_TO_NAME``. -If the weapon is different than the player's current weapon, we assign ``changing_weapon_name``, set ``changing_weapon`` to ``true`` so the player will change weapons in +If the weapon is different from the player's current weapon, we assign ``changing_weapon_name``, set ``changing_weapon`` to ``true`` so the player will change weapons in ``process_changing_weapon``, and set ``mouse_scroll_value`` to ``round_mouse_scroll_value``. .. tip:: The reason we are setting ``mouse_scroll_value`` to the rounded scroll value is because we do not want the player to keep their diff --git a/tutorials/3d/fps_tutorial/part_one.rst b/tutorials/3d/fps_tutorial/part_one.rst index 95b9c4f4a..9aeacd74b 100644 --- a/tutorials/3d/fps_tutorial/part_one.rst +++ b/tutorials/3d/fps_tutorial/part_one.rst @@ -377,7 +377,7 @@ This is a lot of code, so let's break it down function by function: .. tip:: While copy and pasting code is ill advised, as you can learn a lot from manually typing the code in, you can copy and paste the code from this page directly into the script editor. - If you do this, all of the code copied will be using spaces instead of tabs. + If you do this, all the code copied will be using spaces instead of tabs. To convert the spaces to tabs in the script editor, click the "edit" menu and select "Convert Indent To Tabs". This will convert all the spaces into tabs. You can select "Convert Indent To Spaces" to convert tabs back into spaces. @@ -642,7 +642,7 @@ our ``DEACCEL`` constant so the player will decelerate. Then we interpolate the horizontal velocity, set the player's ``X`` and ``Z`` velocity to the interpolated horizontal velocity, and call ``move_and_slide`` to let the :ref:`KinematicBody ` handle moving the player through the physics world. -.. tip:: All of the code in ``process_movement`` is exactly the same as the movement code from the Kinematic Character demo! +.. tip:: All the code in ``process_movement`` is exactly the same as the movement code from the Kinematic Character demo! _________ diff --git a/tutorials/3d/fps_tutorial/part_two.rst b/tutorials/3d/fps_tutorial/part_two.rst index 085e20904..73b2ba037 100644 --- a/tutorials/3d/fps_tutorial/part_two.rst +++ b/tutorials/3d/fps_tutorial/part_two.rst @@ -1164,7 +1164,7 @@ Then we tell the current weapon the player is using to fire by calling its ``fir _______ -Before we are ready to test our new weapons, we still have a little bit of work to do. +Before we are ready to test our new weapons, we still have a bit of work to do. Creating some test subjects --------------------------- diff --git a/tutorials/3d/high_dynamic_range.rst b/tutorials/3d/high_dynamic_range.rst index 0f44d6877..dbdcdfd67 100644 --- a/tutorials/3d/high_dynamic_range.rst +++ b/tutorials/3d/high_dynamic_range.rst @@ -68,7 +68,7 @@ Scene linear & asset pipelines Working in scene-linear sRGB is not as simple as just pressing a 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 +when linearized, those assets may not be perfectly well-suited for use as textures, depending on how they were generated. There are two ways to do this: @@ -84,7 +84,7 @@ These textures may also be compressed later, which can exacerbate the problem. Hardware sRGB transfer function to display linear conversion ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The GPU will do the conversion after reading the texel using floating point. +The GPU will do the conversion after reading the texel using floating-point. This works fine on PC and consoles, but most mobile devices don't support it, or they don't support it on compressed texture formats (iOS for example). diff --git a/tutorials/3d/introduction_to_3d.rst b/tutorials/3d/introduction_to_3d.rst index 99fe75cc1..7f37b6bd5 100644 --- a/tutorials/3d/introduction_to_3d.rst +++ b/tutorials/3d/introduction_to_3d.rst @@ -133,7 +133,7 @@ know what you are doing). When working with 3D assets, it's always best to work in the correct scale (set your DCC to metric). Godot allows scaling post-import and, while this works in most cases, in rare situations it may introduce -floating point precision issues (and thus, glitches or artifacts) in +floating-point precision issues (and thus, glitches or artifacts) in delicate areas, such as rendering or physics, so make sure your artists always work in the right scale! diff --git a/tutorials/3d/spatial_material.rst b/tutorials/3d/spatial_material.rst index 2cc8636a8..d609547bb 100644 --- a/tutorials/3d/spatial_material.rst +++ b/tutorials/3d/spatial_material.rst @@ -142,7 +142,7 @@ Vertex Color ------------ This setting allows choosing what is done by default to vertex colors that come -from your 3D modelling application. By default they are ignored. +from your 3D modelling application. By default, they are ignored. .. image:: img/spatial_material4.png diff --git a/tutorials/3d/using_transforms.rst b/tutorials/3d/using_transforms.rst index d890e3213..cee44fa7d 100644 --- a/tutorials/3d/using_transforms.rst +++ b/tutorials/3d/using_transforms.rst @@ -380,7 +380,11 @@ Converting a rotation to quaternion is straightforward. // Apply back transform.basis = new Basis(c); -The :ref:`class_Quat` type reference has more information on the datatype (it can also do transform accumulation, transform points, etc., though this is used less often). If you interpolate or apply operations to quaternions many times, keep in mind they need to be eventually normalized or they also may suffer from numerical precision errors. +The :ref:`class_Quat` type reference has more information on the datatype (it +can also do transform accumulation, transform points, etc., though this is used +less often). If you interpolate or apply operations to quaternions many times, +keep in mind they need to be eventually normalized. Otherwise, they will also +suffer from numerical precision errors. Quaternions are useful when doing camera/path/etc. interpolations, as the result will always be correct and smooth. diff --git a/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst b/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst index 3215400ce..0b369f720 100644 --- a/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst +++ b/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst @@ -47,7 +47,7 @@ results in real time, without the shader having to recompile. All the motions will be made using cosine waves applied to ``VERTEX`` in model space. We want the vertices to be in model space so that the motion is always relative to the orientation of the fish. For example, side-to-side -will always be move the fish back and forth in its left to right direction, instead of on the ``x`` axis in the +will always move the fish back and forth in its left to right direction, instead of on the ``x`` axis in the world orientation. In order to control the speed of the animation, we will start by defining our own time variable using ``TIME``. @@ -124,7 +124,7 @@ we first construct a rotation matrix. mat2 twist_matrix = mat2(vec2(cos(twist_angle), -sin(twist_angle)), vec2(sin(twist_angle), cos(twist_angle))); We apply the rotation in the ``xy`` axes so that the fish appears to roll around its spine. For -this to work, the fishes spine needs to be centered on the ``z`` axis. +this to work, the fish's spine needs to be centered on the ``z`` axis. .. code-block:: glsl @@ -164,7 +164,7 @@ In order to apply the mask to the twist, we use ``mix``. ``mix`` allows us to mi vertex position between a fully rotated vertex and one that is not rotated. We need to use ``mix`` instead of multiplying ``mask`` by the rotated ``VERTEX`` because we are not adding the motion to the ``VERTEX`` we are replacing the ``VERTEX`` with the rotated -version. If we multiplied that by ``mask`` we would shrink the fish. +version. If we multiplied that by ``mask``, we would shrink the fish. .. code-block:: glsl @@ -203,7 +203,7 @@ a :ref:`Color `. For both ``color_format`` and ``custom_data_format`` you can choose between ``None``, ``Byte``, and ``Float``. ``None`` means you won't be passing in that data (either a per-instance ``COLOR`` variable, or ``INSTANCE_CUSTOM``) to the shader. ``Byte`` means each number making up the color you pass in will -be stored with 8 bits while ``Float`` means each number will be stored in a floating point number +be stored with 8 bits while ``Float`` means each number will be stored in a floating-point number (32 bits). ``Float`` is slower but more precise, ``Byte`` will take less memory and be faster, but you may see some visual artifacts. @@ -268,7 +268,7 @@ custom value. One problem that you will run into at this point is that the fish are animated, but they are not moving. You can move them by updating the per-instance transform for each fish every frame. Although -doing so will be faster then moving thousands of MeshInstances per frame, it is still likely to be +doing so will be faster than moving thousands of MeshInstances per frame, it'll still likely be slow. In the next tutorial we will cover how to use :ref:`Particles ` to take advantage diff --git a/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst b/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst index aeb7ebc52..269988623 100644 --- a/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst +++ b/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst @@ -7,7 +7,7 @@ The problem with :ref:`MeshInstances ` is that it is expensi update their transform array. It is great for placing many static objects around the scene. But it is still difficult to move the objects around the scene. -To make each instance move in an interesting way we will use a +To make each instance move in an interesting way, we will use a :ref:`Particles ` node. Particles take advantage of GPU acceleration by computing and setting the per-instance information in a :ref:`Shader `. @@ -51,7 +51,7 @@ Then add the following two functions: These functions come from the default :ref:`ParticlesMaterial `. They are used to generate a random number from each particle's ``RANDOM_SEED``. -A unique thing about particle shaders is that some of the built-in variables are saved across frames. +A unique thing about particle shaders is that some built-in variables are saved across frames. ``TRANSFORM``, ``COLOR``, and ``CUSTOM`` can all be accessed in the Spatial shader of the mesh, and also in the particle shader the next time it is run. @@ -60,7 +60,7 @@ and no others. First we will distinguish between code that needs to be run only when the particle system starts and code that should always run. We want to give each fish a random position and a random animation -offset when the system is first run so we wrap that code in an ``if`` statement that checks the +offset when the system is first run. To do so, we wrap that code in an ``if`` statement that checks the built-in variable ``RESTART`` which becomes ``true`` for one frame when the particle system is restarted. From a high level, this looks like: diff --git a/tutorials/animation/animation_tree.rst b/tutorials/animation/animation_tree.rst index 5878d3124..2d5ddf321 100644 --- a/tutorials/animation/animation_tree.rst +++ b/tutorials/animation/animation_tree.rst @@ -111,7 +111,7 @@ Very simple state machine (when you don't want to cope with a ``StateMachine`` n BlendSpace2D ^^^^^^^^^^^^ -``BlendSpace2D`` is a node to do advanced blending in two dimensions. Points are added to a two dimensional space and then a position +``BlendSpace2D`` is a node to do advanced blending in two dimensions. Points are added to a two-dimensional space and then a position can be controlled to determine blending: .. image:: img/animtree7.gif diff --git a/tutorials/animation/cutout_animation.rst b/tutorials/animation/cutout_animation.rst index 47c490b5e..6c9a9860a 100644 --- a/tutorials/animation/cutout_animation.rst +++ b/tutorials/animation/cutout_animation.rst @@ -134,7 +134,7 @@ The :ref:`RemoteTransform2D ` node transforms nodes somewhere else in the hierarchy. This node applies its own transform (including any transformation it inherits from its parents) to the remote node it targets. -This allows us to correct the visibility order of our elements independent from +This allows us to correct the visibility order of our elements, independently of the locations of those parts in the cutout hierarchy. Create a ``RemoteTransform2D`` node as a child of the torso. Call it ``remote_arm_l``. @@ -369,4 +369,3 @@ Skeletal deform can be used to augment a cutout rig, allowing single pieces to deform organically (e.g. antennae that wobble as an insect character walks). This process is described in a :ref:`separate tutorial `. - diff --git a/tutorials/animation/introduction_2d.rst b/tutorials/animation/introduction_2d.rst index dc5b0491a..4ff34ca60 100644 --- a/tutorials/animation/introduction_2d.rst +++ b/tutorials/animation/introduction_2d.rst @@ -108,17 +108,17 @@ Tutorial: Creating a simple animation Scene setup ~~~~~~~~~~~ -For this tutorial, we'll going to create an AnimationPlayer node and a -sprite node as its child. +For this tutorial, we'll create an AnimationPlayer node and a sprite node as its +child. .. figure:: img/animation_animation_player_tree.png :alt: Our scene setup Our scene setup -The sprite holds an image texture and we animate that sprite to move -between two points on the screen. For this tutorial use the default Godot -Icon as the sprites' texture. As a starting point, move the sprite +The sprite holds an image texture. We animate that sprite to move +between two points on the screen. For this tutorial, use the default Godot +icon as the sprite's texture. As a starting point, move the sprite to a left position on the screen. .. tip:: @@ -155,8 +155,7 @@ Deselect rotation, because we are only interested in the location of our sprite for this tutorial and click on the key button. As we don't have a track already set up for the transform/location -property, Godot asks, whether it should set it up for us. Click on -"Create". +property, Godot asks whether it should set it up for us. Click **Create**. This creates a new track and our first keyframe at the beginning of the timeline: @@ -181,7 +180,7 @@ the timeline controls in animation panel's lower panel to 2. Animation length -Click on the timeline header near the 2 second mark and move the sprite +Click on the timeline header near the 2-second mark and move the sprite to the target destination on the right side. Again, click the key button in the toolbar. This creates our second @@ -284,7 +283,7 @@ Godot doesn't restrict you to only edit transform properties. Every property can be used as a track where you can set keyframes. If you select your sprite while the animation panel is visible, you get -a small keyframe button for all of the sprite's properties. Click on +a small keyframe button for all the sprite's properties. Click on this button and Godot automatically adds a track and keyframe to the current animation. diff --git a/tutorials/content/making_trees.rst b/tutorials/content/making_trees.rst index dfad9dab8..4ca5fa65c 100644 --- a/tutorials/content/making_trees.rst +++ b/tutorials/content/making_trees.rst @@ -67,7 +67,7 @@ Here, the texture is read, as well as a transmission color, which is used to add This is the code to create the sway of the leaves. It's basic (just uses a sinewave multiplying by the time and axis position, but works well). Notice that the strength is multiplied by the color. Every axis uses a different small near 1.0 multiplication factor so axes don't appear in sync. -Finally all that is left is the fragment shader: +Finally, all that's left is the fragment shader: .. code-block:: glsl diff --git a/tutorials/content/procedural_geometry/immediategeometry.rst b/tutorials/content/procedural_geometry/immediategeometry.rst index f36717e7a..fd5e37a71 100644 --- a/tutorials/content/procedural_geometry/immediategeometry.rst +++ b/tutorials/content/procedural_geometry/immediategeometry.rst @@ -4,8 +4,8 @@ Using ImmediateGeometry ======================= Unlike the SurfaceTool or ArrayMesh, :ref:`ImmediateGeometry ` is an actual -node. Being an node makes it quick to add to a scene and get visual output. It uses an "OpenGL 1.x" style -API like the SurfaceTool, but it's actually designed to create content on the fly. +node. Being a node makes it quick to add to a scene and get visual output. It uses an OpenGL 1.x-style +API like SurfaceTool, but it's actually designed to create meshes on the fly. Generating complex geometry (several thousand vertices) with this node is inefficient, even if it's done only once. Instead, it is designed to generate simple geometry that changes every frame. diff --git a/tutorials/content/procedural_geometry/surfacetool.rst b/tutorials/content/procedural_geometry/surfacetool.rst index 89a3d5899..5728c02bf 100644 --- a/tutorials/content/procedural_geometry/surfacetool.rst +++ b/tutorials/content/procedural_geometry/surfacetool.rst @@ -76,7 +76,7 @@ to remove duplicate vertices. st.add_index(3) st.add_index(2) - # Or alternatively: + # Alternatively: st.index() Similarly, if you have an index array, but you want each vertex to be unique (e.g. because diff --git a/tutorials/gui/bbcode_in_richtextlabel.rst b/tutorials/gui/bbcode_in_richtextlabel.rst index e2af9c371..c9218719f 100644 --- a/tutorials/gui/bbcode_in_richtextlabel.rst +++ b/tutorials/gui/bbcode_in_richtextlabel.rst @@ -6,7 +6,7 @@ BBCode in RichTextLabel Introduction ------------ -Label nodes are great for displaying basic text but they have limits. If you want +Label nodes are great for displaying basic text, but they have limits. If you want to change the color of the text, or its alignment, that change affects all of the text in the Label node. You can't have only one part of the text be one color, or only one part of the text be centered. To get around this limitation you would use diff --git a/tutorials/gui/custom_gui_controls.rst b/tutorials/gui/custom_gui_controls.rst index c5da23d23..a36759dae 100644 --- a/tutorials/gui/custom_gui_controls.rst +++ b/tutorials/gui/custom_gui_controls.rst @@ -93,7 +93,7 @@ for example: return new Vector2(20, 20); } -Or alternatively, set it via function: +Alternatively, set it using a function: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/gui/gui_skinning.rst b/tutorials/gui/gui_skinning.rst index fb0395bde..ae64ced47 100644 --- a/tutorials/gui/gui_skinning.rst +++ b/tutorials/gui/gui_skinning.rst @@ -6,7 +6,7 @@ GUI skinning Oh, beautiful GUI! ------------------ -This tutorial is about advanced skinning of an user interface. Most +This tutorial is about advanced skinning of a user interface. Most games generally don't need this, as they end up just relying on :ref:`Label `, :ref:`TextureRect `, :ref:`TextureButton ` and diff --git a/tutorials/inputs/inputevent.rst b/tutorials/inputs/inputevent.rst index 41e8b7289..3b144aaaf 100644 --- a/tutorials/inputs/inputevent.rst +++ b/tutorials/inputs/inputevent.rst @@ -37,7 +37,7 @@ you can define multiple keys for the same action (e.g. they keyboard escape key You can then more easily change this mapping in the project settings without updating your code, and even build a key mapping feature on top of it to allow your game to change the key mapping at runtime! -You can setup your InputMap under **Project > Project Settings > Input Map** and then use those actions like this: +You can set up your InputMap under **Project > Project Settings > Input Map** and then use those actions like this: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/math/interpolation.rst b/tutorials/math/interpolation.rst index 17717a951..d1ffa21bd 100644 --- a/tutorials/math/interpolation.rst +++ b/tutorials/math/interpolation.rst @@ -9,7 +9,7 @@ The basic idea is that you want to transition from A to B. A value ``t``, repres 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*. -Between two real (floating point) numbers, a simple interpolation is usually described as: +Between two real (floating-point) numbers, a simple interpolation is usually described as: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/math/matrices_and_transforms.rst b/tutorials/math/matrices_and_transforms.rst index c1e87694d..f330994a1 100644 --- a/tutorials/math/matrices_and_transforms.rst +++ b/tutorials/math/matrices_and_transforms.rst @@ -583,7 +583,7 @@ How does it all work in 3D? One of the great things about transformation matrices is that they work very similarly between 2D and 3D transformations. -All of the code and formulas used above for 2D work the same in 3D, +All the code and formulas used above for 2D work the same in 3D, with 3 exceptions: the addition of a third axis, that each axis is of type :ref:`class_Vector3`, and also that Godot stores the :ref:`class_Basis` separately from the :ref:`class_Transform`, @@ -625,7 +625,7 @@ how you represent rotation by itself without the basis vectors. With 2D, we have an easy way (atan2) to switch between a transformation matrix and an angle. In 3D, we can't simply represent rotation as one number. There is something called Euler angles, which can represent -rotations as a set of 3 numbers, however they are limited and not very +rotations as a set of 3 numbers, however, they are limited and not very useful, except for trivial cases. In 3D we do not typically use angles, we either use a transformation basis diff --git a/tutorials/math/vectors_advanced.rst b/tutorials/math/vectors_advanced.rst index b0db0253d..b0c5bbab3 100644 --- a/tutorials/math/vectors_advanced.rst +++ b/tutorials/math/vectors_advanced.rst @@ -180,23 +180,21 @@ degrees to either side: .. tabs:: .. code-tab:: gdscript GDScript - # calculate vector from a to b + # Calculate vector from `a` to `b`. var dvec = (point_b - point_a).normalized() - # rotate 90 degrees + # Rotate 90 degrees. var normal = Vector2(dvec.y, -dvec.x) - # or alternatively + # Alternatively (depending the desired side of the normal): # var normal = Vector2(-dvec.y, dvec.x) - # depending the desired side of the normal .. code-tab:: csharp - // calculate vector from a to b + // Calculate vector from `a` to `b`. var dvec = (pointB - pointA).Normalized(); - // rotate 90 degrees + // Rotate 90 degrees. var normal = new Vector2(dvec.y, -dvec.x); - // or alternatively + // Alternatively (depending the desired side of the normal): // var normal = new Vector2(-dvec.y, dvec.x); - // depending the desired side of the normal The rest is the same as the previous example, either point_a or point_b will work since they are in the same plane: diff --git a/tutorials/misc/jitter_stutter.rst b/tutorials/misc/jitter_stutter.rst index c158914e8..0b551daee 100644 --- a/tutorials/misc/jitter_stutter.rst +++ b/tutorials/misc/jitter_stutter.rst @@ -33,7 +33,7 @@ There can be many causes of jitter, the most typical one happens when the game * at a different resolution than the monitor refresh rate. Check whether your monitor refresh rate is different from 60 Hz. This is generally not a problem, given that refresh rates higher than 60 Hz are barely visible to the human eye, and -starting with Godot 3.1, a frame timer was introduced that tries to synchronize with refresh as best as possible. +starting with Godot 3.1, a frame timer was introduced that tries to synchronize with refresh as well as possible. Sometimes only some objects appear to jitter (character or background). This happens when they are processed in different time sources (one is processed in the physics step while another is processed in the idle step). Godot 3.1 does some diff --git a/tutorials/misc/pausing_games.rst b/tutorials/misc/pausing_games.rst index 52a5aaea0..1d9f0ffc3 100644 --- a/tutorials/misc/pausing_games.rst +++ b/tutorials/misc/pausing_games.rst @@ -8,7 +8,7 @@ Pause? In most games it is desirable to, at some point, interrupt the game to do something else, such as taking a break or changing options. -However this is not as simple as it seems. The game might be stopped, +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. diff --git a/tutorials/networking/websocket.rst b/tutorials/networking/websocket.rst index 8fec0e47a..d45b02cf7 100644 --- a/tutorials/networking/websocket.rst +++ b/tutorials/networking/websocket.rst @@ -7,7 +7,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. +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). diff --git a/tutorials/optimization/using_multimesh.rst b/tutorials/optimization/using_multimesh.rst index 30bdc066f..fd8438893 100644 --- a/tutorials/optimization/using_multimesh.rst +++ b/tutorials/optimization/using_multimesh.rst @@ -30,7 +30,7 @@ for different areas of the world. It is also possible to execute some logic inside the vertex shader (using the ``INSTANCE_ID`` or ``INSTANCE_CUSTOM`` built-in constants). For an example of animating thousands of objects in a MultiMesh, see the :ref:`Animating thousands of fish ` tutorial. Information -to the shader can be provided via textures (there are floating point :ref:`Image` formats +to the shader can be provided via textures (there are floating-point :ref:`Image` formats which are ideal for this). Another alternative is to use GDNative and C++, which should be extremely efficient (it's possible diff --git a/tutorials/optimization/using_servers.rst b/tutorials/optimization/using_servers.rst index a72124d81..45a07c091 100644 --- a/tutorials/optimization/using_servers.rst +++ b/tutorials/optimization/using_servers.rst @@ -123,7 +123,7 @@ Primitives are cleared this way: Instantiating a Mesh into 3D space ---------------------------------- -The 3D APIs are different than the 2D ones, so the instantiation API must be used. +The 3D APIs are different from the 2D ones, so the instantiation API must be used. .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/plugins/gdnative/gdnative-c-example.rst b/tutorials/plugins/gdnative/gdnative-c-example.rst index bb009c06e..2807cdce4 100644 --- a/tutorials/plugins/gdnative/gdnative-c-example.rst +++ b/tutorials/plugins/gdnative/gdnative-c-example.rst @@ -215,7 +215,7 @@ to clear our API pointers. nativescript_api = NULL; } -Finally we have ``nativescript_init`` which is the most important function we'll +Finally, we have ``nativescript_init`` which is the most important function we'll need today. This function will be called by Godot as part of loading a GDNative library and communicates back to the engine what objects we make available. @@ -510,7 +510,7 @@ select our ``.gdnlib`` file by clicking on *Library* and selecting *Load*: .. image:: img/nativescript_library.png -Finally click on the save icon and save this as ``bin/simple.gdns``: +Finally, click on the save icon and save this as ``bin/simple.gdns``: .. image:: img/save_gdns.gif diff --git a/tutorials/shading/shading_reference/shading_language.rst b/tutorials/shading/shading_reference/shading_language.rst index ea6b68062..89c47388c 100644 --- a/tutorials/shading/shading_reference/shading_language.rst +++ b/tutorials/shading/shading_reference/shading_language.rst @@ -46,13 +46,13 @@ Most GLSL ES 3.0 datatypes are supported: +---------------------+---------------------------------------------------------------------------------+ | **uvec4** | Four-component vector of unsigned integers. | +---------------------+---------------------------------------------------------------------------------+ -| **float** | Floating point scalar. | +| **float** | Floating-point scalar. | +---------------------+---------------------------------------------------------------------------------+ -| **vec2** | Two-component vector of floating point values. | +| **vec2** | Two-component vector of floating-point values. | +---------------------+---------------------------------------------------------------------------------+ -| **vec3** | Three-component vector of floating point values. | +| **vec3** | Three-component vector of floating-point values. | +---------------------+---------------------------------------------------------------------------------+ -| **vec4** | Four-component vector of floating point values. | +| **vec4** | Four-component vector of floating-point values. | +---------------------+---------------------------------------------------------------------------------+ | **mat2** | 2x2 matrix, in column major order. | +---------------------+---------------------------------------------------------------------------------+ diff --git a/tutorials/shading/shading_reference/spatial_shader.rst b/tutorials/shading/shading_reference/spatial_shader.rst index 153c682c3..33d871991 100644 --- a/tutorials/shading/shading_reference/spatial_shader.rst +++ b/tutorials/shading/shading_reference/spatial_shader.rst @@ -132,7 +132,7 @@ is usually: * **y**: Phase during lifetime (0 to 1). * **z**: Animation frame. -This allows you to easily adjust the shader to a particle system using default particles material. When writing a custom particles +This allows you to easily adjust the shader to a particle system using default particles material. When writing a custom particle shader, this value can be used as desired. +--------------------------------------+-------------------------------------------------------+ diff --git a/tutorials/shading/your_first_shader/what_are_shaders.rst b/tutorials/shading/your_first_shader/what_are_shaders.rst index 54dcdfc43..b2df382b3 100644 --- a/tutorials/shading/your_first_shader/what_are_shaders.rst +++ b/tutorials/shading/your_first_shader/what_are_shaders.rst @@ -104,10 +104,11 @@ many or all cores are doing the same calculation at once, but with different dat That is where shaders come in. The GPU will call the shader a bunch of times simultaneously, and then operate on different bits of data (vertices, or pixels). These bunches of data are often called wavefronts. A shader will run the same for every thread in the wavefront. For example, if a given GPU can handle 100 -threads per wavefront, a wavefront will run on a 10x10 block of pixels together. And it will continue to +threads per wavefront, a wavefront will run on a 10×10 block of pixels together. It will continue to run for all pixels in that wavefront until they are complete. Accordingly, if you have one pixel slower than the rest (due to excessive branching), the entire block will be slowed down, resulting in massively -slower render times. This is different than CPU based operations, on a CPU if you can speed up even one -pixel the entire rendering time will decrease. On a GPU, you have to speed up the entire wavefront -to speed up rendering. +slower render times. +This is different from CPU-based operations. On a CPU, if you can speed up even one +pixel, the entire rendering time will decrease. On a GPU, you have to speed up the entire wavefront +to speed up rendering. diff --git a/tutorials/shading/your_first_shader/your_first_spatial_shader.rst b/tutorials/shading/your_first_shader/your_first_spatial_shader.rst index 54fce9b6e..ec304cd86 100644 --- a/tutorials/shading/your_first_shader/your_first_spatial_shader.rst +++ b/tutorials/shading/your_first_shader/your_first_spatial_shader.rst @@ -156,7 +156,7 @@ To access a texture in a shader add the following code near the top of your shad uniform sampler2D noise; This will allow you to send a noise texture to the shader. Now look in the inspecter under your material. -You should see a section called "Shader Params". If you open it up you will see a section called "noise". +You should see a section called "Shader Params". If you open it up, you'll see a section called "noise". Click beside it where it says "[empty]" and select "New NoiseTexture". Then in your NoiseTexture click beside where it says "Noise" and select "New OpenSimplexNoise". @@ -185,7 +185,7 @@ Using this code you can see the texture creates random looking hills. .. image:: img/noise.png -Right now it is too spiky, we want to soften the hills a bit. To do that we will use a uniform. +Right now it is too spiky, we want to soften the hills a bit. To do that, we will use a uniform. You already used a uniform above to pass in the noise texture, now let's learn how they work. Uniforms @@ -213,7 +213,7 @@ precedence over the value used to initialize it in the shader. # called from the MeshInstance mesh.material.set_shader_param("height_scale", 0.5) -.. note:: Changing uniforms from Spatial nodes is different than in CanvasItem nodes. Here, +.. note:: Changing uniforms in Spatial-based nodes is different from CanvasItem-based nodes. Here, we set the material inside the PlaneMesh resource. In other mesh resources you may need to first access the material by calling ``surface_get_material()``. While in the MeshInstance you would access the material using ``get_surface_material()`` or diff --git a/tutorials/shading/your_first_shader/your_second_spatial_shader.rst b/tutorials/shading/your_first_shader/your_second_spatial_shader.rst index b0d951497..2a22a0124 100644 --- a/tutorials/shading/your_first_shader/your_second_spatial_shader.rst +++ b/tutorials/shading/your_first_shader/your_second_spatial_shader.rst @@ -128,19 +128,20 @@ help achieve a nice watery effect. .. image:: img/rim.png -In order to add fresnal reflectance we will compute a fresnel term in our fragment shader. -We are not going to use a real fresnel term, instead we will approximate it using the dot -product of the ``NORMAL`` and ``VIEW`` vectors. The ``NORMAL`` vector points away from a -surface of the, while the ``VIEW`` vector is the direction between your eye and that point -on the surface. The dot product between them is a handy way to tell when you are looking -at the surface head-on your at a glancing angle. +In order to add fresnal reflectance, we will compute a fresnel term in our +fragment shader. Here, we aren't going to use a real fresnel term for +performance reasons. Instead, we'll approximate it using the dot product of the +``NORMAL`` and ``VIEW`` vectors. The ``NORMAL`` vector points away from the +mesh's surface, while the ``VIEW`` vector is the direction between your eye and +that point on the surface. The dot product between them is a handy way to tell +when you are looking at the surface head-on or at a glancing angle. .. code-block:: glsl float fresnel = sqrt(1.0 - dot(NORMAL, VIEW)); And mix it into both ``ROUGHNESS`` and ``ALBEDO``. This is the benefit of ShaderMaterials over -SpatialMaterials. With SpatialMaterials we could set these properties with a texture, or to a flat +SpatialMaterials. With SpatialMaterials, we could set these properties with a texture, or to a flat number. But with shaders we can set them based on any mathematical function that we can dream up. @@ -166,7 +167,7 @@ decreasing the values of the ``vec3`` we pass into ``ALBEDO``. Let's set them to Animating with ``TIME`` ----------------------- -Going back to the vertex function, we can animated the waves using the built-in variable ``TIME``. +Going back to the vertex function, we can animate the waves using the built-in variable ``TIME``. ``TIME`` is a built-in variable that is accessible from the vertex and fragment functions. @@ -177,10 +178,10 @@ we will do the same. Put the heightmap code in a function called ``height()``. .. code-block:: glsl float height(vec2 position) { - return texture(noise, position / 10.0).x; //scaling factor is based on mesh size (This PlanMesh is 10x10) + return texture(noise, position / 10.0).x; // Scaling factor is based on mesh size (this PlaneMesh is 10×10). } -In order to use ``TIME`` in the ``height()`` function we need to pass it in. +In order to use ``TIME`` in the ``height()`` function, we need to pass it in. .. code-block:: glsl @@ -246,8 +247,8 @@ At first this looks complicated. So let's go through it line-by-line. position += texture(noise, position / 10.0).x * 2.0 - 1.0; -Offset the position by the ``noise`` texture. This will make the waves curve so they are not straight lines -completely aligned with the grid. +Offset the position by the ``noise`` texture. This will make the waves curve, so +they won't be straight lines completely aligned with the grid. .. code-block:: glsl @@ -310,8 +311,8 @@ Note that we add time to two and subtract it from the other two. This makes the creating a complex effect. Also note that the amplitudes (the number the result is multiplied by) all add up to ``1.0``. This keeps the wave in the 0-1 range. -With this code you should end up with more complex looking waves and all you had to do was add a little bit -of math! +With this code you should end up with more complex looking waves and all you had +to do was add a bit of math! .. image:: img/wave3.png diff --git a/tutorials/viewports/using_viewport_as_texture.rst b/tutorials/viewports/using_viewport_as_texture.rst index bd16cfc75..225d65645 100644 --- a/tutorials/viewports/using_viewport_as_texture.rst +++ b/tutorials/viewports/using_viewport_as_texture.rst @@ -20,7 +20,7 @@ a :ref:`Camera `, a :ref:`light source `, a and applying a :ref:`Spatial Material ` to the mesh. The focus will be on using the :ref:`Viewport ` to dynamically create textures that can be applied to the mesh. -During the course of this tutorial, we'll cover the following topics: +In this tutorial, we'll cover the following topics: - How to use a :ref:`Viewport ` as a render texture - Mapping a texture to a sphere with equirectangular mapping @@ -285,7 +285,7 @@ alpha value, it gets drawn as a transparent object over the background. And sinc of the :ref:`Viewport ` is opaque, the ``alpha`` channel of the :ref:`Viewport Texture ` is ``1``, resulting in the planet texture being drawn with slightly fainter colors and a ``Roughness`` value of ``1`` everywhere. To correct this, we -go into the :ref:`Viewport ` and set "Transparent Bg" to on. Since we are now +go into the :ref:`Viewport ` and enable the "Transparent Bg" property. Since we are now rendering one transparent object on top of another, we want to enable ``blend_premul_alpha``: .. code-block:: glsl diff --git a/tutorials/viewports/viewports.rst b/tutorials/viewports/viewports.rst index 7d0f10fb3..742802648 100644 --- a/tutorials/viewports/viewports.rst +++ b/tutorials/viewports/viewports.rst @@ -108,7 +108,7 @@ Worlds For 3D, a :ref:`Viewport ` will contain a :ref:`World `. This is basically the universe that links physics and rendering together. -Spatial-base nodes will register using the :ref:`World ` of the closest +Spatial-based nodes will register using the :ref:`World ` of the closest :ref:`Viewport `. By default, newly created :ref:`Viewports ` do not contain a :ref:`World ` but use the same as their parent :ref:`Viewport ` (the root :ref:`Viewport ` always contains a :ref:`World `, which is the one objects are rendered to by default). A :ref:`World ` can @@ -140,8 +140,8 @@ following code: # Retrieve the captured Image using get_data(). var img = get_viewport().get_texture().get_data() - # Flip on the y axis. - # You can also set "V Flip" to true if not on the Root Viewport. + # Flip on the Y axis. + # You can also set "V Flip" to true if not on the root Viewport. img.flip_y() # Convert Image to ImageTexture. var tex = ImageTexture.new() @@ -237,7 +237,7 @@ and then selecting the :ref:`Viewport ` you want to use. .. image:: img/texturepath.png Every frame, the :ref:`Viewport `'s texture is cleared away with the default clear color (or a transparent -color if :ref:`Transparent BG` is set to ``true``). This can be changed by setting :ref:`Clear Mode` to Never or Next Frame. +color if :ref:`Transparent Bg` is set to ``true``). This can be changed by setting :ref:`Clear Mode` to Never or Next Frame. As the name implies, Never means the texture will never be cleared, while next frame will clear the texture on the next frame and then set itself to Never. 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 c1fa12ecb..bbd66ecf1 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 @@ -193,7 +193,7 @@ Creating the controllers .. image:: img/starter_vr_tutorial_hands.png Right now all that the VR user can do is stand around, which isn't really what we are going for unless we are working on a VR film. Lets write the code for the -VR controllers. We are going to write all of the code for the VR controllers in one go, so the code is rather long. That said, once we are finished you will be +VR controllers. We are going to write all the code for the VR controllers in one go, so the code is rather long. That said, once we are finished you will be able to teleport around the scene, artificially move using the touchpad/joystick on the VR controller, and be able to pick up, drop, and throw :ref:`RigidBody `-based nodes. @@ -244,7 +244,7 @@ the same script, so it doesn't matter which you use first. With ``VR_Controller. .. tip:: You can copy and paste the code from this page directly into the script editor. - If you do this, all of the code copied will be using spaces instead of tabs. + If you do this, all the code copied will be using spaces instead of tabs. To convert the spaces to tabs in the script editor, click the ``Edit`` menu and select ``Convert Indent To Tabs``. This will convert all the spaces into tabs. You can select ``Convert Indent To Spaces`` to convert tabs back into spaces. @@ -542,7 +542,7 @@ This is quite a bit of code to go through. Let's go through what the code does s Explaining the VR controller code ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -First, let's go through all of the class variables in the script: +First, let's go through all the class variables in the script: * ``controller_velocity``: A variable to hold a rough approximation of the VR controller's velocity. * ``prior_controller_position``: A variable to hold the VR controller's last position in 3D space. @@ -653,7 +653,7 @@ This section of code will keep the held object in the same position and rotation _________________ -Finally, the last section of code simply calls the ``_physics_process_directional_movement`` function. This function contains all of the code for moving the player when the +Finally, the last section of code simply calls the ``_physics_process_directional_movement`` function. This function contains all the code for moving the player when the touchpad/joystick on the VR controller moves. 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 bd2a38136..53bc66d14 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 @@ -81,7 +81,7 @@ Let's go over how this script works. Explaining the Sphere Target code ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -First, let's go through all of the class variables in the script: +First, let's go through all the class variables in the script: * ``destroyed``: A variable to track whether the sphere target has been destroyed. * ``destroyed_timer``: A variable to track how long the sphere target has been destroyed. @@ -98,7 +98,7 @@ First, let's go through all of the class variables in the script: """""""""""""""""""""""""""""""""""""""""""" All the ``_ready`` function does is that it stops the ``_physics_process`` from being called by calling ``set_physics_process`` and passing ``false``. -The reason we do this is because all of the code in ``_physics_process`` is for destroying this node when enough time has passed, which we only want to +The reason we do this is because all the code in ``_physics_process`` is for destroying this node when enough time has passed, which we only want to do when the target has been destroyed. @@ -1033,4 +1033,3 @@ help serve as an introduction to making fully-featured VR games in Godot! The co story-based games, and more! .. warning:: You can download the finished project for this tutorial series on the `OpenVR GitHub repository `_, under the releases tab! -