From 93489bbefbeb7e5d5fba95b284e9d748144c7529 Mon Sep 17 00:00:00 2001 From: tetrapod00 <145553014+tetrapod00@users.noreply.github.com> Date: Mon, 18 Nov 2024 13:47:58 -0800 Subject: [PATCH] Use "low-level" and "high-level" instead of "low level" and "high level" Co-Authored-By: John Veness <2512915+JohnVeness@users.noreply.github.com> --- .../best_practices_for_engine_contributors.rst | 2 +- contributing/workflow/bug_triage_guidelines.rst | 2 +- tutorials/2d/2d_transforms.rst | 2 +- tutorials/2d/custom_drawing_in_2d.rst | 4 ++-- tutorials/export/exporting_for_web.rst | 4 ++-- tutorials/networking/high_level_multiplayer.rst | 2 +- tutorials/networking/websocket.rst | 10 ++++++++-- tutorials/performance/using_servers.rst | 4 ++-- tutorials/physics/ray-casting.rst | 4 ++-- tutorials/scripting/scene_tree.rst | 6 +++--- 10 files changed, 23 insertions(+), 17 deletions(-) diff --git a/contributing/development/best_practices_for_engine_contributors.rst b/contributing/development/best_practices_for_engine_contributors.rst index b0dd1de56..7ac729986 100644 --- a/contributing/development/best_practices_for_engine_contributors.rst +++ b/contributing/development/best_practices_for_engine_contributors.rst @@ -179,7 +179,7 @@ they'll need to do* in the future? .. 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 +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. diff --git a/contributing/workflow/bug_triage_guidelines.rst b/contributing/workflow/bug_triage_guidelines.rst index ae4a5776b..370ef628c 100644 --- a/contributing/workflow/bug_triage_guidelines.rst +++ b/contributing/workflow/bug_triage_guidelines.rst @@ -114,7 +114,7 @@ describe an issue or pull request. - *3D*: relates to 3D-specific issues. Should be coupled with one of the labels below, and should not be coupled with *2D*. - *Animation*: relates to the Animation system, editors and importers. - *Assetlib*: relates to issues with the asset library. -- *Audio*: relates to the audio features (low and high level). +- *Audio*: relates to the audio features (low- and high-level). - *Buildsystem*: relates to building issues, either linked to the SCons buildsystem or to compiler peculiarities. - *Codestyle*: relates to the programming style used within the codebase. diff --git a/tutorials/2d/2d_transforms.rst b/tutorials/2d/2d_transforms.rst index b8e8ccee8..7edbdd533 100644 --- a/tutorials/2d/2d_transforms.rst +++ b/tutorials/2d/2d_transforms.rst @@ -8,7 +8,7 @@ Introduction This is an overview of the 2D transforms going on for nodes from the moment they draw their content locally to the time they are drawn onto -the screen. This overview discusses very low level details of the engine. +the screen. This overview discusses very low-level details of the engine. The goal of this tutorial is to teach a way for feeding input events to the Input with a position in the correct coordinate system. diff --git a/tutorials/2d/custom_drawing_in_2d.rst b/tutorials/2d/custom_drawing_in_2d.rst index ccb39cff4..466ad8a26 100644 --- a/tutorials/2d/custom_drawing_in_2d.rst +++ b/tutorials/2d/custom_drawing_in_2d.rst @@ -613,7 +613,7 @@ Drawing text ^^^^^^^^^^^^ While using the :ref:`Label ` Node is the most common way to add -text to your application, the low level `_draw` function includes functionality +text to your application, the low-level `_draw` function includes functionality to add text to your custom Node drawing. We will use it to add the name "GODOT" under the robot head. @@ -844,7 +844,7 @@ It will look somewhat like this when run: Please note that ``_mouth_width`` is a user defined property like any other and it or any other used as a drawing argument can be animated using more -standard and high level methods such as a :ref:`Tween` or an +standard and high-level methods such as a :ref:`Tween` or an :ref:`AnimationPlayer` Node. The only difference is that a ``queue_redraw()`` call is needed to apply those changes so they get shown on screen. diff --git a/tutorials/export/exporting_for_web.rst b/tutorials/export/exporting_for_web.rst index 5744d7d4a..d260a2932 100644 --- a/tutorials/export/exporting_for_web.rst +++ b/tutorials/export/exporting_for_web.rst @@ -235,10 +235,10 @@ player to click, tap or press a key/button to enable audio, for instance when di Networking ~~~~~~~~~~ -.. UPDATE: Not implemented. When low level networking is implemented, remove +.. UPDATE: Not implemented. When low-level networking is implemented, remove .. this paragraph. -Low level networking is not implemented due to lacking support in browsers. +Low-level networking is not implemented due to lacking support in browsers. Currently, only :ref:`HTTP client `, :ref:`HTTP requests `, diff --git a/tutorials/networking/high_level_multiplayer.rst b/tutorials/networking/high_level_multiplayer.rst index 00dcd395c..a850f5710 100644 --- a/tutorials/networking/high_level_multiplayer.rst +++ b/tutorials/networking/high_level_multiplayer.rst @@ -97,7 +97,7 @@ for full IPv6 support. Initializing the network ------------------------ -High level networking in Godot is managed by the :ref:`SceneTree `. +High-level networking in Godot is managed by the :ref:`SceneTree `. Each node has a ``multiplayer`` property, which is a reference to the ``MultiplayerAPI`` instance configured for it by the scene tree. Initially, every node is configured with the same default ``MultiplayerAPI`` object. diff --git a/tutorials/networking/websocket.rst b/tutorials/networking/websocket.rst index 43ffdd1f7..548ce37de 100644 --- a/tutorials/networking/websocket.rst +++ b/tutorials/networking/websocket.rst @@ -20,7 +20,10 @@ Godot supports WebSocket in both native and HTML5 exports. Using WebSocket in Godot ------------------------ -WebSocket is implemented in Godot via :ref:`WebSocketPeer `. The WebSocket implementation is compatible with the High Level Multiplayer. See section on :ref:`high-level multiplayer ` for more details. +WebSocket is implemented in Godot via :ref:`WebSocketPeer `. +The WebSocket implementation is compatible with the High-Level Multiplayer. See +section on :ref:`high-level multiplayer ` for more +details. .. warning:: @@ -161,4 +164,7 @@ This will print (when a client connects) something similar to this: Advanced chat demo ^^^^^^^^^^^^^^^^^^ -A more advanced chat demo which optionally uses the multiplayer mid-level abstraction and a high level multiplayer demo are available in the `godot demo projects `_ under `networking/websocket_chat` and `networking/websocket_multiplayer`. +A more advanced chat demo which optionally uses the multiplayer mid-level +abstraction and a high-level multiplayer demo are available in the +`godot demo projects `_ +under `networking/websocket_chat` and `networking/websocket_multiplayer`. diff --git a/tutorials/performance/using_servers.rst b/tutorials/performance/using_servers.rst index bbe780cfa..54d9f153f 100644 --- a/tutorials/performance/using_servers.rst +++ b/tutorials/performance/using_servers.rst @@ -5,7 +5,7 @@ Optimization using Servers ========================== -Engines like Godot provide increased ease of use thanks to their high level constructs and features. +Engines like Godot provide increased ease of use thanks to their high-level constructs and features. Most of them are accessed and used via the :ref:`Scene System`. Using nodes and resources simplifies project organization and asset management in complex games. @@ -21,7 +21,7 @@ with signals, so no polling is required). Still, sometimes it can be. For exampl tens of thousands of instances for something that needs to be processed every frame can be a bottleneck. This type of situation makes programmers regret they are using a game engine and wish they could go -back to a more handcrafted, low level implementation of game code. +back to a more handcrafted, low-level implementation of game code. Still, Godot is designed to work around this problem. diff --git a/tutorials/physics/ray-casting.rst b/tutorials/physics/ray-casting.rst index 06f3a5e33..a9b716f8e 100644 --- a/tutorials/physics/ray-casting.rst +++ b/tutorials/physics/ray-casting.rst @@ -11,7 +11,7 @@ custom shaped object) and checking what it hits. This enables complex behaviors, AI, etc. to take place. This tutorial will explain how to do this in 2D and 3D. -Godot stores all the low level game information in servers, while the +Godot stores all the low-level game information in servers, while the scene is only a frontend. As such, ray casting is generally a lower-level task. For simple raycasts, nodes like :ref:`RayCast3D ` and :ref:`RayCast2D ` @@ -24,7 +24,7 @@ so a way to do this by code must exist. Space ----- -In the physics world, Godot stores all the low level collision and +In the physics world, Godot stores all the low-level collision and physics information in a *space*. The current 2d space (for 2D Physics) can be obtained by accessing :ref:`CanvasItem.get_world_2d().space `. diff --git a/tutorials/scripting/scene_tree.rst b/tutorials/scripting/scene_tree.rst index fca7183fe..8b1aad1e6 100644 --- a/tutorials/scripting/scene_tree.rst +++ b/tutorials/scripting/scene_tree.rst @@ -32,11 +32,11 @@ level and when making games in Godot, writing your own MainLoop seldom makes sen SceneTree --------- -One of the ways to explain how Godot works is that it's a high level -game engine over a low level middleware. +One of the ways to explain how Godot works is that it's a high-level +game engine over a low-level middleware. The scene system is the game engine, while the :ref:`OS ` -and servers are the low level API. +and servers are the low-level API. The scene system provides its own main loop to OS, :ref:`SceneTree `.