Alright! I have managed to find a *tolerable* working environment while travelling, so it's time for the #bevymergetrain that y'all have been waiting for!
Follow along, and see how we make decisions over at @bevy, as we build an #opensource #rustlang engine for #gamedev.
There's 15 community-approved PRs in the backlog this week: let's get started :) https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Ready-For-Final-Review+-label%3AX-Controversial+-label%3AS-Blocked+-label%3AS-Adopt-Me+
@bevy 1. https://github.com/bevyengine/bevy/pull/6624
Oh wow, that's... 6000 issues / PRs and 2 years old? That must be due to Jasmine's efforts to get through our backlog! Lovely to see some mergeable stuff to come out of that.
The PR itself is very simple and reasonable: don't use `usize`/ `isize` unless there's a good reason to: it's harder to reason about and less portable. +3/-3 no merge conflicts let's go!
@bevy 2. https://github.com/bevyengine/bevy/pull/8039
Another old PR, this time with merge conflicts. Adds a helpful little constructor for `Sprite`, with a custom size.
Closing out, this is more than a year old, seemingly abandoned and trivial to redo. If you want this, please submit a PR and credit the original author!
@bevy 3. https://github.com/bevyengine/bevy/pull/9805
Looks like another backlog item: a helper for computing vertex buffer layouts with offsets. Rendering *loves* working with very raw indexes and pointers, so I'm not surprised that this is useful.
A very simple little helper with nice docs. Merging.
@bevy 4. https://github.com/bevyengine/bevy/pull/10823
Effectively a bug fix for one of our impls: broadening them to cover *any* lifetime, not just 'static. Straightforward and useful: looks like we'd forgotten to apply the Ready-For-Final-Review label despite two approvals.
Pinging the author about the merge conflicts :)
@bevy 5. https://github.com/bevyengine/bevy/pull/12637
A quality-of-life PR for rendering: downgrading a panic when invalid texture formats are passed into a shader into a warning.
Lovely to see (Bevy needs to panic *way* less), but there's non-trivial merge conflicts. Pinging the author...
The accumulation of merge conflicts is a big part of why I want to trim down the backlog and focus reviews more tightly. Throughput and frustration is much better with a rapid turnaround and fewer PRs in flight!
@bevy 6. https://github.com/bevyengine/bevy/pull/12929
A complex performance optimization PR for the ECS internals that was cut from Bevy 0.14 due to risk. Very reasonable choice, but I'm pleased to see this come back around now!
Thoroughly reviewed, benchmarked (and even adds new ones for us!). Awesome. Thanks to Jondolf for bringing this to my attention.
Spun out a follow-up and merging once conflicts are resolved: now is a good point in the cycle.
@bevy 7. https://github.com/bevyengine/bevy/pull/14392
A regression fix: we lost the automatic `Send` + `Sync` implementations for `Commands`. That's annoying.
Really good review / mentorship by hymm: tackling this on `Commands` is much more reasonable. Safety comments are good (`Command` does require `Sync`), so I'm pleased with this.
Merging.
@bevy 8. https://github.com/bevyengine/bevy/pull/14580
Oh good, one of the more arcane bits of lore of "how do bevy_ecs's internals work" is getting documented.
Bevy has two distinct but related mechanisms for runtime borrow checking of systems and queries: one for "can this ever conflict" and a second for "does this conflict given the current world". Unsurprisingly, this was confusing!
Well-written and correct, merging :)
@bevy 9. https://github.com/bevyengine/bevy/pull/14651
Utility methods for infinite planes! Math folks love their utility methods TBH, and with good reason. Many of these operations are annoying to get right / fast, and well-named operations are often much less mysterious than a pile of matrix multiplications.
Signed distance, projection, isometry conversions... Okay, all reasonable. Well-documented and tested, and thoroughly bikeshedded. Merging.
@bevy 10. https://github.com/bevyengine/bevy/pull/14784
Conversion methods to and from `bool` and `Visibility`. Unfortunately, our visibility component is a tri-bool: visible, hidden and inherited. But for many users, they just want to operate on it quickly and easily, as if it were a bool.
This comes up *regularly*, and so while I'm not sure I'll personally make much use of it, there's definitely users who will.
At my urging, done via the `From` and `TryFrom` traits to be more useful and idiomatic. Merging.
@bevy 11. https://github.com/bevyengine/bevy/pull/14793
Ohoho: one of my oldest bugbears is finally getting fixed. `Style`, our layout component (obviously...) has a useless field, `direction`. In CSS, this sets the text direction, but in Bevy, it does literally nothing.
We should note waste bytes, and more importantly, should not expose nonfunctional APIs. Salvaged from an old, more complex PR! Yeet :D
@bevy 12. https://github.com/bevyengine/bevy/pull/14795
Evidently we're creating an RNG source twice in one of our examples. Whoops I wonder why dead code didn't catch that...
Looks good, merging.
@bevy 13. https://github.com/bevyengine/bevy/pull/14804
A great little lesson in defensive programming. You might think a window will *always* exist, but it turns out, it's destroyed before the application ends, causing a panic on exit.
This is sloppy: fix it with a graceful check. Love to see our examples getting cleaned up like that (and a good example of why I want better syntax for "just early return" in Rust / Bevy).
Merging.
@bevy 14. https://github.com/bevyengine/bevy/pull/14809
Ooh, this is a nice demonstration of why `catch_unwind` on panics is useful. Rather than endlessly checking if an asset whose loader panicked is loaded, catch the panic, convert it into an AssetState::Failed and then let the main program recover gracefully. Lovely!
Good to see this split out from the previously stalled work. Merging :)
@bevy 15. https://github.com/bevyengine/bevy/pull/14813
And finally, a good example of why rapid public iteration is so useful. Over the course of this development cycle, we introduced reflected functions, extended it to reflected closures, realized the closure form is actually just strictly more useful, and then collapsed it all to a single abstraction called `DynamicFunction`.
I like the naming and agree with the collapse. Changes are straightforward and the last-minute issue is fixed. Merging!
@bevy And that's it! Thanks a lot for following along: it was nice to see the little improvements everyone had made, and get through the backlog.
Now, I have family to socialize with, roller coasters to ride and hobby gamedev to do. See y'all in a week!
Auto traits are neat, but unfortunately, this happens regularly. I wish we could do better tbh!
I think the `assert_impl_all!` macro from the `static_assertions` crate could help with this problem.
What do you think?
https://docs.rs/static_assertions/1.1.0/static_assertions/macro.assert_impl_all.html
They specifically mention the use case of ensuring auto trait impls like `Send` & `Sync`