godot-cpp VS godot-jolt

Write C++ classes or functions using C++ bindings for the Godot engine.

Might have sth to do with https://github.com/godotengine/godot-cpp/issues/1057 . All of these errors pop up when godot::Refs are returned by certain engine functions like the one in FastNoiseLite but objects instantiated via memnew work like a charm. Plus with more gdextensions registered these issues seem to happen at more places.

I think part of the problem is that using GDExtension is like a two-way FFI. You can call (C++) extension functions from GDScript, but the same interface and overhead are used to call (lib) Godot functions from the (C++) extension.

Here's a good example (look, there I am!), although it's a bit old and actually led to perf improvement:

https://github.com/godotengine/godot-cpp/issues/1063

I've had some performance problems with GDExtensions: https://github.com/godotengine/godot-cpp/issues/1063

I tried checking out cpp repo for my godot version 4 from this repo

godot-cpp/gdextension/gdextension_interface.h

Thanks! At the moment I've been running into issues with accessing some methods of the AudioServer as well as overriding some native functions (primarily related to audio_stream and audio_stream_player). These issues on the issue tracker cover them: https://github.com/godotengine/godot-cpp/issues/1090 https://github.com/godotengine/godot-cpp/issues/1088 That said, there may be a way around this, it could just be that different bindings need to be used - currently the audio stream and audio stream player code is heavily based on existing classes like AudioStreamPlayerPolyphonic. Worst case I believe Godot itself needs to be updated to expose the appropriate bindings. I'll upload a separate branch for what I have for the GDExtensions version (though it fails compilation) sometime soon. I started this as a traditional Godot module during the 4.0 pre-alpha days but I definitely want to move it to GDExtension so its super easy for people to pull into the official engine release.

Some other Rust game engines ship with their own physics engine. Fyrox, for example, has advanced 2D/3D physics, supporting rigid bodies, joints, ray casting and more. Godot too, which has community-led Rust bindings also has an in-built physics engine as well as a Godot-native extension using the Jolt physics engine. In fact, which is reported to be more performant than the official physics engine.

When the performance of Godot's physics engine has been mentioned before I've seen https://github.com/godot-jolt/godot-jolt pointed to as a drop in more performant solution.

Haven't tried it in a project yet myself

No idea if this will solve your problems, but with Godot 4 Physics being a bit undercooked you might want to try a different physics engine. Like Godot-Jolt: https://github.com/godot-jolt/godot-jolt

Godot 4 itself is actually fairly good about diving to its C/C++ base for the nasty stuff. Like its Physics. The reimplementation for Jolt physics into Godot 4 is again C/C++ calculation library.

If you'd like to try out Godot Jolt for yourself, you can find the latest release, as well as important gotchas, on the project's GitHub page. Just bear in mind that the extension is still in development and will likely have a couple of bugs that have yet to be found. C# support for GDExtension is also not in a great place right now, so there are some issues there as well.

Try a different physics engine: https://github.com/godot-jolt/godot-jolt

Your comment made me do a bit of research and I found this: https://github.com/godot-jolt/godot-jolt

It's possible to create a GDExtension for it (similar to what was done for Jolt), but I haven't seen any for Bullet yet. There's a lot of hype going around Jolt, so it's understandably where most of the community effort is going :)

Or godot-jolt (linked in that Tweeter thread respones).