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)
WebGL does not support MapBufferRange or UnmapBuffer.
Also used in non-ES platforms where an extra-copy is avoided.
(cherry picked from commit 92e7c8daf0)
Fix for incorrect types used in MeshDataTool for bones and weights.
If your mesh contains these memory accesses get OOB and might crash
the application
Closes#21713
(cherry picked from commit e50d56b4c6)
Rémi Verschelde
Fabio Alessandrelli
Ibrahn Sahir
Hein-Pieter van Braam-Stewart
Hugo Locurcio
Marc Gilleron
Bojidar Marinov
Bastiaan Olij
Konrad Nowakowski
marxin
RedMser
bruvzg
Daniel Abbott
João Álvaro Ferreira
Ruslan Mustakov
Pedro J. Estébanez
Aaron Franke
Leon Krause
allkhor
Marcelo Fernandez
pshe94
Colin Kinloch
Poommetee Ketson
Xavier Sellier
Karen Schwane
Sean McCarthy
DualMatrix
exts
Gleb Mineev
qonnop
Sergey Lapin