Cumulative transformations

[DaanVanYperen]

see https://github.com/junkdog/artemis-odb/issues/76

[Namek]

what I did:

public class Position extends PooledComponent {
    public final Vector2 current = new Vector2();
    public final Vector2 desired = new Vector2();
    public final Vector2 graphicalOffset = new Vector2();
}

1. desired is being set idiotically by PositionSystem (based on Velocity component). When my custom-game PlayerCollisionSystem decides that desired is ok, then it pushes desired into the current. Otherwise the system tries to correct the value and then push into current.
2. current is the position for final usage, like render and so on - it's always proper position (player doesn't stand on wall or sth).
3. graphicalOffset is being set by some shakes etc. It's always called by my RenderableSystem.

That way I always have correct logic positions and I can do final graphical transformations (bullet 3.) like shaking, without changing logic position.

[DaanVanYperen]

Thanks for your insight!

It seems hard to design something reusable that doesn't end up a bit messy somewhere. This ticket will probably hit tweening and networking as well.

I've used a push/pop or save/restore method before, where temporary transformations are rolled back after rendering. Or using entity hierarchy, absolute position as an invisible entity, and the sprite is shaken in relation to it.

[Namek]

Well, networking kills everything. Game needs to be fuzzy so rules are strengthened for game mechanics design. I'm talking about shooters or car games which is my main area of interest in programming right now.

[DaanVanYperen]

Low value, out of scope.