Rust bindings for GDNative

Overview

GDNative bindings for Rust

Docs Status

Rust bindings to the Godot game engine.

Website | User Guide | API Documentation

Stability

The bindings cover most of the exposed API of Godot 3.2, and are being used on a number of projects in development, but we still expect non-trivial breaking changes in the API in the coming releases.

Engine compatibility

We are serious about engine compatibility. We are committed to keeping compatibility with the latest stable patch releases of all minor versions of the engine, starting from Godot 3.2.

The current minimum compatible version, with api.json replacement, is Godot 3.2-stable. Changes to this will be considered a breaking change, and will be called out in the release notes.

The bindings do not support Godot 4.0 (master branch) currently.

Requirements

The generator makes use of bindgen, which depends on Clang. Instructions for installing bindgen's dependencies for popular OSes can be found in their documentation: https://rust-lang.github.io/rust-bindgen/requirements.html.

bindgen may complain about a missing llvm-config binary, but it is not actually required to build the gdnative crate. If you see a warning about llvm-config and a failed build, it's likely that you're having a different problem!

Usage

Godot 3.2.3-stable

After bindgen dependencies are installed, add the gdnative crate as a dependency, and set the crate type to cdylib:

[dependencies]
gdnative = "0.9.3"

[lib]
crate-type = ["cdylib"]

Other versions or custom builds

The bindings are currently generated from the API description of Godot 3.2.3-stable by default. To use the bindings with another version or a custom build, see Using custom builds of Godot in the user guide.

Example

The most general use-case of the bindings will be to interact with Godot using the generated wrapper classes, as well as providing custom functionality by exposing Rust types as NativeScripts.

NativeScript is an extension for GDNative that allows a dynamic library to register "script classes" to Godot.

As is tradition, a simple "Hello World" should serve as an introduction. For a full tutorial, check out "Getting Started" from the user guide!

use gdnative::prelude::*;

#[derive(NativeClass)]
#[inherit(Node)]
pub struct HelloWorld;

#[methods]
impl HelloWorld {
    fn new(_owner: &Node) -> Self {
        HelloWorld
    }

    #[export]
    fn _ready(&self, _owner: &Node) {
        godot_print!("hello, world.");
    }
}

fn init(handle: InitHandle) {
    handle.add_class::<HelloWorld>();
}

godot_init!(init);

Further examples

The /examples directory contains several ready to use examples, complete with Godot projects and setup for easy compilation from Cargo:

Third-party resources

Tutorials

Open-source projects

Tools

Contributing

See the contribution guidelines

License

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be licensed under the MIT license, without any additional terms or conditions.

Comments
  • Continuous Integration Overhaul

    Continuous Integration Overhaul

    CI improvements:

    • Run time optimization (16min -> 6-11min)

      • Job-local cache of Rust, LLVM, Godot
      • Avoid unnecessary steps (e.g. cargo check instead of build, download LLVM only on Windows)
      • Parallelize independent steps into jobs (e.g. test and check-release)
      • Disable incremental compilation
    • Code ergonomics

      • Consistent use of external actions and their versions
      • Own composite actions for Rust and LLVM
      • Comments and explanations
    • New workflow Minimal CI

      • Runs automatically on PRs
      • Basic checks, unit tests and Godot integration tests on Linux
      • Very fast feedback (typically 2.5 - 4min)
    • Existing workflow Full CI

      • Fix nightly jobs not actually using nightly toolchain
      • Updated versions of external actions
      • Minor restructuring/grouping
      • Option to fast-fail on job and workflow level
      • Run tests against MSRV (excluding UI tests with expected compiler errors)
      • Naming of jobs/steps, colorized Cargo output
    feature c: ci 
    opened by Bromeon 60
  • serde support for core types & VariantDispatch

    serde support for core types & VariantDispatch

    I got curious about how hard it would be to add serde support, and ended up basically fully implementing it so I figured I should start a PR 😂

    There are no tests yet, and honestly I haven't really even tested it in my own project yet. I'll be doing so over the next few days probably, but for now I'll open this as a draft to allow for comments, feedback, and opinions.

    The implementations for Object types is a bit hacky, but I really like the idea of being able to replace Godot's resource files with something more Rust-y. Since I had to wrap the references in newtypes, I suppose they could be part of a separate crate anyway, unless anyone has a better idea of how to get around the orphan rules. Even if we can implement serde's traits directly on gdnative_core types, there should probably be some discussion about whether it's actually desirable to skip properties that are set to their defaults (this would end up serializing a LOT of properties otherwise).

    Would close #9

    feature c: core 
    opened by Waridley 51
  • [ios] Unable to load GDNative library on iOS simulator

    [ios] Unable to load GDNative library on iOS simulator

    I manage to compile successfully build for iOS using this code:

    #[macro_use]
    extern crate gdnative;
    
    #[derive(gdnative::NativeClass)]
    #[inherit(gdnative::Sprite)]
    struct Simpler;
    
    #[gdnative::methods]
    impl Simpler {
      fn _init(_owner: gdnative::Sprite) -> Self {
        Simpler 
      }
    
      #[export]
      unsafe fn _ready(&self, mut _owner: gdnative::Sprite) {
          godot_dbg!("Start");
      }
    
      #[export]
      unsafe fn _process(&mut self, mut owner: gdnative::Sprite, _delta: f64) {
        godot_dbg!("process called");
      }
    }
    
    fn init(handle: gdnative::init::InitHandle) {
      handle.add_class::<Simpler>();
    }
    
    
    godot_gdnative_init!();
    godot_nativescript_init!(init);
    godot_gdnative_terminate!();
    

    But not able to run it on the device.

    I added rustup target add aarch64-apple-ios and rustup target add x86_64-apple-ios then using cargo lipo to compile.

    During compilation was no issue. Final steps I added compiled libsimpler.a into my simpler.gdns: simpler.gdns

    After I exported to Xcode project and compile and run the sample on my Iphone I facing this bunch of errors (game doesn't crash):

    2020-05-15 11:28:25.835997+0800 Fc[365:10488] **ERROR**: Failed to obtain godot_gdnative_init symbol
    2020-05-15 11:28:25.836034+0800 Fc[365:10488]    At: modules/gdnative/gdnative.cpp:342:initialize() - Failed to obtain godot_gdnative_init symbol
    **ERROR**: Failed to obtain godot_gdnative_init symbol
       At: modules/gdnative/gdnative.cpp:342:initialize() - Failed to obtain godot_gdnative_init symbol
    2020-05-15 11:28:25.836110+0800 Fc[365:10488] **ERROR**: No valid library handle, can't get symbol from GDNative object
    2020-05-15 11:28:25.836165+0800 Fc[365:10488]    At: modules/gdnative/gdnative.cpp:483:get_symbol() - No valid library handle, can't get symbol from GDNative object
    **ERROR**: No valid library handle, can't get symbol from GDNative object
       At: modules/gdnative/gdnative.cpp:483:get_symbol() - No valid library handle, can't get symbol from GDNative object
    2020-05-15 11:28:25.836210+0800 Fc[365:10488] **ERROR**: No nativescript_init in "res://scripts/native/ios64/libsimpler.a" found
    2020-05-15 11:28:25.836278+0800 Fc[365:10488]    At: modules/gdnative/nativescript/nativescript.cpp:1506:init_library() - No nativescript_init in "res://scripts/native/ios64/libsimpler.a" found
    **ERROR**: No nativescript_init in "res://scripts/native/ios64/libsimpler.a" found
       At: modules/gdnative/nativescript/nativescript.cpp:1506:init_library() - No nativescript_init in "res://scripts/native/ios64/libsimpler.a" found
    

    What exactly I did wrong? Why is not working?

    help wanted question 
    opened by atonamy 38
  • Allow the use of the new Android ndk paths

    Allow the use of the new Android ndk paths

    Hi,

    As said in #345 comments, ndk is now installed in the ndk folder and the ndk-bundle folder installation is obsolete (as shown in the SDK Manager of Android studio). image

    The new way allow multiple ndk to be installed in parallel. If there is only one available, the build script pick this one. If multiple NDK versions are installed, you can specify one with the ANDROID_NDK_VERSION env var.

    It still fallbacks to the ndk-bundle folder just to maintain old behaviour.

    I added a check that the ndk is present too, and panic if absent, as it's needed for the headers.

    Feel free to ask for any modifications, I'm clearly not a rust expert. I manually tested all the code paths on my install, but I don't know where the tests for this are written (as they are not present in #345 PR).

    feature help wanted 
    opened by orion78fr 32
  • Simplify module structure II

    Simplify module structure II

    [Edit] Results are now visible on https://godot-rust.github.io/docs.


    This PR is a continuation of #788 and addresses the remaining, somewhat ambitious tasks for module cleanup.

    Goals:

    • Every symbol appears at most once in prelude
    • Every symbol appears at exactly once outside prelude
    • 2-3 modules (inside the crate) are the maximum nesting depth
    • Modules named according to related functionality from user point of view

    Changes:

    1. nativescript module

      • Rename to export. Rationale: "native script" is quite a wide term, while most the module's current functionality is directly related to exporting symbols from Rust. In practice, godot-rust is always (?) used as a native script. Other potential use cases, as a pure Godot API library or with native_calls, seem to be the exception, if at all.
      • Along with renaming, the nativescript feature is removed.
      • Nested symbols in export::{properties, methods} are moved one level up.
      • As a result, we can avoid very long qualifiers and multiple candidates for use statements.
        • nativescript::init::property::hint::EnumHint -> export::hint::EnumHint
        • nativescript::export::method::MethodBuilder -> export::MethodBuilder
    2. api module

      • Remove inner types like api::area::Area, as they are already present in api.
      • Remove all modules which would then become empty.
      • Create doc links between class (Camera2D) and related module (camera_2d).
    3. Smaller top-level modules

      • Add init (previously part of nativescript).
      • Add profiler (previously part of nativescript).
      • Extend log with related macros.
      • Remove macros and distribute its symbols to the most fitting API.
    4. prelude module

      • Remove a few macros (godot_gdnative_init etc.) from the prelude, suggesting that godot_init should be used.
      • user_data symbols are accessible through prelude::user_data instead of prelude directly. This mirrors common usage in examples.
    5. core_types module No changes in this PR; see PR discussion for reasons and potential alternatives.

    c: core documentation breaking-change quality-of-life 
    opened by Bromeon 26
  • Implement some of the Transform2D API in rust

    Implement some of the Transform2D API in rust

    As we discussed, here's an initial implementation of the Transform2D. The implementation is currently untested, so I'm marking it as a work-in-progress. I'm just posting this early so we can discuss if you thing this is the right approach :+1:

    The code closely follows the exposed GDScript API and even copies its documentation strings. The Implementation is adapted from Godot's C++ source code, delegating to glam (via Vector2) when necessary.

    I decided against adding a conversion between glam::Affine2 and Transform2D because it was not immediately clear to me if the mapping would be 1:1 (godot's Transform2D does not necessarily need to be an affine transformation, although it's assumed in certain places).

    Instead, I decided to just follow the C++ implementation, which was simple enough, to ensure results would be predictable when porting code from GDScript. We are still using glam underneath when delegating all of Vector3's operations, which happens in many places.

    feature c: core 
    opened by setzer22 26
  • Godot 3.5 support

    Godot 3.5 support

    Integrates support for Godot 3.5.1, including:

    Godot

    • Updated api.json + XML documentation
    • Version compatibility warning to avoid accidental mix-ups
    • CI suite for new engine version (+ support for RCs)
    • Backwards compatibility down to Godot 3.2, when using custom-godot feature

    Rust

    • MSRV 1.63
    • Updated crate dependencies
    feature c: bindings breaking-change c: ci 
    opened by Bromeon 24
  • Replace euclid with glam (proof-of-concept)

    Replace euclid with glam (proof-of-concept)

    I had some time to take a look at #594. I decided to go with glam since it compiles the fastest.

    I went with the "front-end" approach as I believe that is the most flexible approach.

    I did rename a few things (like zero() to ZERO, quaternion() to new(), ...) but that is easy to revert if required.

    It doesn't seem like many changes are required. Wrapping all the methods in glam is easy to do with extensive use of glam() and into(). The crate does seem to miss implementations for a few types and methods like Rect2 and rotated, so we'll have to implement those from scratch.

    the impl Mul/Div/Add/...s for Vector2 and Vector3 are pretty much identical, maybe there is some way to reduce duplication?

    Closes #594 Closes #670 (Vector3 is fully implemented)

    opened by Demindiro 23
  • error: Unsupported architecture [macOS->Android]

    error: Unsupported architecture [macOS->Android]

    This issue related to macOS.

    While I trying to build my script for Android using cargo build --target aarch64-linux-android I getting this (architecture not supported) compiler error:

    error: failed to run custom build command for `gdnative-sys v0.8.0`
    
    Caused by:
      process didn't exit successfully: `/Users/arsenius/Projects/godot/FC/scripts/target/debug/build/gdnative-sys-ef8bc7869be9b0c8/build-script-build` (exit code: 101)
    --- stdout
    cargo:warning=couldn't execute `llvm-config --prefix` (error: No such file or directory (os error 2))
    cargo:warning=set the LLVM_CONFIG_PATH environment variable to a valid `llvm-config` executable
    
    --- stderr
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_intptr_t.h:32:9: error: unknown type name '__darwin_intptr_t'
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'
    fatal error: too many errors emitted, stopping now [-ferror-limit=]
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture, err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported, err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/types.h:37:2: error: architecture not supported, err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_intptr_t.h:32:9: error: unknown type name '__darwin_intptr_t', err: true
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t', err: true
    fatal error: too many errors emitted, stopping now [-ferror-limit=], err: true
    thread 'main' panicked at 'Unable to generate bindings: ()', /Users/arsenius/.cargo/registry/src/github.com-1ecc6299db9ec823/gdnative-sys-0.8.0/build.rs:110:24
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    
    warning: build failed, waiting for other jobs to finish...
    error: build failed
    

    I used make_standalone_toolchain.py script to generate standalone NDKs for arm64, arm and x86 and then created ~/.cargo/config file with following data:

    [target.aarch64-linux-android]
    ar = "<path_to_standalone_ndk>/arm64/bin/aarch64-linux-android-ar"
    linker = "<path_to_standalone_ndk>/arm64/bin/aarch64-linux-android-clang"
    
    [target.armv7-linux-androideabi]
    ar = "<path_to_standalone_ndk>/arm/bin/arm-linux-androideabi-ar"
    linker = <path_to_standalone_ndk>/arm/bin/arm-linux-androideabi-clang"
    
    [target.i686-linux-android]
    ar = "<path_to_standalone_ndk>/x86/bin/i686-linux-android-ar"
    linker = "<path_to_standalone_ndk>/x86/bin/i686-linux-android-clang"
    

    How to solve this issue?

    bug 
    opened by atonamy 23
  • Fix `Dictionary::get` unsoundness and add a few convenience functions

    Fix `Dictionary::get` unsoundness and add a few convenience functions

    For some strange reason godot_dictionary_get calls Dictionary::operator[] instead of Dictionary::get, which ends up inserting Nil if the key doesn't already exist in the dictionary. https://github.com/godotengine/godot/blame/3.3/modules/gdnative/gdnative/dictionary.cpp#L126 This means it is unsound to call godot_dictionary_get on a Dictionary<Shared>. This PR re-implements godot-rust's Dictionary::get in terms of godot_dictionary_get_with_default (the behavior originally intended and likely expected by most Rust users), and adds Dictionary::get_or_insert_nil to provide the original behavior if it is indeed desired, but only on Dictionary<T: LocalThreadAccess> and an unsafe counterpart for Dictionary<Shared>, like the other mutating functions on Dictionary.

    I also updated the documentation of get_ref and get_mut_ref since they call operator[]. Perhaps they should also be moved to non-shared access, but I figured that's less important since they're unsafe anyway?

    I also added try_get and get_non_nil while I was at it, to simplify checking if a key exists and checking that its corresponding value is not Nil respectively.

    opened by Waridley 22
  • Add missing tests to #[methods] macro

    Add missing tests to #[methods] macro

    Added tests for the following features.

    • Minimal derive
    • Omitted inherit
    • Omitted base prameter
    • Method attribute
    • Deref return
    • Rename method

    I could not add a test for Rpc mode. We need a way to add a node to the scene tree during a test.

    c: export quality-of-life 
    opened by B-head 19
  • Implement automatic `NativeClass` registration via inventory. Implement mix-ins.

    Implement automatic `NativeClass` registration via inventory. Implement mix-ins.

    Implement automatic NativeClass registration via inventory

    This adds the optional inventory feature, which allows NativeClass types to be automatically registered on supported platforms (everything that OSS Godot currently supports except WASM).

    Run-time diagnostic functions are added to help debug missing registration problems that are highly likely to arise when porting inventory-enabled projects to WASM.

    An internal cfg_ex attribute macro is added to help manage cfg conditions.

    Close #350. Note that the standalone registration attribute syntax proposed by the original issue isn't implemented, for the limited usefulness -- there are much fewer cases where manual NativeClass impls are necessary thanks to all the improvements since the original issue.

    Implement mix-in #[methods] blocks

    Adds the #[methods(mixin = "Name")] syntax for declaring mix-in blocks. Mix-in blocks have a many-to-many relationship with NativeClass types. Both impl Type and impl Trait for Type blocks are accepted.

    The argument name is changed from as in the original proposal to mixin, because we might still want to keep universal #[methods] blocks in the future for ease of use with WASM. #[methods(mixin)] makes a lot more sense for a future auto-registered mixin block than #[methods(as /* as what? */)].

    All mix-in blocks have to be manually registered for gdnative v0.11.x. Some difficulty was encountered when trying to make auto-mixins compatible with existing code. It might still be possible with some tricks like autoref-specialization, but that might be too much effort given that we likely want to re-design much of the hierarchy for 0.12.

    Close #984.

    Allow #[register_with] for #[monomorphize]

    Enables #[monomorphize] to take the same standalone #[register_with] attribute as #[derive(NativeClass)]. This is chosen for short term consistency, but will probably change in a later version w/ #848, which might not still get implemented for a fair bit of time.

    feature c: export 
    opened by chitoyuu 3
  • Add a free-floating constructor for `Null<T>`

    Add a free-floating constructor for `Null`

    Created during survey of commented code (#377).

    Consider adding a module::null::<T>() constructor for Null<T> similar to std::ptr::null().

    quality-of-life 
    opened by chitoyuu 0
  • Unify string parameters across all builders

    Unify string parameters across all builders

    Created during survey of commented code (#377).

    As of Rust 1.63.0, the turbofish syntax can now be used along with impl Trait: https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html#turbofish-for-generics-in-functions-with-impl-trait

    As such, we now have more freedom to use types like impl Into<GodotString> or impl Into<Cow<'a, str>> where we need to take string arguments (for names) along with explicit type arguments in builders.

    This may still constitute a breaking change, if a technical one.

    c: export breaking-change quality-of-life 
    opened by chitoyuu 0
  • RPC mode for properties

    RPC mode for properties

    Created during survey of commented code (#377).

    See the official docs on RPC for more details.

    This can be exposed at two levels:

    • As a new method in PropertyBuilder.
    • As an attribute arguments for #[property]. The same syntax for #[method(rpc = "master")] can be used.
    feature c: export 
    opened by chitoyuu 0
  • Enforce `Plane` invariants via private fields & setters

    Enforce `Plane` invariants via private fields & setters

    Created during survey of commented code (#377).

    There are a number of invariants expected mathematically of the Plane type, that cannot currently be enforced due to the fields being public.

    A few issues to consider:

    • Should validation be performed when getting values from Godot, or should we just trust the engine with those invariants?
    • What about floating point errors? Should we just accept the drift or attempt to normalize after each operation? It could be useful to see what Godot does in its own source regarding this.

    A test should also be added for contains_point_eps.

    feature c: core breaking-change 
    opened by chitoyuu 2
  • Decide whether to expose `godot_char_string` publicly

    Decide whether to expose `godot_char_string` publicly

    Created during survey of commented code (#377).

    godot_char_string is a Godot string type representing a byte string of some encoding. It is currently used internally in the #[doc(hidden)] Utf8String type in the conversion process from GodotString to the Rust String.

    Reasons we might want this type to become public (likely with a re-designed API):

    • Sake of completeness.
    • Beyond UTF8, Godot also exposes functions to create char_strings in ascii and ascii_extended encodings, that could be interesting.

    Reasons we might want to remove it altogether in favor of inline FFI calls in conversion:

    • Extremely narrow API surface of the type that essentially consists of only a &[c_char] getter.
    feature c: core 
    opened by chitoyuu 2
Owner
GDNative bindings for the Rust programming language.
null
FPS library for gdnative written in Rust.

gd_rusty_fps FPS library for gdnative written in Rust. This projects aims to create easy to use .dll library to be used with godot engine for FPS game

null 1 Jan 4, 2022
A Rust wrapper and bindings of Allegro 5 game programming library

RustAllegro A thin Rust wrapper of Allegro 5. Game loop example extern crate allegro; extern crate allegro_font; use allegro::*; use allegro_font::*;

null 80 Dec 31, 2022
SDL bindings for Rust

Rust-SDL Bindings for SDL in Rust Overview Rust-SDL is a library for talking to SDL from Rust. Low-level C components are wrapped in Rust code to make

Brian Anderson 174 Nov 22, 2022
SDL2 bindings for Rust

Rust-SDL2 Bindings for SDL2 in Rust Changelog for 0.34.2 Overview Rust-SDL2 is a library for talking to the new SDL2.0 libraries from Rust. Low-level

null 2.2k Jan 5, 2023
SFML bindings for Rust

rust-sfml Rust bindings for SFML, the Simple and Fast Multimedia Library. Requirements Linux, Windows, or OS X Rust 1.42 or later SFML 2.5 CSFML 2.5 D

Jeremy Letang 567 Jan 7, 2023
Rust bindings for libtcod 1.6.3 (the Doryen library/roguelike toolkit)

Warning: Not Maintained This project is no longer actively developed or maintained. Please accept our apologies. Open pull requests may still get merg

Tomas Sedovic 226 Nov 17, 2022
Some Rust bindings for Binary Ninja

Binary Ninja Rust Bindings Work in progress Rust bindings geared towards analysis. Features added as they come up. No promises anything works at this

Cory Duplantis 21 May 5, 2022
Qt Quick / QML bindings for Rust

qmlrsng Qt Quick bindings for Rust, based on libqmlbind. The crate libqmlbind-sys wraps libqmlbind C library in Rust and exposes an unsafe API. The go

Nicolas Bigaouette 5 Jul 13, 2017
Idiomatic Rust bindings for Pdfium

Idiomatic Rust bindings for Pdfium pdfium-render provides an idiomatic high-level Rust interface around the low-level bindings to Pdfium exposed by th

Alastair Carey 65 Jan 8, 2023
Wein2D.js bindings for creating browser games in Rust using WebAssembly.

Wein2D.js-WASM Wein2D.js bindings for creating browser games in Rust using WebAssembly. Wein2D.js-WASM requires Wein2d.js to be loaded in the same doc

DevTaube 1 Apr 14, 2022
A simple Verlet integration solver written using the Rust SDL2 bindings.

Rust Verlet Solver A simple Verlet integration solver written using the Rust SDL2 bindings. Where's the friction?! Building cargo-vcpkg is required in

Will 8 Jun 6, 2022
MMDeploy bindings for Rust.

rust-mmdeploy-sys MMDeploy bindings for Rust. ?? THIS REPO IS STILL UNDER CONSTRUCTION! Prerequisites NOTICE: Linux only. Onnxruntime only. In order t

梦阳 2 Sep 29, 2022
Rust bindings for googleprojectzero/TinyInst

tinyinst-rs FFI to TinyInst. Created for LibAFL. Dependencies cxxbridge cargo-make python3 git Running the test Open a terminal and set up your build

Advanced Fuzzing League ++ 12 Jan 20, 2023
Rust bindings for entity-gym.

EntityGym for Rust EntityGym is a Python library that defines a novel entity-based abstraction for reinforcement learning environments which enables h

null 18 Apr 15, 2023
A simple Verlet integration solver written using the Rust SDL2 bindings.

Rust Verlet Solver A simple Verlet integration solver written using the Rust SDL2 bindings. Where's the friction?! Building cargo-vcpkg is required in

Will 8 Jun 6, 2022
corange-rs CorangeCorange lucidscape/corange-rs — Corange bindings

CORANGE-RS This crate provides an interface to the Corange game engine, written in Pure C, SDL and OpenGL by Daniel Holden. Features include: deferred

null 43 Jul 22, 2022
Pure and simple Vulkan bindings generated from Vulkan-Headers!

mira Pure and simple Vulkan bindings generated from Vulkan-Headers! Mira provides a simple and straightforward way to interact with Vulkan. Everything

maresia 3 Mar 3, 2022
Python bindings for egg

Python bindings for egg Installing Install maturin, a cool Rust/Python builder thingy. Download from their site or just pip install maturin. Type make

null 28 Dec 25, 2022
Bindings to TinyGL, a Small, Free and Fast Subset of OpenGL

TinyGL is a very lightweight partial OpenGL implementation. Its small size makes it ideal for static linking.

null 12 Oct 13, 2022