Non-exhaustive list of case-sensitive renames:
GDExtension -> GDNative
GDNATIVE -> GDEXTENSION
gdextension -> gdnative
ExtensionExtension -> Extension (for where there was GDNativeExtension)
EXTENSION_EXTENSION -> EXTENSION (for where there was GDNATIVE_EXTENSION)
gdnlib -> gdextension
gdn_interface -> gde_interface
gdni -> gde_interface
The `GDCLASS` macro should not assume to be called inside the `godot`
namespace and should thus prefix function calls for that namespace with
`::godot::` to ensure proper namespace referencing.
The unqualified ClassDB friending was causing (at least for me on
VS2022) an implicit forward declaration of ClassDB in the namespace
of my class, instead of using the godot namespaced one. By qualifying
the namespace, this compiles for me.
Test-Information:
My project builds now.
This is an attempt to make the lifecycle of wrapped objects clearer.
Godot keeps track of bindings' userdata for each object it creates.
This allows allocating the memory of the wrapper only once per object
even if that object is passed multiple times between binding code and
godot code.
The binding information is composed of multiple functions, this includes
a callback for when the userdata is to be allocated (called once) and
for when the userdata is to be deallocated (again, called once).
When allocating data with "memnew" we set the object bindings during the
postinitialize phase, but surely we shouldn't do that when allocating
the userdata as a result of bindings callback themselves.
Additionally, since we let Godot handle (and track) raw memory
allocation and de-allocation, we need to manually call the deconstructor
of the wrapper class during the free callback, to ensure that its
non-trivial members are correctly de-initialized.
Proper initialization for godot-cpp classes with memnew.
Extension classes (i.e. the `GDCLASS` macro) behave differently from
regular wrapped classes, and requires Godot to initialize them during
object construction.
This commit update the GDCLASS macro to not create/destroy the instance
during the bindings callback, but during the extension callbacks.
When setting the object instance, the bindings instance is set to the
pointer of the extension instance so that it can later be retrieved
normally via `object_get_instance_bindings`.
This makes sure custom constructors are always called on extension
classes. However, note that constructors should not take any parameters,
since Godot doesn't support that. Parameters are ignore in memnew macro.
Use memnew(MyClass()) instead of memnew(MyClass) since it now needs a
value instead of a class name. This macro calls MyClass::_new() (define
in GDCLASS macro) which ultimately calls Godot to create the object,
ensuring that both the Godot and the extension instances are created.
Non Godot classes (that don't derive godot::Object) are constructed as
usual an can have parameters.
memdelete is also changed for the same reason, as it needs to destroy
the Godot object as well, and that automatically frees the bound
extension instance.
Andy Maloney
Rémi Verschelde
Gilles Roudière
Emmanuel Leblond
Aaron Franke
Marc Gilleron
bruvzg
Fabio Alessandrelli
Kevin Smith
Bastiaan Olij
George Marques