Implement dynamic autotiling

[haath]

Hello!

With this PR I'd like to add support for dynamic auto-tiling.
And by that I mean that layers who are auto-tiled depending on another int grid layer, will now have their tiles automatically updated whenever the values of the corresponding IntGridCell are changed.

You can see this in action in the screencap below, which happens to be captured from the new autotile example that I've also added to this repo.

This is for now a draft PR and a request for feedback.

In particular, I would ideally like some maintainer to help me with the following questions.

1. Should this functionality always be available, or enabled via a cargo feature?
2. Should it be always on for all auto layers? Or perhaps controlled by some marker component (e.g EnableAutoLayer)? In the case of the latter, should the marker be added to all newly spawned auto layers by default, or should the user opt-in to this functionality?
3. The system I've added currently starts by looking up which layers are affected for each int grid layer, and this is done by querying up to find the project and get the information from the json metadata. Since this inter-layer dependency will not change since loading the project though, I propose to cache this information as a new field in LayerMetadata. Do you agree? Or even better in a new component, since this only concerns int grid layers.

The implementation itself is also a work in progress, after we settle on the above I'd like to do some refactoring and maybe also add some tests if it makes sense.

[haath]

Since the PR went a bit under the radar, I took some liberties with my previous questions to make it ready for the review.

The current design goes like this:

1. The dynamic autotiling behavior is enabled with a new component called EnableDynamicAutotiling which is added by default to all layers.
2. A new component on int grid layers called IntGridLayerAffectedLayers keeps the list of the other layer Entity ids which have some dependency on it for autotiling. It gets initialized for newly spawned layers by the new init_int_grid_affected_layers system.
3. A new component on int grid layers called IntGridLayerCellValues keeps a copy of the 2D array of current int grid cell values on the layer. This is used both to speed up lookups, and to avoid triggering changes unnecessary. This is updated by the new update_int_grid_layer_values system which watches for Changed<IntGridCell>.
4. The new system apply_int_grid_autotiling watches for Changed<IntGridLayerCellValues> and performs the autotiling on all affected layers accordingly.

I guess some further optimization can be achieved by storing the autotiling rules (which is a Vec<AutoLayerRuleGroup) on each autotiled layer. What do you think?

Also some cases are currently not handled, and they error-out here:

bevy_ecs_ldtk/src/systems.rs

Lines 368 to 374 in a566896

	debug_assert!(!rule.perlin_active);
	debug_assert!(!rule.flip_x);
	debug_assert!(!rule.flip_y);
	debug_assert_eq!(rule.checker, Checker::None);
	debug_assert!([1, 3, 5, 7, 9].contains(&rule.size));
	debug_assert!(!rule.tile_rects_ids.is_empty());
	debug_assert!(rule.tile_rects_ids.iter().all(|rect| rect.len() == 1));

[Trouv]

Sorry I never got to this, it's been a crazy year or two. This is some impressive work, I appreciate the effort.

The main issue for me to decide here is whether or not this is "in scope" for this plugin. Typically I've defined the scope as: assets for LDtk projects + spawning of LDtk levels w/ some hooks. This is more like a re-implementation of LDtk autotile rules, which I think is definitely within the bounds of "LDtk integration" but not really in the bounds of "spawning LDtk levels". So, this is scope creep, but it may be acceptable scope creep. I'd like to hear your thoughts on this too.

Should this functionality always be available, or enabled via a cargo feature?

Absolutely, I think this is heavy enough to warrant a separate feature flag.

My question to you is - how difficult would it be to make this a 3rd party crate? And more specifically, if there's some inelegance or annoyance in making it a 3rd party crate, what changes could we make to this plugin to support it better?

I guess some further optimization can be achieved by storing the autotiling rules (which is a Vec<AutoLayerRuleGroup) on each autotiled layer. What do you think?

I'd prefer to keep the code simpler and suboptimal for an initial implementation.