Enable Godot reinstantiation on iOS for embedding in a single view

[louis-prudhomme]

Partially adresses : godotengine/godot-proposals#1473.

The goal is to be able to run Godot from within a classically-made mobile app (think Snapchat Games). As underlined in the umbrella issue, several things will still be missing after this PR is merged :

1. boot splashscreen management : a way to enable / disable the boot splashscreen at will
2. export configuration : supporting project export as either an embeddable or a full-fledged standalone app

We faced many issues related to instanciating Godot several times. We fixed all of them, but are unsure for some fixes ; specificially, we came up using a queue to store StringName references. We are iOS developers and we're humble about our C++ knowledge, but we're committed to make this work ; any feedback is therefore much appreciated.

While the ability to embed Godot is functional with this PR, some manual adjustments are still required. An example implementation demonstrating how to embed Godot in a basic mobile app is available in our repository: here.

[AThousandShips]

You have a lot of TODOs in your code, was this supposed to be a draft? Is this ready for review?

[louis-prudhomme]

You have a lot of TODOs in your code, was this supposed to be a draft? Is this ready for review?

The several TODOs in the code are all linked to the same root cause. This is the part we're unsure of, but couldn't find a better way to make it work.

It could definitely be seen as a draft, but we're at our wits' end on this, so any feedback would be much appreciated. Not sure about the etiquette here, let me know if it should be converted to a draft.

[AThousandShips]

If it's ready to be reviewed and is in a form you would be comfortable merging it it should be marked as ready, if there are several issues still to resolve I'd suggest marking it as draft

Especially seeing how there's parts of the feature you haven't worked out how to solve yet

[bruvzg]

Extra cleanup is probably fine, but I'm not sure what you are trying to do with static StringNames. What's the purpose of reinitialization of StringNames or class info? It (and most low level stiff like OS) probably can be preserved and reused, you only need to reinitialize scene tree and view/view controller.

[bruvzg]

STL containers are not allowed, see https://docs.godotengine.org/en/stable/contributing/development/cpp_usage_guidelines.html#standard-template-library

[m4gr3d]

cc @kisg @migueldeicaza

[Xseuguh]

Extra cleanup is probably fine, but I'm not sure what you are trying to do with static StringNames. What's the purpose of reinitialization of StringNames or class info? It (and most low level stiff like OS) probably can be preserved and reused, you only need to reinitialize scene tree and view/view controller.

The purpose of reinitializing StringName is to enable embedding Godot within an existing iOS app as an external module. Our goal is to ensure that all objects created by the Godot instance are removed when exiting its view. To do so, we initialize Godot when launching it via a button and deinitialize it when exiting the Godot view.
To achieve this, the start and cleanup methods from the main Godot code are used. However, invoking the cleanup method results in a reference error during the next launch attempt.
To address this error, we reinitialize StringName.

[migueldeicaza]

We did originally try the clear approach a year ago, but found it very brittle, but it did serve as a good proof-of-concept that we could relaunch Godot multiple times.

For the stated goal of this PR, we ended up going with a more robust approach which is the libgodot/DisplayServerEmbedded approach patch that @kisg and his team developed and you can see in action here, and solves the iOS embedding problem, but also allows for not just embedding one view, but can support multiple views in the same screen (among other things):

#90510

You can take it for a spin on iOS with both Swift or Godot-cpp with the samples here:

https://github.com/migeran/libgodot_project

The patches here won't hurt, but in our view, are neither sufficient or desirable for the intended goal. They did spot the challenging StringName issue, which is the ugliest part of the reset approach, but from memory, this is about a third of the static state that needs to be properly reset, there are plenty more globals and statics that need to be worked on.