jojojet / bevy-trait-query Goto Github PK

View Code? Open in Web Editor NEW

64.0 2.0 10.0 128 KB

adds trait queries to the bevy game engine

License: Apache License 2.0

Rust 100.00%

bevy-engine bevy-plugin game-development rust

bevy-trait-query's People

Contributors

Stargazers

Watchers

Forkers

timjentzsch leafwing-studios itsdoot bzm3r hymm csh bennoinbeta robwalt no-materials

bevy-trait-query's Issues

Is `register_component_as` idempotent?

For my (a bit hacky) use-case of bevy-trait-query, I need to register a generic struct as a trait, for different generic variants that I can't know in advance.

Hence, I need to call register_component_as for certain user actions and cannot guarantee that the combination of generics is different every time.

Is register_component_as idempotent, i.e., is it fine to call it multiple times for the same combination of trait-component combinations?

Bevy 0.13.0 Compatibility

The release of Bevy 0.13.0 includes changes like (Bevy PR #9918) that affect bevy-trait-query. These updates likely require adjustments beyond a simple version bump.

Could we look into updating bevy-trait-query for Bevy 0.13.0 support? This would ensure continued compatibility for users relying on both.

In attempting to upgrade the crate for Bevy 0.13.0 compatibility and submitting a PR (#53), I realized the update entails more than a straightforward version bump due to intricacies in Bevy's Query system that I'm not yet familiar with.

Significant performance differences since benchmarks were last posted

Decided to compare the benchmark results from c757a17 (when benchmark results were last posted) until 2869f9d (latest commit at time of writing).

I noticed some significant performance differences, and am curious why that could be:

     Running benches/all.rs (target/release/deps/all-164e82f8f06f0a40)
Gnuplot not found, using plotters backend
All<> - 1 match         time:   [86.178 µs 86.584 µs 87.044 µs]
                        change: [+63.099% +63.800% +64.533%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 6 outliers among 100 measurements (6.00%)
  6 (6.00%) high severe

10000
All<> - 2 matches       time:   [115.23 µs 115.41 µs 115.63 µs]
                        change: [+33.806% +34.788% +35.940%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) high mild
  3 (3.00%) high severe

20000
All<> - 1-2 matches     time:   [99.420 µs 99.742 µs 100.10 µs]
                        change: [+41.814% +43.307% +44.795%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high severe

15000
     Running benches/concrete.rs (target/release/deps/concrete-fdfa9e097d2b391d)
Gnuplot not found, using plotters backend
concrete - 1 match      time:   [10.453 µs 10.460 µs 10.468 µs]
                        change: [+30.343% +31.453% +32.302%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

10000
concrete - 2 matches    time:   [10.536 µs 10.571 µs 10.609 µs]
                        change: [+21.170% +22.323% +23.419%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 13 outliers among 100 measurements (13.00%)
  1 (1.00%) low severe
  1 (1.00%) low mild
  5 (5.00%) high mild
  6 (6.00%) high severe

10000
     Running benches/fragmented.rs (target/release/deps/fragmented-599b12242e573cfa)
Gnuplot not found, using plotters backend
concrete - fragmented   time:   [1.0395 µs 1.0597 µs 1.0862 µs]
                        change: [-3.1553% -1.5826% -0.1409%] (p = 0.03 < 0.05)
                        Change within noise threshold.
Found 5 outliers among 100 measurements (5.00%)
  4 (4.00%) high mild
  1 (1.00%) high severe

4497169560
One<> - fragmented      time:   [3.1337 ns 3.1424 ns 3.1598 ns]
                        change: [-40.444% -40.207% -39.959%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 15 outliers among 100 measurements (15.00%)
  7 (7.00%) high mild
  8 (8.00%) high severe

0
All<> - fragmented      time:   [5.5079 µs 5.5820 µs 5.6784 µs]
                        change: [-0.0460% +0.7549% +1.6465%] (p = 0.08 > 0.05)
                        No change in performance detected.
Found 5 outliers among 100 measurements (5.00%)
  5 (5.00%) high severe

2014870000
     Running benches/one.rs (target/release/deps/one-6682cb865896f1c3)
Gnuplot not found, using plotters backend
One<>                   time:   [27.594 µs 27.610 µs 27.630 µs]
                        change: [+0.1968% +1.0798% +2.2258%] (p = 0.03 < 0.05)
                        Change within noise threshold.
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) high mild
  4 (4.00%) high severe

10000
One<> - filtering       time:   [14.427 µs 14.456 µs 14.496 µs]
                        change: [-0.8238% -0.6224% -0.3342%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) high mild
  2 (2.00%) high severe

5000

Semi-automatic registration

It is possible to make struct registration semi-automatic, using inventory crate. The solution simplifies registration a lot and does not require a centralized registration function with all the structs listed.

A feature (which may not be enabled by default) can be introduced to toggle this, since it requires an additional dependency which may not be wanted.

It can be achieved using these three things:

A helper struct:

pub struct Register(pub fn(&mut World));

An attribute #[register] for impl Trait for Struct, which generates:

inventory::submit!(bevy_trait_query::Register(|world| {
    use bevy_trait_query::RegisterExt;
    world.register_component_as::<dyn Trait, Struct>();
}));

A global registration function, which should be called manually (that's why the solution is semi-automatic):

fn register_traits(world: &mut World) {
    inventory::collect!(Register);
    for callback in inventory::iter::<Register> {
        callback(world);
    }
}

Add support for change detection filters `Changed<>`, `Added<>`, etc

TODO: figure out exact semantics

Add support for traits in Query filters

In my particular use case, I would like the ability to be able to use traits in a With<> or Without<> filter in the query.

Example:

pub fn cleanup_status(
    mut commands: Commands,
    q: Query<
        Entity,
        (
            With<PawnStatus<pawn_status::Attacking>>,
            Without<dyn work_order::OrderItem>,
        ),
    >,
) {
}

The above return a compile error because

the size for values of type (dyn OrderItem + 'static) cannot be known at compilation time the trait Sized is not implemented for (dyn OrderItem + 'static)
the trait bound (dyn OrderItem + 'static): bevy::prelude::Component is not satisfied
the following other types implement trait bevy::prelude::Component

The definition for OrderItem is as such:

    #[bevy_trait_query::queryable]
    pub trait OrderItem {}

jojojet / bevy-trait-query Goto Github PK

bevy-trait-query's People

Contributors

Stargazers

Watchers

Forkers

bevy-trait-query's Issues

Is `register_component_as` idempotent?

Bevy 0.13.0 Compatibility

Significant performance differences since benchmarks were last posted

Semi-automatic registration

Add support for change detection filters `Changed<>`, `Added<>`, etc

Add support for traits in Query filters

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent