The XDG Base Directory specification does not allow using relative paths
(which broke things in Godot anyway). If a relative path is detected,
it should be ignored.
(cherry picked from commits 011a99316a
and 0e1d45b210)
We found that this flag causes this error on PR #48812 which does not add any
fancy inline assembly:
```
/tmp/tile_set-ce236a.s: Assembler messages:
/tmp/tile_set-ce236a.s:34676: Error: selected processor does not support `bfc x0,#32,#32'
clang++: error: assembler command failed with exit code 1 (use -v to see invocation)
```
That flag is mentioned in various errors related to assembler failures on
arm64v8 with Clang from the Android NDK.
It was added in Godot in #6958 when migrating from GCC to Clang, and is indeed
referenced in the NDK's Clang migration guide:
https://android.googlesource.com/platform/ndk/+/master/docs/ClangMigration.md
> Especially for ARM and ARM64, Clang is much stricter about assembler rules
> than GCC/GAS. Use `-fno-integrated-as` if Clang reports errors in inline
> assembly or assembly files that you don't wish to modernize.
We don't get those errors nowadays so it seems the flag is no longer needed.
(cherry picked from commit 23f7c75126)
Add `WARN_ON_UNDEFINED_SYMBOLS=0` for the main module (which defines
`godot_js_main` as extern coming from the "side" module, i.e. the main
Godot binary).
(cherry picked from commit 14c057eab6)
This changes the types of a big number of variables.
General rules:
- Using `uint64_t` in general. We also considered `int64_t` but eventually
settled on keeping it unsigned, which is also closer to what one would expect
with `size_t`/`off_t`.
- We only keep `int64_t` for `seek_end` (takes a negative offset from the end)
and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means
we only need to guard against passing negative values in `core_bind.cpp`.
- Using `uint32_t` integers for concepts not needing such a huge range, like
pages, blocks, etc.
In addition:
- Improve usage of integer types in some related places; namely, `DirAccess`,
core binds.
Note:
- On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with
version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for
big files on 32-bit Windows builds made with that toolchain. We might add a
workaround.
Fixes#44363.
Fixesgodotengine/godot-proposals#400.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
We don't get updates when the window is unfocused/minimized, so we must
detect the situation where the counted ticks start drifting away
resulting in more frames drawn than needed.
This commit adds a check to ensure that the target ticks do not drift
away more than one second.
(cherry picked from commit a1fe6d6899)
This uses the `event.code` value to retrieve the physical code, while
still using the extra logic to map the unicode value to our keylist,
when computing the `scancode` (supporting ASCII and Latin-1).
Since we clone the environments to build thirdparty code, we don't get an
explicit dependency on the build objects produced by that environment.
So when we update thirdparty code, Godot code using it is not necessarily
rebuilt (I think it is for changed headers, but not for changed .c/.cpp files),
which can lead to an invalid compilation output (linking old Godot .o files
with a newer, potentially ABI breaking version of thirdparty code).
This was only seen as really problematic with bullet updates (leading to
crashes when rebuilding Godot after a bullet update without cleaning .o files),
but it's safer to fix it everywhere, even if it's a LOT of hacky boilerplate.
(cherry picked from commit c7b53c03ae)
We've been using standard C library functions `memcpy`/`memset` for these since
2016 with 67f65f6639.
There was still the possibility for third-party platform ports to override the
definitions with a custom header, but this doesn't seem useful anymore.
Backport of #48239.
It seems 30.0.1 had issues with compatibility with JDK 8 and 11,
which appear to be solved in 30.0.3 as per godotengine/godot-docs#4796.
(cherry picked from commit d88e1f04df)
Generates a key/cert snakeoil pair or use a custom SSL cert/key.
This is of course false security, and potentially detrimental for it.
But, so long, those are the requirements browser vendors agreed on to
use things like the Gamepad API, and more advanced topics like wasm
threads.
You don't need this if you run on localhost (at least!), but you do
need this (or a much safer nginx proxy) to try those things on your
local network (e.g. when debugging a phone, networking, etc).
We used to only generate the favicon if it was specified in the user
project settings, now it's optional, will export it to `NAME.icon.png`,
(falling back to the default project icon if none is set in project
settings), and the `<link>` tag is added using the `$HEAD_INCLUDE`
instead of being hardcoded in the template.
After further testing it seems to work fine now when building binaries with GCC 5
on Ubuntu 16.04 (previously we were using GCC 9 on Ubuntu 14.04).
Follow-up to #45629.
(cherry picked from commit aa15ad72ee)
We need to propagate the hacky checks from the raycast config to the
lightmapper config, as the failure of a `can_build()` check is not notified to
other modules (which might even be checked further depending on the processing
order in SConstruct).
A more thorough fix would be to change SConstruct to do two loops on modules:
one to check `can_build()` and disable modules which can't build, then another
one to rechecked `can_build()` with the new lineup and do further config.
But there would be more risk for regressions than with this ad hoc hack.
Similar story for the `platform/x11/detect.py` change... oh my eyes :(
in uwp's version of export.cpp create a ExportNotifier object so that EditorExportPlugin _export_begin and _export_end functions will be called as documentated.
(cherry picked from commit 564ddcde77)
We were using `Content-Length` from the server when `Content-Encoding`
was not set (i.e. response was not compressed).
Sadly, in CORS requests accessing headers is restricted, and while
`Content-Length` is enabled by default, `Content-Encoding` is not.
This results in the impossibility of knowing if the content was
compressed, unless the server explicitly enabled the encoding header
via `Access-Control-Expose-Headers`.
To keep maximum compatibility we must disable `body_size` completely.
(cherry picked from commit 737ed0f66e)
Promise chaining the emscripten module `then` function breaks it badly,
causing an infinite loop.
I'm unsure about the source of the issue, but most likely at this point
is due to the old emscripten version (I remember very old html5 builds
having issue with promise chaining too).
With this commit, we no longer use the module as a promise, and
instantiate it using `Promise` objects directly for compatibility.
(cherry picked from commit ae3c9345cc)
We might be able to make it work by building Mono itself with
ASLR protection too, but there might still be issues when loading
e.g. GDNative DLLs built without ASLR protection.
In the short term this is not a goal, but we can reconsider later
what is actually needed for ASLR protection to work and keep things
user-friendly.
This commit changes the way Thread::caller_id works. By moving caller_id
to the .cpp file we make sure that the TLS variable doesn't get
relocated twice causing a crash. Since we build with LTO for release
builds (and everyone should be doing that anyway) there is no extra
overhead from the non-static method. We do do an extra bool check now
there but I don't think this will add much in the way of overhead.
This check cannot be avoided if we still want to be able to cache the
thread ID hash, as we had to move the setter because of limitations of
the WinRT platform. The original workaround for this was in #46813 but
this has some unintended consequences. Specifically; threads that never
create a Thread object will always return 0 in Thread::get_caller_id()
which caused a regression. For instance the editor now freezes when
importing large textures. This PR also addresses that.
Additionally we now enable ASLR support when building with MingW, this
includes a workaround for MingW. MingW refuses to create an appropriate
relocation table if no symbols are exported. So we just export the
various main() functions in godot_windows.cpp.
While ASLR support isn't criticial for Godot, previous versions of Godot
just happened to work with a dynamic base 'by accident' and some users
run Godot this way. After the thread change the .tls section now needs
relocations to make this work. By enabling ASLR at build-time we create
these relocations and people who forced ALSR on previously will now get
a working Godot again.
This fixes#47256 and fixes#47219
This is the 3.x version of this PR. For master a different approach is
possible which I will make in the coming days.
`WebAssembly.instantiateStreaming` requires the mime-type to be
`application/wasm`, but some servers (including most debug servers) do
not provide the content-type header.
This commit forces it via JavaScript, by creating a `Response` object
with the `wasm` content, and explicitly defined `content-type` header.
(cherry picked from commit 778ef4e217)
Exposes AddressSanitizer support in MSVC compiler. Can be installed via individual
components in the Visual Studio 2019 Installer.
Disabled by default. Compile the engine with `scons use_asan=yes`.
(cherry picked from commit 53901d870b)
With a very nice hack, a new hidden configuration option that delays
dropped files removal at exit.
This still leaks while the project manager is running, but will clear
memory as soon as it exits or load something.
(reminder, dropped files are reguarly removed after the signal is
emitted specifically to avoid leaks, but I prefer hacking the HTML5
config then the project manager).
(cherry picked from commit f1e810adcb)
It used to be updated before the first iteration, causing the
window/viewport size values to be incorrect during the initialization
phase (e.g. during the first `_ready` notification).
(cherry picked from commit 3f059b90d6)
Added as an export option "Experimental Virtual Keyboard".
There is no zoom, so text/line edit must be in the top part of the
screen, or it will get hidden by the virtual keyboard.
UTF8/Latin-1 only (I think regular UTF-8 should work out of the box in
4.0 but I can't test it).
It uses an hidden textarea or input, based on the multiline variable,
and only gets activated if the device has a touchscreen.
This could cause problems on devices with both touchscreen and a real
keyboard (although input should still work in general with some minor
focus issues). I'm thinking of a system to detect the first physical
keystroke and disable it in case, but it might do more harm then good,
so it must be well thought.
