Merge branch 'master' into 3.2

tutorials/optimization/cpu_optimization.rst

@@ -6,12 +6,12 @@ CPU optimization
 Measuring performance
 =====================
 
-To know how to speed up our program, we have to know where the "bottlenecks"
-are. Bottlenecks are the slowest parts of the program that limit the rate that
-everything can progress. This allows us to concentrate our efforts on optimizing
-the areas which will give us the greatest speed improvement, instead of spending
-a lot of time optimizing functions that will lead to small performance
-improvements.
+We have to know where the "bottlenecks" are to know how to speed up our program.
+Bottlenecks are the slowest parts of the program that limit the rate that
+everything can progress. Focussing on bottlenecks allows us to concentrate our
+efforts on optimizing the areas which will give us the greatest speed
+improvement, instead of spending a lot of time optimizing functions that will
+lead to small performance improvements.
 
 For the CPU, the easiest way to identify bottlenecks is to use a profiler.
 
@@ -45,7 +45,8 @@ When a project is running slowly, you will often see an obvious function or
 process taking a lot more time than others. This is your primary bottleneck, and
 you can usually increase speed by optimizing this area.
 
-For more info about using Godot's built-in profiler, see :ref:`doc_debugger_panel`.
+For more info about using Godot's built-in profiler, see
+:ref:`doc_debugger_panel`.
 
 External profilers
 ~~~~~~~~~~~~~~~~~~

tutorials/optimization/general_optimization.rst

@@ -145,8 +145,8 @@ Principles
 The messages are very important:
 
 - Developer time is limited. Instead of blindly trying to speed up
-  all aspects of a program, we should concentrate our efforts on the aspects that
-  really matter.
+  all aspects of a program, we should concentrate our efforts on the aspects
+  that really matter.
 - Efforts at optimization often end up with code that is harder to read and
   debug than non-optimized code. It is in our interests to limit this to areas
   that will really benefit.
@@ -156,9 +156,9 @@ mean that we *should*. Knowing when and when not to optimize is a great skill to
 develop.
 
 One misleading aspect of the quote is that people tend to focus on the subquote
-*"premature optimization is the root of all evil"*. While *premature* optimization
-is (by definition) undesirable, performant software is the result of performant
-design.
+*"premature optimization is the root of all evil"*. While *premature*
+optimization is (by definition) undesirable, performant software is the result
+of performant design.
 
 Performant design
 ~~~~~~~~~~~~~~~~~
@@ -166,9 +166,9 @@ Performant design
 The danger with encouraging people to ignore optimization until necessary, is
 that it conveniently ignores that the most important time to consider
 performance is at the design stage, before a key has even hit a keyboard. If the
-design or algorithms of a program are inefficient, then no amount of polishing the
-details later will make it run fast. It may run *faster*, but it will never run
-as fast as a program designed for performance.
+design or algorithms of a program are inefficient, then no amount of polishing
+the details later will make it run fast. It may run *faster*, but it will never
+run as fast as a program designed for performance.
 
 This tends to be far more important in game or graphics programming than in
 general programming. A performant design, even without low-level optimization,
@@ -179,18 +179,18 @@ Incremental design
 ~~~~~~~~~~~~~~~~~~
 
 Of course, in practice, unless you have prior knowledge, you are unlikely to
-come up with the best design the first time. Instead, you'll often make a series of
-versions of a particular area of code, each taking a different approach to the
-problem, until you come to a satisfactory solution. It's important not to spend
-too much time on the details at this stage until you have finalized the overall
-design. Otherwise, much of your work will be thrown out.
+come up with the best design the first time. Instead, you'll often make a series
+of versions of a particular area of code, each taking a different approach to
+the problem, until you come to a satisfactory solution. It's important not to
+spend too much time on the details at this stage until you have finalized the
+overall design. Otherwise, much of your work will be thrown out.
 
 It's difficult to give general guidelines for performant design because this is
-so dependent on the problem. One point worth mentioning though, on the CPU
-side, is that modern CPUs are nearly always limited by memory bandwidth. This
-has led to a resurgence in data-oriented design, which involves designing data
-structures and algorithms for *cache locality* of data and linear access, rather than
-jumping around in memory.
+so dependent on the problem. One point worth mentioning though, on the CPU side,
+is that modern CPUs are nearly always limited by memory bandwidth. This has led
+to a resurgence in data-oriented design, which involves designing data
+structures and algorithms for *cache locality* of data and linear access, rather
+than jumping around in memory.
 
 The optimization process
 ~~~~~~~~~~~~~~~~~~~~~~~~

tutorials/optimization/gpu_optimization.rst

@@ -176,8 +176,8 @@ amount of work the GPU has to do. You can do this by simplifying the shader
 (perhaps turn off expensive options if you are using a :ref:`SpatialMaterial
 <class_SpatialMaterial>`), or reducing the number and size of textures used.
 
-**When targeting mobile devices, consider using the simplest possible shaders you
-can reasonably afford to use.**
+**When targeting mobile devices, consider using the simplest possible shaders
+you can reasonably afford to use.**
 
 Reading textures
 ~~~~~~~~~~~~~~~~

tutorials/optimization/index.rst

@@ -8,11 +8,11 @@ Godot follows a balanced performance philosophy. In the performance world,
 there are always trade-offs, which consist of trading speed for usability
 and flexibility. Some practical examples of this are:
 
--  Rendering objects efficiently in high amounts is easy, but when a
+-  Rendering large amounts of objects efficiently is easy, but when a
    large scene must be rendered, it can become inefficient. To solve this,
    visibility computation must be added to the rendering. This makes rendering
-   less efficient, but at the same time, fewer objects are rendered.
-   Therefore, the overall rendering efficiency is improved.
+   less efficient, but at the same time, fewer objects are rendered. Therefore,
+   the overall rendering efficiency is improved.
 
 -  Configuring the properties of every material for every object that
    needs to be rendered is also slow. To solve this, objects are sorted by
@@ -24,14 +24,14 @@ and flexibility. Some practical examples of this are:
    insertion and removal, as well as raycasting, will not be able to handle as
    many active objects.
 
-And there are many more examples of this! Game engines strive to be general-purpose
-in nature. Balanced algorithms are always favored over algorithms
-that might be fast in some situations and slow in others, or algorithms that are
-fast but are more difficult to use.
+And there are many more examples of this! Game engines strive to be
+general-purpose in nature. Balanced algorithms are always favored over
+algorithms that might be fast in some situations and slow in others, or
+algorithms that are fast but are more difficult to use.
 
-Godot is not an exception to this. While it is designed to have backends swappable
-for different algorithms, the default backends prioritize balance and flexibility
-over performance.
+Godot is not an exception to this. While it is designed to have backends
+swappable for different algorithms, the default backends prioritize balance and
+flexibility over performance.
 
 With this clear, the aim of this tutorial section is to explain how to get the
 maximum performance out of Godot. While the tutorials can be read in any order,