Restructure Animation Component/System

[paked]

In the ECS paradigm components are designed to only store data, systems are supposed to manipulate this data. The current animation implementation has logic spread between the component and its related system.

[matiwinnetou]

Ok, having spend even more time with animation.go I can see what you were trying to achieve there.

The main issue is with increment() method which obviously processes data.

However, I am slowly coming to some conclusions how I would like this to look like:

For me

1. We should delete an actual Sprite type (legacy like you said)
2. We should seriously consider renaming Region to Sprite as Region is form of a sprite. I am also fine to keep this Region if this is more natural for you. I am torn myself, as plain texture is also a kinda sprite.
3. We should provide Render method for Region (Sprite) and in future Draw if the code base is refactored to use Draw everywhere. I already have it working locally - but without camera
4. AnimationComponent apart from data it has (with some tweaks) should take as part of construction process - simply an array of Regions. Array is already indexed. Later through methods or constructors we can pick which indexes are part of which frames. This gives us enormous flexibility, Spriteheet is today a very specific and concrete implementation. I can imagine other implementation based on some ripped sprite sheets from the internet, which do not conform to the contract (like Hero.png example). Since AnimationComponent does not have to know much about actual concrete Spritesheet type and implementation (which assumes too many things) we can simply provide other implementations of Sprite collections, like Spritemap.

To understand me better you can have a look at spritesheet I found on the internet:
http://www.spriters-resource.com/game_boy_advance/namcomuseum/sheet/22731/

This one is far from predictable patterns despite what it seems and Spritesheet freaks out on this even with my Region various Region tweaks. With such a spritemap the only option may be to manually define Region and then form a number of array Region from them that can be animated.

Thoughts?

PS.
I miss what is this dt, which is passed in update method and also what u,v mean in Region. Help appreciated.

[paked]

@matiwinnetou IMO Region != Sprite. A Region represents part of a Texture.

Yes. Regions should be Renderable, so we can stop this kind of situation.

[paked]

Sure. Structure the AnimationComponent however you want. As long as no logic is performed on it. Logic should be performed on the AnimationSystem.

[paked]

dt is delta time, the change in time since the last frame was rendered... Useful for computing movement and stuff :)

[matiwinnetou]

Close please.