Fixed: Error cause by attemptng to delete a NULL pointer.
unregister_gdnative_types() now checks discoverer to see if it is NULL
before deleting. After selecting a godot project to edit (in Win10), the
discoverer_callback() wasn't called thus discoverer was NULL.
After discussing with @reduz and @akien-mga it was decided that we do
not allow assignments or declarations in if statements. This PR removes
the instances of this I could find by automated means.
Basically, `GridMap` wasn't reacting to the
`NOTIFICATION_VISIBILITY_CHANGED` event. This reacts to such events and
walks over the set of `Octants` and all of their `MultiMeshInstances` to
set their visibility on the `VisualServer`.
A GDNativeLibrary now has a field "gdnative_singleton" which can be
used to let the `godot_gdnative_singleton` procedure be executed on
Godot's startup. In future this can be used to register new
scripting languages or resource importer types.
The changes include work done to ensure that GDNative apps and Nim
integration specifically can run on Android. The changes have been
tested on our WIP game, which uses godot-nim and depends on several
third-party .so libs, and Platformer demo to ensure nothing got broken.
- .so libraries are exported to lib/ folder in .apk, instead of assets/,
because that's where Android expects them to be and it resolves the
library name into "lib/<ABI>/<name>", where <ABI> is the ABI matching
the current device. So we establish the convention that Android .so
files in the project must be located in the folder corresponding to
the ABI they were compiled for.
- Godot callbacks (event handlers) are now called from the same thread
from which Main::iteration is called. It is also what Godot now
considers to be the main thread, because Main::setup is also called
from there. This makes threading on Android more consistent with
other platforms, making the code that depends on Thread::get_main_id
more portable (GDNative has such code).
- Sizes of GDNative API types have been fixed to work on 32-bit
platforms.
Apparently -ffast-math generates incorrect code with recent versions of
GCC and Clang. The manual page for GCC warns about this possibility.
In my tests it doesn't actually appear to be measurably slower in this
case, and this is used in a batch process so it seems safe to disable
this.
This fixes#10758 and fixes#10070
