Also fix iOS export logic that would force a min target of iOS 14.0 (for Metal)
even when targeting the Compatibility renderer.
Co-authored-by: Pāvels Nadtočajevs <7645683+bruvzg@users.noreply.github.com>
Simpler alternative to #103026 which avoids breaking compatibility.
Instead of introducing a new `auto` default value, we ensure that all
supported drivers are registered regardless of the editor's host platform,
and that the defaults are the intended ones.
This solves the following issues:
- macOS exports are meant to default to Metal in 4.4, but they would
default to Vulkan if exported from Linux, Windows, or Android editors.
- Windows exports couldn't be made with Direct3D 12 from Linux, macOS, or
Android editors, as the option couldn't be selected outside Windows.
Unlike #103026, it doesn't solve the issue of not always saving the
rendering drivers to `project.godot`, but now the defaults are at least
consistent between editor platforms.
Co-authored-by: Pāvels Nadtočajevs <7645683+bruvzg@users.noreply.github.com>
This reverts commit dea20c4a9b.
This had unforeseen consequences for editor code that relies on querying these settings,
and possibly thirdparty code that would do the same. In hindsight, it's a bit too late
in the release cycle to make such a compatibility breaking change.
Mask with INT64_MAX to avoid negative UIDs which cause bugs.
If the generated .translation UID is already in use (renamed), overwrite that file instead.
Fixes viewport scale being wrong at resolutions that are not
integer multiples of content_scale_factor.
This is done by allowing size_2d_override to be Size2 instead of
Size2i. This change is not propagated to the exposed SubViewport
to keep compatibility for now.
And anything that uses luminance.
The class Luminance in luminance.cpp is in charge of averaging the
luminance of all pixels.
It performs multiple passes until it reaches a 1x1 texture containing
the total average. This is standard luminance averaging on GPU.
Then the "result" of this frame and the "prev_frame_result" are averaged
together at a certain speed to mimic eye adaptation.
Then this avarege becomes the "source" for the next frame. This is done
here:
```cpp
SWAP(p_luminance_buffers->current,
p_luminance_buffers->reduce.write[p_luminance_buffers->reduce.size() -
1]);
```
So far pretty normal stuff.
**The problem is: prev_frame_result IS UNINITIALIZED**. Therefore it's
possible for prev_frame_result to contain garbage values like -5+e15
which causes the screen to stay black for a minute until eye adaptation
catches up.
Windows will always force allocations to be reset to 0, but Linux does
not do that.
However Windows just delays the bug; because it's possible for VMA to
reuse a block.
You can repro this bug by downloading Bistro, creating a camera,
selecting a default scene; and then launching Bistro.
Everything will work fine.
Until you decide to resize the window. It takes a few tries on Godot,
but eventually the screen becomes black.
If you wait around a minute, the screen will "unblack" itself back to
normal.
Even if it's not stuck in black after resize, you may notice that every
resize is inconsistent in how the eye adaptation catches up (i.e.
sometimes it flashes to white, sometimes it does not).
If you can't repro the bug, you need to try harder by doing arbitrary
resizes until it triggers.
Also, I advise to try this on Linux; since Windows' sanitization of
memory gets in the way.
There's probably multiple tickets already filled around issues that were
rooted in luminance calculations starting from uninitialized memory.
This PR sets a default value of 0, which causes the screen to always
flash white after resize. Setting a different value like 0.1 makes the
flash effect weaker. Setting it to a high value like 5.0 makes the
screen flash from dark instead.
This bug can be backported to 4.3. I don't know if it can be backported
to earlier; as the render graph makes sure the texture_clear() calls
gets issued in the right place; whereas in <= 4.2 it might be
problematic depending on when Luminance::LuminanceBuffers::configure is
being called.
