cocos2d/cocos2d-iphone — pull request #275 by rsanchezsaez (2012-12-17 15:26:52+00:00)
Title: Stackable CCMoveBy and CCMoteTo actions

I have rewritten the CCMoveBy and CCMoveTo actions so they are stackable.

### Description ###

This means that you can now run two simultaneous CCMoveBy/CCMoveTo actions on the same CCNode, and the node will perform a movement equal to the result of applying both movements at the same time.

### Uses ###

This allows for several cool effects. Some examples:
- Have a looping CCMoveBy action constantly running inside a CCRepeatForever action, and still be able to move the node around the screen with additional CCMoveBy actions (think, for example, of a balloon that has a looping floating animation and also moves around the screen).
- Having a character being affected by different move forces (think of a character affected by the wind and by the player controlled movement at the same time).

### Performance ###

I added CCMoveBy/CCMoveTo tests to the PerformanceTest-Sprite target. I ran tests comparing the new implementation to the previous one. The new implementation doesn't affect performance whatsoever.

You can compare performance of both sets of actions by checking out commit 3eceb6831f6151cfda1e2beb618e47fa3284145e (in this commit, my implementations are called CCMoveByEx and CCMoveToEx).

### Additional comments ###

#### Details ####

In order to make movement actions stackable, CCMoveBy must be the base action. The new implementation makes CCMoveBy the base action, and CCMoveTo a child of CCMoveBy. CCMoveTo just calculates a CCMoveBy based on the current node position. The old implementation was the other way around.

The new CCMoveBy implementation uses a new CCNode helper method called

- (void)moveBy:(CGPoint)positionDelta {
position_ = ccpAdd(position_, positionDelta);
isTransformDirty_ = isInverseDirty_ = YES;
}

which also allows for writing cleaner code regarding positioning of CCNodes that usually do relative (as opposed to absolute) movements.

#### Previous behaviour ####

The previous behaviour when executing two CCMoveBy actions at the same time was that only the latest executed action affected the sprite. This resulted in a somewhat awkward behaviour when, for example, there was a very long CCMoveBy action being run and you executed a new shorter CCMoveBy action without stopping the previous one first. In this case, the longer action would stop being applied while the new shorter one was running, but then it would weirdly resume after the new one finished.