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).
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.
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.
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)
`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)
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.
This allows to install it as an app, and provide offline support (after
the first run).
Practically, this boils down to adding a JSON file as a manifest, an
offline page to be displayed when the cached files are not avaialble,
and a JS file to cache resources and return them.
The reason for the "first run requirements" is that some browsers, will
emit an "install" by just visiting the page (to see if the JS code is
compatibile), and we do not want to force casual visitors to just
download the 10 MiB+ compressed editor WebAssembly file without pressing
the start button.
Special thanks to Hugo Locurcio (Calinou) for the initial work.
This allow the loading bar to be much more reliable, even in cases where
realible stream loading status is not detectable (server-side
compression, chunked encoding).
A template for `jsdoc` that generat the HTML5 public classref.
The script can be run via `npm run docs` to print to stdout.
You can dry run via `npm run docs -- --d dry-run` or write to file via
`npm run docs -- -d /path/to/file.rst`
Also update Makefile in `doc/` and add dry run test to CI.
(cherry picked from commit 472482013e)
This commit also removes the utils.js engine file, moving some of it's
content to config.js and some to engine.js .
(cherry picked from commit 018ee5a4dc)
We used to have it like `$GODOT_VERSION` which caused inconsistencies
between different scons versions when substituting it.
It's now `@GODOT_VERSION@`, which is safe on both scons3 and scons4.
(cherry picked from commit 4404eb57e4)
Three canvas resize policies:
- `None`: Godot window settings are ignored.
- `Project`: Godot handles the canvas like a native app (resizing it
when setting the window size).
- `Adaptive`: Canvas size will always adapt to browser window size.
Use `None` if you want to control the canvas size with custom JavaScript
code.
- Based on C++11's `thread` and `thread_local`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed (except for the few cases of non-portable functions)
- Simpler for `NO_THREADS`
- Thread ids are now the same across platforms (main is 1; others follow)
- Based on C++11's `mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
- `BinaryMutex` added for special cases as the non-recursive version
- `MutexLock` now takes a reference. At this point the cases of null `Mutex`es are rare. If you ever need that, just don't use `MutexLock`.
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
`OS.get_screen_scale` will now return the `window.devicePixelRatio`
value, `OS.get_screen_dpi` uses CSS media queries to find approximate
DPI value for the current display.
`OS.get_screen_size` also return the actual screen size (not the CSS
pixel size).
