Bevy 0.19#404
Conversation
Hmm, I guess the draw order is basically undefined for sprites with the same z coordinate? Still a regression from 0.18, where the order was stable, rather than changing when moving. I also can't find anything related in the release notes or migration guide. I see the following options:
|
Trouv
left a comment
Trouv
left a comment
There was a problem hiding this comment.
Thanks for this, so far I've only reviewed src. Curious how difficult it would be to split this up into a PR for the avian migration and the bevy 0.19 migration? I don't mind merging this with a git dependency on rapier
|
Avian migration moved to #405 and PR description updated. |
Being a native bevy plugin, avian provides support for new bevy versions quickly and is not plagued by dependency incompatibilities (like requiring rapier and bevy to use the same version of glam). Prepares for the Bevy 0.19 update in #404. As noted in dimforge/bevy_rapier#694, rapier skipped the glam version used by Bevy 0.19, so making them work together is cumbersome (and not even using a git version of bevy_rapier would work). Using avian instead of bevy_rapier allows us to update bevy without waiting for a solution and avoids similar problems in the future. As far as I can tell, nothing about the game feels significantly different with this change applied. One ugly hack was necessary to make it work correctly, marked by a comment.
|
I see the issue you're talking about w/ the sprite ordering, though I think it had something to do with the avian migration? Not bevy 0.19, I'm seeing it main now too. Regardless I think it's acceptable for now. It kinda makes sense to me that ordering between equal z-value entities would be undefined. Idk if bevy_ecs_ldtk should have an opinion on it, I think if users want to explicitly make the player on top, then add .1 to its z in post-processing. I'd be happy accepting a system for that in the platformer example in another PR |
|
Oh, you are right! I thought I hadn't seen in with avian on 0.18, but I guess I didn't properly pay attention. Kinda weird that the physics engine has an effect on the sprite ordering when it should handle only two dimensions, I'll try to figure out what is going on. |
|
Hmm, using bevy-inspector-egui I see additional components being added to entities while they are colliding. Maybe archetype changes can result in a different draw order for equal z coordinates? |
|
@neocturne |
Very straightforward update with only a few changes needed to fix all new errors and warnings, mostly around Resources as Components.
|
Great, PR is updated now. |
Update all dependencies that are unrelated to Bevy. No code changes. --- Depends on #404, as both touch adjacent lines in Cargo.toml.
🤖 I have created a release *beep* *boop* --- ## [0.15.0](v0.14.0...v0.15.0) (2026-07-05) ### ⚠ BREAKING CHANGES * upgrade to bevy 0.19 ([#404](#404)) ### Features * set per-tile opacity in tile maker ([#400](#400)) ([351986c](351986c)) * upgrade to bevy 0.19 ([#404](#404)) ([5c48dcb](5c48dcb)) ### Bug Fixes * map Array<FilePath> field to correct FieldValue variant ([#403](#403)) ([564dcb7](564dcb7)) ### Documentation Changes * add bevy_ecs_ldtk 0.15 to compatibility chart ([#407](#407)) ([8954fb5](8954fb5)) ### Example Changes * port platformer example from bevy_rapier to avian ([#405](#405)) ([c34db11](c34db11)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
3 participants
With the platformer example I'm seeing inconsistent sprite ordering between the player and the chests after the update to 0.19. See #404 (comment).I've also given this a superficial test with a simple personal project. I didn't notice any obvious issues here.