Standardize RST header syntax

tutorials/performance/cpu_optimization.rst

@@ -168,7 +168,7 @@ language you choose. If your project is making a lot of calculations in its own
 code, consider moving those calculations to a faster language.
 
 GDScript
-^^^^^^^^
+~~~~~~~~
 
 :ref:`GDScript <toc-learn-scripting-gdscript>` is designed to be easy to use and iterate,
 and is ideal for making many types of games. However, in this language, ease of
@@ -177,7 +177,7 @@ calculations, consider moving some of your project to one of the other
 languages.
 
 C#
-^^
+~~
 
 :ref:`C# <toc-learn-scripting-C#>` is popular and has first-class support in Godot. It
 offers a good compromise between speed and ease of use. Beware of possible
@@ -186,13 +186,13 @@ common approach to workaround issues with garbage collection is to use *object
 pooling*, which is outside the scope of this guide.
 
 Other languages
-^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~
 
 Third parties provide support for several other languages, including `Rust
 <https://github.com/godot-rust/gdext>`_.
 
 C++
-^^^
+~~~
 
 Godot is written in C++. Using C++ will usually result in the fastest code.
 However, on a practical level, it is the most difficult to deploy to end users'

tutorials/performance/general_optimization.rst

@@ -23,7 +23,7 @@ To achieve the best results, we have two approaches:
 And preferably, we will use a blend of the two.
 
 Smoke and mirrors
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 Part of working smarter is recognizing that, in games, we can often get the
 player to believe they're in a world that is far more complex, interactive, and
@@ -31,7 +31,7 @@ graphically exciting than it really is. A good programmer is a magician, and
 should strive to learn the tricks of the trade while trying to invent new ones.
 
 The nature of slowness
-^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~
 
 To the outside observer, performance problems are often lumped together.
 But in reality, there are several different kinds of performance problems:
@@ -73,7 +73,7 @@ different hardware. It's often a good idea to measure timings on more than one
 device. This is especially the case if you're targeting mobile devices.
 
 Limitations
-^^^^^^^^^^^
+~~~~~~~~~~~
 
 CPU profilers are often the go-to method for measuring performance. However,
 they don't always tell the whole story.
@@ -98,7 +98,7 @@ and also in terms of bug fixing). This can include hypothesis testing, and
 binary search.
 
 Hypothesis testing
-^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~
 
 Say, for example, that you believe sprites are slowing down your game.
 You can test this hypothesis by:
@@ -112,7 +112,7 @@ the performance drop?
   size, and measuring performance.
 
 Binary search
-^^^^^^^^^^^^^
+~~~~~~~~~~~~~
 
 If you know that frames are taking much longer than they should, but you're
 not sure where the bottleneck lies. You could begin by commenting out
@@ -167,7 +167,7 @@ optimization is (by definition) undesirable, performant software is the result
 of performant design.
 
 Performant design
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 The danger with encouraging people to ignore optimization until necessary, is
 that it conveniently ignores that the most important time to consider
@@ -182,7 +182,7 @@ will often run many times faster than a mediocre design with low-level
 optimization.
 
 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
@@ -199,7 +199,7 @@ structures and algorithms for *cache locality* of data and linear access, rather
 than jumping around in memory.
 
 The optimization process
-^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 Assuming we have a reasonable design, and taking our lessons from Knuth, our
 first step in optimization should be to identify the biggest bottlenecks - the
@@ -216,7 +216,7 @@ The process is thus:
 3. Return to step 1.
 
 Optimizing bottlenecks
-^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~
 
 Some profilers will even tell you which part of a function (which data accesses,
 calculations) are slowing things down.
@@ -244,7 +244,7 @@ Appendix
 --------
 
 Bottleneck math
-^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~
 
 The proverb *"a chain is only as strong as its weakest link"* applies directly to
 performance optimization. If your project is spending 90% of the time in

tutorials/performance/gpu_optimization.rst

@@ -42,7 +42,7 @@ as much as possible so they can be rendered together, or with the minimum number
 of these expensive state changes.
 
 2D batching
-^^^^^^^^^^^
+~~~~~~~~~~~
 
 In 2D, the costs of treating each item individually can be prohibitively high -
 there can easily be thousands of them on the screen. This is why 2D *batching*
@@ -56,7 +56,7 @@ much cheaper with Vulkan compared to OpenGL, there is less of a need to have 2D
 batching (although it can still be beneficial in some cases).
 
 3D batching
-^^^^^^^^^^^
+~~~~~~~~~~~
 
 In 3D, we still aim to minimize draw calls and state changes. However, it can be
 more difficult to batch together several objects into a single draw call. 3D
@@ -78,7 +78,7 @@ For more information on 3D specific optimizations, see
 :ref:`doc_optimizing_3d_performance`.
 
 Reuse shaders and materials
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The Godot renderer is a little different to what is out there. It's designed to
 minimize GPU state changes as much as possible. :ref:`StandardMaterial3D
@@ -192,7 +192,7 @@ their material to decrease the shading cost.
 you can reasonably afford to use.**
 
 Reading textures
-^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~
 
 The other factor in fragment shaders is the cost of reading textures. Reading
 textures is an expensive operation, especially when reading from several
@@ -205,7 +205,7 @@ mobiles.
 algorithms that require as few texture reads as possible.**
 
 Texture compression
-^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~
 
 By default, Godot compresses textures of 3D models when imported using video RAM
 (VRAM) compression. Video RAM compression isn't as efficient in size as PNG or
@@ -230,7 +230,7 @@ textures with transparency (only opaque), so keep this in mind.
    significantly due to their low resolution.
 
 Post-processing and shadows
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Post-processing effects and shadows can also be expensive in terms of fragment
 shading activity. Always test the impact of these on different hardware.

tutorials/performance/optimizing_3d_performance.rst

@@ -15,7 +15,7 @@ take place in a small area, however things can quickly become problematic in
 larger levels.
 
 Occlusion culling
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 Walking around a town for example, you may only be able to see a few buildings
 in the street you are in, as well as the sky and a few birds flying overhead. As
@@ -85,7 +85,7 @@ Visibility ranges are also a good way to set up *impostors* for distant geometry
 (see below).
 
 Billboards and imposters
-^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 The simplest version of using transparency to deal with LOD is billboards. For
 example, you can use a single transparent quad to represent a tree at distance.
@@ -105,7 +105,7 @@ significantly. This can be complex to get working, but may be worth it depending
 on the type of project you are making.
 
 Use instancing (MultiMesh)
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If several identical objects have to be drawn in the same place or nearby, try
 using :ref:`MultiMesh <class_MultiMesh>` instead. MultiMesh allows the drawing