feat!: upgrade to bevy and bevy_ecs_tilemap 0.15 (#340)

To keep up with the bevy ecosystem, this change makes bevy_ecs_ldtk compatible with bevy 0.15. Aside from the dependency breaking changes, this also introduces some breaking changes to bevy_ecs_ldtk itself, which are covered in the new migration guide in the book.

---------

Co-authored-by: Matthias Schiffer <mschiffer@universe-factory.net>
Co-authored-by: Trevor Lovell <trevorlovelldesign@gmail.com>

Author: 3 people

Cargo.toml

@@ -15,8 +15,10 @@ members = ["macros"]
 
 [dependencies]
 bevy_ecs_ldtk_macros = { version = "0.10.0", optional = true, path = "macros" }
-bevy_ecs_tilemap = { version = "0.14.0", default-features = false}  
-bevy = { version = "0.14", default-features = false, features = ["bevy_sprite"] }
+bevy_ecs_tilemap = { version = "0.15.0", default-features = false }
+bevy = { version = "0.15", default-features = false, features = [
+    "bevy_sprite",
+] }
 derive-getters = "0.3.0"
 serde = { version = "1.0", features = ["derive"] }
 serde_json = "1.0"
@@ -27,11 +29,11 @@ derive_more = "0.99.17"
 path-clean = "1.0.1"
 
 [dev-dependencies]
-bevy = "0.14"
-bevy_rapier2d = "0.27.0"
+bevy = "0.15"
+bevy_rapier2d = "0.28.0"
 fake = { version = "2.8.0", features = ["uuid"] }
 rand = "0.8"
-bevy-inspector-egui = "0.25" 
+bevy-inspector-egui = "0.28"
 
 [features]
 default = ["derive", "render", "internal_levels"]

book/src/SUMMARY.md

@@ -32,5 +32,6 @@
 - [Migration Guides](how-to-guides/migration-guides/README.md)
   - [Migrate from 0.8 to 0.9](how-to-guides/migration-guides/migrate-from-0.8-to-0.9.md)
   - [Migrate from 0.9 to 0.10](how-to-guides/migration-guides/migrate-from-0.9-to-0.10.md)
+  - [Migrate from 0.10 to 0.11](how-to-guides/migration-guides/migrate-from-0.10-to-0.11.md)
 ---
 [API Reference](api-reference.md).

book/src/explanation/anatomy-of-the-world.md

@@ -40,8 +40,8 @@ Naturally, this can only occur in Tile/AutoTile layers (or IntGrid layers with A
 ## Level backgrounds
 LDtk allows you to supply a background color and a background image for individual levels.
 `bevy_ecs_ldtk` renders these by default.
-The background color is spawned as a normal bevy [`SpriteBundle`](https://docs.rs/bevy/latest/bevy/prelude/struct.SpriteBundle.html), as a child of the level entity.
-The background image, if it exists, is also spawned as a `SpriteBundle`.
+The background color is spawned as a normal bevy [`Sprite`](https://docs.rs/bevy/latest/bevy/prelude/struct.Sprite.html), as a child of the level entity.
+The background image, if it exists, is also spawned as a `Sprite`.
 
 These background sprites can be disabled (not spawned) using the settings resource [`LdtkSettings`](https://docs.rs/bevy_ecs_ldtk/0.10.0/bevy_ecs_ldtk/prelude/struct.LdtkSettings.html): <!-- x-release-please-version -->
 ```rust,no_run

book/src/explanation/game-logic-integration.md

@@ -27,14 +27,14 @@ struct Player;
 #[derive(Default, Bundle, LdtkEntity)]
 struct PlayerBundle {
     player: Player,
-    #[sprite_bundle]
-    sprite_bundle: SpriteBundle,
+    #[sprite]
+    sprite: Sprite,
 }
 ```
 
 How does `LdtkEntity`/`LdtkIntCell` construct the bundle when derived?
 Without any intervention, the bundle's fields are constructed using the bundle's `Default` implementation.
-However, various attributes are available to override this behavior, like `#[sprite_bundle]` in the above example.
+However, various attributes are available to override this behavior, like `#[sprite]` in the above example.
 This attribute gives the entity a sprite using the tileset in its LDtk editor visual.
 For documentation about all the available attributes, check out the API reference for these traits:
 - [`LdtkEntity`](https://docs.rs/bevy_ecs_ldtk/0.10.0/bevy_ecs_ldtk/app/trait.LdtkEntity.html) <!-- x-release-please-version -->
@@ -74,11 +74,10 @@ fn process_player(
             commands
                 .entity(entity)
                 .insert(Player)
-                .insert(SpriteBundle {
-                    texture: assets.load("player.png"),
-                    transform: *transform,
-                    ..default()
-                })
+                .insert((
+                    Sprite::from_image(assets.load("player.png")),
+                    *transform,
+                ))
                 .with_children(|commands| {
                     commands.spawn(PlayerChild);
                 });
@@ -121,8 +120,8 @@ struct Player;
 #[derive(Default, Bundle, LdtkEntity)]
 struct PlayerBundle {
     player: Player,
-    #[sprite_bundle]
-    sprite_bundle: SpriteBundle,
+    #[sprite]
+    sprite: Sprite,
 }
 
 fn process_player(

book/src/how-to-guides/make-level-selection-follow-player.md

@@ -25,7 +25,7 @@ Use the transforms of the spawned levels and width/height info from the level's
 
 
 To access the level asset data, you first need to access the project asset data.
-Assuming you only have one project, query for the only `Handle<LdtkProject>` entity and look up its asset data in the `LdtkProject` asset store.
+Assuming you only have one project, query for the only `LdtkProjectHandle` entity and look up its asset data in the `LdtkProject` asset store.
 Then, get the raw level data for every spawned level using the level entity's `LevelIid` component (there is a provided method for this).
 
 ```rust,no_run

book/src/how-to-guides/migration-guides/migrate-from-0.10-to-0.11.md

@@ -0,0 +1,118 @@
+# Migrate from 0.10 to 0.11
+
+## Bevy upgrade
+`bevy_ecs_ldtk` has upgraded to Bevy and `bevy_ecs_tilemap` version `0.15`.
+A Bevy `0.15` migration guide is available on [Bevy's website](https://bevyengine.org/learn/migration-guides/0-14-to-0-15/).
+
+## `LdtkSpriteSheetBundle` replaced with `Sprite`
+Since the `Sprite` struct in Bevy `0.15` can now store `TextureAtlas` information on its own, the use of `LdtkSpriteSheetBundle` has been replaced by a simple use of `Sprite`. The macro has changed as well, and is now named `#[sprite_sheet]`.
+```rust,ignore
+// 0.10
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+#[derive(Default, Bundle, LdtkEntity)]
+struct PlayerBundle {
+    #[sprite_sheet_bundle]
+    sprite_bundle: LdtkSpriteSheetBundle,
+    #[grid_coords]
+    grid_coords: GridCoords,
+}
+```
+```rust,ignore
+// 0.11
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+#[derive(Default, Bundle, LdtkEntity)]
+struct PlayerBundle {
+    #[sprite_sheet]
+    sprite_sheet: Sprite,
+    #[grid_coords]
+    grid_coords: GridCoords,
+}
+```
+
+## `SpriteBundle` also replaced with `Sprite`
+When using a `SpriteBundle` with the `#[sprite_bundle]` macro, use a `Sprite` instead. The macro is now named `#[sprite]`.
+```rust,ignore
+// 0.10
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+#[derive(Bundle, LdtkEntity, Default)]
+pub struct Player {
+    player: PlayerComponent,
+    health: Health,
+    #[sprite_bundle]
+    sprite_bundle: SpriteBundle,
+}
+```
+```rust,ignore
+// 0.11
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+#[derive(Bundle, LdtkEntity, Default)]
+pub struct Player {
+    player: PlayerComponent,
+    health: Health,
+    #[sprite]
+    sprite: Sprite,
+}
+```
+
+## `Handle<LdtkProject>` replaced with `LdtkProjectHandle`
+Handles cannot be used as components in Bevy `0.15` onward. This has two changes.
+### Call `.into()` when loading a project
+First, you must call `.into()` when loading the world.
+```rust,ignore
+// 0.10
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
+    commands.spawn(LdtkWorldBundle {
+        ldtk_handle: asset_server.load("my_project.ldtk"),
+        ..Default::default()
+    });
+}
+```
+```rust,ignore
+// 0.11
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
+    commands.spawn(LdtkWorldBundle {
+        ldtk_handle: asset_server.load("my_project.ldtk").into(),
+        ..Default::default()
+    });
+}
+```
+### Replace usages of `Handle<LdtkProject>`
+Second, uses of `Handle<LdtkProject>` in queries must be replaced with `LdtkProjectHandle`. It is enough to replace the type in the signature, as the `LdtkProjectHandle` type is a drop-in replacement for the handle.
+
+```rust,ignore
+// 0.10
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+fn respawn_world(
+    mut commands: Commands,
+    ldtk_projects: Query<Entity, With<Handle<LdtkProject>>>,
+    input: Res<ButtonInput<KeyCode>>,
+) {
+    if input.just_pressed(KeyCode::KeyR) {
+        commands.entity(ldtk_projects.single()).insert(Respawn);
+    }
+}
+```
+```rust,ignore
+// 0.11
+# use bevy_ecs_ldtk::prelude::*;
+# use bevy::prelude::*;
+fn respawn_world(
+    mut commands: Commands,
+    ldtk_projects: Query<Entity, With<LdtkProjectHandle>>,
+    input: Res<ButtonInput<KeyCode>>,
+) {
+    if input.just_pressed(KeyCode::KeyR) {
+        commands.entity(ldtk_projects.single()).insert(Respawn);
+    }
+}
+```
+

book/src/how-to-guides/migration-guides/migrate-from-0.8-to-0.9.md

@@ -12,7 +12,7 @@ To update your game to LDtk 1.5.3, you should only need to install the new versi
 Fields on an `LdtkEntity`- or `LdtkIntCell`-derived bundle are no longer constructed from the field's `Default` implementation, but the bundle's.
 
 You may observe different behavior in `0.9` if the value for a field in your bundle's `Default` implementation differs from the field type's own `Default` implementation:
-```rust,no_run
+```rust,ignore
 # use bevy::prelude::*;
 # use bevy_ecs_ldtk::prelude::*;
 #[derive(Component)]
@@ -50,7 +50,7 @@ struct MyBundle {
     component: MyComponentThatImplementsDefault,
 }
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;
 # #[derive(Default, Component)]
@@ -80,7 +80,7 @@ fn get_level_of_entity(
     }
 }
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;
 // 0.9
@@ -114,7 +114,7 @@ fn do_some_processing_with_ldtk_data(
     // do something
 }
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;
 // 0.9
@@ -135,7 +135,7 @@ let tileset_map = ldtk_project.tileset_map;
 let int_grid_image_handle = ldtk_project.int_grid_image_handle;
 let level_map = ldtk_project.level_map;
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # fn foo(ldtk_project: LdtkProject) {
 // 0.9
@@ -157,7 +157,7 @@ ldtk_asset.iter_levels();
 
 ldtk_asset.get_level(&LevelSelection::Uid(24));
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::{prelude::*, ldtk::LdtkJson};
 # fn foo(ldtk_json: LdtkJson, ldtk_project: LdtkProject) {
 // 0.9
@@ -215,7 +215,7 @@ fn print_level_entity(levels: Query<Entity, With<Handle<LdtkLevel>>>) {
     }
 }
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;
 // 0.9
@@ -238,7 +238,7 @@ fn print_level_uid(levels: Query<Handle<LdtkLevel>>, level_assets: Res<Assets<Ld
     }
 }
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;
 // 0.9
@@ -260,7 +260,7 @@ If the level data you need *is* inside the level's `layer_instances`, you may wa
 A `Level` might not have complete data - in the case that it's the "raw" level inside an external-levels project's `LdtkProject` asset.
 This new `LoadedLevel` type provides type guarantees that the level has complete data.
 For internal-levels (aka "standalone") projects, you can retrieve loaded level data with a `LevelIid` and `LdtkProject` alone:
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;
 // 0.9, w/ internal_levels enabled
@@ -336,7 +336,7 @@ let level_set = LevelSet {
     ].into_iter().collect(),
 }
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # fn f() {
 // 0.9
@@ -364,7 +364,7 @@ fn assert_level_event_type(mut level_events: EventReader<LevelEvent>) {
     }
 }
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;
 use std::any::{Any, TypeId};
@@ -387,7 +387,7 @@ fn assert_level_event_type(mut level_events: EventReader<LevelEvent>) {
 // 0.8
 let level_selection = LevelSelection::Iid("e5eb2d73-60bb-4779-8b33-38a63da8d1db".to_string());
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # fn f() {
 // 0.9
@@ -403,7 +403,7 @@ However, you can still construct a `LevelSelection` from a single level index us
 // 0.8
 let level_selection = LevelSelection::Index(2);
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # fn f() {
 // 0.9
@@ -418,7 +418,7 @@ This new method can accept any iterator of strings rather than just one:
 // 0.8
 let level_set = LevelSet::from_iid("e5eb2d73-60bb-4779-8b33-38a63da8d1db");
 ```
-```rust,no_run
+```rust,ignore
 # use bevy_ecs_ldtk::prelude::*;
 # fn f() {
 // 0.9

book/src/how-to-guides/migration-guides/migrate-from-0.9-to-0.10.md

@@ -17,7 +17,7 @@ struct PlayerBundle {
     grid_coords: GridCoords,
 }
 ```
-```rust,no_run
+```rust,ignore
 // 0.10
 # use bevy_ecs_ldtk::prelude::*;
 # use bevy::prelude::*;

book/src/how-to-guides/respawn-levels-and-worlds.md

@@ -51,7 +51,7 @@ There is a method on `LdtkProject` to perform this search.
 # use bevy::prelude::*;
 # use bevy_ecs_ldtk::prelude::*;
 {{ #include ../../../examples/collectathon/respawn.rs:13:17 }}
-    ldtk_projects: Query<&Handle<LdtkProject>>,
+    ldtk_projects: Query<&LdtkProjectHandle>,
     ldtk_project_assets: Res<Assets<LdtkProject>>,
 ) {
     if input.just_pressed(KeyCode::KeyL) {