Currently the GL thread is started / stopped when the activity is respectively resumed / paused. However, according to the `GLSurfaceView` documentation, this should be done instead when the activity is started / stopped, so this change updates the start / stop logic for the GL thread to match the documentation.
- m4gr3d
194452bf38
This breaks the build with our updated i686 Linux SDK which doesn't contain
this path, and may not be needed at all.
(cherry picked from commit 63153c9d36768b1e5ab9c1562f400a2bd8c2f8cd)
Quick fix for #82585.
A better fix requires refactoring the way we detect the compiler version
to make it more reliable, and get a consistent output. But I prefer to
keep changes minimal for 3.x branches at this point.
Also set CI version to 3.1.39, which is what we use for official 3.6 builds
since 3.6-beta4.
Remove the base error message in `OS`, we no longer really error out this
way for not implemented methods. Instead, each platform should override them
to provide the context they want.
Fixes#82439.
(cherry picked from commit 0a10f09ce4321695940a626eef9c64b36f599193)
- Set `-sSTACK_SIZE` to what it was before emscripten 3.1.27.
It was renamed in 3.1.25 so also set `-sTOTAL_SIZE` for older
versions for consistency.
- Set `-sDEFAULT_PTHREAD_STACK_SIZE` to what it was before 3.1.30.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
(cherry picked from commit 8e5fbd43488ad39a9b987c9abc38134841f44024)
This is done in a hacky way, mostly to keep it simple and avoid having
to do a refactoring of the `EditorExportPlatform` interface.
Only Windows and Linux use `EditorExportPlatformPC`, and thus to
handle the new architectures for Linux, we simply do a few checks here
and there with a couple new methods to register the export template
names for Linux arm64 and arm32.
For Godot 4.0, we did refactor everything to allow exporting binaries
for different architectures cleanly. For 3.6, which is likely the last
feature release for the 3.x branch, I tend to cut corners as these
improvements will be shorter lived and thus new tech debt isn't as big
a concern.
Fixes this error:
```
platform\uwp\os_uwp.cpp(715): error C3149: 'Windows::Storage::Streams::IBuffer': cannot use this type here without a top-level '^'
```
When a hardware keyboard is connected, all key events come through so we can route them directly to the engine.
This is not the case for soft keyboards, for which the current logic was designed as it requires extra processing.
- m4gr3d
620fdd1f07