Instead of updating all viewports, then blitting all viewports
to the backbuffer, then swapping all buffers, we run through
all viewports and render, blit, and swap backbuffer before
going to the next viewport.
Adds support for LTO on macOS and Android. We don't have much experience
with LTO on these platforms so for now we keep it disabled by default
even when `production=yes` is set.
Similarly for iOS where we ship object files for the user to link in
Xcode so LTO makes builds extremely slow to link.
`production=yes` defaults to full LTO.
ThinLTO is much faster for LLVM-based compilers but seems to produce
bigger binaries (at least for the Web platform).
This lets the engine and projects use the same color codes
in the terminal on all platforms. This includes support for
`print_rich()` (GDScript) and `print_line_rich()` (C++).
Previously it was used only on debug builds, but recent
additions to variant_call.cpp have made that unit too
large even in release_debug.
It was originally set to debug only because using it
breaks mingw, so this only reinstates it for MSVC where
it shouldn't have any drawbacks (famous last words).
Test-Information:
Builds for me with
scons -j 40 platform=windows target=release_debug
and my game then runs from it.
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
