2022-05-26 00:27:18 +00:00
|
|
|
mod fixed_timestep;
|
|
|
|
mod stopwatch;
|
|
|
|
#[allow(clippy::module_inception)]
|
|
|
|
mod time;
|
|
|
|
mod timer;
|
|
|
|
|
|
|
|
pub use fixed_timestep::*;
|
|
|
|
pub use stopwatch::*;
|
|
|
|
pub use time::*;
|
|
|
|
pub use timer::*;
|
|
|
|
|
2022-07-11 23:19:00 +00:00
|
|
|
use bevy_ecs::system::{Local, Res, ResMut};
|
|
|
|
use bevy_utils::{tracing::warn, Instant};
|
|
|
|
use crossbeam_channel::{Receiver, Sender};
|
|
|
|
|
2022-05-26 00:27:18 +00:00
|
|
|
pub mod prelude {
|
|
|
|
//! The Bevy Time Prelude.
|
|
|
|
#[doc(hidden)]
|
|
|
|
pub use crate::{Time, Timer};
|
|
|
|
}
|
|
|
|
|
|
|
|
use bevy_app::prelude::*;
|
|
|
|
use bevy_ecs::prelude::*;
|
|
|
|
|
|
|
|
/// Adds time functionality to Apps.
|
|
|
|
#[derive(Default)]
|
|
|
|
pub struct TimePlugin;
|
|
|
|
|
|
|
|
#[derive(Debug, PartialEq, Eq, Clone, Hash, SystemLabel)]
|
|
|
|
/// Updates the elapsed time. Any system that interacts with [Time] component should run after
|
|
|
|
/// this.
|
|
|
|
pub struct TimeSystem;
|
|
|
|
|
|
|
|
impl Plugin for TimePlugin {
|
|
|
|
fn build(&self, app: &mut App) {
|
|
|
|
app.init_resource::<Time>()
|
|
|
|
.init_resource::<FixedTimesteps>()
|
|
|
|
.register_type::<Timer>()
|
register missing reflect types (#5747)
# Objective
- While generating https://github.com/jakobhellermann/bevy_reflect_ts_type_export/blob/main/generated/types.ts, I noticed that some types that implement `Reflect` did not register themselves
- `Viewport` isn't reflect but can be (there's a TODO)
## Solution
- register all reflected types
- derive `Reflect` for `Viewport`
## Changelog
- more types are not registered in the type registry
- remove `Serialize`, `Deserialize` impls from `Viewport`
I also decided to remove the `Serialize, Deserialize` from the `Viewport`, since they were (AFAIK) only used for reflection, which now is done without serde. So this is technically a breaking change for people who relied on that impl directly.
Personally I don't think that every bevy type should implement `Serialize, Deserialize`, as that would lead to a ton of code generation that mostly isn't necessary because we can do the same with `Reflect`, but if this is deemed controversial I can remove it from this PR.
## Migration Guide
- `KeyCode` now implements `Reflect` not as `reflect_value`, but with proper struct reflection. The `Serialize` and `Deserialize` impls were removed, now that they are no longer required for scene serialization.
2022-08-23 17:41:39 +00:00
|
|
|
.register_type::<Time>()
|
|
|
|
.register_type::<Stopwatch>()
|
2022-05-26 00:27:18 +00:00
|
|
|
// time system is added as an "exclusive system" to ensure it runs before other systems
|
|
|
|
// in CoreStage::First
|
|
|
|
.add_system_to_stage(
|
|
|
|
CoreStage::First,
|
|
|
|
time_system.exclusive_system().at_start().label(TimeSystem),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-11 23:19:00 +00:00
|
|
|
/// Channel resource used to receive time from render world
|
Make `Resource` trait opt-in, requiring `#[derive(Resource)]` V2 (#5577)
*This PR description is an edited copy of #5007, written by @alice-i-cecile.*
# Objective
Follow-up to https://github.com/bevyengine/bevy/pull/2254. The `Resource` trait currently has a blanket implementation for all types that meet its bounds.
While ergonomic, this results in several drawbacks:
* it is possible to make confusing, silent mistakes such as inserting a function pointer (Foo) rather than a value (Foo::Bar) as a resource
* it is challenging to discover if a type is intended to be used as a resource
* we cannot later add customization options (see the [RFC](https://github.com/bevyengine/rfcs/blob/main/rfcs/27-derive-component.md) for the equivalent choice for Component).
* dependencies can use the same Rust type as a resource in invisibly conflicting ways
* raw Rust types used as resources cannot preserve privacy appropriately, as anyone able to access that type can read and write to internal values
* we cannot capture a definitive list of possible resources to display to users in an editor
## Notes to reviewers
* Review this commit-by-commit; there's effectively no back-tracking and there's a lot of churn in some of these commits.
*ira: My commits are not as well organized :')*
* I've relaxed the bound on Local to Send + Sync + 'static: I don't think these concerns apply there, so this can keep things simple. Storing e.g. a u32 in a Local is fine, because there's a variable name attached explaining what it does.
* I think this is a bad place for the Resource trait to live, but I've left it in place to make reviewing easier. IMO that's best tackled with https://github.com/bevyengine/bevy/issues/4981.
## Changelog
`Resource` is no longer automatically implemented for all matching types. Instead, use the new `#[derive(Resource)]` macro.
## Migration Guide
Add `#[derive(Resource)]` to all types you are using as a resource.
If you are using a third party type as a resource, wrap it in a tuple struct to bypass orphan rules. Consider deriving `Deref` and `DerefMut` to improve ergonomics.
`ClearColor` no longer implements `Component`. Using `ClearColor` as a component in 0.8 did nothing.
Use the `ClearColorConfig` in the `Camera3d` and `Camera2d` components instead.
Co-authored-by: Alice <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: devil-ira <justthecooldude@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2022-08-08 21:36:35 +00:00
|
|
|
#[derive(Resource)]
|
2022-07-11 23:19:00 +00:00
|
|
|
pub struct TimeReceiver(pub Receiver<Instant>);
|
Make `Resource` trait opt-in, requiring `#[derive(Resource)]` V2 (#5577)
*This PR description is an edited copy of #5007, written by @alice-i-cecile.*
# Objective
Follow-up to https://github.com/bevyengine/bevy/pull/2254. The `Resource` trait currently has a blanket implementation for all types that meet its bounds.
While ergonomic, this results in several drawbacks:
* it is possible to make confusing, silent mistakes such as inserting a function pointer (Foo) rather than a value (Foo::Bar) as a resource
* it is challenging to discover if a type is intended to be used as a resource
* we cannot later add customization options (see the [RFC](https://github.com/bevyengine/rfcs/blob/main/rfcs/27-derive-component.md) for the equivalent choice for Component).
* dependencies can use the same Rust type as a resource in invisibly conflicting ways
* raw Rust types used as resources cannot preserve privacy appropriately, as anyone able to access that type can read and write to internal values
* we cannot capture a definitive list of possible resources to display to users in an editor
## Notes to reviewers
* Review this commit-by-commit; there's effectively no back-tracking and there's a lot of churn in some of these commits.
*ira: My commits are not as well organized :')*
* I've relaxed the bound on Local to Send + Sync + 'static: I don't think these concerns apply there, so this can keep things simple. Storing e.g. a u32 in a Local is fine, because there's a variable name attached explaining what it does.
* I think this is a bad place for the Resource trait to live, but I've left it in place to make reviewing easier. IMO that's best tackled with https://github.com/bevyengine/bevy/issues/4981.
## Changelog
`Resource` is no longer automatically implemented for all matching types. Instead, use the new `#[derive(Resource)]` macro.
## Migration Guide
Add `#[derive(Resource)]` to all types you are using as a resource.
If you are using a third party type as a resource, wrap it in a tuple struct to bypass orphan rules. Consider deriving `Deref` and `DerefMut` to improve ergonomics.
`ClearColor` no longer implements `Component`. Using `ClearColor` as a component in 0.8 did nothing.
Use the `ClearColorConfig` in the `Camera3d` and `Camera2d` components instead.
Co-authored-by: Alice <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: devil-ira <justthecooldude@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2022-08-08 21:36:35 +00:00
|
|
|
|
2022-07-11 23:19:00 +00:00
|
|
|
/// Channel resource used to send time from render world
|
Make `Resource` trait opt-in, requiring `#[derive(Resource)]` V2 (#5577)
*This PR description is an edited copy of #5007, written by @alice-i-cecile.*
# Objective
Follow-up to https://github.com/bevyengine/bevy/pull/2254. The `Resource` trait currently has a blanket implementation for all types that meet its bounds.
While ergonomic, this results in several drawbacks:
* it is possible to make confusing, silent mistakes such as inserting a function pointer (Foo) rather than a value (Foo::Bar) as a resource
* it is challenging to discover if a type is intended to be used as a resource
* we cannot later add customization options (see the [RFC](https://github.com/bevyengine/rfcs/blob/main/rfcs/27-derive-component.md) for the equivalent choice for Component).
* dependencies can use the same Rust type as a resource in invisibly conflicting ways
* raw Rust types used as resources cannot preserve privacy appropriately, as anyone able to access that type can read and write to internal values
* we cannot capture a definitive list of possible resources to display to users in an editor
## Notes to reviewers
* Review this commit-by-commit; there's effectively no back-tracking and there's a lot of churn in some of these commits.
*ira: My commits are not as well organized :')*
* I've relaxed the bound on Local to Send + Sync + 'static: I don't think these concerns apply there, so this can keep things simple. Storing e.g. a u32 in a Local is fine, because there's a variable name attached explaining what it does.
* I think this is a bad place for the Resource trait to live, but I've left it in place to make reviewing easier. IMO that's best tackled with https://github.com/bevyengine/bevy/issues/4981.
## Changelog
`Resource` is no longer automatically implemented for all matching types. Instead, use the new `#[derive(Resource)]` macro.
## Migration Guide
Add `#[derive(Resource)]` to all types you are using as a resource.
If you are using a third party type as a resource, wrap it in a tuple struct to bypass orphan rules. Consider deriving `Deref` and `DerefMut` to improve ergonomics.
`ClearColor` no longer implements `Component`. Using `ClearColor` as a component in 0.8 did nothing.
Use the `ClearColorConfig` in the `Camera3d` and `Camera2d` components instead.
Co-authored-by: Alice <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: devil-ira <justthecooldude@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2022-08-08 21:36:35 +00:00
|
|
|
#[derive(Resource)]
|
2022-07-11 23:19:00 +00:00
|
|
|
pub struct TimeSender(pub Sender<Instant>);
|
|
|
|
|
|
|
|
/// Creates channels used for sending time between render world and app world
|
|
|
|
pub fn create_time_channels() -> (TimeSender, TimeReceiver) {
|
|
|
|
// bound the channel to 2 since when pipelined the render phase can finish before
|
|
|
|
// the time system runs.
|
|
|
|
let (s, r) = crossbeam_channel::bounded::<Instant>(2);
|
|
|
|
(TimeSender(s), TimeReceiver(r))
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The system used to update the [`Time`] used by app logic. If there is a render world the time is sent from
|
|
|
|
/// there to this system through channels. Otherwise the time is updated in this system.
|
|
|
|
fn time_system(
|
|
|
|
mut time: ResMut<Time>,
|
|
|
|
time_recv: Option<Res<TimeReceiver>>,
|
|
|
|
mut has_received_time: Local<bool>,
|
|
|
|
) {
|
|
|
|
if let Some(time_recv) = time_recv {
|
|
|
|
// TODO: Figure out how to handle this when using pipelined rendering.
|
|
|
|
if let Ok(new_time) = time_recv.0.try_recv() {
|
|
|
|
time.update_with_instant(new_time);
|
|
|
|
*has_received_time = true;
|
|
|
|
} else if *has_received_time {
|
|
|
|
warn!("time_system did not receive the time from the render world! Calculations depending on the time may be incorrect.");
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
time.update();
|
|
|
|
}
|
2022-05-26 00:27:18 +00:00
|
|
|
}
|