It is possible that input comes before the engine is fully initialized.
This fixes the crashes that ocurred when that happens.
(cherry picked from commit 995724b762)
Starting from April 2018 Apple no longer accepts apps that do not
support iPhone X. For games this mainly means respecting the safe area,
unobstructed by notch and virtual home button. UI controls must be
placed within the safe area so that users can interact with them.
This commit:
- Adds OS::get_window_safe_area method that returns unobscured area of
the window, where interactive controls should be rendered.
- Reorganizes how launch screens are exported - the previous way was
incorrect and modern iPhones did not pick up the correct screens and
because of that used a non-native resolution to render the game.
- Adds launch screen options for iPhone X.
- Makes launch screens optional in the export template. If not
specified, a white screen will be used.
- Adds App Store icon (1024x1024) export option as it now has to be
bundled with the app instead of being provided in iTunes Connect.
- Fixes crash when launching games in iOS Simulator. It happened because
controllerWasConnected callback came before the engine was
initialized. Now in such case the controllers will be queued up and
registered after initialization is done.
- Fixes issue with the virtual keyboard where for some reason
autocorrection panel would intersect with the keyboard itself and not
allow you to use the top row of the keyboard. This is fixed by
disabling autocorrection altogether.
Closes#17358. Fixes#17428. Fixes#17331.
(cherry picked from commit 1d9a3a9b1c)
set_pause can be called before the driver is initialized, and there
already is a check for that. The problem is that the 'active' field
was not initialied in the constructor, which lead to it having an
undefined value.
(cherry picked from commit c10749d51f)
The previous logic with VERSION_MKSTRING was a bit unwieldy, so there were
several places hardcoding their own variant of the version string, potentially
with bugs (e.g. forgetting the patch number when defined).
The new logic defines:
- VERSION_BRANCH, the main 'major.minor' version (e.g. 3.1)
- VERSION_NUMBER, which can be 'major.minor' or 'major.minor.patch',
depending on whether the latter is defined (e.g. 3.1.4)
- VERSION_FULL_CONFIG, which contains the version status (e.g. stable)
and the module-specific suffix (e.g. mono)
- VERSION_FULL_BUILD, same as above but with build/reference name
(e.g. official, custom_build, mageia, etc.)
Note: Slight change here, as the previous format had the build name
*before* the module-specific suffix; now it's after
- VERSION_FULL_NAME, same as before, so VERSION_FULL_BUILD prefixed
with "Godot v" for readability
Bugs fixed thanks to that:
- Export templates version matching now properly takes VERSION_PATCH
into account by relying on VERSION_FULL_CONFIG.
- ClassDB hash no longer takes the build name into account, but limits
itself to VERSION_FULL_CONFIG (build name is cosmetic, not relevant
for the API hash).
- Docs XML no longer hardcode the VERSION_STATUS, this was annoying.
- Small cleanup in Windows .rc file thanks to new macros.
(cherry picked from commit 23ebae01dc)
Found via `codespell -q 3 --skip="./thirdparty,./editor/translations" -I ../godot-word-whitelist.txt`
Whitelist consists of:
```
ang
doubleclick
lod
nd
que
te
unselect
```
(cherry picked from commit 612ab4bbc6)
We were already linking libstdc++ statically for official binaries,
protecting us against most portability issues. But apparently since
we started using GCC 7 for official builds, we also need to link
libgcc statically for at least 32-bit builds to be portable.
Fixes#16409.
(cherry picked from commit b526088ae2)
Command line options were refactored for 3.0 to follow the common usage
of double-dashed long options, but `--main-pack` went through the cracks.
Fixes#16533.
(cherry picked from commit e3658a6464)
Current this is hardcoded as '1' for any platform except Unix. The
little is_wow64() dance is required to get correct output on a 32bit
compiled godot running on 64bit Windows according to MSDN.
This code should be UWP safe but I have no way to test that so it's not
implemented for UWP yet.
(cherry picked from commit b4d369c887)
The target of the TARGETS type should be XA_ATOM and not XA_TARGETS when
requested. Since we are sending a number of ATOMS the size should be set
to the integer size and not the char size.
The size field of the atoms is also the number of atoms and not the size
of the array. This caused some clients to wrongly interpret the data and
read garbage in the X11 packet.
I also add the more modern representation for UTF-8 and clarify the
error message if a client attempts to request a type we don't know
about.
This fixes#10431
(cherry picked from commit fb60f2dbe6)
