Remove references to removed GLES2 backend

- Update FAQ to remove issues resolved in 4.0, and add more advice on resolving VRR flicker issues.
Sightwalker · Mar 11, 2023 · 9286f1b · 9286f1b
1 parent ffd5e00
commit 9286f1b
Show file tree

Hide file tree

Showing 14 changed files with 83 additions and 120 deletions.
diff --git a/about/troubleshooting.rst b/about/troubleshooting.rst
@@ -9,20 +9,9 @@ This page lists common issues encountered when using Godot and possible solution
 
 .. seealso::
 
-    See :ref:`doc_using_the_web_editor` for caveats specific to the HTML5 version
+    See :ref:`doc_using_the_web_editor` for caveats specific to the Web version
     of the Godot editor.
 
-Everything I do in the editor or project manager appears delayed by one frame
------------------------------------------------------------------------------
-
-This is a `known bug <https://github.com/godotengine/godot/issues/23069>`__ on
-Intel graphics drivers on Windows. Updating to the latest graphics driver
-version *provided by Intel* should fix the issue.
-
-You should use the graphics driver provided by Intel rather than the one
-provided by your desktop or laptop's manufacturer because their version is often
-outdated.
-
 The editor runs slowly and uses all my CPU and GPU resources, making my computer noisy
 --------------------------------------------------------------------------------------
 
@@ -49,7 +38,12 @@ The editor stutters and flickers on my variable refresh rate monitor (G-Sync/Fre
 --------------------------------------------------------------------------------------
 
 This is a `known issue <https://github.com/godotengine/godot/issues/38219>`__.
-There are two workarounds for this:
+Variable refresh rate monitors need to adjust their gamma curves continuously to
+emit a consistent amount of light over time. This can cause flicker to appear in
+dark areas of the image when the refresh rate varies a lot, which occurs as
+the Godot editor only redraws when necessary.
+
+There are several workarounds for this:
 
 - Enable **Interface > Editor > Update Continuously** in the Editor Settings. Keep in mind
   this will increase power usage and heat/noise emissions since the editor will
@@ -59,36 +53,29 @@ There are two workarounds for this:
   *microseconds* between frames to render. Higher values will make the editor
   feel less reactive but will help decrease CPU and GPU usage significantly.
 - Alternatively, disable variable refresh rate on your monitor or in the graphics driver.
-
-The grid disappears and meshes turn black when I rotate the 3D camera in the editor
------------------------------------------------------------------------------------
-
-This is a `known bug <https://github.com/godotengine/godot/issues/30330>`__ on
-Intel graphics drivers on Windows.
-
-The only workaround, for now, is to switch to the GLES2 renderer. You can switch
-the renderer in the top-right corner of the editor or the Project Settings.
-
-If you use a computer allowing you to switch your graphics card, like NVIDIA
-Optimus, you can use the dedicated graphics card to run Godot.
+- VRR flicker can be reduced on some displays using the **VRR Control** or
+  **Fine Tune Dark Areas** options in your monitor's OSD. These options may
+  increase input lag or result in crushed blacks.
+- If using an OLED display, use the **Black (OLED)** editor theme preset in the
+  Editor Settings. This hides VRR flicker thanks to OLED's perfect black levels.
 
 The editor or project takes a very long time to start
 -----------------------------------------------------
 
-This is a `known bug <https://github.com/godotengine/godot/issues/20566>`__ on
+When using one of the the Vulkan-based renderers (Forward+ or Forward Mobile),
+the first startup is expected to be relatively long. This is because shaders
+need to be compiled before they can be cached. Shaders also need to be cached
+again after updating Godot, after updating graphics drivers or after switching
+graphics cards.
+
+If the issue persists after the first startup, this is a
+`known bug <https://github.com/godotengine/godot/issues/20566>`__ on
 Windows when you have specific USB peripherals connected. In particular,
 Corsair's iCUE software seems to cause this bug. Try updating your USB
 peripherals' drivers to their latest version. If the bug persists, you need to
 disconnect the specific peripheral before opening the editor. You can then
 connect the peripheral again.
 
-Editor tooltips in the Inspector and Node docks blink when they're displayed
-----------------------------------------------------------------------------
-
-This is a `known issue <https://github.com/godotengine/godot/issues/32990>`__
-caused by the third-party Stardock Fences application on Windows.
-The only known workaround is to disable Stardock Fences while using Godot.
-
 The Godot editor appears frozen after clicking the system console
 -----------------------------------------------------------------
 
@@ -111,18 +98,6 @@ default values in the NVIDIA Control Panel.
 To disable this overlay on Linux, open ``nvidia-settings``, go to **X Screen 0 >
 OpenGL Settings** then uncheck **Enable Graphics API Visual Indicator**.
 
-The project window appears blurry, unlike the editor
-----------------------------------------------------
-
-Unlike the editor, the project isn't marked as DPI-aware by default. This is
-done to improve performance, especially on integrated graphics, where rendering
-3D scenes in hiDPI is slow.
-
-To resolve this, open **Project > Project Settings**, make sure **Advanced
-Settings** is active, and enable **Display >
-Window > DPI > Allow hiDPI**. On top of that, make sure your project is
-configured to support :ref:`multiple resolutions <doc_multiple_resolutions>`.
-
 The project window doesn't appear centered when I run the project
 -----------------------------------------------------------------
 

diff --git a/tutorials/2d/particle_systems_2d.rst b/tutorials/2d/particle_systems_2d.rst
@@ -21,16 +21,20 @@ parameters and then adding randomness to them.
 Particle nodes
 ~~~~~~~~~~~~~~
 
-Godot provides two different nodes for 2D particles, :ref:`class_GPUParticles2D` and
-:ref:`class_CPUParticles2D`.
-GPUParticles2D is more advanced and uses the GPU to process particle effects, but that limits
-it to higher end graphics API, and in our case to the GLES3 renderer. For projects using
-the GLES2 backend, CPUParticles2D is a CPU-driven option with near feature parity with
-GPUParticles2D, but lesser performance. While GPUParticles2D is configured via a
-:ref:`class_ParticleProcessMaterial` (and optionally with a custom shader), the matching options
-are provided via node properties in CPUParticles2D (with the exception of the trail settings).
-You can convert a GPUParticles2D node into a CPUParticles2D node by clicking on the node in the
-inspector, and selecting "Convert to CPUParticles2D" in the "Particles" menu of the toolbar.
+Godot provides two different nodes for 2D particles, :ref:`class_GPUParticles2D`
+and :ref:`class_CPUParticles2D`. GPUParticles2D is more advanced and uses the
+GPU to process particle effects. CPUParticles2D is a CPU-driven option with
+near-feature parity with GPUParticles2D, but lower performance when using large
+amounts of particles. On the other hand, CPUParticles2D may perform better on
+low-end systems or in GPU-bottlenecked situations.
+
+While GPUParticles2D is configured via a :ref:`class_ParticleProcessMaterial`
+(and optionally with a custom shader), the matching options are provided via
+node properties in CPUParticles2D (with the exception of the trail settings).
+
+You can convert a GPUParticles2D node into a CPUParticles2D node by clicking on
+the node in the inspector, and selecting **Particles > Convert to
+CPUParticles2D** in the toolbar at the top of the 3D editor viewport.
 
 .. image:: img/particles_convert.png
 

diff --git a/tutorials/3d/3d_rendering_limitations.rst b/tutorials/3d/3d_rendering_limitations.rst
@@ -33,23 +33,28 @@ without affecting the source file.
 Color banding
 -------------
 
-When using the GLES3 or Vulkan renderers, Godot's 3D engine renders internally
-in HDR. However, the rendering output will be tonemapped to a low dynamic range
-so it can be displayed on the screen. This can result in visible banding,
-especially when using untextured materials. This can also be seen in 2D projects
-when using smooth gradient textures.
+When using the Forward+ or Forward Mobile rendering methods, Godot's 3D engine
+renders internally in HDR. However, the rendering output will be tonemapped to a
+low dynamic range so it can be displayed on the screen. This can result in
+visible banding, especially when using untextured materials. For performance
+reasons, color precision is also lower when using the Forward Mobile rendering
+method compared to Forward+.
+
+When using the Compatibility rendering method, HDR is not used and the color
+precision is the lowest of all rendering methods. This also applies to 2D
+rendering, where banding may be visible when using smooth gradient textures.
 
 There are two main ways to alleviate banding:
 
-- Enable **Use Debanding** in the Project Settings. This applies a
-  fullscreen debanding shader as a post-processing effect and is very cheap.
-  Fullscreen debanding is only supported when using the GLES3 or Vulkan renderers.
-  It also requires HDR to be enabled in the Project Settings (which is the default).
-- Alternatively, bake some noise into your textures. This is mainly effective in 2D,
-  e.g. for vignetting effects. In 3D, you can also use a
-  `custom debanding shader <https://github.com/fractilegames/godot-gles2-debanding-material>`__
-  to be applied on your *materials*. This technique works even if your project is
-  rendered in LDR, which means it will work when using the GLES2 renderer.
+- If using the Forward+ or Forward Mobile rendering methods, enable **Use
+  Debanding** in the advanced Project Settings. This applies a fullscreen debanding
+  shader as a post-processing effect and is very cheap.
+- Alternatively, bake some noise into your textures. This is mainly effective in
+  2D, e.g. for vignetting effects. In 3D, you can also use a `custom debanding
+  shader <https://github.com/fractilegames/godot-gles2-debanding-material>`__ to
+  be applied on your *materials*. This technique works even if your project is
+  rendered with low color precision, which means it will work when using the
+  Mobile and Compatibility rendering methods.
 
 .. seealso::
 

diff --git a/tutorials/animation/2d_skeletons.rst b/tutorials/animation/2d_skeletons.rst
@@ -3,11 +3,6 @@
 2D skeletons
 ============
 
-.. warning::
-
-    There are known issues with 2D skeletons on mobile and web platforms with the GLES2 renderer. We
-    recommend using the GLES3 renderer if your project relies on Skeleton2D for now.
-
 Introduction
 ------------
 

diff --git a/tutorials/editor/using_the_web_editor.rst b/tutorials/editor/using_the_web_editor.rst
@@ -30,8 +30,8 @@ proper threading support is added.
 
 **Mobile browsers are currently not supported.**
 
-The web editor supports both the GLES3 and GLES2 renderers, although GLES2 is
-recommended for better performance and compatibility with old/low-end hardware.
+The web editor only supports the Compatibility rendering method, as there is no
+stable way to run Vulkan applications on the web yet.
 
 .. note::
 

diff --git a/tutorials/export/exporting_for_web.rst b/tutorials/export/exporting_for_web.rst
@@ -39,20 +39,13 @@ in the user's browser.
 WebGL version
 -------------
 
-Depending on your choice of renderer, Godot can target WebGL 1.0 (*GLES2*) or
-WebGL 2.0 (*GLES3*).
+Godot 4.0 and later can only target WebGL 2.0 (using the Compatibility rendering
+method). There is no stable way to run Vulkan applications on the web yet.
 
-WebGL 1.0 is the recommended option if you want your project to be supported
-on all browsers with the best performance.
-
-Godot's GLES3 renderer targets high end devices, and the performance using
-WebGL 2.0 can be subpar. Some features are also not supported in WebGL 2.0
-specifically.
-
-Additionally, while most browsers support WebGL 2.0, this is not yet the case
-for **Safari**. WebGL 2.0 support is coming in Safari 15 for macOS, and is not
-available yet for any **iOS** browser (all WebKit-based like Safari).
-See `Can I use WebGL 2.0 <https://caniuse.com/webgl2>`__ for details.
+See `Can I use WebGL 2.0 <https://caniuse.com/webgl2>`__ for a list of browser
+versions supporting WebGL 2.0. Note that Safari has several issues with WebGL
+2.0 support that other browsers don't have, so we recommend using a
+Chromium-based browser or Firefox if possible.
 
 .. _doc_javascript_export_options:
 
@@ -200,12 +193,6 @@ The default HTML page does not display the boot splash while loading. However,
 the image is exported as a PNG file, so :ref:`custom HTML pages <doc_customizing_html5_shell>`
 can display it.
 
-Shader language limitations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When exporting a GLES2 project to HTML5, WebGL 1.0 will be used. WebGL 1.0
-doesn't support dynamic loops, so shaders using those won't work there.
-
 Serving the files
 -----------------
 

diff --git a/tutorials/performance/gpu_optimization.rst b/tutorials/performance/gpu_optimization.rst
@@ -274,8 +274,8 @@ but attempting to port it to mobile at the last minute is a recipe for disaster.
 
 In general, you should design your game for the lowest common denominator, then
 add optional enhancements for more powerful platforms. For example, you may want
-to use the GLES2 backend for both desktop and mobile platforms where you target
-both.
+to use the Compatibility rendering method for both desktop and mobile platforms
+where you target both.
 
 Mobile/tiled renderers
 ======================

diff --git a/tutorials/performance/vertex_animation/animating_thousands_of_fish.rst b/tutorials/performance/vertex_animation/animating_thousands_of_fish.rst
@@ -229,7 +229,7 @@ to loop over all the instances and set their transform to a random position.
 Running this script will place the fish in random positions in a box around the position of the
 MultiMeshInstance3D.
 
-.. note:: If performance is an issue for you, try running the scene with GLES2 or with fewer fish.
+.. note:: If performance is an issue for you, try running the scene with fewer fish.
 
 Notice how all the fish are all in the same position in their swim cycle? It makes them look very
 robotic. The next step is to give each fish a different position in the swim cycle so the entire

diff --git a/tutorials/performance/vertex_animation/controlling_thousands_of_fish.rst b/tutorials/performance/vertex_animation/controlling_thousands_of_fish.rst
@@ -13,9 +13,6 @@ To make each instance move in an interesting way, we will use a
 :ref:`GPUParticles3D <class_GPUParticles3D>` node. Particles take advantage of GPU acceleration
 by computing and setting the per-instance information in a :ref:`Shader <class_Shader>`.
 
-.. note:: Particles are not available in GLES2, instead use :ref:`CPUParticles3D <class_CPUParticles3D>`,
-          which do the same thing as Particles, but do not benefit from GPU acceleration.
-
 First create a Particles node. Then, under "Draw Passes" set the Particle's "Draw Pass 1" to your
 :ref:`Mesh <class_Mesh>`. Then under "Process Material" create a new
 :ref:`ShaderMaterial <class_ShaderMaterial>`.

diff --git a/tutorials/shaders/shader_reference/particle_shader.rst b/tutorials/shaders/shader_reference/particle_shader.rst
@@ -20,8 +20,15 @@ to the fragment shader for pixel-processing. Because of this, transform feedback
 shaders can build on themselves each run, unlike other shaders that discard the
 data they have calculated once they draw to the frame buffer.
 
-.. note:: Particle shaders are only available in the GLES3 backend. If you need
-          particles in GLES2, use :ref:`CPUParticles3D <class_CPUParticles3D>`.
+.. note::
+
+    Particle shaders are only available with GPU-based particle nodes
+    (:ref:`class_GPUParticles2D` and :ref:`class_GPUParticles3D`).
+
+    CPU-based particle nodes (:ref:`class_CPUParticles2D` and
+    :ref:`class_CPUParticles3D`) are *rendered* on the GPU (which means they can
+    use custom CanvasItem or Spatial shaders), but their motion is *simulated*
+    on the CPU.
 
 Render modes
 ^^^^^^^^^^^^

diff --git a/tutorials/shaders/shader_reference/shading_language.rst b/tutorials/shaders/shader_reference/shading_language.rst
@@ -548,11 +548,6 @@ larger the epsilon value should be.
 See `floating-point-gui.de <https://floating-point-gui.de/>`__ for more
 information.
 
-.. warning::
-
-    When exporting a GLES2 project to HTML5, WebGL 1.0 will be used. WebGL 1.0
-    doesn't support dynamic loops, so shaders using those won't work there.
-
 Discarding
 ----------
 
@@ -875,7 +870,7 @@ table of the corresponding types:
 +----------------------+-------------------------+------------------------------------------------------------+
 | **samplerCubeArray** | **CubemapArray**        |                                                            |
 +----------------------+-------------------------+------------------------------------------------------------+
- 
+
 .. note:: Be careful when setting shader uniforms from GDScript, no error will
           be thrown if the type does not match. Your shader will just exhibit
           undefined behavior.

diff --git a/tutorials/shaders/shader_reference/spatial_shader.rst b/tutorials/shaders/shader_reference/spatial_shader.rst
@@ -170,8 +170,9 @@ shader, this value can be used as desired.
 +----------------------------------------+--------------------------------------------------------+
 | in vec3 **CAMERA_DIRECTION_WORLD**     | Camera world space direction.                          |
 +----------------------------------------+--------------------------------------------------------+
-| in bool **OUTPUT_IS_SRGB**             | ``true`` when calculations happen in sRGB color space  |
-|                                        | (``true`` in GLES2, ``false`` in GLES3).               |
+| in bool **OUTPUT_IS_SRGB**             | ``true`` when output is in sRGB color space            |
+|                                        | (this is ``true`` in the Compatibility renderer,       |
+|                                        | ``false`` in Forward+ and Forward Mobile).             |
 +----------------------------------------+--------------------------------------------------------+
 | in int **INSTANCE_ID**                 | Instance ID for instancing.                            |
 +----------------------------------------+--------------------------------------------------------+
@@ -259,7 +260,8 @@ these properties, and if you don't write to them, Godot will optimize away the c
 +----------------------------------------+--------------------------------------------------------------------------------------------------+
 | in vec2 **POINT_COORD**                | Point Coordinate for drawing points with POINT_SIZE.                                             |
 +----------------------------------------+--------------------------------------------------------------------------------------------------+
-| in bool **OUTPUT_IS_SRGB**             | ``true`` when calculations happen in sRGB color space (``true`` in GLES2, ``false`` in GLES3).   |
+| in bool **OUTPUT_IS_SRGB**             | ``true`` when output is in sRGB color space (this is ``true`` in the Compatibility renderer,     |
+|                                        | ``false`` in Forward+ and Forward Mobile).                                                       |
 +----------------------------------------+--------------------------------------------------------------------------------------------------+
 | in mat4 **MODEL_MATRIX**               | Model space to world space transform.                                                            |
 +----------------------------------------+--------------------------------------------------------------------------------------------------+
@@ -442,8 +444,9 @@ If you want the lights to add together, add the light contribution to ``DIFFUSE_
 +-----------------------------------+----------------------------------------------------+
 | in float **ROUGHNESS**            | Roughness.                                         |
 +-----------------------------------+----------------------------------------------------+
-| in bool **OUTPUT_IS_SRGB**        | ``true`` when calculations happen in sRGB color    |
-|                                   | space (``true`` in GLES2, ``false`` in GLES3).     |
+| in bool **OUTPUT_IS_SRGB**        | ``true`` when output is in sRGB color space        |
+|                                   | (this is ``true`` in the Compatibility renderer,   |
+|                                   | ``false`` in Forward+ and Forward Mobile).         |
 +-----------------------------------+----------------------------------------------------+
 | out vec3 **DIFFUSE_LIGHT**        | Diffuse light result.                              |
 +-----------------------------------+----------------------------------------------------+

diff --git a/tutorials/shaders/shaders_style_guide.rst b/tutorials/shaders/shaders_style_guide.rst
@@ -11,7 +11,7 @@ auto-formatting tools.
 Since the Godot shader language is close to C-style languages and GLSL, this
 guide is inspired by Godot's own GLSL formatting. You can view an example of a
 GLSL file in Godot's source code
-`here <https://github.com/godotengine/godot/blob/master/drivers/gles2/shaders/copy.glsl>`__.
+`here <https://github.com/godotengine/godot/blob/master/drivers/gles3/shaders/copy.glsl>`__.
 
 Style guides aren't meant as hard rulebooks. At times, you may not be able to
 apply some of the guidelines below. When that happens, use your best judgment,