Age | Commit message (Collapse) | Author |
|
Fixes #25301.
|
|
Fixes #16100.
|
|
|
|
Some construct (like match) actually depends on the second pass. This
adds some extra checks to not perform specific type-checks on release
since not all type information is available.
|
|
|
|
This is needed to create export variables from enums defined in a parent
class.
|
|
|
|
|
|
|
|
Add environment variable to specify a custom --debugger-agent for mono.
|
|
Fixed area overlaps if not move
|
|
|
|
|
|
BaseIntermediateOutputPath seems to be empty by default. The workaround is to explicitly set it.
Also fixed passing char instead of char[] to String.Split. Why was this even working with Mono?
|
|
Fixes #25082, fixes #24709.
|
|
C# Bindings Generator: Fix vararg methods with custom return type
|
|
C#: Fix trying to build when there's no solution
|
|
C#: Fix crash due to missing gchandle ref null check
|
|
|
|
This would cause errors that shouldn't happen unless there was something to build.
|
|
|
|
A bit more of GDScript fixes
|
|
Otherwise these checks might trigger the insertion of an empty value,
leading to crashes.
|
|
They may happen with any cyclic dependency, not only with inheritance.
|
|
|
|
Fixes export PackedScene "reset to default" throwing errors
|
|
Like arm64v8, this is only supported by API 21 and later,
so we enforce 21 as min API for x86_64.
Part of #25030.
|
|
Fix some errors found by static analysis
|
|
Fixes items 10, 16 and 19 from PVS-Studio blog post
in #24014.
|
|
When exporting variables from a gdscript, default values of uninitialized variables would never be set. This caused the default value to be Variant::NIL, and when a user tried to reset the variable through the editor, an error would be thrown because too few arguments would be counted(end of argument list for calls are detected by NIL values).
Fixed by simply setting default value to an empty variant of the proper type in gdscript parser.
|
|
Some classes are represented internally with an underscore prefix, so we
need to make sure we match this representation when type-checking,
otherwise the check might fail on a valid scenario.
|
|
There's always a constructor, even if implicit, especially for native
types.
Also don't check for signature match on function call, since this
information is not available in release builds.
|
|
The engine allows this already, so the parser should not fail in this
case.
|
|
A lot of information is missing on release, and the checks might take a
performance hit. Also, having GDScript more lenient on release is
usually desirable.
|
|
Guessing the type from an `is` operator should no be considered an
assigment. This would cause crashes in certain scenarios.
|
|
A missing condition caused infinite looping, despite
the video playing flag being set to false.
Small change to fix.
Fixes: #20552
|
|
Fix properties being lost when reloading placeholder GDScript instance
|
|
|
|
Consistency in resource format saver/loader de-registration
|
|
Fix broken encrypted scripts during export
|
|
Use temporary cache directory instead of editor settings directory
in order to resolve encrypted file access needed for encrypting scripts
on all platforms.
|
|
Some used 'is_valid()' checks, others not. Validity is already checked in 'unref()',
and 'remove_resource_format_*()' has an ERR_FAIL condition on 'is_null()' already
(which shouldn't happen since we're only unregistering things that we previously
registered.
Also add missing GDCLASS statement in ResourceFormatLoaderVideoStreamGDNative,
missed in #20552 which was last amended before #19501 was merged.
|
|
|
|
During reloading in `GDScriptLanguage::reload_all_scripts` a placeholder instance that must remain so is replaced with a new placeholder instance. The state is then restored by calling `ScriptInstance::set` for each property. This does not work if the script is missing the properties due to build/parse failing.
The fix for such cases is to call `placeholder_set_fallback` instead of `set` on the script instance.
I took this chance to move the `build_failed` flag from `PlaceHolderScriptInstance` to `Script`. That improves the code a lot. I also renamed it to `placeholder_fallback_enabled` which is a much better name (`build_failed` could lead to misunderstandings).
|
|
Added interface for GDNative Videodecoder.
|
|
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
|
|
This fixes the previously wrong PR
Because we don't actually ship 'debug' templates to users make sure
the mono exporter picks the correct 'data' directory for export
templates.
This fixes #24752
|
|
Because we don't actually ship 'debug' templates to users make sure
the mono exporter picks the correct 'data' directory for export
templates.
This fixes #24752
|
|
|
|
Thanks @PJB3005
|