New contributors added to AUTHORS:
@creikey, @IronicallySerious, @LikeLakers2, @minraws, @NilsIrl,
@profan, @raphael10241024
New Platinum sponsor, added to splash screen:
Heroic Labs
Merged some duplicates via .mailmap to allow better tracking of
commit counts with `git shortlog -s -n -e --no-merges`.
Thanks to all contributors and donors for making Godot possible!
(cherry picked from commit 664d7e7336)
New contributors added to AUTHORS:
@merumelu, @sparkart
Thanks to all contributors and donors for making Godot possible!
(cherry picked from commit 41beecaa08)
Closes: #30969
The FG rectangle of the progressbar is incorrect when dealing with a non-zero border. This issue stems from wrong order of operations when drawing the rectangle: int p = r * get_size().width - mp;
(cherry picked from commit 7db96e22dd)
This is actually expected by the function although it was apparently
working in GCC without the terminator, it breaks (at least some) clang
versions.
(cherry picked from commit 2f91e250f6)
New contributors added to AUTHORS:
@Anutrix, @hbina, @santouits
Thanks to all contributors and donors for making Godot possible!
(cherry picked from commit 6d6b9ccc9a)
Two modules fail building with this option, so we force users to disable them.
Small cleanup based on 2.1 branch and cherry-pick 01e65c4555
to fix support for NDK r20 (fixes#30688).
Theora and WebM video streams were mistakenly imported with a ResourceImporter,
but those imported ogvstr and webmstr were simply links to the local resource.
While that works fine in the editor, it no longer works when exporting a game
as the "source" ogv and webm files are ommitted and only the ogvstr and webmstr
references were exported.
As discussed with @reduz, it doesn't make sense to import videos, as we only
intend to play them back and not modify them/access their raw data. As such we
use a ResourceFormatLoader instead of an importer, to load the file on the fly.
ogv and webm files linked to this loader are now considered as resources, and
thus exported.
Note: The Theora and WebM loaders lack any kind of validity check beyond the
existence of the target file, but it was already the case with the importer.
Better checks and error reports could be added, but those loaders will eventually
be obsoleted by GDNative plugins anyway.
Fixes#14954.
(cherry picked from commit 6dc20adadd)
In x11, windows and osx crash handlers, check project settings exists
before looking up the crash handler message setting.
Avoids crashing the crash handler when handling a crash outside project
settings lifetime. Instead omitting the configurable message and
continuing with trace dump.
(cherry picked from commit 63068e2ccd)
Maximum stack size is only 8KiB, this will try to allocate 8193 *
sizeof(void*) * 2 = 131088 bytes on the stack. This causes a crash in
some cases.
(cherry picked from commit c52f890626)
It appears that Object::script may be a valid ScriptInstance but not be
castable to Ref<Script>. There were only 5 places in the code that made
this assumption. This commit fixes that.
(cherry picked from commit 20b0046945)
We used to abort if the system-specific data folder (e.g. `~/.local`
or `%APPDATA%`) is missing, but the next code chunk actually creates
it with `make_dir_recursive` if missing.
Fixes#26598.
(cherry picked from commit c0050d9295)
It is not valid in C++ to store into shadow_matrix1[16] with shadow_matrix1[16 * j]
(for j > 0). Even though there's a valid space in a struct after shadow_matrix1.
Knowing that GCC performs aggressive optimizations that eventually lead
to a wrong code. Code has been changed into union where one can either
use shadow_matrix[4 * 16], or individual shadow_matrix1, shadow_matrix2, etc. GCC pragma
is not needed any longer.
(cherry picked from commit d9eb6a5b20)
Godot supports many different compilers and for production releases we
have to support 3 currently: GCC8, Clang6, and MSVC2017. These compilers
all do slightly different things with -ffast-math and it is causing
issues now. See #24841, #24540, #10758, #10070. And probably other
complaints about physics differences between release and release_debug
builds.
I've done some performance comparisons on Linux x86_64. All tests are
ran 20 times.
Bunnymark: (higher is better)
(bunnies) min max stdev average
fast-math 7332 7597 71 7432
this pr 7379 7779 108 7621 (102%)
FPBench (gdscript port http://fpbench.org/) (lower is better)
(ms)
fast-math 15441 16127 192 15764
this pr 15671 16855 326 16001 (99%)
Float_add (adding floats in a tight loop) (lower is better)
(sec)
fast-math 5.49 5.78 0.07 5.65
this pr 5.65 5.90 0.06 5.76 (98%)
Float_div (dividing floats in a tight loop) (lower is better)
(sec)
fast-math 11.70 12.36 0.18 11.99
this pr 11.92 12.32 0.12 12.12 (99%)
Float_mul (multiplying floats in a tight loop) (lower is better)
(sec)
fast-math 11.72 12.17 0.12 11.93
this pr 12.01 12.62 0.17 12.26 (97%)
I have also looked at FPS numbers for tps-demo, 3d platformer, 2d
platformer, and sponza and could not find any measurable difference.
I believe that given the issues and oft-reported (physics) glitches on
release builds I believe that the couple of percent of tight-loop
floating point performance regression is well worth it.
This fixes#24540 and fixes#24841
(cherry picked from commit e5b335d367)
Seemingly a typo, I did not check what exact impact it had, but
the x_ofs would likely have accumulated errors when using fonts
with varying char widths.
(cherry picked from commit 7cb5e005ee)
Jonathan Mannancheril
Rémi Verschelde
Max
bruvzg
mellondill
Emmanuel Barroga
Fabio Alessandrelli
StraToN
Bastiaan Olij
Leon Krause
Ibrahn Sahir
Hein-Pieter van Braam-Stewart
Hugo Locurcio
Marc Gilleron
Bojidar Marinov
Konrad Nowakowski
marxin
RedMser
Daniel Abbott
João Álvaro Ferreira