Chris Biscardi
banner
chrisbiscardi.bsky.social
Chris Biscardi
@chrisbiscardi.bsky.social
5.3K followers 340 following 540 posts
Rustlang and Rustlang accessories * YouTube: https://www.youtube.com/@chrisbiscardi * Learn Rust: https://www.rustadventure.dev/ * Rust Discord: https://discord.gg/GJ5UfxzUcP * Party Corgi Content Discord: https://discord.gg/partycorgi
Posts Media Videos Starter Packs
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
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
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.
there's so much cool ui in pokemon za
Cinnog is what I use for This Week in Bevy.

thisweekinbevy.com
The experimental static site generator Cinnog is now updated to #leptos 0.8 and #bevy ECS 0.17

Write static sites with in Leptos island mode. Bevy ECS is used as a data layer that can be queried with "normal" rust code.

github.com/NiklasEi/cin...
GitHub - NiklasEi/cinnog: Experimental static site generator using Leptos with Bevy ECS as a data layer
Experimental static site generator using Leptos with Bevy ECS as a data layer - NiklasEi/cinnog
github.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.