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.
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.
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).
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.
See discussion in #43811, it was only implemented on iOS and even that
implementation was fairly limited. This would best be provided as plugins
for Android and iOS without cluttering the shared OS API.
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.
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.
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.
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.
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.
`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.
This is beacuse on Android these values are already in m/s^2 while on
iOS and UWP they are in g. This just makes the behaviour consistent on
all platforms.
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`.
