Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Concept] : [Q] Crate : Godot Extension #4145

Open
h0lybyte opened this issue Mar 1, 2025 · 3 comments
Open

[Concept] : [Q] Crate : Godot Extension #4145

h0lybyte opened this issue Mar 1, 2025 · 3 comments
Assignees
Labels
4 Level 4 staging This item is in progress.

Comments

@h0lybyte
Copy link
Member

h0lybyte commented Mar 1, 2025

Core Concept/Theory
We would need a clear and concise description of the concept. For example, It would be cool if [...]

It would be cool if Q could serve as a lightweight, all-in-one toolkit for Rust developers to extend Godot functionality, seamlessly integrating game management, audio handling, ECS architecture, and multi-threading into a single crate."


Alternative Ideas
Is there any other way this concept could be used?

Q could also be adapted as a modular framework, allowing developers to opt-in to specific features (e.g., just the Music Manager or Bevy ECS) instead of using the full suite, or extended to support additional Godot features like physics or UI management.


Alternative Examples/Sources
Are there any other references that you can provide?

Similar projects include the Godot Rust GDExtension examples (https://github.com/godot-rust/gdextension), Bevy Engine’s ECS approach (https://bevyengine.org/), and Tokio’s async runtime documentation (https://tokio.rs/). These could inspire further refinements or integrations for Q.


Additional information
Add any other context or examples of this concept here.

The Q crate is designed for developers familiar with Rust and Godot, aiming to reduce boilerplate code and improve performance. An example use case: managing a multiplayer game loop with Tokio while using Bevy ECS for entity updates, all within Godot’s ecosystem.

Rust Application Notes
GoDot Application Notes

@h0lybyte
Copy link
Member Author

h0lybyte commented Mar 1, 2025

TODO (1): Remove the extra String allocation:

  pub fn get(&self, key: &str) -> Option<Gd<T>> {
    self.map.pin().get(&key.to_string()).cloned()
  }

  pub fn get_arc(&self, key: &str) -> Option<Arc<Gd<T>>> {
    self.map
      .pin()
      .get(&key.to_string())
      .map(|gd| Arc::new(gd.clone()))
  }

  pub fn contains(&self, key: &str) -> bool {
    self.map.pin().contains_key(&key.to_string())
  }

The to_string() is not needed.

@h0lybyte h0lybyte added 4 Level 4 staging This item is in progress. and removed 0 Neutral Level enhancement New feature or request labels Mar 1, 2025
@h0lybyte h0lybyte moved this from Theory to Staging in KBVE Mar 1, 2025
@h0lybyte
Copy link
Member Author

h0lybyte commented Mar 3, 2025

For the string conversion

godot-rust/gdext#1062

Good to keep a reference of that for the future ^

@h0lybyte
Copy link
Member Author

h0lybyte commented Mar 5, 2025

Updated the extension to use v0.2.4 of GDExt and then fixing the user_data.rs to no longer use guards but rather pins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 Level 4 staging This item is in progress.
Projects
Status: Staging
Development

No branches or pull requests

1 participant