If you know rust, the Godot rust bindings for GDExtension are also really good and let you use any Rust library in Godot (including tokio and async rust if you really want)
https://godot-rust.github.io/
> Engine modules are compiled into the engine itself. They have full access to the internals, but you need to build and ship your own copy of Godot, including the editor and export templates for every platform.
I’m not familiar with distributing godot games. If I build a game to distribute on steam (for example) would this be an option? Or is a GDExtension (runtime loaded .so) the standard way to go?
It depends on what your use case is. GDExtension is the standard way to go, unless its API is too limited and you have to access/modify engine internals not otherwise exposed.
That being said, this has no impact on distribution either way as far as I know.
GDExtension is the standard way. But building a custom version of Godot is common and won't be a problem for distributing the game on steam or any platform.
It's necessary to build your own godot version and export templates to produce an encrypted build not too easily hackable for example.
So, what profiling support is available to find the critical parts of your GDscript or C# code. Before needlessly jumping into c++ hassle for performance reasons? Tfa addresses functional reasons, which is ok.
I am building something similar, with c++26 reflection. So any language can use c++ libs with only a few lines of boilerplate in a lifetime and memory safe way where possible. And where it’s not possible to infer the safe lifetime of an object i got a small .toml file which tells the lib how to safely use those functions.
Just don't forget the versioning script needed on at least Linux. It's either that or build with the same older distro Godot uses, so you have a matching libstdc++ version. You can link with a newer stdlibc++ but you will need a linker versioning script that hides your impl from the dynamic linker so you don't get random ghosts in your machine.
Hi! Yes, you are right, thanks for pointing this out. It's something to keep in mind when distributing an extension for Linux. I have just updated the post with a note about it.
Hi! I don't think the boundary itself is the issue, although I'm not an expert on that part of Godot. My understanding is that the copy in this example comes from converting data from flecs into the layout MultiMesh expects. A different layout might reduce that work, but I haven't explored if fully zero-copy is possible.
I’m not familiar with distributing godot games. If I build a game to distribute on steam (for example) would this be an option? Or is a GDExtension (runtime loaded .so) the standard way to go?
That being said, this has no impact on distribution either way as far as I know.
Than started to move alot of heavy logic to c++ simulation : tedious indeed but the results speak for themself.
Basically allows me to use godot for things like menus dialogues and similar stuff while running the true heavy work in a c++ simulation.
the hierarchy and physics api isn’t great either, it’s easy to hit heap allocs even from a gdextension
a lot of things wrong with this generic engine, but at least it’s lightweight
A bit tedious but that's how it goes.
So, is a zero-copy impossible due to world (C++ vs Godot) boundaries?