2023-03-18 01:45:34 +00:00
|
|
|
use crate::{App, Plugin};
|
|
|
|
use bevy_ecs::{
|
Separate state crate (#13216)
# Objective
Extracts the state mechanisms into a new crate called "bevy_state".
This comes with a few goals:
- state wasn't really an inherent machinery of the ecs system, and so
keeping it within bevy_ecs felt forced
- by mixing it in with bevy_ecs, the maintainability of our more robust
state system was significantly compromised
moving state into a new crate makes it easier to encapsulate as it's own
feature, and easier to read and understand since it's no longer a
single, massive file.
## Solution
move the state-related elements from bevy_ecs to a new crate
## Testing
- Did you test these changes? If so, how? all the automated tests
migrated and passed, ran the pre-existing examples without changes to
validate.
---
## Migration Guide
Since bevy_state is now gated behind the `bevy_state` feature, projects
that use state but don't use the `default-features` will need to add
that feature flag.
Since it is no longer part of bevy_ecs, projects that use bevy_ecs
directly will need to manually pull in `bevy_state`, trigger the
StateTransition schedule, and handle any of the elements that bevy_app
currently sets up.
---------
Co-authored-by: Kristoffer Søholm <k.soeholm@gmail.com>
2024-05-09 18:06:05 +00:00
|
|
|
schedule::{ExecutorKind, InternedScheduleLabel, Schedule, ScheduleLabel},
|
2023-03-18 01:45:34 +00:00
|
|
|
system::{Local, Resource},
|
|
|
|
world::{Mut, World},
|
|
|
|
};
|
|
|
|
|
|
|
|
/// The schedule that contains the app logic that is evaluated each tick of [`App::update()`].
|
|
|
|
///
|
|
|
|
/// By default, it will run the following schedules in the given order:
|
|
|
|
///
|
|
|
|
/// On the first run of the schedule (and only on the first run), it will run:
|
|
|
|
/// * [`PreStartup`]
|
|
|
|
/// * [`Startup`]
|
|
|
|
/// * [`PostStartup`]
|
|
|
|
///
|
|
|
|
/// Then it will run:
|
|
|
|
/// * [`First`]
|
|
|
|
/// * [`PreUpdate`]
|
2024-06-10 13:23:14 +00:00
|
|
|
/// * [`StateTransition`](bevy_state::transition::StateTransition)
|
2023-12-14 04:35:40 +00:00
|
|
|
/// * [`RunFixedMainLoop`]
|
|
|
|
/// * This will run [`FixedMain`] zero to many times, based on how much time has elapsed.
|
2023-03-18 01:45:34 +00:00
|
|
|
/// * [`Update`]
|
|
|
|
/// * [`PostUpdate`]
|
|
|
|
/// * [`Last`]
|
2024-01-08 23:02:46 +00:00
|
|
|
///
|
|
|
|
/// # Rendering
|
|
|
|
///
|
|
|
|
/// Note rendering is not executed in the main schedule by default.
|
2024-03-31 03:16:10 +00:00
|
|
|
/// Instead, rendering is performed in a separate [`SubApp`]
|
2024-01-08 23:02:46 +00:00
|
|
|
/// which exchanges data with the main app in between the main schedule runs.
|
|
|
|
///
|
|
|
|
/// See [`RenderPlugin`] and [`PipelinedRenderingPlugin`] for more details.
|
|
|
|
///
|
|
|
|
/// [`RenderPlugin`]: https://docs.rs/bevy/latest/bevy/render/struct.RenderPlugin.html
|
|
|
|
/// [`PipelinedRenderingPlugin`]: https://docs.rs/bevy/latest/bevy/render/pipelined_rendering/struct.PipelinedRenderingPlugin.html
|
2024-03-31 03:16:10 +00:00
|
|
|
/// [`SubApp`]: crate::SubApp
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct Main;
|
|
|
|
|
|
|
|
/// The schedule that runs before [`Startup`].
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct PreStartup;
|
|
|
|
|
|
|
|
/// The schedule that runs once when the app starts.
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct Startup;
|
|
|
|
|
|
|
|
/// The schedule that runs once after [`Startup`].
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct PostStartup;
|
|
|
|
|
|
|
|
/// Runs first in the schedule.
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct First;
|
|
|
|
|
|
|
|
/// The schedule that contains logic that must run before [`Update`]. For example, a system that reads raw keyboard
|
|
|
|
/// input OS events into an `Events` resource. This enables systems in [`Update`] to consume the events from the `Events`
|
2023-07-10 00:11:51 +00:00
|
|
|
/// resource without actually knowing about (or taking a direct scheduler dependency on) the "os-level keyboard event system".
|
2023-03-18 01:45:34 +00:00
|
|
|
///
|
|
|
|
/// [`PreUpdate`] exists to do "engine/plugin preparation work" that ensures the APIs consumed in [`Update`] are "ready".
|
|
|
|
/// [`PreUpdate`] abstracts out "pre work implementation details".
|
|
|
|
///
|
2023-11-22 20:50:37 +00:00
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct PreUpdate;
|
|
|
|
|
2023-12-14 04:35:40 +00:00
|
|
|
/// Runs the [`FixedMain`] schedule in a loop according until all relevant elapsed time has been "consumed".
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
2023-12-14 04:35:40 +00:00
|
|
|
pub struct RunFixedMainLoop;
|
|
|
|
|
|
|
|
/// Runs first in the [`FixedMain`] schedule.
|
|
|
|
///
|
|
|
|
/// See the [`FixedMain`] schedule for details on how fixed updates work.
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct FixedFirst;
|
|
|
|
|
|
|
|
/// The schedule that contains logic that must run before [`FixedUpdate`].
|
|
|
|
///
|
|
|
|
/// See the [`FixedMain`] schedule for details on how fixed updates work.
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct FixedPreUpdate;
|
|
|
|
|
|
|
|
/// The schedule that contains most gameplay logic.
|
|
|
|
///
|
|
|
|
/// See the [`FixedMain`] schedule for details on how fixed updates work.
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct FixedUpdate;
|
|
|
|
|
|
|
|
/// The schedule that runs after the [`FixedUpdate`] schedule, for reacting
|
|
|
|
/// to changes made in the main update logic.
|
|
|
|
///
|
|
|
|
/// See the [`FixedMain`] schedule for details on how fixed updates work.
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct FixedPostUpdate;
|
|
|
|
|
|
|
|
/// The schedule that runs last in [`FixedMain`]
|
|
|
|
///
|
|
|
|
/// See the [`FixedMain`] schedule for details on how fixed updates work.
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct FixedLast;
|
2023-03-18 01:45:34 +00:00
|
|
|
|
|
|
|
/// The schedule that contains systems which only run after a fixed period of time has elapsed.
|
|
|
|
///
|
2023-12-14 04:35:40 +00:00
|
|
|
/// The exclusive `run_fixed_main_schedule` system runs this schedule.
|
|
|
|
/// This is run by the [`RunFixedMainLoop`] schedule.
|
2023-11-16 17:41:55 +00:00
|
|
|
///
|
|
|
|
/// Frequency of execution is configured by inserting `Time<Fixed>` resource, 64 Hz by default.
|
|
|
|
/// See [this example](https://github.com/bevyengine/bevy/blob/latest/examples/time/time.rs).
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
2023-12-14 04:35:40 +00:00
|
|
|
pub struct FixedMain;
|
2023-03-18 01:45:34 +00:00
|
|
|
|
2023-12-14 04:35:40 +00:00
|
|
|
/// The schedule that contains app logic. Ideally containing anything that must run once per
|
|
|
|
/// render frame, such as UI.
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct Update;
|
|
|
|
|
2023-08-15 18:53:58 +00:00
|
|
|
/// The schedule that contains scene spawning.
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-08-15 18:53:58 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct SpawnScene;
|
|
|
|
|
2023-03-18 01:45:34 +00:00
|
|
|
/// The schedule that contains logic that must run after [`Update`]. For example, synchronizing "local transforms" in a hierarchy
|
|
|
|
/// to "global" absolute transforms. This enables the [`PostUpdate`] transform-sync system to react to "local transform" changes in
|
|
|
|
/// [`Update`] without the [`Update`] systems needing to know about (or add scheduler dependencies for) the "global transform sync system".
|
|
|
|
///
|
|
|
|
/// [`PostUpdate`] exists to do "engine/plugin response work" to things that happened in [`Update`].
|
|
|
|
/// [`PostUpdate`] abstracts out "implementation details" from users defining systems in [`Update`].
|
|
|
|
///
|
2023-11-22 20:50:37 +00:00
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct PostUpdate;
|
|
|
|
|
|
|
|
/// Runs last in the schedule.
|
2023-11-22 20:50:37 +00:00
|
|
|
///
|
|
|
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
2023-03-18 01:45:34 +00:00
|
|
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
|
|
|
pub struct Last;
|
|
|
|
|
|
|
|
/// Defines the schedules to be run for the [`Main`] schedule, including
|
|
|
|
/// their order.
|
|
|
|
#[derive(Resource, Debug)]
|
|
|
|
pub struct MainScheduleOrder {
|
2023-12-14 04:34:54 +00:00
|
|
|
/// The labels to run for the main phase of the [`Main`] schedule (in the order they will be run).
|
Replace all labels with interned labels (#7762)
# Objective
First of all, this PR took heavy inspiration from #7760 and #5715. It
intends to also fix #5569, but with a slightly different approach.
This also fixes #9335 by reexporting `DynEq`.
## Solution
The advantage of this API is that we can intern a value without
allocating for zero-sized-types and for enum variants that have no
fields. This PR does this automatically in the `SystemSet` and
`ScheduleLabel` derive macros for unit structs and fieldless enum
variants. So this should cover many internal and external use cases of
`SystemSet` and `ScheduleLabel`. In these optimal use cases, no memory
will be allocated.
- The interning returns a `Interned<dyn SystemSet>`, which is just a
wrapper around a `&'static dyn SystemSet`.
- `Hash` and `Eq` are implemented in terms of the pointer value of the
reference, similar to my first approach of anonymous system sets in
#7676.
- Therefore, `Interned<T>` does not implement `Borrow<T>`, only `Deref`.
- The debug output of `Interned<T>` is the same as the interned value.
Edit:
- `AppLabel` is now also interned and the old
`derive_label`/`define_label` macros were replaced with the new
interning implementation.
- Anonymous set ids are reused for different `Schedule`s, reducing the
amount of leaked memory.
### Pros
- `InternedSystemSet` and `InternedScheduleLabel` behave very similar to
the current `BoxedSystemSet` and `BoxedScheduleLabel`, but can be copied
without an allocation.
- Many use cases don't allocate at all.
- Very fast lookups and comparisons when using `InternedSystemSet` and
`InternedScheduleLabel`.
- The `intern` module might be usable in other areas.
- `Interned{ScheduleLabel, SystemSet, AppLabel}` does implement
`{ScheduleLabel, SystemSet, AppLabel}`, increasing ergonomics.
### Cons
- Implementors of `SystemSet` and `ScheduleLabel` still need to
implement `Hash` and `Eq` (and `Clone`) for it to work.
## Changelog
### Added
- Added `intern` module to `bevy_utils`.
- Added reexports of `DynEq` to `bevy_ecs` and `bevy_app`.
### Changed
- Replaced `BoxedSystemSet` and `BoxedScheduleLabel` with
`InternedSystemSet` and `InternedScheduleLabel`.
- Replaced `impl AsRef<dyn ScheduleLabel>` with `impl ScheduleLabel`.
- Replaced `AppLabelId` with `InternedAppLabel`.
- Changed `AppLabel` to use `Debug` for error messages.
- Changed `AppLabel` to use interning.
- Changed `define_label`/`derive_label` to use interning.
- Replaced `define_boxed_label`/`derive_boxed_label` with
`define_label`/`derive_label`.
- Changed anonymous set ids to be only unique inside a schedule, not
globally.
- Made interned label types implement their label trait.
### Removed
- Removed `define_boxed_label` and `derive_boxed_label`.
## Migration guide
- Replace `BoxedScheduleLabel` and `Box<dyn ScheduleLabel>` with
`InternedScheduleLabel` or `Interned<dyn ScheduleLabel>`.
- Replace `BoxedSystemSet` and `Box<dyn SystemSet>` with
`InternedSystemSet` or `Interned<dyn SystemSet>`.
- Replace `AppLabelId` with `InternedAppLabel` or `Interned<dyn
AppLabel>`.
- Types manually implementing `ScheduleLabel`, `AppLabel` or `SystemSet`
need to implement:
- `dyn_hash` directly instead of implementing `DynHash`
- `as_dyn_eq`
- Pass labels to `World::try_schedule_scope`, `World::schedule_scope`,
`World::try_run_schedule`. `World::run_schedule`, `Schedules::remove`,
`Schedules::remove_entry`, `Schedules::contains`, `Schedules::get` and
`Schedules::get_mut` by value instead of by reference.
---------
Co-authored-by: Joseph <21144246+JoJoJet@users.noreply.github.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-10-25 21:39:23 +00:00
|
|
|
pub labels: Vec<InternedScheduleLabel>,
|
2023-12-14 04:34:54 +00:00
|
|
|
/// The labels to run for the startup phase of the [`Main`] schedule (in the order they will be run).
|
|
|
|
pub startup_labels: Vec<InternedScheduleLabel>,
|
2023-03-18 01:45:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Default for MainScheduleOrder {
|
|
|
|
fn default() -> Self {
|
|
|
|
Self {
|
|
|
|
labels: vec![
|
Replace all labels with interned labels (#7762)
# Objective
First of all, this PR took heavy inspiration from #7760 and #5715. It
intends to also fix #5569, but with a slightly different approach.
This also fixes #9335 by reexporting `DynEq`.
## Solution
The advantage of this API is that we can intern a value without
allocating for zero-sized-types and for enum variants that have no
fields. This PR does this automatically in the `SystemSet` and
`ScheduleLabel` derive macros for unit structs and fieldless enum
variants. So this should cover many internal and external use cases of
`SystemSet` and `ScheduleLabel`. In these optimal use cases, no memory
will be allocated.
- The interning returns a `Interned<dyn SystemSet>`, which is just a
wrapper around a `&'static dyn SystemSet`.
- `Hash` and `Eq` are implemented in terms of the pointer value of the
reference, similar to my first approach of anonymous system sets in
#7676.
- Therefore, `Interned<T>` does not implement `Borrow<T>`, only `Deref`.
- The debug output of `Interned<T>` is the same as the interned value.
Edit:
- `AppLabel` is now also interned and the old
`derive_label`/`define_label` macros were replaced with the new
interning implementation.
- Anonymous set ids are reused for different `Schedule`s, reducing the
amount of leaked memory.
### Pros
- `InternedSystemSet` and `InternedScheduleLabel` behave very similar to
the current `BoxedSystemSet` and `BoxedScheduleLabel`, but can be copied
without an allocation.
- Many use cases don't allocate at all.
- Very fast lookups and comparisons when using `InternedSystemSet` and
`InternedScheduleLabel`.
- The `intern` module might be usable in other areas.
- `Interned{ScheduleLabel, SystemSet, AppLabel}` does implement
`{ScheduleLabel, SystemSet, AppLabel}`, increasing ergonomics.
### Cons
- Implementors of `SystemSet` and `ScheduleLabel` still need to
implement `Hash` and `Eq` (and `Clone`) for it to work.
## Changelog
### Added
- Added `intern` module to `bevy_utils`.
- Added reexports of `DynEq` to `bevy_ecs` and `bevy_app`.
### Changed
- Replaced `BoxedSystemSet` and `BoxedScheduleLabel` with
`InternedSystemSet` and `InternedScheduleLabel`.
- Replaced `impl AsRef<dyn ScheduleLabel>` with `impl ScheduleLabel`.
- Replaced `AppLabelId` with `InternedAppLabel`.
- Changed `AppLabel` to use `Debug` for error messages.
- Changed `AppLabel` to use interning.
- Changed `define_label`/`derive_label` to use interning.
- Replaced `define_boxed_label`/`derive_boxed_label` with
`define_label`/`derive_label`.
- Changed anonymous set ids to be only unique inside a schedule, not
globally.
- Made interned label types implement their label trait.
### Removed
- Removed `define_boxed_label` and `derive_boxed_label`.
## Migration guide
- Replace `BoxedScheduleLabel` and `Box<dyn ScheduleLabel>` with
`InternedScheduleLabel` or `Interned<dyn ScheduleLabel>`.
- Replace `BoxedSystemSet` and `Box<dyn SystemSet>` with
`InternedSystemSet` or `Interned<dyn SystemSet>`.
- Replace `AppLabelId` with `InternedAppLabel` or `Interned<dyn
AppLabel>`.
- Types manually implementing `ScheduleLabel`, `AppLabel` or `SystemSet`
need to implement:
- `dyn_hash` directly instead of implementing `DynHash`
- `as_dyn_eq`
- Pass labels to `World::try_schedule_scope`, `World::schedule_scope`,
`World::try_run_schedule`. `World::run_schedule`, `Schedules::remove`,
`Schedules::remove_entry`, `Schedules::contains`, `Schedules::get` and
`Schedules::get_mut` by value instead of by reference.
---------
Co-authored-by: Joseph <21144246+JoJoJet@users.noreply.github.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-10-25 21:39:23 +00:00
|
|
|
First.intern(),
|
|
|
|
PreUpdate.intern(),
|
2023-12-14 04:35:40 +00:00
|
|
|
RunFixedMainLoop.intern(),
|
Replace all labels with interned labels (#7762)
# Objective
First of all, this PR took heavy inspiration from #7760 and #5715. It
intends to also fix #5569, but with a slightly different approach.
This also fixes #9335 by reexporting `DynEq`.
## Solution
The advantage of this API is that we can intern a value without
allocating for zero-sized-types and for enum variants that have no
fields. This PR does this automatically in the `SystemSet` and
`ScheduleLabel` derive macros for unit structs and fieldless enum
variants. So this should cover many internal and external use cases of
`SystemSet` and `ScheduleLabel`. In these optimal use cases, no memory
will be allocated.
- The interning returns a `Interned<dyn SystemSet>`, which is just a
wrapper around a `&'static dyn SystemSet`.
- `Hash` and `Eq` are implemented in terms of the pointer value of the
reference, similar to my first approach of anonymous system sets in
#7676.
- Therefore, `Interned<T>` does not implement `Borrow<T>`, only `Deref`.
- The debug output of `Interned<T>` is the same as the interned value.
Edit:
- `AppLabel` is now also interned and the old
`derive_label`/`define_label` macros were replaced with the new
interning implementation.
- Anonymous set ids are reused for different `Schedule`s, reducing the
amount of leaked memory.
### Pros
- `InternedSystemSet` and `InternedScheduleLabel` behave very similar to
the current `BoxedSystemSet` and `BoxedScheduleLabel`, but can be copied
without an allocation.
- Many use cases don't allocate at all.
- Very fast lookups and comparisons when using `InternedSystemSet` and
`InternedScheduleLabel`.
- The `intern` module might be usable in other areas.
- `Interned{ScheduleLabel, SystemSet, AppLabel}` does implement
`{ScheduleLabel, SystemSet, AppLabel}`, increasing ergonomics.
### Cons
- Implementors of `SystemSet` and `ScheduleLabel` still need to
implement `Hash` and `Eq` (and `Clone`) for it to work.
## Changelog
### Added
- Added `intern` module to `bevy_utils`.
- Added reexports of `DynEq` to `bevy_ecs` and `bevy_app`.
### Changed
- Replaced `BoxedSystemSet` and `BoxedScheduleLabel` with
`InternedSystemSet` and `InternedScheduleLabel`.
- Replaced `impl AsRef<dyn ScheduleLabel>` with `impl ScheduleLabel`.
- Replaced `AppLabelId` with `InternedAppLabel`.
- Changed `AppLabel` to use `Debug` for error messages.
- Changed `AppLabel` to use interning.
- Changed `define_label`/`derive_label` to use interning.
- Replaced `define_boxed_label`/`derive_boxed_label` with
`define_label`/`derive_label`.
- Changed anonymous set ids to be only unique inside a schedule, not
globally.
- Made interned label types implement their label trait.
### Removed
- Removed `define_boxed_label` and `derive_boxed_label`.
## Migration guide
- Replace `BoxedScheduleLabel` and `Box<dyn ScheduleLabel>` with
`InternedScheduleLabel` or `Interned<dyn ScheduleLabel>`.
- Replace `BoxedSystemSet` and `Box<dyn SystemSet>` with
`InternedSystemSet` or `Interned<dyn SystemSet>`.
- Replace `AppLabelId` with `InternedAppLabel` or `Interned<dyn
AppLabel>`.
- Types manually implementing `ScheduleLabel`, `AppLabel` or `SystemSet`
need to implement:
- `dyn_hash` directly instead of implementing `DynHash`
- `as_dyn_eq`
- Pass labels to `World::try_schedule_scope`, `World::schedule_scope`,
`World::try_run_schedule`. `World::run_schedule`, `Schedules::remove`,
`Schedules::remove_entry`, `Schedules::contains`, `Schedules::get` and
`Schedules::get_mut` by value instead of by reference.
---------
Co-authored-by: Joseph <21144246+JoJoJet@users.noreply.github.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-10-25 21:39:23 +00:00
|
|
|
Update.intern(),
|
|
|
|
SpawnScene.intern(),
|
|
|
|
PostUpdate.intern(),
|
|
|
|
Last.intern(),
|
2023-03-18 01:45:34 +00:00
|
|
|
],
|
2023-12-14 04:34:54 +00:00
|
|
|
startup_labels: vec![PreStartup.intern(), Startup.intern(), PostStartup.intern()],
|
2023-03-18 01:45:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl MainScheduleOrder {
|
2023-12-14 04:34:54 +00:00
|
|
|
/// Adds the given `schedule` after the `after` schedule in the main list of schedules.
|
2023-03-18 01:45:34 +00:00
|
|
|
pub fn insert_after(&mut self, after: impl ScheduleLabel, schedule: impl ScheduleLabel) {
|
|
|
|
let index = self
|
|
|
|
.labels
|
|
|
|
.iter()
|
|
|
|
.position(|current| (**current).eq(&after))
|
|
|
|
.unwrap_or_else(|| panic!("Expected {after:?} to exist"));
|
Replace all labels with interned labels (#7762)
# Objective
First of all, this PR took heavy inspiration from #7760 and #5715. It
intends to also fix #5569, but with a slightly different approach.
This also fixes #9335 by reexporting `DynEq`.
## Solution
The advantage of this API is that we can intern a value without
allocating for zero-sized-types and for enum variants that have no
fields. This PR does this automatically in the `SystemSet` and
`ScheduleLabel` derive macros for unit structs and fieldless enum
variants. So this should cover many internal and external use cases of
`SystemSet` and `ScheduleLabel`. In these optimal use cases, no memory
will be allocated.
- The interning returns a `Interned<dyn SystemSet>`, which is just a
wrapper around a `&'static dyn SystemSet`.
- `Hash` and `Eq` are implemented in terms of the pointer value of the
reference, similar to my first approach of anonymous system sets in
#7676.
- Therefore, `Interned<T>` does not implement `Borrow<T>`, only `Deref`.
- The debug output of `Interned<T>` is the same as the interned value.
Edit:
- `AppLabel` is now also interned and the old
`derive_label`/`define_label` macros were replaced with the new
interning implementation.
- Anonymous set ids are reused for different `Schedule`s, reducing the
amount of leaked memory.
### Pros
- `InternedSystemSet` and `InternedScheduleLabel` behave very similar to
the current `BoxedSystemSet` and `BoxedScheduleLabel`, but can be copied
without an allocation.
- Many use cases don't allocate at all.
- Very fast lookups and comparisons when using `InternedSystemSet` and
`InternedScheduleLabel`.
- The `intern` module might be usable in other areas.
- `Interned{ScheduleLabel, SystemSet, AppLabel}` does implement
`{ScheduleLabel, SystemSet, AppLabel}`, increasing ergonomics.
### Cons
- Implementors of `SystemSet` and `ScheduleLabel` still need to
implement `Hash` and `Eq` (and `Clone`) for it to work.
## Changelog
### Added
- Added `intern` module to `bevy_utils`.
- Added reexports of `DynEq` to `bevy_ecs` and `bevy_app`.
### Changed
- Replaced `BoxedSystemSet` and `BoxedScheduleLabel` with
`InternedSystemSet` and `InternedScheduleLabel`.
- Replaced `impl AsRef<dyn ScheduleLabel>` with `impl ScheduleLabel`.
- Replaced `AppLabelId` with `InternedAppLabel`.
- Changed `AppLabel` to use `Debug` for error messages.
- Changed `AppLabel` to use interning.
- Changed `define_label`/`derive_label` to use interning.
- Replaced `define_boxed_label`/`derive_boxed_label` with
`define_label`/`derive_label`.
- Changed anonymous set ids to be only unique inside a schedule, not
globally.
- Made interned label types implement their label trait.
### Removed
- Removed `define_boxed_label` and `derive_boxed_label`.
## Migration guide
- Replace `BoxedScheduleLabel` and `Box<dyn ScheduleLabel>` with
`InternedScheduleLabel` or `Interned<dyn ScheduleLabel>`.
- Replace `BoxedSystemSet` and `Box<dyn SystemSet>` with
`InternedSystemSet` or `Interned<dyn SystemSet>`.
- Replace `AppLabelId` with `InternedAppLabel` or `Interned<dyn
AppLabel>`.
- Types manually implementing `ScheduleLabel`, `AppLabel` or `SystemSet`
need to implement:
- `dyn_hash` directly instead of implementing `DynHash`
- `as_dyn_eq`
- Pass labels to `World::try_schedule_scope`, `World::schedule_scope`,
`World::try_run_schedule`. `World::run_schedule`, `Schedules::remove`,
`Schedules::remove_entry`, `Schedules::contains`, `Schedules::get` and
`Schedules::get_mut` by value instead of by reference.
---------
Co-authored-by: Joseph <21144246+JoJoJet@users.noreply.github.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-10-25 21:39:23 +00:00
|
|
|
self.labels.insert(index + 1, schedule.intern());
|
2023-03-18 01:45:34 +00:00
|
|
|
}
|
2023-12-14 04:34:54 +00:00
|
|
|
|
2024-06-20 01:02:16 +00:00
|
|
|
/// Adds the given `schedule` before the `before` schedule in the main list of schedules.
|
|
|
|
pub fn insert_before(&mut self, before: impl ScheduleLabel, schedule: impl ScheduleLabel) {
|
|
|
|
let index = self
|
|
|
|
.labels
|
|
|
|
.iter()
|
|
|
|
.position(|current| (**current).eq(&before))
|
|
|
|
.unwrap_or_else(|| panic!("Expected {before:?} to exist"));
|
|
|
|
self.labels.insert(index, schedule.intern());
|
|
|
|
}
|
|
|
|
|
2023-12-14 04:34:54 +00:00
|
|
|
/// Adds the given `schedule` after the `after` schedule in the list of startup schedules.
|
|
|
|
pub fn insert_startup_after(
|
|
|
|
&mut self,
|
|
|
|
after: impl ScheduleLabel,
|
|
|
|
schedule: impl ScheduleLabel,
|
|
|
|
) {
|
|
|
|
let index = self
|
|
|
|
.startup_labels
|
|
|
|
.iter()
|
|
|
|
.position(|current| (**current).eq(&after))
|
|
|
|
.unwrap_or_else(|| panic!("Expected {after:?} to exist"));
|
|
|
|
self.startup_labels.insert(index + 1, schedule.intern());
|
|
|
|
}
|
2024-06-20 01:02:16 +00:00
|
|
|
|
|
|
|
/// Adds the given `schedule` before the `before` schedule in the list of startup schedules.
|
|
|
|
pub fn insert_startup_before(
|
|
|
|
&mut self,
|
|
|
|
before: impl ScheduleLabel,
|
|
|
|
schedule: impl ScheduleLabel,
|
|
|
|
) {
|
|
|
|
let index = self
|
|
|
|
.startup_labels
|
|
|
|
.iter()
|
|
|
|
.position(|current| (**current).eq(&before))
|
|
|
|
.unwrap_or_else(|| panic!("Expected {before:?} to exist"));
|
|
|
|
self.startup_labels.insert(index, schedule.intern());
|
|
|
|
}
|
2023-03-18 01:45:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Main {
|
|
|
|
/// A system that runs the "main schedule"
|
|
|
|
pub fn run_main(world: &mut World, mut run_at_least_once: Local<bool>) {
|
|
|
|
if !*run_at_least_once {
|
2023-12-14 04:34:54 +00:00
|
|
|
world.resource_scope(|world, order: Mut<MainScheduleOrder>| {
|
|
|
|
for &label in &order.startup_labels {
|
|
|
|
let _ = world.try_run_schedule(label);
|
|
|
|
}
|
|
|
|
});
|
2023-03-18 01:45:34 +00:00
|
|
|
*run_at_least_once = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
world.resource_scope(|world, order: Mut<MainScheduleOrder>| {
|
Replace all labels with interned labels (#7762)
# Objective
First of all, this PR took heavy inspiration from #7760 and #5715. It
intends to also fix #5569, but with a slightly different approach.
This also fixes #9335 by reexporting `DynEq`.
## Solution
The advantage of this API is that we can intern a value without
allocating for zero-sized-types and for enum variants that have no
fields. This PR does this automatically in the `SystemSet` and
`ScheduleLabel` derive macros for unit structs and fieldless enum
variants. So this should cover many internal and external use cases of
`SystemSet` and `ScheduleLabel`. In these optimal use cases, no memory
will be allocated.
- The interning returns a `Interned<dyn SystemSet>`, which is just a
wrapper around a `&'static dyn SystemSet`.
- `Hash` and `Eq` are implemented in terms of the pointer value of the
reference, similar to my first approach of anonymous system sets in
#7676.
- Therefore, `Interned<T>` does not implement `Borrow<T>`, only `Deref`.
- The debug output of `Interned<T>` is the same as the interned value.
Edit:
- `AppLabel` is now also interned and the old
`derive_label`/`define_label` macros were replaced with the new
interning implementation.
- Anonymous set ids are reused for different `Schedule`s, reducing the
amount of leaked memory.
### Pros
- `InternedSystemSet` and `InternedScheduleLabel` behave very similar to
the current `BoxedSystemSet` and `BoxedScheduleLabel`, but can be copied
without an allocation.
- Many use cases don't allocate at all.
- Very fast lookups and comparisons when using `InternedSystemSet` and
`InternedScheduleLabel`.
- The `intern` module might be usable in other areas.
- `Interned{ScheduleLabel, SystemSet, AppLabel}` does implement
`{ScheduleLabel, SystemSet, AppLabel}`, increasing ergonomics.
### Cons
- Implementors of `SystemSet` and `ScheduleLabel` still need to
implement `Hash` and `Eq` (and `Clone`) for it to work.
## Changelog
### Added
- Added `intern` module to `bevy_utils`.
- Added reexports of `DynEq` to `bevy_ecs` and `bevy_app`.
### Changed
- Replaced `BoxedSystemSet` and `BoxedScheduleLabel` with
`InternedSystemSet` and `InternedScheduleLabel`.
- Replaced `impl AsRef<dyn ScheduleLabel>` with `impl ScheduleLabel`.
- Replaced `AppLabelId` with `InternedAppLabel`.
- Changed `AppLabel` to use `Debug` for error messages.
- Changed `AppLabel` to use interning.
- Changed `define_label`/`derive_label` to use interning.
- Replaced `define_boxed_label`/`derive_boxed_label` with
`define_label`/`derive_label`.
- Changed anonymous set ids to be only unique inside a schedule, not
globally.
- Made interned label types implement their label trait.
### Removed
- Removed `define_boxed_label` and `derive_boxed_label`.
## Migration guide
- Replace `BoxedScheduleLabel` and `Box<dyn ScheduleLabel>` with
`InternedScheduleLabel` or `Interned<dyn ScheduleLabel>`.
- Replace `BoxedSystemSet` and `Box<dyn SystemSet>` with
`InternedSystemSet` or `Interned<dyn SystemSet>`.
- Replace `AppLabelId` with `InternedAppLabel` or `Interned<dyn
AppLabel>`.
- Types manually implementing `ScheduleLabel`, `AppLabel` or `SystemSet`
need to implement:
- `dyn_hash` directly instead of implementing `DynHash`
- `as_dyn_eq`
- Pass labels to `World::try_schedule_scope`, `World::schedule_scope`,
`World::try_run_schedule`. `World::run_schedule`, `Schedules::remove`,
`Schedules::remove_entry`, `Schedules::contains`, `Schedules::get` and
`Schedules::get_mut` by value instead of by reference.
---------
Co-authored-by: Joseph <21144246+JoJoJet@users.noreply.github.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-10-25 21:39:23 +00:00
|
|
|
for &label in &order.labels {
|
|
|
|
let _ = world.try_run_schedule(label);
|
2023-03-18 01:45:34 +00:00
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-12-14 04:35:40 +00:00
|
|
|
/// Initializes the [`Main`] schedule, sub schedules, and resources for a given [`App`].
|
2023-03-18 01:45:34 +00:00
|
|
|
pub struct MainSchedulePlugin;
|
|
|
|
|
|
|
|
impl Plugin for MainSchedulePlugin {
|
|
|
|
fn build(&self, app: &mut App) {
|
|
|
|
// simple "facilitator" schedules benefit from simpler single threaded scheduling
|
2023-08-28 20:44:48 +00:00
|
|
|
let mut main_schedule = Schedule::new(Main);
|
2023-03-18 01:45:34 +00:00
|
|
|
main_schedule.set_executor_kind(ExecutorKind::SingleThreaded);
|
2023-12-14 04:35:40 +00:00
|
|
|
let mut fixed_main_schedule = Schedule::new(FixedMain);
|
|
|
|
fixed_main_schedule.set_executor_kind(ExecutorKind::SingleThreaded);
|
|
|
|
let mut fixed_main_loop_schedule = Schedule::new(RunFixedMainLoop);
|
|
|
|
fixed_main_loop_schedule.set_executor_kind(ExecutorKind::SingleThreaded);
|
2023-03-18 01:45:34 +00:00
|
|
|
|
2023-08-28 20:44:48 +00:00
|
|
|
app.add_schedule(main_schedule)
|
2023-12-14 04:35:40 +00:00
|
|
|
.add_schedule(fixed_main_schedule)
|
|
|
|
.add_schedule(fixed_main_loop_schedule)
|
2023-03-18 01:45:34 +00:00
|
|
|
.init_resource::<MainScheduleOrder>()
|
2023-12-14 04:35:40 +00:00
|
|
|
.init_resource::<FixedMainScheduleOrder>()
|
|
|
|
.add_systems(Main, Main::run_main)
|
|
|
|
.add_systems(FixedMain, FixedMain::run_fixed_main);
|
System Stepping implemented as Resource (#8453)
# Objective
Add interactive system debugging capabilities to bevy, providing
step/break/continue style capabilities to running system schedules.
* Original implementation: #8063
- `ignore_stepping()` everywhere was too much complexity
* Schedule-config & Resource discussion: #8168
- Decided on selective adding of Schedules & Resource-based control
## Solution
Created `Stepping` Resource. This resource can be used to enable
stepping on a per-schedule basis. Systems within schedules can be
individually configured to:
* AlwaysRun: Ignore any stepping state and run every frame
* NeverRun: Never run while stepping is enabled
- this allows for disabling of systems while debugging
* Break: If we're running the full frame, stop before this system is run
Stepping provides two modes of execution that reflect traditional
debuggers:
* Step-based: Only execute one system at a time
* Continue/Break: Run all systems, but stop before running a system
marked as Break
### Demo
https://user-images.githubusercontent.com/857742/233630981-99f3bbda-9ca6-4cc4-a00f-171c4946dc47.mov
Breakout has been modified to use Stepping. The game runs normally for a
couple of seconds, then stepping is enabled and the game appears to
pause. A list of Schedules & Systems appears with a cursor at the first
System in the list. The demo then steps forward full frames using the
spacebar until the ball is about to hit a brick. Then we step system by
system as the ball impacts a brick, showing the cursor moving through
the individual systems. Finally the demo switches back to frame stepping
as the ball changes course.
### Limitations
Due to architectural constraints in bevy, there are some cases systems
stepping will not function as a user would expect.
#### Event-driven systems
Stepping does not support systems that are driven by `Event`s as events
are flushed after 1-2 frames. Although game systems are not running
while stepping, ignored systems are still running every frame, so events
will be flushed.
This presents to the user as stepping the event-driven system never
executes the system. It does execute, but the events have already been
flushed.
This can be resolved by changing event handling to use a buffer for
events, and only dropping an event once all readers have read it.
The work-around to allow these systems to properly execute during
stepping is to have them ignore stepping:
`app.add_systems(event_driven_system.ignore_stepping())`. This was done
in the breakout example to ensure sound played even while stepping.
#### Conditional Systems
When a system is stepped, it is given an opportunity to run. If the
conditions of the system say it should not run, it will not.
Similar to Event-driven systems, if a system is conditional, and that
condition is only true for a very small time window, then stepping the
system may not execute the system. This includes depending on any sort
of external clock.
This exhibits to the user as the system not always running when it is
stepped.
A solution to this limitation is to ensure any conditions are consistent
while stepping is enabled. For example, all systems that modify any
state the condition uses should also enable stepping.
#### State-transition Systems
Stepping is configured on the per-`Schedule` level, requiring the user
to have a `ScheduleLabel`.
To support state-transition systems, bevy generates needed schedules
dynamically. Currently it’s very difficult (if not impossible, I haven’t
verified) for the user to get the labels for these schedules.
Without ready access to the dynamically generated schedules, and a
resolution for the `Event` lifetime, **stepping of the state-transition
systems is not supported**
---
## Changelog
- `Schedule::run()` updated to consult `Stepping` Resource to determine
which Systems to run each frame
- Added `Schedule.label` as a `BoxedSystemLabel`, along with supporting
`Schedule::set_label()` and `Schedule::label()` methods
- `Stepping` needed to know which `Schedule` was running, and prior to
this PR, `Schedule` didn't track its own label
- Would have preferred to add `Schedule::with_label()` and remove
`Schedule::new()`, but this PR touches enough already
- Added calls to `Schedule.set_label()` to `App` and `World` as needed
- Added `Stepping` resource
- Added `Stepping::begin_frame()` system to `MainSchedulePlugin`
- Run before `Main::run_main()`
- Notifies any `Stepping` Resource a new render frame is starting
## Migration Guide
- Add a call to `Schedule::set_label()` for any custom `Schedule`
- This is only required if the `Schedule` will be stepped
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2024-02-03 05:18:38 +00:00
|
|
|
|
|
|
|
#[cfg(feature = "bevy_debug_stepping")]
|
|
|
|
{
|
|
|
|
use bevy_ecs::schedule::{IntoSystemConfigs, Stepping};
|
|
|
|
app.add_systems(Main, Stepping::begin_frame.before(Main::run_main));
|
|
|
|
}
|
2023-12-14 04:35:40 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Defines the schedules to be run for the [`FixedMain`] schedule, including
|
|
|
|
/// their order.
|
|
|
|
#[derive(Resource, Debug)]
|
|
|
|
pub struct FixedMainScheduleOrder {
|
|
|
|
/// The labels to run for the [`FixedMain`] schedule (in the order they will be run).
|
|
|
|
pub labels: Vec<InternedScheduleLabel>,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Default for FixedMainScheduleOrder {
|
|
|
|
fn default() -> Self {
|
|
|
|
Self {
|
|
|
|
labels: vec![
|
|
|
|
FixedFirst.intern(),
|
|
|
|
FixedPreUpdate.intern(),
|
|
|
|
FixedUpdate.intern(),
|
|
|
|
FixedPostUpdate.intern(),
|
|
|
|
FixedLast.intern(),
|
|
|
|
],
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl FixedMainScheduleOrder {
|
|
|
|
/// Adds the given `schedule` after the `after` schedule
|
|
|
|
pub fn insert_after(&mut self, after: impl ScheduleLabel, schedule: impl ScheduleLabel) {
|
|
|
|
let index = self
|
|
|
|
.labels
|
|
|
|
.iter()
|
|
|
|
.position(|current| (**current).eq(&after))
|
|
|
|
.unwrap_or_else(|| panic!("Expected {after:?} to exist"));
|
|
|
|
self.labels.insert(index + 1, schedule.intern());
|
|
|
|
}
|
2024-06-20 01:02:16 +00:00
|
|
|
|
|
|
|
/// Adds the given `schedule` before the `before` schedule
|
|
|
|
pub fn insert_before(&mut self, before: impl ScheduleLabel, schedule: impl ScheduleLabel) {
|
|
|
|
let index = self
|
|
|
|
.labels
|
|
|
|
.iter()
|
|
|
|
.position(|current| (**current).eq(&before))
|
|
|
|
.unwrap_or_else(|| panic!("Expected {before:?} to exist"));
|
|
|
|
self.labels.insert(index, schedule.intern());
|
|
|
|
}
|
2023-12-14 04:35:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl FixedMain {
|
|
|
|
/// A system that runs the fixed timestep's "main schedule"
|
|
|
|
pub fn run_fixed_main(world: &mut World) {
|
|
|
|
world.resource_scope(|world, order: Mut<FixedMainScheduleOrder>| {
|
|
|
|
for &label in &order.labels {
|
|
|
|
let _ = world.try_run_schedule(label);
|
|
|
|
}
|
|
|
|
});
|
2023-03-18 01:45:34 +00:00
|
|
|
}
|
|
|
|
}
|