They are! It's a great way to send data between systems and break functionality out across plugins. I plan to give them more love going forward and this was just the quick intro to them.
Most of what I'm working on right now is 2D. I probably won't do another absolute beginner series for a bit though. Nothing in bevy really changes that much from 2d-3d, this game would work as is with 2d. Change the camera and the art and start ignoring z values
Isn't checking through every Entity's health constantly performance intensive? Or is it negligible enough to ignore? I've read that querying is a low cost for performance, but iterating thru the query can be performance heavy.
You can use a change filter to limit how many you iterate through but always profile before getting too into things like that. I've never had simply iterating a query have a meaningful performance impact. In this case my experience would say you'd hit rendering performance problems before querying for small components cause the problems
Regarding Stages, the docs list 3 Main stages. Are the "substages" within each of those treated as stages (I'm assuming). render sub-app (RenderStage): Extract, Prepare, Queue, PhaseSort, Render, Cleanup. Is this like "top level stages" each with some child stages or are the child stages here not considered "bevy stages" (proper)
The CoreStage enum has 5 stages. Can you link the 3 Main Stages you are referring to? Also Startup is the only stage with substages I'm aware of by default and each one of those is treated as its own stage and personally I don't know the nuance of nesting stages that well if you wanted to implement that yourself. The render app is a complex topic. Basically imagine it as a completely separate game running with its own entities and systems. Those stages are customized for the render pipeline and the cheatbook has an overview page on what is done in each one. Currently the render app schedule runs after the main app every frame.
Here's how I think an improved API (or layer on top of) for the system configuration would look. app.when_entering(GameState::GamePlay).run_systems(system1, system2, system3) .when_updating(GameState::GamePlay).run_systems(system4, system5) -- would read much better IMO. Right now my eyes go all over the place determining what is being wired together. I think they did an amazing job, but this config API could get cleaned up in 1.0 release. I'm probably a lot less of a programmer in a lot of ways than most rust devs, but one thing I'm good at is readability improvements. I basically require it in able for me to work effectively as I just lose track too easily (adhd). That's a lot what we get out of the "builder" style apis is that it's possible to build it up in a way it really reads like a sentence, which is how I feel all 'top level' code should read. The little bit of genius I do have all revolves around making it simple at the high level. I think the API I suggested above could use some readability improvements itself, but it's much simpler to see than current api. I guess everyone is hopping on the iyes_loopless for this tho, so I guess that's what I should be looking at anyways. The other thought is that there could be a builtin way of configuring systems that uses a Ron file. That way, it could be easier to create a design time editor as well for configuring the systems.
If you read the discussion on the stageless rfc there is tons of discussion on making the API clear and flexible. I think bevy (and most rust projects) value the flexibility much more than readability if a tradeoff is made however. Every bevy update comes with better readability though and there's always active discussion on the bevy discord about changing names and things in the API to make it less confusing. If you're passionate enough about bevy, you can participate in it's development and help drive it in a more clear direction.
Wanted to suggest a topic. For those of us coming from more higher level languages like .NET, we don't do much bit wrangling. When I come across stuff like this in various framework's source code, I cringe. ((self.counter >> 56) & 0xff) as u8, ((self.counter >> 48) & 0xff) as u8, ((self.counter >> 40) & 0xff) as u8 Because it has no readability. But know it's just my lack of understanding most likely. As I understand it, the reason is just that it's faster, correct? Is this "the way" of the system programmer - do all math stuff in bitwise operations?
Where did you come across code like that? I don't believe it would be faster because any modern compiler should trivially turn divisions by powers of 2 into shifts meaning the resulting asm is identical. But in the case you gave it's clear that it's trying to extract 3 consecutive bytes from that number (maybe for networking reasons? It's unclear the context). I'd only use that code style when working very close to hardware where bits matter (i.e. if a manual says bit 3 controls a color mode then using bitwise ops is often a clearest way of showing that in the code). On some very weak embedded platforms there also may not be a fast division operation at the asm level (I've seen a single division by 3 get turned into 3 function calls by the compiler for a MSP430), so it is common in those circles to use bit shifting which restricts you to only dividing by 2 because that will have a very fast asm implementation. At some point I will do some embedded rust and maybe even hardware design videos because that is my real specialty.
@@logicprojects - thanks, great answer. I didn't know that hte compiler converted to a bit shift automatically. I can't remember the source, just some code on github when browsing around some crates. It's not too uncommon to see in lower level rust code. Maybe we really don't need much at "application" level. Cool regarding hardware stuff - I'd like to get into that eventually. I've been neck deep in 3d for a while now. Bevy and 3D alone is a beast to keep my mind around, but would love to start integrating hardware solutions at some point. Very relevant in upcoming VR world (a lot of external gadget interactions as well via bluetooth/wifi). Nannou project looks amazing - haven't dug into it yet tho ...
Events seem like a really powerful system in Bevy, thank you for covering them!
They are! It's a great way to send data between systems and break functionality out across plugins. I plan to give them more love going forward and this was just the quick intro to them.
Thanks for updating these series. One of the only good series on Bevy on RUclips.
Thank you!
@@logicprojects Should we wait for a new 2D project or not?
Most of what I'm working on right now is 2D. I probably won't do another absolute beginner series for a bit though. Nothing in bevy really changes that much from 2d-3d, this game would work as is with 2d. Change the camera and the art and start ignoring z values
@@logicprojects Thanks for the reply...
Waiting for the rapier crate update to bevy 0.9 soon (trait bound errors right now), this is growing pretty fast though.
I was watching the rapier PR. It looked like it was ready to go 2 days ago but I don't know why they haven't merged it yet...
Same here and then I'm upgrading
Isn't checking through every Entity's health constantly performance intensive? Or is it negligible enough to ignore? I've read that querying is a low cost for performance, but iterating thru the query can be performance heavy.
You can use a change filter to limit how many you iterate through but always profile before getting too into things like that. I've never had simply iterating a query have a meaningful performance impact. In this case my experience would say you'd hit rendering performance problems before querying for small components cause the problems
Regarding Stages, the docs list 3 Main stages.
Are the "substages" within each of those treated as stages (I'm assuming).
render sub-app (RenderStage): Extract, Prepare, Queue, PhaseSort, Render, Cleanup.
Is this like "top level stages" each with some child stages or are the child stages here not considered "bevy stages" (proper)
The CoreStage enum has 5 stages. Can you link the 3 Main Stages you are referring to? Also Startup is the only stage with substages I'm aware of by default and each one of those is treated as its own stage and personally I don't know the nuance of nesting stages that well if you wanted to implement that yourself.
The render app is a complex topic. Basically imagine it as a completely separate game running with its own entities and systems. Those stages are customized for the render pipeline and the cheatbook has an overview page on what is done in each one. Currently the render app schedule runs after the main app every frame.
will there be anymore bevy longs?
I might record more in the future. I dont have any planned at the moment
@@logicprojects ok thank you
Here's how I think an improved API (or layer on top of) for the system configuration would look.
app.when_entering(GameState::GamePlay).run_systems(system1, system2, system3)
.when_updating(GameState::GamePlay).run_systems(system4, system5)
-- would read much better IMO. Right now my eyes go all over the place determining what is being wired together.
I think they did an amazing job, but this config API could get cleaned up in 1.0 release.
I'm probably a lot less of a programmer in a lot of ways than most rust devs, but one thing I'm good at is readability improvements. I basically require it in able for me to work effectively as I just lose track too easily (adhd). That's a lot what we get out of the "builder" style apis is that it's possible to build it up in a way it really reads like a sentence, which is how I feel all 'top level' code should read. The little bit of genius I do have all revolves around making it simple at the high level. I think the API I suggested above could use some readability improvements itself, but it's much simpler to see than current api. I guess everyone is hopping on the iyes_loopless for this tho, so I guess that's what I should be looking at anyways.
The other thought is that there could be a builtin way of configuring systems that uses a Ron file. That way, it could be easier to create a design time editor as well for configuring the systems.
If you read the discussion on the stageless rfc there is tons of discussion on making the API clear and flexible. I think bevy (and most rust projects) value the flexibility much more than readability if a tradeoff is made however. Every bevy update comes with better readability though and there's always active discussion on the bevy discord about changing names and things in the API to make it less confusing. If you're passionate enough about bevy, you can participate in it's development and help drive it in a more clear direction.
@@logicprojects - yeah, I'm not worried or nothing. I think it's pretty amazing as is. Probably use the iyes_loopless for a real world project.
Wanted to suggest a topic.
For those of us coming from more higher level languages like .NET, we don't do much bit wrangling.
When I come across stuff like this in various framework's source code, I cringe.
((self.counter >> 56) & 0xff) as u8,
((self.counter >> 48) & 0xff) as u8,
((self.counter >> 40) & 0xff) as u8
Because it has no readability. But know it's just my lack of understanding most likely.
As I understand it, the reason is just that it's faster, correct?
Is this "the way" of the system programmer - do all math stuff in bitwise operations?
Where did you come across code like that? I don't believe it would be faster because any modern compiler should trivially turn divisions by powers of 2 into shifts meaning the resulting asm is identical. But in the case you gave it's clear that it's trying to extract 3 consecutive bytes from that number (maybe for networking reasons? It's unclear the context). I'd only use that code style when working very close to hardware where bits matter (i.e. if a manual says bit 3 controls a color mode then using bitwise ops is often a clearest way of showing that in the code).
On some very weak embedded platforms there also may not be a fast division operation at the asm level (I've seen a single division by 3 get turned into 3 function calls by the compiler for a MSP430), so it is common in those circles to use bit shifting which restricts you to only dividing by 2 because that will have a very fast asm implementation. At some point I will do some embedded rust and maybe even hardware design videos because that is my real specialty.
@@logicprojects - thanks, great answer. I didn't know that hte compiler converted to a bit shift automatically. I can't remember the source, just some code on github when browsing around some crates. It's not too uncommon to see in lower level rust code. Maybe we really don't need much at "application" level. Cool regarding hardware stuff - I'd like to get into that eventually. I've been neck deep in 3d for a while now. Bevy and 3D alone is a beast to keep my mind around, but would love to start integrating hardware solutions at some point. Very relevant in upcoming VR world (a lot of external gadget interactions as well via bluetooth/wifi). Nannou project looks amazing - haven't dug into it yet tho ...