Particles, UI, and Animation in Bevy (0.10 Devlog 3)

[@jeffg4686]

@5:07 - In the Attack component, you store Entity as an owned. Is this just because it's a Copy type? There's this place in the mind with ECS where lifetimes start getting complicated. Can you speak to that at some point - managing lifetimes between objects in ECS (or am I just viewing this from the wrong angle?). I get that most components will be Copy types though.

[@logicprojects]

One of the beautiful things about Bevy is you almost never need to worry about lifetimes. Here remember Entities are literally just an id number so in a sense it's unsafe to keep the Entity because the underlying entity can despawn (but that's why query.get returns a Result). Bevy usually won't let you store a reference because you don't own any of your ECS data, Bevy does and you can only hold it for as long as the query lives. Trying to hold a reference between frames will always lead to horrible problems and is probably fundamentally impossible.

[@tim-blackbird]

Most of Bevy's screen space co-ordinates like for UI and viewports is +Y down except cursor position which is +Y up. viewport_to_world and friends currently match the cursor position. I might try to get cursor position swapped to match the rest in 0.11

[@logicprojects]

Interesting! It isn't a big problem, just a quirk. I'm always shocked that the game dev and UI world in general struggle to decide that y up is positive but industry standards are hard to change I guess.

[@jeffg4686]

I wonder if hanabi will be for WASM when WebGPU api browser implementations have their security sandbox implemented for all gpu communication?

[@principleshipcoleoid8095]

I wonder if gifs can be used in bevy

[@jeffg4686]

Not sure if you'd be interested, but I think there's a lot of use for a bevy shader site (like a market place, kind of like blendermarket but for bevy). I just wanted to throw the idea out there hoping someone runs with it. Would be cool to both be able to buy and sell wgsl shaders and ones that might require a full bevy example app - not just a WGSL itself - full rust examples ... Anyways, I think it would be good idea to spread around in case someone wants to go that direction (and take a cut on every sale ...). It's too much for me right now because I'm prepping house for sale, and moving. But wanted to put it out there as a need in Bevy land.

[@jeffg4686]

Can you do a comparison sometime of splitting logic in a bevy app into plugins versus using rust modules? Is there a benefit to one over the other?

[@logicprojects]

I don't think they solve the same problem and are actually used together in some projects I've seen. I try to stick to one plugin per module just to keep things simple for myself but I've seen a lot people use plugins as a much higher level of abstraction and keep many smaller modules. I don't think there's much of a standard and everyone has their own organizational preferences

[@jeffg4686]

One last comment. I think a focus should be put on Enums in Rust. It's an enum centric language. Getting enums down is one of the keys to being successful in picking up Rust. Like, the variants looking like Types, but their not. That will trip you up. Understanding that you have a reference to the enum as a whole, including the variant identifier when you have a reference to an enum value, until you match on it to get the value. I didn't get that for a long time. And the whole "middle ground" the variants play with being part of a type, but also looking and feeling like a type. This stuff is like Rust 101, but it really gets skipped over ..., most likely because most people coming to Rust have had good exposure to some functional languages that use adt. The documentation for Rust needs to discuss ADT and all these concepts of how variants look, feel, behave.

[@logicprojects]

I actually probably under use enums, I mostly treat them as C enums with no data or only very small datatypes associated with them. My main fear is that (if I remember right) the size of the enum must be the size of the biggest variant so it's easy to accidentally create a very large type that is mostly wasted bytes (but maybe that's premature optimization and byte golf on my side)

[@jeffg4686]

@@logicprojects - thanks. Maybe that's the most common use case in bevy - c style enums. That's one thing I think would be interesting to dig into - how your Rust code differs in Bevy than in non-ECS environment