From 59943487646ca81d5578ba3724e1e3ee61b71260 Mon Sep 17 00:00:00 2001 From: tetrapod00 <145553014+tetrapod00@users.noreply.github.com> Date: Wed, 6 Nov 2024 19:49:08 -0800 Subject: [PATCH] Change all usages of "run-time" to "runtime" --- about/faq.rst | 2 +- about/list_of_features.rst | 12 ++++++------ .../common_engine_methods_and_macros.rst | 2 +- .../core_and_modules/custom_modules_in_cpp.rst | 2 +- .../core_and_modules/custom_platform_ports.rst | 4 ++-- .../internal_rendering_architecture.rst | 4 ++-- .../development/core_and_modules/unit_testing.rst | 4 ++-- getting_started/first_3d_game/index.rst | 2 +- .../introduction_to_global_illumination.rst | 4 ++-- .../3d/global_illumination/using_lightmap_gi.rst | 2 +- tutorials/3d/global_illumination/using_voxel_gi.rst | 2 +- tutorials/3d/lights_and_shadows.rst | 4 ++-- tutorials/3d/mesh_lod.rst | 2 +- tutorials/3d/occlusion_culling.rst | 4 ++-- tutorials/3d/resolution_scaling.rst | 4 ++-- .../assets_pipeline/importing_audio_samples.rst | 2 +- tutorials/export/feature_tags.rst | 4 ++-- tutorials/i18n/internationalizing_games.rst | 4 ++-- tutorials/inputs/inputevent.rst | 6 +++--- tutorials/migrating/upgrading_to_godot_4.1.rst | 2 +- tutorials/migrating/upgrading_to_godot_4.2.rst | 2 +- tutorials/migrating/upgrading_to_godot_4.3.rst | 2 +- tutorials/migrating/upgrading_to_godot_4.rst | 4 ++-- tutorials/performance/using_multiple_threads.rst | 2 +- tutorials/rendering/jitter_stutter.rst | 4 ++-- tutorials/rendering/multiple_resolutions.rst | 2 +- .../scripting/gdextension/what_is_gdextension.rst | 4 ++-- tutorials/scripting/gdscript/gdscript_advanced.rst | 2 +- .../shaders/shader_reference/shader_preprocessor.rst | 6 +++--- .../shaders/shader_reference/shading_language.rst | 10 +++++----- tutorials/ui/bbcode_in_richtextlabel.rst | 2 +- tutorials/ui/gui_using_fonts.rst | 2 +- 32 files changed, 57 insertions(+), 57 deletions(-) diff --git a/about/faq.rst b/about/faq.rst index 4f13dd46be7..3fe32cd979a 100644 --- a/about/faq.rst +++ b/about/faq.rst @@ -567,7 +567,7 @@ resulted in better usability while still being fast enough for most use cases. That said, nothing prevents you from making use of composition in your project by creating child Nodes with individual scripts. These nodes can then be added and -removed at run-time to dynamically add and remove behaviors. +removed at runtime to dynamically add and remove behaviors. More information about Godot's design choices can be found in `this article `__. diff --git a/about/list_of_features.rst b/about/list_of_features.rst index a9e55ed9e27..42453162858 100644 --- a/about/list_of_features.rst +++ b/about/list_of_features.rst @@ -239,7 +239,7 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods. **Global illumination with indirect lighting:** -- :ref:`Baked lightmaps ` (fast, but can't be updated at run-time). +- :ref:`Baked lightmaps ` (fast, but can't be updated at runtime). - Supports baking indirect light only or baking both direct and indirect lighting. The bake mode can be adjusted on a per-light basis to allow for hybrid light @@ -256,7 +256,7 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods. - :ref:`Voxel-based GI probes `. Supports dynamic lights *and* dynamic occluders, while also supporting reflections. Requires a fast baking step which can be performed in the editor or at - run-time (including from an exported project). + runtime (including from an exported project). - :ref:`Signed-distance field GI ` designed for large open worlds. Supports dynamic lights, but not dynamic occluders. Supports reflections. No baking required. @@ -290,7 +290,7 @@ See :ref:`doc_renderers` for a detailed comparison of the rendering methods. - Texture channels are smoothly overlaid on top of the underlying material, with support for normal/ORM-only decals. - Support for normal fade to fade the decal depending on its incidence angle. -- Does not rely on run-time mesh generation. This means decals can be used on +- Does not rely on runtime mesh generation. This means decals can be used on complex skinned meshes with no performance penalty, even if the decal moves every frame. - Support for nearest, bilinear, trilinear or anisotropic texture filtering (configured globally). - Optional distance fade system to fade distant decals, improving performance. @@ -407,7 +407,7 @@ improve quality. This can be helpful when - :ref:`3D geometry helper class `. - Support for exporting the current scene as a glTF 2.0 file, both from the editor - and at run-time from an exported project. + and at runtime from an exported project. 3D physics ---------- @@ -544,7 +544,7 @@ Import - Collada (.dae). - Wavefront OBJ (static scenes only, can be loaded directly as a mesh or imported as a 3D scene). -- Support for loading glTF 2.0 scenes at run-time, including from an exported project. +- Support for loading glTF 2.0 scenes at runtime, including from an exported project. - 3D meshes use `Mikktspace `__ to generate tangents on import, which ensures consistency with other 3D applications such as Blender. @@ -576,7 +576,7 @@ Navigation - A* algorithm in :ref:`2D ` and :ref:`3D `. - Navigation meshes with dynamic obstacle avoidance in :ref:`2D ` and :ref:`3D `. -- Generate navigation meshes from the editor or at run-time (including from an exported project). +- Generate navigation meshes from the editor or at runtime (including from an exported project). Networking ---------- diff --git a/contributing/development/core_and_modules/common_engine_methods_and_macros.rst b/contributing/development/core_and_modules/common_engine_methods_and_macros.rst index 0cbd4106c78..7754a40d136 100644 --- a/contributing/development/core_and_modules/common_engine_methods_and_macros.rst +++ b/contributing/development/core_and_modules/common_engine_methods_and_macros.rst @@ -85,7 +85,7 @@ There are two types of internationalization in Godot's codebase: editor. If a user uses the same text in one of their projects, it won't be translated if they provide a translation for it. When contributing to the engine, this is generally the macro you should use for localizable strings. -- ``RTR()``: **Run-time translations** will be automatically localized in +- ``RTR()``: **Runtime translations** will be automatically localized in projects if they provide a translation for the given string. This kind of translation shouldn't be used in editor-only code. diff --git a/contributing/development/core_and_modules/custom_modules_in_cpp.rst b/contributing/development/core_and_modules/custom_modules_in_cpp.rst index 31ba1ee77c7..14afdf5fac5 100644 --- a/contributing/development/core_and_modules/custom_modules_in_cpp.rst +++ b/contributing/development/core_and_modules/custom_modules_in_cpp.rst @@ -339,7 +339,7 @@ type registration methods: ScriptServer::init_languages(); Our ``Summator`` class is initialized during the ``register_module_types()`` -call. Imagine that we need to satisfy some common module run-time dependency +call. Imagine that we need to satisfy some common module runtime dependency (like singletons), or allow us to override existing engine method callbacks before they can be assigned by the engine itself. In that case, we want to ensure that our module classes are registered *before* any other built-in type. diff --git a/contributing/development/core_and_modules/custom_platform_ports.rst b/contributing/development/core_and_modules/custom_platform_ports.rst index 3c24193d234..5ff58bb607b 100644 --- a/contributing/development/core_and_modules/custom_platform_ports.rst +++ b/contributing/development/core_and_modules/custom_platform_ports.rst @@ -161,9 +161,9 @@ games. If the target platform doesn't support running Vulkan, Direct3D 12, OpenGL 3.3, or OpenGL ES 3.0, you have two options: -- Use a library at run-time to translate Vulkan or OpenGL calls to another graphics API. +- Use a library at runtime to translate Vulkan or OpenGL calls to another graphics API. For example, `MoltenVK `__ is used on macOS - to translate Vulkan to Metal at run-time. + to translate Vulkan to Metal at runtime. - Create a new renderer from scratch. This is a large undertaking, especially if you want to support both 2D and 3D rendering with advanced features. diff --git a/contributing/development/core_and_modules/internal_rendering_architecture.rst b/contributing/development/core_and_modules/internal_rendering_architecture.rst index b2c8e0b791d..8cd9905335a 100644 --- a/contributing/development/core_and_modules/internal_rendering_architecture.rst +++ b/contributing/development/core_and_modules/internal_rendering_architecture.rst @@ -744,7 +744,7 @@ This is done by rasterizing a low-resolution buffer on the CPU using `Embree `__. The buffer's resolution depends on the number of CPU threads on the system, as this is done in parallel. This buffer includes occluder shapes that were baked in the editor or created at -run-time. +runtime. As complex occluders can introduce a lot of strain on the CPU, baked occluders can be simplified automatically when generated in the editor. @@ -752,7 +752,7 @@ can be simplified automatically when generated in the editor. Godot's occlusion culling doesn't support dynamic occluders yet, but OccluderInstance3D nodes can still have their visibility toggled or be moved. However, this will be slow when updating complex occluders this way. Therefore, -updating occluders at run-time is best done only on simple occluder shapes such +updating occluders at runtime is best done only on simple occluder shapes such as quads or cuboids. This CPU-based approach has a few advantages over other solutions, such as diff --git a/contributing/development/core_and_modules/unit_testing.rst b/contributing/development/core_and_modules/unit_testing.rst index 0f705693d62..e9d94db7bd0 100644 --- a/contributing/development/core_and_modules/unit_testing.rst +++ b/contributing/development/core_and_modules/unit_testing.rst @@ -147,7 +147,7 @@ writing test cases themselves. Test cases are created using ``TEST_CASE`` function-like macro. Each test case must have a brief description written in parentheses, optionally including -custom tags which allow to filter the tests at run-time, such as ``[String]``, +custom tags which allow to filter the tests at runtime, such as ``[String]``, ``[Stress]`` etc. Test cases are written in a dedicated namespace. This is not required, but @@ -227,7 +227,7 @@ macros which allow to log test output in a format written by doctest. | ``FAIL`` | Fails the test immediately. Can be wrapped in conditionals for complex checks. | +----------------+-----------------------------------------------------------------------------------------------------------+ -Different reporters can be chosen at run-time. For instance, here's how the +Different reporters can be chosen at runtime. For instance, here's how the output can be redirected to an XML file: .. code-block:: shell diff --git a/getting_started/first_3d_game/index.rst b/getting_started/first_3d_game/index.rst index 05d7b04c7ff..dacb13543f4 100644 --- a/getting_started/first_3d_game/index.rst +++ b/getting_started/first_3d_game/index.rst @@ -24,7 +24,7 @@ You will learn to: - Use physics layers and a group to detect interactions with specific entities. - Code basic procedural gameplay by instancing monsters at regular time intervals. -- Design a movement animation and change its speed at run-time. +- Design a movement animation and change its speed at runtime. - Draw a user interface on a 3D game. And more. diff --git a/tutorials/3d/global_illumination/introduction_to_global_illumination.rst b/tutorials/3d/global_illumination/introduction_to_global_illumination.rst index 0e52cc3b529..d5b3b0b139f 100644 --- a/tutorials/3d/global_illumination/introduction_to_global_illumination.rst +++ b/tutorials/3d/global_illumination/introduction_to_global_illumination.rst @@ -272,7 +272,7 @@ Real-time ability - **LightmapGI:** |bad| Baked, and therefore not real-time. - Both indirect lighting and SH reflections are baked and can't be changed at - run-time. Real-time GI must be + runtime. Real-time GI must be :ref:`simulated via other means `, such as real-time positional lights. Dynamic objects receive indirect lighting via light probes, which can be placed automatically or manually by the user @@ -286,7 +286,7 @@ Real-time ability is set to **Always** (which is expensive). - Indirect lighting must be configured manually by the user, but can be changed - at run-time without causing an expensive computation to happen behind the scenes. + at runtime without causing an expensive computation to happen behind the scenes. This makes ReflectionProbes viable for procedurally generated levels. User work needed diff --git a/tutorials/3d/global_illumination/using_lightmap_gi.rst b/tutorials/3d/global_illumination/using_lightmap_gi.rst index e25b4624f3c..c6aaa0816e0 100644 --- a/tutorials/3d/global_illumination/using_lightmap_gi.rst +++ b/tutorials/3d/global_illumination/using_lightmap_gi.rst @@ -6,7 +6,7 @@ Using Lightmap global illumination Baked lightmaps are a workflow for adding indirect (or fully baked) lighting to a scene. Unlike the :ref:`VoxelGI ` and :ref:`SDFGI ` approaches, baked lightmaps work fine on low-end PCs -and mobile devices, as they consume almost no resources at run-time. Also unlike +and mobile devices, as they consume almost no resources at runtime. Also unlike VoxelGI and SDFGI, baked lightmaps can optionally be used to store direct lighting, which provides even further performance gains. diff --git a/tutorials/3d/global_illumination/using_voxel_gi.rst b/tutorials/3d/global_illumination/using_voxel_gi.rst index 7f7b6ce4ce2..30be7cdf530 100644 --- a/tutorials/3d/global_illumination/using_voxel_gi.rst +++ b/tutorials/3d/global_illumination/using_voxel_gi.rst @@ -81,7 +81,7 @@ contained within a VoxelGI node after it has been baked: If in doubt, leave this unchanged. - **Energy:** The indirect lighting's overall energy. This also effects the energy of direct lighting emitted by meshes with emissive materials. -- **Bias:** Optional bias added to lookups into the voxel buffer at run time. +- **Bias:** Optional bias added to lookups into the voxel buffer at runtime. This helps avoid self-occlusion artifacts. - **Normal Bias:** Similar to **Bias**, but offsets the lookup into the voxel buffer by the surface normal. This also helps avoid self-occlusion artifacts. Higher diff --git a/tutorials/3d/lights_and_shadows.rst b/tutorials/3d/lights_and_shadows.rst index 32e89106228..437073a074d 100644 --- a/tutorials/3d/lights_and_shadows.rst +++ b/tutorials/3d/lights_and_shadows.rst @@ -431,10 +431,10 @@ Balancing performance and quality Shadow rendering is a critical topic in 3D rendering performance. It's important to make the right choices here to avoid creating bottlenecks. -Directional shadow quality settings can be changed at run-time by calling the +Directional shadow quality settings can be changed at runtime by calling the appropriate :ref:`class_RenderingServer` methods. -Positional (omni/spot) shadow quality settings can be changed at run-time on the +Positional (omni/spot) shadow quality settings can be changed at runtime on the root :ref:`class_Viewport`. Shadow map size diff --git a/tutorials/3d/mesh_lod.rst b/tutorials/3d/mesh_lod.rst index 6fd3d71cd9d..c2758b9e2e4 100644 --- a/tutorials/3d/mesh_lod.rst +++ b/tutorials/3d/mesh_lod.rst @@ -135,7 +135,7 @@ Configuring mesh LOD performance and quality You can adjust how aggressive mesh LOD transitions should be in the root viewport by changing the **Rendering > Mesh LOD > LOD Change > Threshold Pixels** project -setting. To change this value at run-time, set ``mesh_lod_threshold`` on the +setting. To change this value at runtime, set ``mesh_lod_threshold`` on the root viewport as follows: .. tabs:: diff --git a/tutorials/3d/occlusion_culling.rst b/tutorials/3d/occlusion_culling.rst index d5e97098fb5..df1e709a138 100644 --- a/tutorials/3d/occlusion_culling.rst +++ b/tutorials/3d/occlusion_culling.rst @@ -192,7 +192,7 @@ your scene. Note that the performance benefit highly depends on the 3D editor camera's view angle, as occlusion culling is only effective if there are occluders in front of the camera. -To toggle occlusion culling at run-time, set ``use_occlusion_culling`` on the +To toggle occlusion culling at runtime, set ``use_occlusion_culling`` on the root viewport as follows: .. tabs:: @@ -205,7 +205,7 @@ root viewport as follows: GetTree().Root.UseOcclusionCulling = true; -Toggling occlusion culling at run-time is useful to compare performance on a +Toggling occlusion culling at runtime is useful to compare performance on a running project. Performance considerations diff --git a/tutorials/3d/resolution_scaling.rst b/tutorials/3d/resolution_scaling.rst index 67fc6d439db..a34281cd9c1 100644 --- a/tutorials/3d/resolution_scaling.rst +++ b/tutorials/3d/resolution_scaling.rst @@ -93,7 +93,7 @@ The **Rendering > Scaling 3D > Scale** setting adjusts the resolution scale. matching the 2D rendering resolution. Resolution scales *below* ``1.0`` can be used to speed up rendering, at the cost of a blurrier final image and more aliasing. -The rendering scale can be adjusted at run-time by changing the ``scaling_3d_scale`` +The rendering scale can be adjusted at runtime by changing the ``scaling_3d_scale`` property on a :ref:`class_Viewport` node. Resolution scales *above* ``1.0`` can be used for supersample antialiasing @@ -234,7 +234,7 @@ not change depending on resolution scale. The texture LOD bias can manually be changed by adjusting the **Rendering > Textures > Default Filters > Texture Mipmap Bias** advanced project setting. It -can also be changed at run-time on :ref:`Viewports ` by +can also be changed at runtime on :ref:`Viewports ` by adjusting the ``texture_mipmap_bias`` property. .. warning:: diff --git a/tutorials/assets_pipeline/importing_audio_samples.rst b/tutorials/assets_pipeline/importing_audio_samples.rst index aeb54641e80..5470cb4ee90 100644 --- a/tutorials/assets_pipeline/importing_audio_samples.rst +++ b/tutorials/assets_pipeline/importing_audio_samples.rst @@ -286,7 +286,7 @@ sample rate and number of channels for your audio: - There's no *audible* benefit to using 24-bit audio, especially in a game where several sounds are often playing at the same time (which makes it harder to appreciate individual sounds). -- Unless you are slowing down the audio at run-time, there's no *audible* +- Unless you are slowing down the audio at runtime, there's no *audible* benefit to using a sample rate greater than 48 kHz. If you wish to keep a source with a higher sample rate for editing, use the **Force > Max Rate** import option to limit the sample rate of the imported sound (only available diff --git a/tutorials/export/feature_tags.rst b/tutorials/export/feature_tags.rst index 9ce3dfd8ed3..4f42e1a213c 100644 --- a/tutorials/export/feature_tags.rst +++ b/tutorials/export/feature_tags.rst @@ -17,7 +17,7 @@ Each *feature* is represented as a string, which can refer to many of the follow * Whether the project is running from the editor or a "standalone" binary. * Many more things. -Features can be queried at run-time from the singleton API by calling: +Features can be queried at runtime from the singleton API by calling: .. tabs:: .. code-tab:: gdscript @@ -127,7 +127,7 @@ Here is a list of most feature tags in Godot. Keep in mind they are **case-sensi With the exception of texture compression, ``web_`` and ``movie`` feature tags, default feature tags are **immutable**. - This means that they will *not* change depending on run-time conditions. + This means that they will *not* change depending on runtime conditions. For example, ``OS.has_feature("mobile")`` will return ``false`` when running a project exported to Web on a mobile device. diff --git a/tutorials/i18n/internationalizing_games.rst b/tutorials/i18n/internationalizing_games.rst index afffbd0a1e0..6267ba0e153 100644 --- a/tutorials/i18n/internationalizing_games.rst +++ b/tutorials/i18n/internationalizing_games.rst @@ -233,8 +233,8 @@ TranslationServer Godot has a server handling low-level translation management called the :ref:`TranslationServer `. -Translations can be added or removed during run-time; -the current language can also be changed at run-time. +Translations can be added or removed during runtime; +the current language can also be changed at runtime. .. _doc_internationalizing_games_bidi: diff --git a/tutorials/inputs/inputevent.rst b/tutorials/inputs/inputevent.rst index 1116a902549..8090aae7276 100644 --- a/tutorials/inputs/inputevent.rst +++ b/tutorials/inputs/inputevent.rst @@ -206,8 +206,8 @@ This allows for: - The same code to work on different devices with different inputs (e.g., keyboard on PC, Joypad on console). -- Input to be reconfigured at run-time. -- Actions to be triggered programmatically at run-time. +- Input to be reconfigured at runtime. +- Actions to be triggered programmatically at runtime. Actions can be created from the Project Settings menu in the **Input Map** tab and assigned input events. @@ -250,7 +250,7 @@ InputMap Customizing and re-mapping input from code is often desired. If your whole workflow depends on actions, the :ref:`InputMap ` singleton is -ideal for reassigning or creating different actions at run-time. This +ideal for reassigning or creating different actions at runtime. This singleton is not saved (must be modified manually) and its state is run from the project settings (project.godot). So any dynamic system of this type needs to store settings in the way the programmer best sees fit. diff --git a/tutorials/migrating/upgrading_to_godot_4.1.rst b/tutorials/migrating/upgrading_to_godot_4.1.rst index d490b02c75b..f23f558a5a5 100644 --- a/tutorials/migrating/upgrading_to_godot_4.1.rst +++ b/tutorials/migrating/upgrading_to_godot_4.1.rst @@ -23,7 +23,7 @@ This article indicates whether each breaking change affects GDScript and whether the C# breaking change is *binary compatible* or *source compatible*: - **Binary compatible** - Existing binaries will load and execute successfully without - recompilation, and the run-time behavior won't change. + recompilation, and the runtime behavior won't change. - **Source compatible** - Source code will compile successfully without changes when upgrading Godot. diff --git a/tutorials/migrating/upgrading_to_godot_4.2.rst b/tutorials/migrating/upgrading_to_godot_4.2.rst index 158495db370..80e17a1eab3 100644 --- a/tutorials/migrating/upgrading_to_godot_4.2.rst +++ b/tutorials/migrating/upgrading_to_godot_4.2.rst @@ -44,7 +44,7 @@ This article indicates whether each breaking change affects GDScript and whether the C# breaking change is *binary compatible* or *source compatible*: - **Binary compatible** - Existing binaries will load and execute successfully without - recompilation, and the run-time behavior won't change. + recompilation, and the runtime behavior won't change. - **Source compatible** - Source code will compile successfully without changes when upgrading Godot. diff --git a/tutorials/migrating/upgrading_to_godot_4.3.rst b/tutorials/migrating/upgrading_to_godot_4.3.rst index fb1cbb46e72..fa13a25d594 100644 --- a/tutorials/migrating/upgrading_to_godot_4.3.rst +++ b/tutorials/migrating/upgrading_to_godot_4.3.rst @@ -17,7 +17,7 @@ This article indicates whether each breaking change affects GDScript and whether the C# breaking change is *binary compatible* or *source compatible*: - **Binary compatible** - Existing binaries will load and execute successfully without - recompilation, and the run-time behavior won't change. + recompilation, and the runtime behavior won't change. - **Source compatible** - Source code will compile successfully without changes when upgrading Godot. diff --git a/tutorials/migrating/upgrading_to_godot_4.rst b/tutorials/migrating/upgrading_to_godot_4.rst index 57f7b99f7dc..d0bda16bcbb 100644 --- a/tutorials/migrating/upgrading_to_godot_4.rst +++ b/tutorials/migrating/upgrading_to_godot_4.rst @@ -494,7 +494,7 @@ Checking Environment settings ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Graphics quality settings were moved from Environment properties to project -settings. This was done to make run-time quality adjustments easier, without +settings. This was done to make runtime quality adjustments easier, without having to access the currently active Environment resource then modify its properties. @@ -569,7 +569,7 @@ The most notable examples of this are: The conversion tool will use the string-based syntax which is still present in Godot 4, but it's recommended to switch to the :ref:`class_Signal`-based syntax described on the linked page. This way, strings are no longer involved, - which avoids issues with signal name errors that can only be discovered at run-time. + which avoids issues with signal name errors that can only be discovered at runtime. - Built-in scripts that are :ref:`tool scripts ` do not get the ``tool`` keyword converted to the ``@tool`` annotation. - The Tween node was removed in favor of Tweeners, which are also available in diff --git a/tutorials/performance/using_multiple_threads.rst b/tutorials/performance/using_multiple_threads.rst index 8ee122ce03e..2382d0b748f 100644 --- a/tutorials/performance/using_multiple_threads.rst +++ b/tutorials/performance/using_multiple_threads.rst @@ -54,7 +54,7 @@ wait until the thread is done (if not done yet), then properly dispose of it. .. warning:: - Creating threads at run-time is slow on Windows and should be avoided to + Creating threads at runtime is slow on Windows and should be avoided to prevent stuttering. Semaphores, explained later on this page, should be used instead. diff --git a/tutorials/rendering/jitter_stutter.rst b/tutorials/rendering/jitter_stutter.rst index 0f1f10dd188..42c81db9437 100644 --- a/tutorials/rendering/jitter_stutter.rst +++ b/tutorials/rendering/jitter_stutter.rst @@ -174,7 +174,7 @@ Increasing the number of physics iterations per second can also reduce physics-induced input latency. This is especially noticeable when using physics interpolation (which improves smoothness but increases latency). To do so, set **Physics > Common > Physics Ticks Per Second** to a value higher than the -default ``60``, or set ``Engine.physics_ticks_per_second`` at run-time in a +default ``60``, or set ``Engine.physics_ticks_per_second`` at runtime in a script. Values that are a multiple of the monitor refresh rate (typically ``60``) work best when physics interpolation is disabled, as they will avoid jitter. This means values such as ``120``, ``180`` and ``240`` are good starting @@ -220,7 +220,7 @@ the same framerate cap (usually less than 1 ms greater), but without any tearing. This can be done by changing the **Application > Run > Max FPS** project -setting or assigning ``Engine.max_fps`` at run-time in a script. +setting or assigning ``Engine.max_fps`` at runtime in a script. On some platforms, you can also opt into a low-latency mode in the graphics driver options (such as the NVIDIA Control Panel on Windows). The **Ultra** diff --git a/tutorials/rendering/multiple_resolutions.rst b/tutorials/rendering/multiple_resolutions.rst index f44db43fa5e..34b393abf9d 100644 --- a/tutorials/rendering/multiple_resolutions.rst +++ b/tutorials/rendering/multiple_resolutions.rst @@ -247,7 +247,7 @@ to the region outside the blue frame you see in the 2D editor. landscape mode, use 720×720 as the project's base window size in the Project Settings. - To allow the user to choose their preferred screen orientation at run-time, + To allow the user to choose their preferred screen orientation at runtime, remember to set **Display > Window > Handheld > Orientation** to ``sensor``. To configure the stretch aspect at runtime from a script, use the diff --git a/tutorials/scripting/gdextension/what_is_gdextension.rst b/tutorials/scripting/gdextension/what_is_gdextension.rst index 48732c58f27..f918d9046fe 100644 --- a/tutorials/scripting/gdextension/what_is_gdextension.rst +++ b/tutorials/scripting/gdextension/what_is_gdextension.rst @@ -8,7 +8,7 @@ Introduction **GDExtension** is a Godot-specific technology that lets the engine interact with native `shared libraries `__ -at run-time. You can use it to run native code without compiling it with the engine. +at runtime. You can use it to run native code without compiling it with the engine. .. note:: GDExtension is *not* a scripting language and has no relation to :ref:`GDScript `. @@ -50,7 +50,7 @@ Also: languages. - You can use the same compiled GDExtension library in the editor and exported project. With C++ modules, you have to recompile all the export templates you - plan to use if you require its functionality at run-time. + plan to use if you require its functionality at runtime. - GDExtension only requires you to compile your library, not the whole engine. That's unlike C++ modules, which are statically compiled into the engine. Every time you change a module, you need to recompile the engine. Even with diff --git a/tutorials/scripting/gdscript/gdscript_advanced.rst b/tutorials/scripting/gdscript/gdscript_advanced.rst index 6db90d18e17..01d443c8e04 100644 --- a/tutorials/scripting/gdscript/gdscript_advanced.rst +++ b/tutorials/scripting/gdscript/gdscript_advanced.rst @@ -38,7 +38,7 @@ While the main disadvantages are: 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). + known at runtime). 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 diff --git a/tutorials/shaders/shader_reference/shader_preprocessor.rst b/tutorials/shaders/shader_reference/shader_preprocessor.rst index 05f3af1a585..ea370edd348 100644 --- a/tutorials/shaders/shader_reference/shader_preprocessor.rst +++ b/tutorials/shaders/shader_reference/shader_preprocessor.rst @@ -191,11 +191,11 @@ Be careful, as ``defined()`` must only wrap a single identifier within parenthes In the shader editor, preprocessor branches that evaluate to ``false`` (and are therefore excluded from the final compiled shader) will appear grayed - out. This does not apply to run-time ``if`` statements. + out. This does not apply to runtime ``if`` statements. **#if preprocessor versus if statement: Performance caveats** -The :ref:`shading language ` supports run-time ``if`` statements: +The :ref:`shading language ` supports runtime ``if`` statements: .. code-block:: glsl @@ -221,7 +221,7 @@ of the ``#if`` preprocessor statement: #endif However, the ``#if`` variant can be faster in certain scenarios. This is because -all run-time branches in a shader are still compiled and variables within +all runtime branches in a shader are still compiled and variables within those branches may still take up register space, even if they are never run in practice. diff --git a/tutorials/shaders/shader_reference/shading_language.rst b/tutorials/shaders/shader_reference/shading_language.rst index c03a9073c24..17e68faa51e 100644 --- a/tutorials/shaders/shader_reference/shading_language.rst +++ b/tutorials/shaders/shader_reference/shading_language.rst @@ -1059,7 +1059,7 @@ value using ``global uniform vec4 my_color = ...`` in the shader code, it will be ignored as the global uniform must always be defined in the Project Settings anyway. -To change the value of a global uniform at run-time, use the +To change the value of a global uniform at runtime, use the :ref:`RenderingServer.global_shader_parameter_set ` method in a script: @@ -1071,20 +1071,20 @@ Assigning global uniform values can be done as many times as desired without impacting performance, as setting data doesn't require synchronization between the CPU and GPU. -You can also add or remove global uniforms at run-time: +You can also add or remove global uniforms at runtime: .. code-block:: gdscript RenderingServer.global_shader_parameter_add("my_color", RenderingServer.GLOBAL_VAR_TYPE_COLOR, Color(0.3, 0.6, 1.0)) RenderingServer.global_shader_parameter_remove("my_color") -Adding or removing global uniforms at run-time has a performance cost, although +Adding or removing global uniforms at runtime has a performance cost, although it's not as pronounced compared to getting global uniform values from a script (see the warning below). .. warning:: - While you *can* query the value of a global uniform at run-time in a script + While you *can* query the value of a global uniform at runtime in a script using ``RenderingServer.global_shader_parameter_get("uniform_name")``, this has a large performance penalty as the rendering thread needs to synchronize with the calling thread. @@ -1138,7 +1138,7 @@ the inspector: Setting a per-instance uniform's value in the GeometryInstance3D section of the inspector -Per-instance uniform values can also be set at run-time using +Per-instance uniform values can also be set at runtime using :ref:`set_instance_shader_parameter ` method on a node that inherits from :ref:`class_GeometryInstance3D`: diff --git a/tutorials/ui/bbcode_in_richtextlabel.rst b/tutorials/ui/bbcode_in_richtextlabel.rst index 6b40540d46c..24b1a4c93c1 100644 --- a/tutorials/ui/bbcode_in_richtextlabel.rst +++ b/tutorials/ui/bbcode_in_richtextlabel.rst @@ -566,7 +566,7 @@ clicked URLs using the user's default web browser:: # the function below using the signal connection dialog. func _richtextlabel_on_meta_clicked(meta): # `meta` is not guaranteed to be a String, so convert it to a String - # to avoid script errors at run-time. + # to avoid script errors at runtime. OS.shell_open(str(meta)) For more advanced use cases, it's also possible to store JSON in an ``[url]`` diff --git a/tutorials/ui/gui_using_fonts.rst b/tutorials/ui/gui_using_fonts.rst index 5da7ea2a249..0c881225b80 100644 --- a/tutorials/ui/gui_using_fonts.rst +++ b/tutorials/ui/gui_using_fonts.rst @@ -750,7 +750,7 @@ System fonts in non-functional system font loading. System fonts are a different type of resource compared to imported fonts. They -are never actually imported into the project, but are loaded at run-time. This +are never actually imported into the project, but are loaded at runtime. This has 2 benefits: - The fonts are not included within the exported PCK file, leading to a smaller