Working, with emscripten > 2.0.9
Yes, the unreleased version. 2.0.9 works, but throws and error due to a
bug in emscripten with the thirdparty ENet library.
The issue is fixed upstream so newer releases will work.
This was caused by the devicePixelRatio being applied twice, once by the
HTML code, once by the OS code.
More specifically, OS.get_window_size() would return the canvas element
size, while OS.set_window_size() would set the element size to the
specified value times the devicePixelRatio.
Calling OS.set_window_size(OS.get_window_size()) would reapply the
devicePixelRatio every time.
This commit changes the behaviour so that OS.set_window_size() do not
apply the devicePixelRatio to the canvas element size, by it divides the
CSS size instead.
Applies to javascript files inside the platform library folder, the
exposed Engine code, and any javascript files in modules.
Files ending with ".externs.js" will be ignored, you can create a
".eslintignore" file to specify extra files to be ignored.
Initial work to make liniting easier.
This includes:
- Rename http_request.js to library_godot_http_request.js.
- Rename externs.js to engine.externs.js.
- New library_godot_runtime.js (GodotRuntime) wraps around emscripten
functions.
- Refactor of XMLHttpRequest handler in engine/preloader.js.
- Few fixes to bugs spotted by early stage linting.
Rewrote AudioDriverJavaScript to support multiple processor nodes.
The old (and deprecated) ScriptProcessorNode when threads are not
available, and the new AudioWorklet API when threads are enabled.
The new implementation uses two ring buffers and a shared state to
communicated with the AudioWorklet thread.
The audio.worklet.js JavaScript file is always added to the export
template, but only really used (and download) in the thread build.
The API is implemented in javascript, and generates C functions that can
be called from godot.
This allows much cleaner code replacing all `EM_ASM` calls in our C++
code with plain C function calls.
This also gets rid of few hacks and comes with few optimizations (e.g.
custom cursor shapes should be much faster now).
The size of the audio buffer was incorrectly doubled when creating the
script processor.
latencyHint is expressed in seconds, not milliseconds.
Additionally, on some browsers it actually affect the performance and
stability of the audio driver.
For this reason it has been completely disabled (interactive) and a not
has been left for future reference.
A new editor plugin, specific to HTML5, that provide some extra features
needed to make the editor usable on that platform.
For now, it adds a "Download project sources" option in the "Tool" menu,
so the user can download the work done as a zip file (from the browser
storage).
This should be made available in emscripten in a decent way.
Possibly after unmount, to free the database lock and allow performing
operations on it from javascript after the Emscripten Runtime has
exited.
This fixes a "random" deadlock when quitting the editor.
I still haven't figure out the root cause, but having a bigger seems to
greatly mitigate the issue.
The new pool size (pre-allocated threads) is now 8.
No longer parse emscripten/emsdk config to detect emcc/node paths.
Use WhereIs to find "emcc" and "node", look for "node_modules" in "emcc"
path.
(cherry picked from commit 7998745237)
This should fix some of the audio stuttering issues when the HTML5
export is compiled with threads support.
The API should be ported to AudioWorklet to (hopefully) be perfect.
That though, cannot be backported to 3.2 due to extra restriction of
AudioWorklet (which only runs in SecureContext, and needs a polyfill for
Safari).
This allow the page to be considered a SecureContext if the address is
localhost (127.0.0.1/::1) and let Firefox (and future Chrome versions)
enable extra features needed for the HTML5 threaded export.
The engine now expects to emscripten FS to be setup and sync-ed before
main is called. This is exposed via `Module["initFS"]` which also allows
to setup multiple persistence paths (internal use only for now).
Additionally, FS syncing is done **once** for every loop if at least one
file in a persistent path was open for writing and closed, and if the FS
is not syncing already.
This should potentially fix issues reported by users where "autosave"
would not work on the web (never calling `syncfs` because of too many
writes).
Fabio Alessandrelli
David Snopek
Rémi Verschelde
Marcel Admiraal