Without this patch, the following exception is thrown when the touch
screen is used: TypeError: e.getBoundingClientRect is not a function.
No touch events arrive in the engine.
From my testing, this PR fixes the issue and behaves as expected.
Tested with godot-demo-projects/misc/multitouch_view/, emscripten 1.39.8
and Firefox mobile emulator as well as FF on Android
- Renames PackedIntArray to PackedInt32Array.
- Renames PackedFloatArray to PackedFloat32Array.
- Adds PackedInt64Array and PackedFloat64Array.
- Renames Variant::REAL to Variant::FLOAT for consistency.
Packed arrays are for storing large amount of data and creating stuff like
meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of
memory. That said, many users requested the ability to have 64 bits packed
arrays for their games, so this is just an optional added type.
For Variant, the float datatype is always 64 bits, and exposed as `float`.
We still have `real_t` which is the datatype that can change from 32 to 64
bits depending on a compile flag (not entirely working right now, but that's
the idea). It affects math related datatypes and code only.
Neither Variant nor PackedArray make use of real_t, which is only intended
for math precision, so the term is removed from there to keep only float.
It was initially implemented in #5871 for Godot 3.0, but never really
completed or thoroughly tested for most platforms. It then stayed in
limbo and nobody seems really keen to finish it, so it's better to
remove it in 4.0, and re-add eventually (possibly with a different API)
if there's demand and an implementation confirmed working on all
platforms.
Closes#8770.
Due to the port to Vulkan and complete redesign of the rendering backend,
the `drivers/gles3` code is no longer usable in this state and is not
planned to be ported to the new architecture.
The GLES2 backend is kept (while still disabled and non-working) as it
will eventually be ported to serve as the low-end renderer for Godot 4.0.
Some GLES3 features might be selectively ported to the updated GLES2
backend if there's a need for them, and extensions we can use for that.
So long, OpenGL driver bugs!
-Texture renamed to Texture2D
-TextureLayered as base now inherits 2Darray, cubemap and cubemap array
-Removed all references to flags in textures (they will go in the shader)
-Texture3D gone for now (will come back later done properly)
-Create base rasterizer for RenderDevice, RasterizerRD
Fixes compatibility with emscripten 1.39.5+ .
Most input callbacks now require a target and no longer support NULL
defaults.
This commit changes all required null targets to the expected default in
the binding phase.
Since for canvas-related callbacks there is no default, the "#canvas"
selector is used instead.
Additionally, since canvasX and canvasY event properties are no longer
supported, event positions are computed from "clientX" and "clientY" and
the "#canvas" bounding client rect.
It was removed as noted in the changelog:
https://github.com/emscripten-core/emscripten/blob/1.39.5/ChangeLog.md#v1395-12202019
> Removed `timestamp` field from mouse, wheel, devicemotion and
> deviceorientation events. The presence of a `timestamp` on these
> events was slightly arbitrary, and populating this field caused
> a small profileable overhead that all users might not care about.
> It is easy to get a timestamp of an event by calling
> `emscripten_get_now()` or `emscripten_performance_now()` inside
> the event handler function of any event.
Fixes#34648.
I'm barely scratching the surface of the changes needed to make the
--export command line interface easy to use, but this should already
improve things somewhat.
- Streamline `can_export()` templates check in all platforms, checking
first for the presence of official templates, then of any defined
custom template, and reporting on the absence of any.
Shouldn't change the actual return value much which is still true if
either release or debug is usable - we might want to change that
eventually and better validate against the requested target.
- Fix discrepancy between platforms using `custom_package/debug` and
`custom_template/debug` (resp. `release`).
All now use `custom_template`, which will break compatibility for
`export_presets.cfg` with earlier projects (but is easy to fix).
- Use `can_export()` when attempting a command line export and report
the same errors that would be shown in the editor.
- Improve error reporting after a failed export attempt, handling
missing template and invalid path more gracefully.
- Cleanup of unused stuff in EditorNode around the export workflow.
- Improve --export documentation in --help a bit.
Fixes#16949 (at least many of the misunderstandings listed there).
Fixes#18470.
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
The option is needed when using the 'fastcomp' backend (default before
1.39.0), and must not be defined when using 'upstream' (new default).
So we define it conditionally to support both backends.
Follow-up to #30751.
This allows setting the `read_chunk_size` of the internal HTTPClient.
This is important to reduce the allocation overhead and number of file
writes when downloading large files, allowing for better download speed.
Third-party platforms (e.g. console ports) need to be able to
disable JIT support in the regex module too, so it can't be
hardcoded in the module SCsub. This is cleaner this way anyway.
Fixes#19316.
Upstream Emscripten changed this in 1.39.1+, so IDBFS is no longer
included by default and has to be linked manually.
The explicit linking doesn't seem to be problematic on earlier
versions (tested `1.38.47-upstream`).
Fixes#33724.
A change in upstream Emscripten 1.39.1+ made our buildsystem error
out where it was previously only issuing a warning:
```
[ 5%] Linking Static Library ==> main/libmain.javascript.opt.bc
shared:WARNING: Assuming object file output in the absence of `-c`, based on output filename. Please add with `-c` or `-r` to avoid this warning
Ranlib Library ==> main/libmain.javascript.opt.bc
/opt/emsdk/upstream/bin/llvm-ranlib: error: unable to load 'main/libmain.javascript.opt.bc': file too small to be an archive
```
As advised on emscripten-core/emscripten#9806, we should be using
`emar` here to create the static library and not `emcc`.
This was apparently done to workaround Emscripten issues in the past,
but evidently this is no longer necessary.
The rest of the `env` redefinitions should probably be re-assessed
against the current state of Emscripten.
Fixes#33374.
Since most browsers no longer allow making async requests from a page
loaded from `file://`, we now need a proper HTTP server to load the
exported HTML5 game.
This should also allow us to get the debugger to work over a WebSocket
connection.
- Add or remove the necessary subdirectorires to the includes to remove
dependency on the editor directory being in the build's include path.
- Ensure includes in modified files conform to style guideline.
- Remove editor from the build include path.
So far we left most temporary files lying around, so this attempts to
fix that.
I added a helper method to DirAccess to factor out the boilerplate of
creating a DirAccess, checking if the file exists, remove it or print
an error on failure.
It is not supported in Emscripten's `latest-upstream` LLVM backend,
and doesn't seem necessary in the `latest` backend either.
It was initially added in #22857 to solve a compilation error with the latter.
Part of #30270.
Emscripten is apparently changing the variables in its config file,
causing potential breakage of our build system.
Binaries of the latest/latest-upstream releases are located in a
subfolder of BINARYEN_ROOT called emscripten.
Binaries of the other releases (e.g. sdk-1.38.31-64bit) are instead
placed under the EMSCRIPTEN_ROOT folder.
This PR checks if BINARYEN_ROOT has a subfolder called emscripten, if
that does not exists, it falls back to checking the EMSCRIPTEN_ROOT.
This way we give precedence to the new releases, given that activating
multiple releases sequentially might result in having mismatching
BINARYEN_ROOT and EMSCRIPTEN_ROOT.
Recent Emscripten SDK versions seem to only include the
`BINARYEN_ROOT` variable in the Emscripten configuration file,
whereas the platform's `detect.py` only looked at `EMSCRIPTEN_ROOT`.
