gdext VS godot-cpp

As an alternative, you can code in C++ or C#. If desired, Godot has bindings for other languages, such as Rust. Going ahead—in the end, C++ came in handy and useful for the project.

The world has moved on though to opinionated tools, and Rust isn't even the furthest in that direction (That would be Go). The equivalent of those two lines in Cargo.toml would be this example of a basic configuration from the jacoco-maven-plugin: https://www.jacoco.org/jacoco/trunk/doc/examples/build/pom.x... - That's 40 lines in the section to do the "defaults".

Yes, you could add a load of config for files to include/exclude from coverage and so on, but the idea that that's a norm is way more common in Java projects than other languages. Like here's some example Cargo.toml files from complicated Rust projects:

Servo: https://github.com/servo/servo/blob/main/Cargo.toml

rust-gdext: https://github.com/godot-rust/gdext/blob/master/godot-core/C...

ripgrep: https://github.com/BurntSushi/ripgrep/blob/master/Cargo.toml

socketio: https://github.com/1c3t3a/rust-socketio/blob/main/socketio/C...

Starting with Godot 4.0, they now support GDExtension which allows you to basically write your own game code in C++ (and other languages), then have the engine import your code: https://docs.godotengine.org/en/stable/tutorials/scripting/g.... There is also a set of Rust bindings that utilize GDExtension too: https://github.com/godot-rust/gdext.

They might be worth looking into.

Godot currently has 2 versions, the 3.X LTS version has a different api for which rust support ist fully there, that version is I think like 6months old and quite mature. The timeline for GDExtention Rust is difficult to predict but this is the status: https://github.com/godot-rust/gdext/issues/24

Adding onto this, I successfully written a game in Godot using gdnative / gdext. I started with a split approach using gdscript and rust for CPU intensive but found that the API layer was slow at transferring large amounts of data (serialization?). I ended up rewriting it in all rust and it worked like a charm. I was able to target native and web assembly, the web assembly was much slower but worked on the browser.

You can always port performance-sensitive parts of your code later to C#, or even Rust using GDExtension modules: https://github.com/godot-rust/gdext

I’ve recently switched from my own custom game engine written in Rust to Godot and want to use my knowledge in Rust to create game logic. I’ve looked at the book for godot-rust and can’t figure out how to use it properly. My goal is to write Rust code and implement it as a script in Godot 4.

To add to your point, here’s also godot-rust if you want something semi-native in godot

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.