- Adds Swappy for Android for stable frame pacing
- Implements pre-transformed Swapchain so that Godot's compositor is in
charge of rotating the screen instead of Android's compositor
(performance optimization for phones that don't have HW rotator)
============================
The work was performed by collaboration of TheForge and Google. I am
merely splitting it up into smaller PRs and cleaning it up.
Changes from original PR:
- Removed "display/window/frame_pacing/android/target_frame_rate" option
to use Engine::get_max_fps instead.
- Target framerate can be changed at runtime using Engine::set_max_fps.
- Swappy is enabled by default.
- Added documentation.
- enable_auto_swap setting is replaced with swappy_mode.
"Raycast Normals" was introduced in 4.4 dev and defaulted to "false".
The limited testing results at the time suggested that raycasting
generally reduces normal quality compared to native simplifier results,
at the same time increasing vertex memory and import time.
To play it safe, we introduced a setting that defaulted to false, with
the goal of removing it later in 4.4 development cycle if no regressions
are noticed. Since we already had three dev snapshots and no reports,
this change removes the setting and associated code.
"Normal Split Angle" was only used when raycast normals were enabled;
this change removes it from the settings, but keeps it in the script
binding for compatibility.
Existing meshes import exactly the same after this change (unless they
chose to override raycasting which would be surprising).
split_normals helper was only used in this code path and is also removed
for simplicity; it is unlikely that this code will be useful as is, as
it can only regenerate normals without fixing tangents or updating
positions.
This puts OBJ mesh import on parity with 3D scene import. It's now
possible to have the same level of optimization as imported 3D scenes
while using the OBJ mesh workflow.
`optimize_indices_for_cache()` is now always called on import as well,
similar to what the 3D scene import already does.
Previous wording said that @GDScript referred to entries that could be accessed in any script. Although with common sense we could imagine that it is only refering to GDScript specific pieces of code, the wording is a little unclear.
In general there are small changes to the wording which makes it more clear and concise.
Wording change
Tried to match the wording up with my last change which should make it a bit easier to parse at a glance what the docs mean by "from any script"
Changed language from "not specific to" to "which work in any language"
After consulting multiple people the new wording seems easier to parse, even for non coders
Update doc/classes/@GlobalScope.xml
Update modules/gdscript/doc_classes/@GDScript.xml
Update modules/gdscript/doc_classes/@GDScript.xml
Co-Authored-By: Micky <66727710+Mickeon@users.noreply.github.com>
The project setting does not reflect CLI argument overrides
(including `--headless` which sets the audio driver to `Dummy`),
so it can't be reliably used to detect which audio driver is
actually being used at run-time.
