Usage with bevy_asset_loader

[tedtramonte]

Does anyone have any insight into the best way to use bevy_ecs_ldtk and bevy_asset_loader together? I'm new to bevy, so excuse any ignorance.

My various bundles already have a SpriteSheetBundle in them which uses bevy_asset_loader to clone a handle for the texture_atlas from the Resources. I'm stumbling on how to use this same process when bevy_ecs_ldtk is handling the spawning of the entities. For that matter, drawing the tiles, as well.

Perhaps I'm misunderstanding how things work and how things have to be done in the real world, but it seems weird to me that Ldtk is loading textures and sprites in its editor that this crate can then use within bevy, while also needing a developer to load textures and sprites a more traditional way. It's definitely premature optimization on my part, but it doesn't seem right to be loading the same sprite sheets twice.

I searched a bit and found @jrasanen had a PR mentioning improving ergonomics with bevy_asset_loader (#90), so I know I'm not the first person to give this combination a shot.

Basically, what's the optimal way to load assets with bevy_asset_loader and applying those assets to levels assembled in Ldtk using bevy_ecs_ldtk?

[Trouv]

Sorry I didn't see this. I would eventually like to improve the ability to access the dependent assets loaded by the plugin.

There's some plans to make bevy_ecs_tilemap support the use of bevy TextureAtlases for a tilemap which I'll eventually take advantage of. So as it stands, the plugin doesn't actually generate TextureAtlases from the LDtk file for the tilemaps, it only loads their images into Assets<Image>. It DOES generate the TextureAtlases used for the #[sprite_sheet_bundle] attribute of the LdtkEntity derive macro though, but the plugin doesn't provide great access to these. Actually, the plugin could handle these better in general (#87).

That being said, is there some reason why you can't use #[sprite_sheet_bundle] on entities spawned by the plugin and let the plugin handle generating the texture atlas, instead of relying on bevy_asset_loader for this?

If you really do need to load it separately, one pattern I find myself using a lot is the "blueprint" pattern, where I give the entity a marker component of some sort using LdtkEntity registration, and then flesh it out further in an actual system that queries for Added<MyMarkerComponent> entities, that way you can access other resources in the world like your bevy_asset_loader asset collection.

I'm not 100% sure, but I don't think loading the same Image via bevy_ecs_ldtk and bevy_asset_loader would actually load the image twice if you're worried about that. I believe the bevy asset API caches based off the file path. TextureAtlases are another story, but like I mentioned earlier, we aren't actually generating TextureAtlases unless you're using #[sprite_sheet_bundle]