2
0
Fork 0
mirror of https://github.com/bevyengine/bevy synced 2024-12-27 05:23:07 +00:00
Commit graph

393 commits

Author SHA1 Message Date
Zicklag
e290a7e29c Implement Sub-App Labels ()
This is a rather simple but wide change, and it involves adding a new `bevy_app_macros` crate. Let me know if there is a better way to do any of this!

---

# Objective

- Allow adding and accessing sub-apps by using a label instead of an index

## Solution

- Migrate the bevy label implementation and derive code to the `bevy_utils` and `bevy_macro_utils` crates and then add a new `SubAppLabel` trait to the `bevy_app` crate that is used when adding or getting a sub-app from an app.
2021-08-24 00:31:21 +00:00
Carter Anderson
a89a954a17 Not me ... us ()
I don't see much of a reason at this point to boost my name over anyone elses. We are all Bevy Contributors.
2021-08-15 20:08:52 +00:00
davier
6aedb2500a Cleanup FromResources ()
## Objective

- Clean up remaining references to the trait `FromResources`, which was replaced in favor of `FromWorld` during the ECS rework.

## Solution

- Remove the derive macro for `FromResources`
- Change doc references of `FromResources` to `FromWorld`

(this is the first item in )
2021-08-13 22:21:34 +00:00
Klim Tsoutsman
0c91317102 Change definition of ScheduleRunnerPlugin ()
# Objective

- Allow `ScheduleRunnerPlugin` to be instantiated without curly braces. Other plugins in the library already use the semicolon syntax.
- Currently, you have to do the following:
```rust
App::build()
    .add_plugin(bevy::core::CorePlugin)
    .add_plugin(bevy::app::ScheduleRunnerPlugin {})
```
- With the proposed change you can do this:
```rust
App::build()
    .add_plugin(bevy::core::CorePlugin)
    .add_plugin(bevy::app::ScheduleRunnerPlugin)
```

## Solution

- Change the `ScheduleRunnerPlugin` definition to use a semicolon instead of curly braces.
2021-08-10 02:48:40 +00:00
François
b724a0f586 Down with the system! ()
# Objective

- Remove all the `.system()` possible.
- Check for remaining missing cases.

## Solution

- Remove all `.system()`, fix compile errors
- 32 calls to `.system()` remains, mostly internals, the few others should be removed after 
2021-07-27 23:42:36 +00:00
bjorn3
6d6bc2a8b4 Merge AppBuilder into App ()
This is extracted out of eb8f973646476b4a4926ba644a77e2b3a5772159 and includes some additional changes to remove all references to AppBuilder and fix examples that still used App::build() instead of App::new(). In addition I didn't extract the sub app feature as it isn't ready yet.

You can use `git diff --diff-filter=M eb8f973646476b4a4926ba644a77e2b3a5772159` to find all differences in this PR. The `--diff-filtered=M` filters all files added in the original commit but not in this commit away.

Co-Authored-By: Carter Anderson <mcanders1@gmail.com>
2021-07-27 20:21:06 +00:00
Carter Anderson
2e99d84cdc remove .system from pipelined code ()
Now that we have main features, lets use them!
2021-07-26 23:44:23 +00:00
Carter Anderson
955c79f299 adapt to upstream changes 2021-07-24 16:43:37 -07:00
Carter Anderson
ac6b27925e fix clippy 2021-07-24 16:43:37 -07:00
StarArawn
cdf06ea293 Added compute to the new pipelined renderer. 2021-07-24 16:43:37 -07:00
Carter Anderson
4ac2ed7cc6 pipelined rendering proof of concept 2021-07-24 16:43:37 -07:00
Carter Anderson
e167a1d9cf Relicense Bevy under the dual MIT or Apache-2.0 license ()
This relicenses Bevy under the dual MIT or Apache-2.0 license. For rationale, see .

* Changes the LICENSE file to describe the dual license. Moved the MIT license to docs/LICENSE-MIT. Added the Apache-2.0 license to docs/LICENSE-APACHE. I opted for this approach over dumping both license files at the root (the more common approach) for a number of reasons:
  * Github links to the "first" license file (LICENSE-APACHE) in its license links (you can see this in the wgpu and rust-analyzer repos). People clicking these links might erroneously think that the apache license is the only option. Rust and Amethyst both use COPYRIGHT or COPYING files to solve this problem, but this creates more file noise (if you do everything at the root) and the naming feels way less intuitive. 
  * People have a reflex to look for a LICENSE file. By providing a single license file at the root, we make it easy for them to understand our licensing approach. 
  * I like keeping the root clean and noise free
  * There is precedent for putting the apache and mit license text in sub folders (amethyst) 
* Removed the `Copyright (c) 2020 Carter Anderson` copyright notice from the MIT license. I don't care about this attribution, it might make license compliance more difficult in some cases, and it didn't properly attribute other contributors. We shoudn't replace it with something like "Copyright (c) 2021 Bevy Contributors" because "Bevy Contributors" is not a legal entity. Instead, we just won't include the copyright line (which has precedent ... Rust also uses this approach).
* Updates crates to use the new "MIT OR Apache-2.0" license value
* Removes the old legion-transform license file from bevy_transform. bevy_transform has been its own, fully custom implementation for a long time and that license no longer applies.
* Added a License section to the main readme
* Updated our Bevy Plugin licensing guidelines.

As a follow-up we should update the website to properly describe the new license.

Closes 
2021-07-23 21:11:51 +00:00
bjorn3
ebd10681ac Remove unused deps ()
# Objective

Reduce compilation time

# Solution

Remove unused dependencies. While this PR doesn't remove any crates from `Cargo.lock`, it may unlock more build parallelism.
2021-07-14 20:52:50 +00:00
Daniel McNab
c893b99224 Optional .system ()
This can be your 6 months post-christmas present.

# Objective

- Make `.system` optional
- yeet
- It's ugly
- Alternative title: `.system` is dead; long live `.system`
- **yeet**

## Solution

- Use a higher ranked lifetime, and some trait magic.

N.B. This PR does not actually remove any `.system`s, except in a couple of examples. Once this is merged we can do that piecemeal across crates, and decide on syntax for labels.
2021-06-27 00:40:09 +00:00
CGMossa
3106dc4937 Added helpful adders for systemsets ()
# Objective

- This adds a way to add `SystemSet`s to Apps.
2021-06-23 16:47:08 +00:00
Mika
73ae6af6ef Add inline documentation to bevy code ()
For review, first iteration of bevy code documentation.

I can continue submitting docs every now and then for relevant parts.

Some challenges I found:
* plugins example had to be commented out, as adding bevy_internal (where plugins reside) would pull in too many dependencies

Co-authored-by: Mika <1299457+blaind@users.noreply.github.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2021-05-06 02:26:54 +00:00
François
07e772814f add a span for frames ()
add a span for frames
2021-04-30 02:08:49 +00:00
Lucas Rocha
b1ed28e17e Hide re-exported docs ()
Solves  

Co-authored-by: caelumLaron <caelum.laron@gmail.com>
2021-04-27 18:29:33 +00:00
Alice Cecile
e4e32598a9 Cargo fmt with unstable features ()
Fresh version of  off the latest main.

Mostly fixing documentation wrapping.
2021-04-21 23:19:34 +00:00
François
d868d07d0b run some examples on CI using swiftshader ()
From suggestion from Godot workflows: https://github.com/bevyengine/bevy/issues/1730#issuecomment-810321110

* Add a feature `bevy_debug` that will make Bevy read a debug config file to setup some debug systems
  * Currently, only one that will exit after x frames
  * Could add option to dump screen to image file once that's possible
* Add a job in CI workflow that will run a few examples using [`swiftshader`](https://github.com/google/swiftshader)
  * This job takes around 13 minutes, so doesn't add to global CI duration

|example|number of frames|duration|
|-|-|-|
|`alien_cake_addict`|300|1:50|
|`breakout`|1800|0:44|
|`contributors`|1800|0:43|
|`load_gltf`|300|2:37|
|`scene`|1800|0:44|
2021-04-14 21:40:36 +00:00
Yoh Deadfall
04a37f722a Moved events to ECS ()
Fixes . It makes it also possible to use `derive` for `SystemParam` inside ECS and avoid manual implementation. An alternative solution to macro changes is to use `use crate as bevy_ecs;` in `event.rs`.
2021-04-13 20:36:37 +00:00
Carter Anderson
97d8e4e179 Release 0.5.0 () 2021-04-06 18:48:48 +00:00
Carter Anderson
7a511394ac Add register_component to AppBuilder and improve error message () 2021-03-26 04:15:07 +00:00
Jakob Hellermann
ad60046982 fix clippy lints () 2021-03-25 20:48:18 +00:00
Carter Anderson
1d7196da4f Add state app builder docs ()
This is intended to help protect users against . It doesn't resolve the issue, but I think its a good stop-gap solution for 0.5. A "full" fix would be very involved (and maybe not worth the added complexity).
2021-03-25 06:12:14 +00:00
Alexander Sepity
d3e020a1e7 System sets and run criteria v2 ()
I'm opening this prematurely; consider this an RFC that predates RFCs and therefore not super-RFC-like.

This PR does two "big" things: decouple run criteria from system sets, reimagine system sets as weapons of mass system description.

### What it lets us do:

* Reuse run criteria within a stage.
* Pipe output of one run criteria as input to another.
* Assign labels, dependencies, run criteria, and ambiguity sets to many systems at the same time.

### Things already done:
* Decoupled run criteria from system sets.
* Mass system description superpowers to `SystemSet`.
* Implemented `RunCriteriaDescriptor`.
* Removed `VirtualSystemSet`.
* Centralized all run criteria of `SystemStage`.
* Extended system descriptors with per-system run criteria.
* `.before()` and `.after()` for run criteria.
* Explicit order between state driver and related run criteria. Fixes .
* Opt-in run criteria deduplication; default behavior is to panic.
* Labels (not exposed) for state run criteria; state run criteria are deduplicated.

### API issues that need discussion:

* [`FixedTimestep::step(1.0).label("my label")`](eaccf857cd/crates/bevy_ecs/src/schedule/run_criteria.rs (L120-L122)) and [`FixedTimestep::step(1.0).with_label("my label")`](eaccf857cd/crates/bevy_core/src/time/fixed_timestep.rs (L86-L89)) are both valid but do very different things.

---

I will try to maintain this post up-to-date as things change. Do check the diffs in "edited" thingy from time to time.

Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2021-03-24 20:11:55 +00:00
Alice Cecile
ab0165d20d Improved documentation for Events ()
Explains subtle behavior more explicitly, documents `add_event`, mentions `EventWriter`.

Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2021-03-17 23:42:19 +00:00
TheRawMeatball
284889c64b Redo State architecture ()
An alternative to StateStages that uses SystemSets. Also includes pop and push operations since this was originally developed for my personal project which needed them.
2021-03-15 22:12:04 +00:00
Carter Anderson
b17f8a4bce format comments ()
Uses the new unstable comment formatting features added to rustfmt.toml.
2021-03-11 00:27:30 +00:00
Carter Anderson
be1c317d4e Resolve (most) internal system ambiguities ()
* Adds labels and orderings to systems that need them (uses the new many-to-many labels for InputSystem)
* Removes the Event, PreEvent, Scene, and Ui stages in favor of First, PreUpdate, and PostUpdate (there is more collapsing potential, such as the Asset stages and _maybe_ removing First, but those have more nuance so they should be handled separately)
* Ambiguity detection now prints component conflicts
* Removed broken change filters from flex calculation (which implicitly relied on the z-update system always modifying translation.z). This will require more work to make it behave as expected so i just removed it (and it was already doing this work every frame).
2021-03-10 22:37:02 +00:00
TheRawMeatball
d9b8b3e618 Add EventWriter ()
This adds a `EventWriter<T>` `SystemParam` that is just a thin wrapper around `ResMut<Events<T>>`. This is primarily to have API symmetry between the reader and writer, and has the added benefit of easily improving the API later with no breaking changes.
2021-03-07 20:42:04 +00:00
Carter Anderson
3a2a68852c Bevy ECS V2 ()
# Bevy ECS V2

This is a rewrite of Bevy ECS (basically everything but the new executor/schedule, which are already awesome). The overall goal was to improve the performance and versatility of Bevy ECS. Here is a quick bulleted list of changes before we dive into the details:

* Complete World rewrite
* Multiple component storage types:
    * Tables: fast cache friendly iteration, slower add/removes (previously called Archetypes)
    * Sparse Sets: fast add/remove, slower iteration
* Stateful Queries (caches query results for faster iteration. fragmented iteration is _fast_ now)
* Stateful System Params (caches expensive operations. inspired by @DJMcNab's work in )
* Configurable System Params (users can set configuration when they construct their systems. once again inspired by @DJMcNab's work)
* Archetypes are now "just metadata", component storage is separate
* Archetype Graph (for faster archetype changes)
* Component Metadata
    * Configure component storage type
    * Retrieve information about component size/type/name/layout/send-ness/etc
    * Components are uniquely identified by a densely packed ComponentId
    * TypeIds are now totally optional (which should make implementing scripting easier)
* Super fast "for_each" query iterators
* Merged Resources into World. Resources are now just a special type of component
* EntityRef/EntityMut builder apis (more efficient and more ergonomic)
* Fast bitset-backed `Access<T>` replaces old hashmap-based approach everywhere
* Query conflicts are determined by component access instead of archetype component access (to avoid random failures at runtime)
    * With/Without are still taken into account for conflicts, so this should still be comfy to use
* Much simpler `IntoSystem` impl
* Significantly reduced the amount of hashing throughout the ecs in favor of Sparse Sets (indexed by densely packed ArchetypeId, ComponentId, BundleId, and TableId)
* Safety Improvements
    * Entity reservation uses a normal world reference instead of unsafe transmute
    * QuerySets no longer transmute lifetimes
    * Made traits "unsafe" where relevant
    * More thorough safety docs
* WorldCell
    * Exposes safe mutable access to multiple resources at a time in a World 
* Replaced "catch all" `System::update_archetypes(world: &World)` with `System::new_archetype(archetype: &Archetype)`
* Simpler Bundle implementation
* Replaced slow "remove_bundle_one_by_one" used as fallback for Commands::remove_bundle with fast "remove_bundle_intersection"
* Removed `Mut<T>` query impl. it is better to only support one way: `&mut T` 
* Removed with() from `Flags<T>` in favor of `Option<Flags<T>>`, which allows querying for flags to be "filtered" by default 
* Components now have is_send property (currently only resources support non-send)
* More granular module organization
* New `RemovedComponents<T>` SystemParam that replaces `query.removed::<T>()`
* `world.resource_scope()` for mutable access to resources and world at the same time
* WorldQuery and QueryFilter traits unified. FilterFetch trait added to enable "short circuit" filtering. Auto impled for cases that don't need it
* Significantly slimmed down SystemState in favor of individual SystemParam state
* System Commands changed from `commands: &mut Commands` back to `mut commands: Commands` (to allow Commands to have a World reference)

Fixes 

## `World` Rewrite

This is a from-scratch rewrite of `World` that fills the niche that `hecs` used to. Yes, this means Bevy ECS is no longer a "fork" of hecs. We're going out our own!

(the only shared code between the projects is the entity id allocator, which is already basically ideal)

A huge shout out to @SanderMertens (author of [flecs](https://github.com/SanderMertens/flecs)) for sharing some great ideas with me (specifically hybrid ecs storage and archetype graphs). He also helped advise on a number of implementation details.

## Component Storage (The Problem)

Two ECS storage paradigms have gained a lot of traction over the years:

* **Archetypal ECS**: 
    * Stores components in "tables" with static schemas. Each "column" stores components of a given type. Each "row" is an entity.
    * Each "archetype" has its own table. Adding/removing an entity's component changes the archetype.
    * Enables super-fast Query iteration due to its cache-friendly data layout
    * Comes at the cost of more expensive add/remove operations for an Entity's components, because all components need to be copied to the new archetype's "table"
* **Sparse Set ECS**:
    * Stores components of the same type in densely packed arrays, which are sparsely indexed by densely packed unsigned integers (Entity ids)
    * Query iteration is slower than Archetypal ECS because each entity's component could be at any position in the sparse set. This "random access" pattern isn't cache friendly. Additionally, there is an extra layer of indirection because you must first map the entity id to an index in the component array.
    * Adding/removing components is a cheap, constant time operation 

Bevy ECS V1, hecs, legion, flec, and Unity DOTS are all "archetypal ecs-es". I personally think "archetypal" storage is a good default for game engines. An entity's archetype doesn't need to change frequently in general, and it creates "fast by default" query iteration (which is a much more common operation). It is also "self optimizing". Users don't need to think about optimizing component layouts for iteration performance. It "just works" without any extra boilerplate.

Shipyard and EnTT are "sparse set ecs-es". They employ "packing" as a way to work around the "suboptimal by default" iteration performance for specific sets of components. This helps, but I didn't think this was a good choice for a general purpose engine like Bevy because:

1. "packs" conflict with each other. If bevy decides to internally pack the Transform and GlobalTransform components, users are then blocked if they want to pack some custom component with Transform.
2. users need to take manual action to optimize

Developers selecting an ECS framework are stuck with a hard choice. Select an "archetypal" framework with "fast iteration everywhere" but without the ability to cheaply add/remove components, or select a "sparse set" framework to cheaply add/remove components but with slower iteration performance.

## Hybrid Component Storage (The Solution)

In Bevy ECS V2, we get to have our cake and eat it too. It now has _both_ of the component storage types above (and more can be added later if needed):

* **Tables** (aka "archetypal" storage)
    * The default storage. If you don't configure anything, this is what you get
    * Fast iteration by default
    * Slower add/remove operations
* **Sparse Sets**
    * Opt-in
    * Slower iteration
    * Faster add/remove operations

These storage types complement each other perfectly. By default Query iteration is fast. If developers know that they want to add/remove a component at high frequencies, they can set the storage to "sparse set":

```rust
world.register_component(
    ComponentDescriptor:🆕:<MyComponent>(StorageType::SparseSet)
).unwrap();
```

## Archetypes

Archetypes are now "just metadata" ... they no longer store components directly. They do store:

* The `ComponentId`s of each of the Archetype's components (and that component's storage type)
    * Archetypes are uniquely defined by their component layouts
    * For example: entities with "table" components `[A, B, C]` _and_ "sparse set" components `[D, E]` will always be in the same archetype.
* The `TableId` associated with the archetype
    * For now each archetype has exactly one table (which can have no components),
    * There is a 1->Many relationship from Tables->Archetypes. A given table could have any number of archetype components stored in it:
        * Ex: an entity with "table storage" components `[A, B, C]` and "sparse set" components `[D, E]` will share the same `[A, B, C]` table as an entity with `[A, B, C]` table component and `[F]` sparse set components.
        * This 1->Many relationship is how we preserve fast "cache friendly" iteration performance when possible (more on this later)
* A list of entities that are in the archetype and the row id of the table they are in
* ArchetypeComponentIds
    * unique densely packed identifiers for (ArchetypeId, ComponentId) pairs
    * used by the schedule executor for cheap system access control
* "Archetype Graph Edges" (see the next section)  

## The "Archetype Graph"

Archetype changes in Bevy (and a number of other archetypal ecs-es) have historically been expensive to compute. First, you need to allocate a new vector of the entity's current component ids, add or remove components based on the operation performed, sort it (to ensure it is order-independent), then hash it to find the archetype (if it exists). And thats all before we get to the _already_ expensive full copy of all components to the new table storage.

The solution is to build a "graph" of archetypes to cache these results. @SanderMertens first exposed me to the idea (and he got it from @gjroelofs, who came up with it). They propose adding directed edges between archetypes for add/remove component operations. If `ComponentId`s are densely packed, you can use sparse sets to cheaply jump between archetypes.

Bevy takes this one step further by using add/remove `Bundle` edges instead of `Component` edges. Bevy encourages the use of `Bundles` to group add/remove operations. This is largely for "clearer game logic" reasons, but it also helps cut down on the number of archetype changes required. `Bundles` now also have densely-packed `BundleId`s. This allows us to use a _single_ edge for each bundle operation (rather than needing to traverse N edges ... one for each component). Single component operations are also bundles, so this is strictly an improvement over a "component only" graph.

As a result, an operation that used to be _heavy_ (both for allocations and compute) is now two dirt-cheap array lookups and zero allocations.

## Stateful Queries

World queries are now stateful. This allows us to:

1. Cache archetype (and table) matches
    * This resolves another issue with (naive) archetypal ECS: query performance getting worse as the number of archetypes goes up (and fragmentation occurs).
2. Cache Fetch and Filter state
    * The expensive parts of fetch/filter operations (such as hashing the TypeId to find the ComponentId) now only happen once when the Query is first constructed
3. Incrementally build up state
    * When new archetypes are added, we only process the new archetypes (no need to rebuild state for old archetypes)

As a result, the direct `World` query api now looks like this:

```rust
let mut query = world.query::<(&A, &mut B)>();
for (a, mut b) in query.iter_mut(&mut world) {
}
```

Requiring `World` to generate stateful queries (rather than letting the `QueryState` type be constructed separately) allows us to ensure that _all_ queries are properly initialized (and the relevant world state, such as ComponentIds). This enables QueryState to remove branches from its operations that check for initialization status (and also enables query.iter() to take an immutable world reference because it doesn't need to initialize anything in world).

However in systems, this is a non-breaking change. State management is done internally by the relevant SystemParam.

## Stateful SystemParams

Like Queries, `SystemParams` now also cache state. For example, `Query` system params store the "stateful query" state mentioned above. Commands store their internal `CommandQueue`. This means you can now safely use as many separate `Commands` parameters in your system as you want. `Local<T>` system params store their `T` value in their state (instead of in Resources). 

SystemParam state also enabled a significant slim-down of SystemState. It is much nicer to look at now.

Per-SystemParam state naturally insulates us from an "aliased mut" class of errors we have hit in the past (ex: using multiple `Commands` system params).

(credit goes to @DJMcNab for the initial idea and draft pr here )

## Configurable SystemParams

@DJMcNab also had the great idea to make SystemParams configurable. This allows users to provide some initial configuration / values for system parameters (when possible). Most SystemParams have no config (the config type is `()`), but the `Local<T>` param now supports user-provided parameters:

```rust

fn foo(value: Local<usize>) {    
}

app.add_system(foo.system().config(|c| c.0 = Some(10)));
```

## Uber Fast "for_each" Query Iterators

Developers now have the choice to use a fast "for_each" iterator, which yields ~1.5-3x iteration speed improvements for "fragmented iteration", and minor ~1.2x iteration speed improvements for unfragmented iteration. 

```rust
fn system(query: Query<(&A, &mut B)>) {
    // you now have the option to do this for a speed boost
    query.for_each_mut(|(a, mut b)| {
    });

    // however normal iterators are still available
    for (a, mut b) in query.iter_mut() {
    }
}
```

I think in most cases we should continue to encourage "normal" iterators as they are more flexible and more "rust idiomatic". But when that extra "oomf" is needed, it makes sense to use `for_each`.

We should also consider using `for_each` for internal bevy systems to give our users a nice speed boost (but that should be a separate pr).

## Component Metadata

`World` now has a `Components` collection, which is accessible via `world.components()`. This stores mappings from `ComponentId` to `ComponentInfo`, as well as `TypeId` to `ComponentId` mappings (where relevant). `ComponentInfo` stores information about the component, such as ComponentId, TypeId, memory layout, send-ness (currently limited to resources), and storage type.

## Significantly Cheaper `Access<T>`

We used to use `TypeAccess<TypeId>` to manage read/write component/archetype-component access. This was expensive because TypeIds must be hashed and compared individually. The parallel executor got around this by "condensing" type ids into bitset-backed access types. This worked, but it had to be re-generated from the `TypeAccess<TypeId>`sources every time archetypes changed.

This pr removes TypeAccess in favor of faster bitset access everywhere. We can do this thanks to the move to densely packed `ComponentId`s and `ArchetypeComponentId`s.

## Merged Resources into World

Resources had a lot of redundant functionality with Components. They stored typed data, they had access control, they had unique ids, they were queryable via SystemParams, etc. In fact the _only_ major difference between them was that they were unique (and didn't correlate to an entity).

Separate resources also had the downside of requiring a separate set of access controls, which meant the parallel executor needed to compare more bitsets per system and manage more state.

I initially got the "separate resources" idea from `legion`. I think that design was motivated by the fact that it made the direct world query/resource lifetime interactions more manageable. It certainly made our lives easier when using Resources alongside hecs/bevy_ecs. However we already have a construct for safely and ergonomically managing in-world lifetimes: systems (which use `Access<T>` internally).

This pr merges Resources into World:

```rust
world.insert_resource(1);
world.insert_resource(2.0);
let a = world.get_resource::<i32>().unwrap();
let mut b = world.get_resource_mut::<f64>().unwrap();
*b = 3.0;
```

Resources are now just a special kind of component. They have their own ComponentIds (and their own resource TypeId->ComponentId scope, so they don't conflict wit components of the same type). They are stored in a special "resource archetype", which stores components inside the archetype using a new `unique_components` sparse set (note that this sparse set could later be used to implement Tags). This allows us to keep the code size small by reusing existing datastructures (namely Column, Archetype, ComponentFlags, and ComponentInfo). This allows us the executor to use a single `Access<ArchetypeComponentId>` per system. It should also make scripting language integration easier.

_But_ this merge did create problems for people directly interacting with `World`. What if you need mutable access to multiple resources at the same time? `world.get_resource_mut()` borrows World mutably!

## WorldCell

WorldCell applies the `Access<ArchetypeComponentId>` concept to direct world access:

```rust
let world_cell = world.cell();
let a = world_cell.get_resource_mut::<i32>().unwrap();
let b = world_cell.get_resource_mut::<f64>().unwrap();
```

This adds cheap runtime checks (a sparse set lookup of `ArchetypeComponentId` and a counter) to ensure that world accesses do not conflict with each other. Each operation returns a `WorldBorrow<'w, T>` or `WorldBorrowMut<'w, T>` wrapper type, which will release the relevant ArchetypeComponentId resources when dropped.

World caches the access sparse set (and only one cell can exist at a time), so `world.cell()` is a cheap operation. 

WorldCell does _not_ use atomic operations. It is non-send, does a mutable borrow of world to prevent other accesses, and uses a simple `Rc<RefCell<ArchetypeComponentAccess>>` wrapper in each WorldBorrow pointer. 

The api is currently limited to resource access, but it can and should be extended to queries / entity component access.

## Resource Scopes

WorldCell does not yet support component queries, and even when it does there are sometimes legitimate reasons to want a mutable world ref _and_ a mutable resource ref (ex: bevy_render and bevy_scene both need this). In these cases we could always drop down to the unsafe `world.get_resource_unchecked_mut()`, but that is not ideal!

Instead developers can use a "resource scope"

```rust
world.resource_scope(|world: &mut World, a: &mut A| {
})
```

This temporarily removes the `A` resource from `World`, provides mutable pointers to both, and re-adds A to World when finished. Thanks to the move to ComponentIds/sparse sets, this is a cheap operation.

If multiple resources are required, scopes can be nested. We could also consider adding a "resource tuple" to the api if this pattern becomes common and the boilerplate gets nasty.

## Query Conflicts Use ComponentId Instead of ArchetypeComponentId

For safety reasons, systems cannot contain queries that conflict with each other without wrapping them in a QuerySet. On bevy `main`, we use ArchetypeComponentIds to determine conflicts. This is nice because it can take into account filters:

```rust
// these queries will never conflict due to their filters
fn filter_system(a: Query<&mut A, With<B>>, b: Query<&mut B, Without<B>>) {
}
```

But it also has a significant downside:
```rust
// these queries will not conflict _until_ an entity with A, B, and C is spawned
fn maybe_conflicts_system(a: Query<(&mut A, &C)>, b: Query<(&mut A, &B)>) {
}
```

The system above will panic at runtime if an entity with A, B, and C is spawned. This makes it hard to trust that your game logic will run without crashing.

In this pr, I switched to using `ComponentId` instead. This _is_ more constraining. `maybe_conflicts_system` will now always fail, but it will do it consistently at startup. Naively, it would also _disallow_ `filter_system`, which would be a significant downgrade in usability. Bevy has a number of internal systems that rely on disjoint queries and I expect it to be a common pattern in userspace.

To resolve this, I added a new `FilteredAccess<T>` type, which wraps `Access<T>` and adds with/without filters. If two `FilteredAccess` have with/without values that prove they are disjoint, they will no longer conflict.

## EntityRef / EntityMut

World entity operations on `main` require that the user passes in an `entity` id to each operation:

```rust
let entity = world.spawn((A, )); // create a new entity with A
world.get::<A>(entity);
world.insert(entity, (B, C));
world.insert_one(entity, D);
```

This means that each operation needs to look up the entity location / verify its validity. The initial spawn operation also requires a Bundle as input. This can be awkward when no components are required (or one component is required).

These operations have been replaced by `EntityRef` and `EntityMut`, which are "builder-style" wrappers around world that provide read and read/write operations on a single, pre-validated entity:

```rust
// spawn now takes no inputs and returns an EntityMut
let entity = world.spawn()
    .insert(A) // insert a single component into the entity
    .insert_bundle((B, C)) // insert a bundle of components into the entity
    .id() // id returns the Entity id

// Returns EntityMut (or panics if the entity does not exist)
world.entity_mut(entity)
    .insert(D)
    .insert_bundle(SomeBundle::default());
{
    // returns EntityRef (or panics if the entity does not exist)
    let d = world.entity(entity)
        .get::<D>() // gets the D component
        .unwrap();
    // world.get still exists for ergonomics
    let d = world.get::<D>(entity).unwrap();
}

// These variants return Options if you want to check existence instead of panicing 
world.get_entity_mut(entity)
    .unwrap()
    .insert(E);

if let Some(entity_ref) = world.get_entity(entity) {
    let d = entity_ref.get::<D>().unwrap();
}
```

This _does not_ affect the current Commands api or terminology. I think that should be a separate conversation as that is a much larger breaking change.

## Safety Improvements

* Entity reservation in Commands uses a normal world borrow instead of an unsafe transmute
* QuerySets no longer transmutes lifetimes
* Made traits "unsafe" when implementing a trait incorrectly could cause unsafety
* More thorough safety docs

## RemovedComponents SystemParam

The old approach to querying removed components: `query.removed:<T>()` was confusing because it had no connection to the query itself. I replaced it with the following, which is both clearer and allows us to cache the ComponentId mapping in the SystemParamState:

```rust
fn system(removed: RemovedComponents<T>) {
    for entity in removed.iter() {
    }
} 
```

## Simpler Bundle implementation

Bundles are no longer responsible for sorting (or deduping) TypeInfo. They are just a simple ordered list of component types / data. This makes the implementation smaller and opens the door to an easy "nested bundle" implementation in the future (which i might even add in this pr). Duplicate detection is now done once per bundle type by World the first time a bundle is used.

## Unified WorldQuery and QueryFilter types

(don't worry they are still separate type _parameters_ in Queries .. this is a non-breaking change)

WorldQuery and QueryFilter were already basically identical apis. With the addition of `FetchState` and more storage-specific fetch methods, the overlap was even clearer (and the redundancy more painful).

QueryFilters are now just `F: WorldQuery where F::Fetch: FilterFetch`. FilterFetch requires `Fetch<Item = bool>` and adds new "short circuit" variants of fetch methods. This enables a filter tuple like `(With<A>, Without<B>, Changed<C>)` to stop evaluating the filter after the first mismatch is encountered. FilterFetch is automatically implemented for `Fetch` implementations that return bool.

This forces fetch implementations that return things like `(bool, bool, bool)` (such as the filter above) to manually implement FilterFetch and decide whether or not to short-circuit.

## More Granular Modules

World no longer globs all of the internal modules together. It now exports `core`, `system`, and `schedule` separately. I'm also considering exporting `core` submodules directly as that is still pretty "glob-ey" and unorganized (feedback welcome here).

## Remaining Draft Work (to be done in this pr)

* ~~panic on conflicting WorldQuery fetches (&A, &mut A)~~
    * ~~bevy `main` and hecs both currently allow this, but we should protect against it if possible~~
* ~~batch_iter / par_iter (currently stubbed out)~~
* ~~ChangedRes~~
    * ~~I skipped this while we sort out . This pr should be adapted to account for whatever we land on there~~.
* ~~The `Archetypes` and `Tables` collections use hashes of sorted lists of component ids to uniquely identify each archetype/table. This hash is then used as the key in a HashMap to look up the relevant ArchetypeId or TableId. (which doesn't handle hash collisions properly)~~
* ~~It is currently unsafe to generate a Query from "World A", then use it on "World B" (despite the api claiming it is safe). We should probably close this gap. This could be done by adding a randomly generated WorldId to each world, then storing that id in each Query. They could then be compared to each other on each `query.do_thing(&world)` operation. This _does_ add an extra branch to each query operation, so I'm open to other suggestions if people have them.~~
* ~~Nested Bundles (if i find time)~~

## Potential Future Work

* Expand WorldCell to support queries.
* Consider not allocating in the empty archetype on `world.spawn()`
    * ex: return something like EntityMutUninit, which turns into EntityMut after an `insert` or `insert_bundle` op
    * this actually regressed performance last time i tried it, but in theory it should be faster
* Optimize SparseSet::insert (see `PERF` comment on insert)
* Replace SparseArray `Option<T>` with T::MAX to cut down on branching
    * would enable cheaper get_unchecked() operations
* upstream fixedbitset optimizations
    * fixedbitset could be allocation free for small block counts (store blocks in a SmallVec)
    * fixedbitset could have a const constructor 
* Consider implementing Tags (archetype-specific by-value data that affects archetype identity) 
    * ex: ArchetypeA could have `[A, B, C]` table components and `[D(1)]` "tag" component. ArchetypeB could have `[A, B, C]` table components and a `[D(2)]` tag component. The archetypes are different, despite both having D tags because the value inside D is different.
    * this could potentially build on top of the `archetype.unique_components` added in this pr for resource storage.
* Consider reverting `all_tuples` proc macro in favor of the old `macro_rules` implementation
    * all_tuples is more flexible and produces cleaner documentation (the macro_rules version produces weird type parameter orders due to parser constraints)
    * but unfortunately all_tuples also appears to make Rust Analyzer sad/slow when working inside of `bevy_ecs` (does not affect user code)
* Consider "resource queries" and/or "mixed resource and entity component queries" as an alternative to WorldCell
    * this is basically just "systems" so maybe it's not worth it
* Add more world ops
    * `world.clear()`
    * `world.reserve<T: Bundle>(count: usize)`
 * Try using the old archetype allocation strategy (allocate new memory on resize and copy everything over). I expect this to improve batch insertion performance at the cost of unbatched performance. But thats just a guess. I'm not an allocation perf pro :)
 * Adapt Commands apis for consistency with new World apis 

## Benchmarks

key:

* `bevy_old`: bevy `main` branch
* `bevy`: this branch
* `_foreach`: uses an optimized for_each iterator
* ` _sparse`: uses sparse set storage (if unspecified assume table storage)
* `_system`: runs inside a system (if unspecified assume test happens via direct world ops)

### Simple Insert (from ecs_bench_suite)

![image](https://user-images.githubusercontent.com/2694663/109245573-9c3ce100-7795-11eb-9003-bfd41cd5c51f.png)

### Simpler Iter (from ecs_bench_suite)

![image](https://user-images.githubusercontent.com/2694663/109245795-ffc70e80-7795-11eb-92fb-3ffad09aabf7.png)

### Fragment Iter (from ecs_bench_suite)

![image](https://user-images.githubusercontent.com/2694663/109245849-0fdeee00-7796-11eb-8d25-eb6b7a682c48.png)

### Sparse Fragmented Iter

Iterate a query that matches 5 entities from a single matching archetype, but there are 100 unmatching archetypes

![image](https://user-images.githubusercontent.com/2694663/109245916-2b49f900-7796-11eb-9a8f-ed89c203f940.png)
 
### Schedule (from ecs_bench_suite)

![image](https://user-images.githubusercontent.com/2694663/109246428-1fab0200-7797-11eb-8841-1b2161e90fa4.png)

### Add Remove Component (from ecs_bench_suite)

![image](https://user-images.githubusercontent.com/2694663/109246492-39e4e000-7797-11eb-8985-2706bd0495ab.png)


### Add Remove Component Big

Same as the test above, but each entity has 5 "large" matrix components and 1 "large" matrix component is added and removed

![image](https://user-images.githubusercontent.com/2694663/109246517-449f7500-7797-11eb-835e-28b6790daeaa.png)


### Get Component

Looks up a single component value a large number of times

![image](https://user-images.githubusercontent.com/2694663/109246129-87ad1880-7796-11eb-9fcb-c38012aa7c70.png)
2021-03-05 07:54:35 +00:00
TheRawMeatball
fa73036f9d
Extend AppBuilder api with add_system_set and similar methods ()
Extend AppBuilder api with `add_system_set` and similar methods
2021-02-19 11:36:34 -08:00
Alexander Sepity
c2a427f1a3
Non-string labels ( continued) ()
Non-string labels
2021-02-18 13:20:37 -08:00
Alexander Sepity
d5a7330431
System sets and parallel executor v2 ()
System sets and parallel executor v2
2021-02-09 12:14:10 -08:00
MinerSebas
3475a64a2c
More Doctest changes ()
* Add system() to DocTests

* Hide use statements
2021-02-05 17:44:34 -08:00
Zicklag
bff44f76ec
Fix Un-Renamed add_resource Compile Error () 2021-01-30 13:32:46 -08:00
Alice Cecile
6f5a4d9deb
Rename add_resource to insert_resource ()
* Renamed add_resource to insert_resource

* Changed usage of add_resource to insert_resource

* Renamed add_thread_local_resource
2021-01-30 12:55:13 -08:00
Daniel McNab
b922a3ec60
Update init_resource to not overwrite ()
Update init_resource to not overwrite
2021-01-30 12:48:11 -08:00
TheRawMeatball
a880b54508
Make EventReader a SystemParam ()
* Add generic support for `#[derive(SystemParam)]`
* Make EventReader a SystemParam
2021-01-18 22:23:30 -08:00
Carter Anderson
3b2c6ce49b
release 0.4.0 () 2020-12-19 13:28:00 -06:00
Carter Anderson
841755aaf2
Adopt a Fetch pattern for SystemParams () 2020-12-15 21:57:16 -08:00
Carter Anderson
b12e3bf3bb
Improve usability of StateStage and cut down on "magic" ()
Improve usability of StateStage and cut down on "magic"
2020-12-14 17:13:22 -08:00
Carter Anderson
509b138e8f
Schedule v2 ()
Schedule V2
2020-12-12 18:04:42 -08:00
Joshua J. Bouw
9f4c8b1b9a
Fix errors and panics to typical Rust conventions ()
Fix errors and panics to typical Rust conventions
2020-12-02 11:31:16 -08:00
Mariusz Kryński
d96493a42a
use wasm-friendly instant::Instant everywhere ()
* use instant::Instant everywhere
* reexport instant::{Duration, Instant} from bevy_utils
2020-11-21 16:38:24 -08:00
bjorn3
0dbbcd98b6
Expose an EventId for events ()
* Expose an EventId for events

This can be helpful for correlating the place where an event is created
to the place where the event is processed.
2020-11-21 14:03:18 -08:00
Carter Anderson
3a6f6de277
System Inputs, Outputs, Chaining, and Registration Ergo ()
System Inputs, Outputs, Chaining, and Registration Ergo
2020-11-16 18:18:00 -08:00
Carter Anderson
e03f17ba7f
Log Plugin ()
add bevy_log plugin
2020-11-12 17:23:57 -08:00
Robert Swain
a266578992
Add tracing spans to schedules, stages, systems ()
Add tracing spans to schedules, stages, systems
2020-11-10 18:49:49 -08:00
Carter Anderson
ebcdc9fb8c
Flexible ECS System Params ()
system params can be in any order, faster compiles, remove foreach
2020-11-08 12:34:05 -08:00
Carter Anderson
9afe196f16
release: 0.3.0 () 2020-11-03 13:34:00 -08:00
memoryruins
e21705bec6
Remove two unused deps () 2020-11-03 11:38:37 -08:00
Carter Anderson
66f2f76a18
rename add_plugin_group to add_plugins () 2020-11-02 19:01:17 -08:00
Nathan Stocks
9871e7e24b
Remove add_default_plugins and add MinimalPlugins for simple "headless" scenarios ()
Remove add_default_plugins and add MinimalPlugins for simple "headless" scenarios
2020-11-02 18:38:37 -08:00
Carter Anderson
bf2a917b81
app: PluginGroups and DefaultPlugins () 2020-10-29 13:04:28 -07:00
Boxy
8c053e7c67
Run app.initialize in the run_once runner () 2020-10-28 16:43:17 -07:00
CGMossa
58eb7e7e05
Documenting small things here and there.. ()
Documenting small things here and there..
2020-10-21 15:57:03 -07:00
Carter Anderson
267599e577
gamepad: expose raw and filtered gamepad events. () 2020-10-21 15:56:07 -07:00
Carter Anderson
c32e637384
Asset system rework and GLTF scene loading () 2020-10-18 13:48:15 -07:00
Tomasz Sterna
149c39950a
Runners explicitly call App.initialize() () 2020-10-18 12:25:33 -07:00
Carter Anderson
930eba4ccd
add thread local resources () 2020-10-12 15:09:44 -07:00
Carter Anderson
1f27d8c727
fix new clippy error () 2020-10-10 12:16:52 -07:00
Grayson Burton
354d71cc1f
The Great Debuggening ()
The Great Debuggening
2020-10-08 11:43:01 -07:00
EthanYidong
4c753e2588
move dynamic plugin loading to its own optional crate ()
move dynamic plugin loading to its own crate
2020-10-01 13:04:06 -07:00
Jonas Matser
3a4eacbdee
Adds derive for missing debug implementations () 2020-10-01 10:58:21 -07:00
Daniel McNab
cd9e502b12
Fix ScheduleRunnerPlugin ()
Fixes 
2020-10-01 10:52:29 -07:00
Tomasz Sterna
408114269b
Use instant::Instant with wasm-bindgen feature () 2020-09-27 12:55:06 -07:00
Carter Anderson
028a22b129
asset: use bevy_tasks in AssetServer () 2020-09-21 20:23:09 -07:00
memoryruins
fd1d6a388d
Stop looping when scheduler receives an AppExit () 2020-09-20 16:32:07 -07:00
Carter Anderson
74dba5f36b
release: 0.2.1 () 2020-09-20 15:58:32 -07:00
Carter Anderson
ba5af4dd56
release: 0.2.0 () 2020-09-19 15:29:08 -07:00
Boiethios
d4c8436457
Add AppBuilder::add_startup_stage_[before/after] ()
Co-authored-by: Boiethios <felix-dev@daudre-vignier.fr>
2020-09-18 13:30:54 -07:00
Carter Anderson
70ad6671db
ecs: use generational entity ids and other optimizations ()
ecs: use generational entity ids and other optimizations
2020-09-17 17:16:38 -07:00
Tomasz Sterna
34c6f5f41b
Implement WASM support for bevy_winit ()
Also, replaced wasm_timer::Instant with instant::Instant as it is
used by winit WASM implementation.
2020-09-16 13:40:32 -07:00
Tomasz Sterna
2b0ee24a5d
Implement single threaded task scheduler for WebAssembly ()
* Add hello_wasm example

* Implement single threaded task scheduler for WebAssembly
2020-09-15 18:05:31 -07:00
Tomasz Sterna
12deb0bd91
Initialize+Run systems when running the app ()
This is required, so Local<> resources get initialized before systems run.
2020-09-10 12:56:37 -07:00
Smite Rust
a9ce7f4e82
update dependencies () 2020-09-10 12:54:24 -07:00
Philip Degarmo
8b3553002d
Reworked parallel executor to not block ()
Reworked parallel executor to not block
2020-09-05 22:05:33 -07:00
Waridley
4e587db775
Feature to disable libloading ()
esp. helpful for wasm target
Made default only for `bevy` crate
2020-09-01 17:02:11 -07:00
Philip Degarmo
b91fd8a43a
Quick fix for ()
- Use saturating_sub to avoid overflow in core assignment to task pools
- Temporarily force 4 minimum threads to avoid examples stalling
2020-09-01 11:06:45 -07:00
Lachlan Sneff
17e7642611
Task System for Bevy ()
Add bevy_tasks crate to replace rayon
2020-08-29 12:35:41 -07:00
Carter Anderson
b925e22949 0.1.3 upgrade 2020-08-22 10:16:52 -07:00
mfrancis107
47f3a0b8be
Changes ScheduleRunnerPlugin RunMode::Loop to run on fixed interval ()
* Changes ScheduleRunnerPlugin RunMode::Loop to run on fixed interval

* fix formatting
2020-08-21 19:31:46 -07:00
Victor "multun" Collod
c38420f1e9 enforce clippy for all target and features 2020-08-16 07:20:06 -07:00
Victor "multun" Collod
d138647818 enforce cargo fmt --check 2020-08-16 05:02:06 -07:00
Carter Anderson
423c5e3e0f ecs: prepare for publishing 2020-08-09 18:16:12 -07:00
Carter Anderson
34752a27bd add "0.1" version to all bevy crate references 2020-08-09 17:39:28 -07:00
Carter Anderson
9aee5323e1 add crate metadata 2020-08-09 17:24:27 -07:00
Carter Anderson
3d09459813 add more doc comments and clean up some public exports 2020-08-09 16:13:04 -07:00
Carter Anderson
f963cd41dc app: rename AppPlugin to Plugin 2020-08-07 20:22:17 -07:00
Thomas Herzog
b4c185eb0c cargo fmt 2020-07-26 21:10:18 +02:00
Carter Anderson
93bb1d5b8e ui: initial flexbox support 2020-07-24 23:04:45 -07:00
Carter Anderson
6cad80d572 transform|ui: fix transform update lag 2020-07-23 18:26:08 -07:00
Carter Anderson
a4e291d9c8 app: default app runner now runs the schedule once 2020-07-22 13:32:17 -07:00
Carter Anderson
946d5d1024 ecs: refactor resources
fixes unintialized global resource memory
2020-07-19 14:23:06 -07:00
Carter Anderson
f742ce3ef2 app: simplify app imports 2020-07-16 18:47:51 -07:00
Carter Anderson
196bde64e3 cargo fmt 2020-07-16 17:23:50 -07:00
Carter Anderson
d9adea1b5e transform: TransformPlugin 2020-07-16 16:32:39 -07:00
Carter Anderson
362fb92cf8 ecs: only prepare executor on changes. use parallel executor in App 2020-07-15 17:59:13 -07:00
Carter Anderson
fb2dfba5e3 upgrade libloading 2020-07-10 16:11:25 -07:00
Carter Anderson
a656588788 slim down gltf and winit features and remove unused dependencies 2020-07-10 12:08:51 -07:00
Carter Anderson
c81ab99dac cargo fmt 2020-07-10 01:37:06 -07:00
Carter Anderson
950e50bbb1 Bevy ECS migration 2020-07-10 01:06:21 -07:00
Carter Anderson
4f73dca34d add system profile data to Diagnostics (opt in feature) 2020-06-28 01:01:40 -07:00
Carter Anderson
92c44320ee ecs: rename EntityArchetype to ComponentSet 2020-06-25 11:21:56 -07:00
Carter Anderson
6cd5af6f74 app: move startup stages to their own module 2020-06-22 12:55:00 -07:00
Carter Anderson
1dd81587dd events: iter_current_update_events 2020-06-16 22:20:08 -07:00
Carter Anderson
e855995145 cargo fmt 2020-06-15 12:47:35 -07:00
Carter Anderson
e8e3e3c20f move FloatOrd to bevy_core 2020-06-10 15:35:23 -07:00
Carter Anderson
4568f5dae3 remove specialization. bevy now builds on stable rust! 2020-06-07 23:36:39 -07:00
Carter Anderson
70e9892e00 remove bevy_derive from bevy crate and export derives from specific crates 2020-06-07 12:22:16 -07:00
Carter Anderson
ab31bf9d9e impl Default for EventReader 2020-06-03 23:53:00 -07:00
Carter Anderson
4979a06e90 input: fix input example and add cursor move events 2020-06-03 23:22:32 -07:00
Carter Anderson
6eea96366d cargo fmt 2020-06-03 20:08:20 -07:00
Carter Anderson
bab2ad335d add post_startup stage 2020-05-25 16:00:05 -07:00
Carter Anderson
d920100d35 scenes: deserialization and refactor 2020-05-21 17:21:33 -07:00
Carter Anderson
a88982fbfb move universe into Resources 2020-05-19 12:20:14 -07:00
Carter Anderson
bf7f222318 Support async texture loading 2020-05-15 19:30:02 -07:00
Carter Anderson
2bcb8a2a41 cargo fmt 2020-05-13 18:05:18 -07:00
Carter Anderson
6381611e89 Resource -> Res, Ref->Com 2020-05-13 17:57:08 -07:00
Carter Anderson
a7eaf32e7c drainable/extendable events 2020-05-13 16:17:06 -07:00
Carter Anderson
c5ca59dc4d cargo fmt 2020-05-05 18:44:32 -07:00
Carter Anderson
2fb9e115ff Make ecs_guide a "real game" 2020-05-03 00:21:32 -07:00
Carter Anderson
7b79b3de8d organize examples and add ecs guide 2020-05-01 13:12:47 -07:00
Carter Anderson
368a1b8815 cargo fmt 2020-05-01 01:50:07 -07:00
Carter Anderson
913d016344 remove unnecessary custom type_name_of_val 2020-05-01 01:02:13 -07:00
Carter Anderson
a1cbf36b0c Use system type name as default system name 2020-05-01 00:55:32 -07:00
Carter Anderson
45a1f0515f use immutable reference in FromResources 2020-04-30 23:59:05 -07:00
Carter Anderson
3e3ab92ff5 cargo fmt 2020-04-30 22:30:51 -07:00
Carter Anderson
e5a99fde4f port event_update to system function 2020-04-30 16:19:28 -07:00
Carter Anderson
98f9639050 FromResource and derive macro 2020-04-30 13:26:01 -07:00
Carter Anderson
3cdee1b8ad system_fn named/id/anon. add "more-system-fn" cargo feature 2020-04-30 12:22:35 -07:00
Carter Anderson
2d3903299b Resource and ResourceMut pointers 2020-04-29 16:32:19 -07:00
Carter Anderson
45a710fe6a cargo fmt 2020-04-29 01:37:54 -07:00
Carter Anderson
9230c370ba Implement IntoSystem trait for flat functions using macros 2020-04-28 23:02:21 -07:00
Carter Anderson
f1a03a7a3a some system_fn renaming and add system examples 2020-04-28 13:46:07 -07:00
Carter Anderson
713c4a6056 move system function constructors to System 2020-04-28 11:25:24 -07:00
Carter Anderson
9a3700d8f1 Change events.iter(&mut reader) to reader.iter(&events) 2020-04-28 10:59:42 -07:00
Carter Anderson
92182060a9 add app builder shorthand for system function 2020-04-28 02:52:26 -07:00
Carter Anderson
092f3888ca Resource system functions 2020-04-28 02:31:01 -07:00
Carter Anderson
115a009c16 cargo fmt 2020-04-24 18:55:15 -07:00
Carter Anderson
87066cafd3 move bevy crates to their own folder 2020-04-24 17:57:20 -07:00