Upgrade to Bevy 0.17.0 (alternative/minimal)

[mgi388]

This is an alternative (and also WIP) to #49 with minimal changes. It leaves the "event/message" rename for later so that the PR is easier to review.

Like in #49, this PR:

• 3d example doesn't work (flickers and doesn't show sprites).
• headless example crashes with:

Encountered an error in system `bevy_spritesheet_animation::systems::sprite3d::remove_dropped_standard_materials`: Parameter `MessageReader<AssetEvent<StandardMaterial>>::messages` failed validation: Message not initialized

• Not sure if change from clone_weak to clone is acceptable/correct. If I had to guess, this could be the reason the 3d example doesn't work.
• Used my fork of iyes_perf_ui.

PRs/fixes to this PR are welcome.

@merwaaan feel free to push to it if you have ideas. I didn't look at the sprite 3d issue properly but maybe you know quicker than I do what is up.

[merwaaan]

Thanks for your help @mgi388!

I'm a bit overwhelmed at work at the moment, so I won't be able to look at the two blocking issues for now, unfortunately.

Using your fork of iyes_perf_ui sounds good to me (it's only used in a single example anyway).

[merwaaan]

I removed iyes_perf_ui in favor of Bevy's built-in FPS overlay so using a fork won't be necessary anymore.

[merwaaan]

@mgi388 I updated the crate to Bevy 0.17 with the help of your PR.
Also fixed the 3D sprites flickering and headless mode panicking.
It still needs a little bit of cleanup but I should be able to release a new version maybe tomorrow.

[mgi388]

@merwaaan awesome! Close these when ready. Interested to see what the fixes are.

[merwaaan]

The crate now supports Bevy 0.17. I started from your initial upgrade so thank you 🙂

---

Regarding the 3D sprite issue, it was due to the way we swapped meshes/materials when playing an animation.

Before Bevy 0.17:

commands.entity(entity).remove::<Mesh3d>();
commands.entity(entity).insert(Mesh3d(new_mesh_handle.clone()));

With Bevy 0.17 meshes get immediately deleted as if the remove() call unexpectedly applies to the new mesh.
The documented way to swap a mesh is to insert another Mesh3d component anyway so this now works:

commands.entity(entity).insert(Mesh3d(new_mesh_handle.clone()));

---

Regarding the headless example crashing, I switched the crate's systems to use Options for resources that might not exist depending on the context (headless, not all default plugins enabled, etc...)

From

pub fn some_system(
    mut materials: ResMut<Assets<StandardMaterial>>
) {
  // ...
}

To

pub fn some_system(
    mut materials: Option<ResMut<Assets<StandardMaterial>>>
) {
  // ...
}

(An alternative would have been to use conditional run_if_resource_exists when registering the system)

[mgi388]

@merwaaan regarding the headless example. I started to look at it as well and I think your fix does result in it compiling again but I don’t know if it’s the right fix. The reason is that event reader is listening for asset changed events on StandardMaterial. Of course bevy_spritesheet_animation uses StandardMaterial extensively. However, StandardMaterial doesn’t really exist in the minimal set of plugins (as far as I can tell). It does exist in the sense that the type is there, but I don’t think it’s a registered asset unless a specific plug-in is added. I tried to follow the dependency chain of plugins required to make it work but I basically ended up back at DefaultPlugins. Up to you if you want to look further or leave as is. But my approach was going to be to just delete the example and notify the original author they should look into it. I’m fine either way though, I don’t use a headless setup right now.

[merwaaan]

@mgi388 Indeed those resources might not exist with minimal plugins but as long as the types are known this compiles and runs ok. I was expecting the Option<> strategy to fail but Bevy seems to support it.

In practice, I'm not sure we actually have users for this use-case anymore so let's wait and see if anyone encounter issues and/or complains.