Chris Biscardi

Bevy lookin good

Extreme Bevy 6: Sprite animations In this part, we'll add sprites for our main characters and animate them.

I've updated Extreme Bevy, my tutorial series on creating a p2p web game to Bevy 0.17.

I also added a brand new chapter on sprite animations. It's starting to look like a real game now :)

Playable embeds at the end

johanhelsing.studio/posts/extrem...

#bevyengine #rustlang #gamedev

updated the low-poly terrain chunk management demo to 0.17 and made it use bevy_malek_async, which is *awesome*.

github.com/rust-adventu...

2d visibility mesh, passed into a post-process shader and obscuring non-visible areas

Starting a patreon is one thing, but building the community that funds the patreon typically has to be the first concern.

For example: if everything you do is locked behind a patreon paywall, then nobody will be able to share that with others and it's hard to grow the group of patreon members.

(The latest was a wasm document and related code examples)

jeez I have scripts and workshops that I completely wrote, finished, and forgot to ever publish.

Yeah that's a problem in the "pick the closest wall" section of the demo. Given two rays with a series of hits each, how do you pick the right wall to draw the triangle on

Yeah definitely an open question, and I think with some use case based answers

nope, that's it. Its nothing special. I'll do some profiling and maybe some optimizations after I fix the bugs that are left. will look into more serious optimizations like bvh, etc if I need to.

I'm only shooting rays at the vertices so they're all guaranteed "hits" from that perspective. I'm not firing arbitrary numbers of rays hoping they hit, thus there's no resolution issues with number of rays that may or may not hit a vertex, etc.

I mean, in a 2d game how many vertices are you actually drawing? Its not 3d and there's no million+ vertex meshes.

oh and the "algorithm to get the points to raytrace towards" is just "grab the vertices from the meshes".

So there's plenty of things to optimize but I'm not shooting any rays that don't hit. I haven't noticed any issues while I've been working on it, so its sitting somewhere well under 120fps frame budget with all that said.

I haven't finished the implementation, so haven't benchmarked anything yet.

The algorithm iterates over the vertices in sorted angle order, doing line/segment intersection for each. There's no bvh, I'm naively redoing all the work every frame, and I'm running in dev profile with no optimizations

Yes

nothing in this is an sdf

and with rnadom shapes

with wireframes

getting closer

progress on the 2d visibility mesh demo.

We built out raytracing from scratch, now just need to take advantage of it to fill in the rest of the triangles

trigger C; queue D

queue D; trigger C;

Now what *does* happen, is that because observers are recursive, if you "trigger C; queue D" vs "queue D; trigger C" you will see different behavior.

This is because the observer will always run to completion before continuing. One of these images is the former, and the other is the latter.

Observers run their command queues recursively, immediately. So you don't need to "place apply_deferred in the right spot".

For example, if you trigger observer A and B in sequence, then in A's handler you trigger Observer C and queue a command D; C and D run before B.

Avian is getting pretty big nowadays! To mark the start of a new release cycle, I spent some time improving our processes moving forward.

Notably, Avian now stores migration guides in-repo, similar to Bevy:
github.com/avianphysics...

there's so much cool ui in pokemon za

Cinnog is what I use for This Week in Bevy.

thisweekinbevy.com

re: gotchas in the proposed solution.

I haven't tested this at all in that capacity, so just don't know.

That said, it uses a queued command to power the behavior, which works well with observers and their recursive execution. So no frame delay but maybe something more subtle?

re: upstreaming, something that has the behavior people expect will be upstreamed. Alice is very aware of this and wants it to happen.

That slice is empty by default, so It won't fire any observers that have filters.

If you fill that slice, it will fire for *all* components you put in that slice.

So the article shows how to identify which components from a pre-set list are actually on the entity, and only include those

The tricky part is that you as the user calling trigger have to call trigger_with, and place the components you want to trigger in the components slice. Which means you can put *any* components in that slice, even components that do/don't exist on that entity.