forestia/bevy
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Change the ecs_guide example so it doesn't make it seem like startup systems have to be thread local (#759)

Browse Source
This commit is contained in:
Alec Deason 2020-11-01 14:32:48 -08:00 committed by GitHub
parent 9cc6368b28
commit 5cd67f7867
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
examples/ecs/ecs_guide.rs
View File

@ -141,18 +141,16 @@ fn game_over_system(
// the initial "state" of our game. The only thing that distinguishes a "startup" system from a "normal" system is how it is registered: // the initial "state" of our game. The only thing that distinguishes a "startup" system from a "normal" system is how it is registered:
// Startup: app.add_startup_system(startup_system) // Startup: app.add_startup_system(startup_system)
// Normal: app.add_system(normal_system) // Normal: app.add_system(normal_system)
// This startup system needs direct access to the ECS World and Resources, which makes it a "thread local system". fn startup_system(mut commands: Commands, mut game_state: ResMut<GameState>) {
// That being said, startup systems can use any of the system forms we've covered. We will also cover thread local systems more in a bit.
fn startup_system(world: &mut World, resources: &mut Resources) {
// Create our game rules resource // Create our game rules resource
resources.insert(GameRules { commands.insert_resource(GameRules {
max_rounds: 10, max_rounds: 10,
winning_score: 4, winning_score: 4,
max_players: 4, max_players: 4,
}); });
// Add some players to our world. Players start with a score of 0 ... we want our game to be fair! // Add some players to our world. Players start with a score of 0 ... we want our game to be fair!
world.spawn_batch(vec![ commands.spawn_batch(vec![
( (
Player { Player {
name: "Alice".to_string(), name: "Alice".to_string(),
@ -168,7 +166,6 @@ fn startup_system(world: &mut World, resources: &mut Resources) {
]); ]);
// set the total players to "2" // set the total players to "2"
let mut game_state = resources.get_mut::<GameState>().unwrap();
game_state.total_players = 2; game_state.total_players = 2;
} }
@ -201,8 +198,6 @@ fn new_player_system(
// These run on the main app thread (hence the name "thread local") // These run on the main app thread (hence the name "thread local")
// WARNING: These will block all parallel execution of other systems until they finish, so they should generally be avoided if you // WARNING: These will block all parallel execution of other systems until they finish, so they should generally be avoided if you
// care about performance // care about performance
// NOTE: You may notice that this function signature looks exactly like the "startup_system" above.
// Thats because they are both thread local!
#[allow(dead_code)] #[allow(dead_code)]
fn thread_local_system(world: &mut World, resources: &mut Resources) { fn thread_local_system(world: &mut World, resources: &mut Resources) {
// this does the same thing as "new_player_system" // this does the same thing as "new_player_system"
@ -259,7 +254,7 @@ fn main() {
.init_resource::<GameState>() .init_resource::<GameState>()
// Startup systems run exactly once BEFORE all other systems. These are generally used for // Startup systems run exactly once BEFORE all other systems. These are generally used for
// app initialization code (ex: adding entities and resources) // app initialization code (ex: adding entities and resources)
.add_startup_system(startup_system.thread_local_system()) .add_startup_system(startup_system.system())
// my_system.system() calls converts normal rust functions into ECS systems: // my_system.system() calls converts normal rust functions into ECS systems:
.add_system(print_message_system.system()) .add_system(print_message_system.system())
// //