Starting off with an interesting little PR today I see.
So, every operating system (well, at least Windows and normal Linux distros) has a set of hyperparameters that can be controlled by the running application: think overclocking. The basic idea here is that if you're writing a document you want to prioritize battery life, but if you're playing a video game, you probably want performance.
If you are making a video game, your application should probably turn these on correctly, to avoid leaving performance etc on the table, especially relative to other games.
Unfortunately, these are all OS-specific.
Bevy, as a cross-platform game engine, needs some way to expose these.
This PR is one of our first steps towards that (there's various windowing settings you can use too).
Thankfully, winit already basically handles this for us so it's just glue and plumbing.
Off-by-default via a feature flag, which is sensible IMO: Bevy is used for more than just games, and disabling features sucks. Will need to go in a "performance optimization tips and tricks" bit of the Book. One of these days...
Anyways, this is worth doing and the implementation is fine: merging.
The inspector work marches on, carried by Joe!
The core idea of BRP is "here is a nice boring API that you can call into to read and write to a running Bevy app, from any other application or language". The central motivation here is tooling of all sorts: inspectors, debuggers, profilers, automated testing and more.
This PR adds a very simple async HTTP client that reads / writes to a running Bevy app: a little bit of glue code that will be shared by all of these tools. Jackdaw (the community editor project) already uses something very similar: this is effectively an upstream. It's not very sophisticated yet (e.g. no keep-alive on the connection), but that's fine for a first PR: the point is that we can harden and improve it once, rather than reimplementing it a dozen times across the ecosystem.
This PR is a really good example of the value of good module docs. I pushed hard on this through multiple review rounds, asking Joe to give more context on the whole thing: why does this exist, how is it architected, what tradeoffs and limitations exist. Now, someone who is new to either Bevy's tooling story or this sort of architecture can read it, find the key terms to Google, and get a good sense of what's going on, without hunting down the original author. This was particularly useful to me: client-server architectures and RPC and JSON APIs simply don't come up much when doing game engine development or scientific computing. You really never stop learning things.
More to do here, but this is an awesome first step. Merging.
Alas, we are not free of syn.
The Big Macro Crate has a new major version out, and it's our turn to upgrade.
Given that it's already pulled in transitively (with uh a few semver violations, macros are hard),
there's no real cost to doing so.
dependabot was not smart enough to do this automatically, so a human has picked up the torch. Hmm, why is this still in draft with 3 approvals?
Oh I see:
encase 0.12.2 has been yanked, so this is no longer urgent. The remaining goal is the syn 3 migration. I'd like to bump encase along with it, but glam still depends on encase 0.12, so that isn't possible yet. Waiting for glam might let us migrate without the FIXME workaround from #25697, but I don't know when that will happen. So I can either close this in favor of #25697, or keep it as a draft until glam catches up. If there's no preference, I'll close this.
Yeah, let's hold off on this, there's no rush. Marking as blocked, and commenting so everyone understands my rationale.
Bevy's default font setup on main is rather a hack,
and has been for years.
Being able to show text without requiring people to download an asset, or even pick a font is super useful for quick debugging and examples, but doing so runs contrary to how Bevy's asset system and text handling actually works.
Instead, we pack a tiny font into a bunch of bytes, and embed it directly into the library itself. Janky, but effective.
One neat trick though: you can overwrite this asset, changing the default font everywhere in your app. Really useful for prototyping, or if you're debugging and want non-Latin characters for example.
Unfortunately, this hack is not very well-documented, and the previous API for doing so was arcane! Let's make this a real feature. What's that? You can just set a resource? There's docs? Great, that's much more reasonable!
Migration guide has a minor error in it: DefaultFont, not DefaultFontSource.
Verifying, fixing (ty Github suggestion feature), committing and merging.
So, the really cool thing about these sort of helper functions is that you can make simplifying assumptions: speeding up bulk operations by avoiding duplicated work. In this case, we're leaving command flushing until after the batch operation is done. Neat little 2 to 10% speedup, not shabby.
This isn't pure benchmaxxing either: the new despawn_all_with helper takes a filter generic,
making it very useful for selective bulk updates.
We use it in our DespawnOnExit internals already, making your scene transitions just that little bit snappier.
Sensible PR, good benchmarking, merging. Suitably bite-sized, as we can only hope all perf PRs are.
The Populated system param's evil twin: skip this system if any entities match this filter.
I was a bit skeptical at first: can't this just be a run condition? But on reflection, I think that this is quite nice: it keeps the logic localized well, and there's even a place or two in the engine where this can be used. I like the way that it's only one parameter, and the name makes the intent clear.
Okay, I'm sold: this helper is worth a smidgen of compile time. Very well-made PR overall: very good docs, and the cross-links (i.e. breadcrumbs) really help discoverability! Helpers don't help if you don't know about them.
Release notes will almost certainly get cut (too minor) but eh, that's later editing. Merging :)
Today in "let's have parity with the web": border styles! Kind of an eclectic collection (see the screenshot), but this will be great for quick games and non-game applications that don't want to go all-out with artistic nine-patch borders.
Always nice to give folks more creative control, and this sort of procedural variation is particularly approachable. Still a couple of extra border types (dashed and dotted) from the standard set to add, but those need shader changes. Sure, that's fine: don't make perfect the enemy of the good. I'd also accept additional variants if they're interesting and look nice!
Code looks fine and this is a fun feature: merging.
How many years have I wanted a tree widget in Bevy's native UI stack for? It's finally here!
This is so so useful for editor-style work: asset browsing, entity inspection, virtual file systems... We merged the headless (unthemed) version of this: it's time for the prettier Feathers-flavored variation. I'm sure there will be more refinement of the exact style as we go but it's so cool to actually get this in. I even fixed a couple of bugs / perf issues on the headless variant last week :)
Lovely stuff, merging. Can't wait to see this in action.
Tiny doc fixes! Needs more # apparently.
Easy merge.
Great overview of the merge train. I especially appreciate the explanations behind the design decisions and trade-offs for each PR, it provides valuable context beyond the code changes and helps readers understand the direction of the Bevy ecosystem.