Skip to content

Commit 833ebf4

Browse files
authored
Merge pull request #11261 from godotengine/classref/sync-3c7f9b9
classref: Sync with current master branch (3c7f9b9)
2 parents 4404daf + 82d5148 commit 833ebf4

File tree

4 files changed

+20
-14
lines changed

4 files changed

+20
-14
lines changed

classes/class_input.rst

Lines changed: 6 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -678,25 +678,21 @@ On Windows, all XInput joypad GUIDs will be overridden by Godot to ``__XINPUT_DE
678678

679679
Returns a dictionary with extra platform-specific information about the device, e.g. the raw gamepad name from the OS or the Steam Input index.
680680

681-
On Windows, the dictionary contains the following fields:
681+
On Windows, Linux, and macOS, the dictionary contains the following fields:
682682

683-
\ ``xinput_index``: The index of the controller in the XInput system. Undefined for DirectInput devices.
683+
\ ``raw_name``: The name of the controller as it came from the OS, before getting renamed by the controller database.
684684

685685
\ ``vendor_id``: The USB vendor ID of the device.
686686

687687
\ ``product_id``: The USB product ID of the device.
688688

689-
On Linux:
690-
691-
\ ``raw_name``: The name of the controller as it came from the OS, before getting renamed by the godot controller database.
692-
693-
\ ``vendor_id``: The USB vendor ID of the device.
689+
\ ``steam_input_index``: The Steam Input gamepad index, if the device is not a Steam Input device this key won't be present.
694690

695-
\ ``product_id``: The USB product ID of the device.
691+
On Windows, the dictionary can have an additional field:
696692

697-
\ ``steam_input_index``: The Steam Input gamepad index, if the device is not a Steam Input device this key won't be present.
693+
\ ``xinput_index``: The index of the controller in the XInput system. This key won't be present for devices not handled by XInput.
698694

699-
\ **Note:** The returned dictionary is always empty on Web, iOS, Android, and macOS.
695+
\ **Note:** The returned dictionary is always empty on Android, iOS, visionOS, and Web.
700696

701697
.. rst-class:: classref-item-separator
702698

classes/class_projectsettings.rst

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -13436,9 +13436,11 @@ The default compression factor for lossless WebP. Decompression speed is mostly
1343613436

1343713437
:ref:`bool<class_bool>` **rendering/viewport/hdr_2d** = ``false`` :ref:`🔗<class_ProjectSettings_property_rendering/viewport/hdr_2d>`
1343813438

13439-
If ``true``, enables :ref:`Viewport.use_hdr_2d<class_Viewport_property_use_hdr_2d>` on the root viewport. 2D rendering will use a high dynamic range (HDR) format framebuffer matching the bit depth of the 3D framebuffer. When using the Forward+ renderer this will be an ``RGBA16`` framebuffer, while when using the Mobile renderer it will be an ``RGB10_A2`` framebuffer. Additionally, 2D rendering will take place in linear color space and will be converted to sRGB space immediately before blitting to the screen. Practically speaking, this means that the end result of the Viewport will not be clamped into the ``0-1`` range and can be used in 3D rendering without color space adjustments. This allows 2D rendering to take advantage of effects requiring high dynamic range (e.g. 2D glow) as well as substantially improves the appearance of effects requiring highly detailed gradients.
13439+
If ``true``, enables :ref:`Viewport.use_hdr_2d<class_Viewport_property_use_hdr_2d>` on the root viewport. 2D rendering will use a high dynamic range (HDR) format framebuffer matching the bit depth of the 3D framebuffer. When using the Forward+ or Compatibility renderer, this will be an ``RGBA16`` framebuffer. When using the Mobile renderer, it will be an ``RGB10_A2`` framebuffer.
1344013440

13441-
\ **Note:** This setting will have no effect when using the Compatibility renderer, which always renders in low dynamic range for performance reasons.
13441+
Additionally, 2D rendering will take place in linear color space and will be converted to sRGB space immediately before blitting to the screen (if the Viewport is attached to the screen).
13442+
13443+
Practically speaking, this means that the end result of the Viewport will not be clamped to the ``0-1`` range and can be used in 3D rendering without color space adjustments. This allows 2D rendering to take advantage of effects requiring high dynamic range (e.g. 2D glow) as well as substantially improves the appearance of effects requiring highly detailed gradients.
1344213444

1344313445
\ **Note:** This property is only read when the project starts. To toggle HDR 2D at runtime, set :ref:`Viewport.use_hdr_2d<class_Viewport_property_use_hdr_2d>` on the root :ref:`Viewport<class_Viewport>`.
1344413446

classes/class_renderingserver.rst

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12491,7 +12491,11 @@ Equivalent to :ref:`Viewport.use_debanding<class_Viewport_property_use_debanding
1249112491

1249212492
|void| **viewport_set_use_hdr_2d**\ (\ viewport\: :ref:`RID<class_RID>`, enabled\: :ref:`bool<class_bool>`\ ) :ref:`🔗<class_RenderingServer_method_viewport_set_use_hdr_2d>`
1249312493

12494-
If ``true``, 2D rendering will use a high dynamic range (HDR) format framebuffer matching the bit depth of the 3D framebuffer. When using the Forward+ or Compatibility rendering method this will be an ``RGBA16`` framebuffer, while when using the Mobile rendering method it will be an ``RGB10_A2`` framebuffer. Additionally, 2D rendering will take place in linear color space and will be converted to sRGB space immediately before blitting to the screen (if the Viewport is attached to the screen). Practically speaking, this means that the end result of the Viewport will not be clamped into the ``0-1`` range and can be used in 3D rendering without color space adjustments. This allows 2D rendering to take advantage of effects requiring high dynamic range (e.g. 2D glow) as well as substantially improves the appearance of effects requiring highly detailed gradients. This setting has the same effect as :ref:`Viewport.use_hdr_2d<class_Viewport_property_use_hdr_2d>`.
12494+
If ``true``, 2D rendering will use a high dynamic range (HDR) format framebuffer matching the bit depth of the 3D framebuffer. When using the Forward+ or Compatibility renderer, this will be an ``RGBA16`` framebuffer. When using the Mobile renderer, it will be an ``RGB10_A2`` framebuffer.
12495+
12496+
Additionally, 2D rendering will take place in linear color space and will be converted to sRGB space immediately before blitting to the screen (if the Viewport is attached to the screen).
12497+
12498+
Practically speaking, this means that the end result of the Viewport will not be clamped to the ``0-1`` range and can be used in 3D rendering without color space adjustments. This allows 2D rendering to take advantage of effects requiring high dynamic range (e.g. 2D glow) as well as substantially improves the appearance of effects requiring highly detailed gradients. This setting has the same effect as :ref:`Viewport.use_hdr_2d<class_Viewport_property_use_hdr_2d>`.
1249512499

1249612500
.. rst-class:: classref-item-separator
1249712501

classes/class_viewport.rst

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1966,7 +1966,11 @@ See also :ref:`ProjectSettings.rendering/anti_aliasing/quality/use_debanding<cla
19661966
- |void| **set_use_hdr_2d**\ (\ value\: :ref:`bool<class_bool>`\ )
19671967
- :ref:`bool<class_bool>` **is_using_hdr_2d**\ (\ )
19681968

1969-
If ``true``, 2D rendering will use a high dynamic range (HDR) format framebuffer matching the bit depth of the 3D framebuffer. When using the Forward+ or Compatibility rendering method this will be an ``RGBA16`` framebuffer, while when using the Mobile rendering method it will be an ``RGB10_A2`` framebuffer. Additionally, 2D rendering will take place in linear color space and will be converted to sRGB space immediately before blitting to the screen (if the Viewport is attached to the screen). Practically speaking, this means that the end result of the Viewport will not be clamped into the ``0-1`` range and can be used in 3D rendering without color space adjustments. This allows 2D rendering to take advantage of effects requiring high dynamic range (e.g. 2D glow) as well as substantially improves the appearance of effects requiring highly detailed gradients.
1969+
If ``true``, 2D rendering will use a high dynamic range (HDR) format framebuffer matching the bit depth of the 3D framebuffer. When using the Forward+ or Compatibility renderer, this will be an ``RGBA16`` framebuffer. When using the Mobile renderer, it will be an ``RGB10_A2`` framebuffer.
1970+
1971+
Additionally, 2D rendering will take place in linear color space and will be converted to sRGB space immediately before blitting to the screen (if the Viewport is attached to the screen).
1972+
1973+
Practically speaking, this means that the end result of the Viewport will not be clamped to the ``0-1`` range and can be used in 3D rendering without color space adjustments. This allows 2D rendering to take advantage of effects requiring high dynamic range (e.g. 2D glow) as well as substantially improves the appearance of effects requiring highly detailed gradients.
19701974

19711975
.. rst-class:: classref-item-separator
19721976

0 commit comments

Comments
 (0)