Cocos2d development and learning 3: Introduction to node actions

I. Action Actions
From the previous article, we can see that in the menu scenario, the menu layer is loaded with a sliding action effect.
[Cpp]
// Action 1
Id ac = [CCMoveTo actionWithDuration: 2 position: CGPointMake (winSize. width/2, winSize. height/2)];
CCRepeat * repe = [CCRepeat actionWithAction: ac times: 4];
// Action 2
Id bc = [CCCallFunc actionWithTarget: self selector: @ selector (test)];
CCSequence * seq = [CCSequence actions: repe, bc, nil];

[Menu runAction: seq];

The above is just a simple example. We use the cocos2d ccAction class to implement some actions of node elements.
Such as moving and rotating.
As we know, scene, layer, and sprite in cocos2d all implement the CCNode base class,
That is to say, the application scope of action is not as narrow as that of Sprites.
In layer, scene can be used in all aspects. Of course, most of them are used in genie.
For example, we control the movements and jumps of the character genie.

In a broad sense, cocos2D divides an action into "instant action" and "delayed action ".
Real-time actions are more like setting object attributes.
The delayed action is the one we use above.
All the movements of objects belong to this category.

Delayed action:
1. Common delayed actions: CCMoveTo moves to and CCJumpTo jumps to. Different parameters are accepted for the methods,
However, we must at least accept the delay parameters.
2. Soothing action CCEaseAction,
To put it bluntly, we simply put actions in a step-by-step buffer,
Visually more aesthetic.
Most of the time, this type of application is actually a decoration for the basic delayed action above.
[Java]
<Strong> CCAction * c = [CCMoveTo actionWithDuration: 5 position: ccp (240,160)];

CCEaseInOut * ci = [CCEaseInOut actionWithAction: c rate: 5];
[Self runAction: ci];
</Strong>

As shown in the above code, I Have A Moving action, which is then decorated as a speed gradient at the start and end of the movement.
Common soothing classes
1. CCEaseBackIn, CCEaseBackInOut, CCEaseBackOut2. CCEaseBounceIn, CCEaseBounceInOut, CCEaseBounceOut
3. CCEaseElasticIn, CCEaseElasticInOut, CCEaseElasticOut
4. CCEaseExponentialIn, CCEaseExponentialInOut, CCEaseExponentialOut
5. CCEaseIn, CCEaseInOut, CCEaseOut
6. CCEaseSineIn, CCEaseSineInOut, CCEaseSineOut

Repeated action:
Repeated actions are literally understandable.
However, it has limitations. For example, the following code
[Cpp]
CCAction * c = [CCMoveTo actionWithDuration: 3 position: ccp (20,100)];

CCEaseInOut * ci = [CCEaseInOut actionWithAction: c rate: 5];

CCRepeat * re = [CCRepeat actionWithAction: ci times: 2];
[Self runAction: re];

There is no repeated effect, rather than thinking that classes in Android seem to have an action effect like ours.
The action is only executed once.
I guess that later
Repeated actions can be regarded as an Action sequence (as mentioned below). Repeated N times add N such actions. Www.2cto.com
But why can't we see that the mobile action is executed only once.
In fact, this is our own wrong thinking,
In our thinking, we thought that this moveto action was repeated for two times. After the first movement, we saw that this object suddenly appeared at the original start point and then moved again.
But in fact, in the moveTo function, we pass a postion, that is, the position p to move to the screen. The second point is the repetition, because the starting position of the movement is the left p to move.
So it does not seem to change (well, the above is just your own self-Explanation ~)
However, you can use CCMoveBy because the input parameter is an offset value.
However, in some online materials, we say:
Note that actionBy cannot be used repeatedly. If it is used for the second time, it will continue from the position where it was used for the first time. If you do not understand it, try it. The phenomenon is obvious!
So what are their limitations? Of course, api is just a concept.
[Cpp]
CCRotateBy * rotateBy = [CCRotateBy actionWithDuration: 2 angle: 360];
CCRepeatForever * repeat = [CCRepeatForever actionWithAction: rotateBy];
[MyNode runAction: repeat];

This is a column provided on the materials.

Action sequence
CCSequence * seq = [CCSequence actions: repe, bc, nil];
[Menu runAction: seq];
As the name suggests, one action is followed by one action.
It also inherits the action class.
Continuous actions. By the way, the above actions are taken instantly.
As we said, real-time actions are more like always attribute settings. But why does cocos2d introduce the concept of instant action.
In fact, in order to cooperate with the action sequence, we feel that this design logic benefits.
For example, an object first moves to p, then suddenly disappears (hide), then moves to q, and then suddenly appears.
From this description, we can design it like this: first, A delay action A, and then suddenly disappear. Then, set the attribute (object. hide), then perform B in the delayed motion, and then set the property show.
Well, here we will find A problem. If it is designed by the above-mentioned thinking, A callback may be required to execute the attribute after the action is completed. Someone also said, attribute settings are also treated as an action,
Put it in the queue. Then the problem arises here. In what form can I put this attribute setting action in? Real-time actions are actually such a unified design that allows sequences to look.
For instant actions, the document also said: You may wonder why there are instant actions based on CCInstantAction. can you achieve the same goal by changing the node attributes? For example, the locations used to flip nodes and place nodes, and the instant actions used to switch node visibility attributes.
However, through the above delayed action, there will be a habit of doing android. After the first action is executed, I will do some additional operations before the second one, then it seems that there is no such conceptual mechanism as listening in android.
When you look at the call format of the most common CCCallFunc action in real-time actions, you will find that it is not exactly a callback.
The Android callback is generally executed in the finish method of the previous action, but for ios, because it is placed in the sequence,
Then an action is executed to execute the next action. This action is a custom operation function.
Rather than actually, an action is called when an object moves. The action queue is simply an operation queue.
Therefore, the role of real-time actions is self-evident. Using these actions in a sequence can make the actions more flexible.

[Cpp]
CCCallFunc * func = [CCCallFunc actionWithTarget: self selector: @ selector (onCallFunc)]; CCCallFuncN * funcN = [CCCallFuncN actionWithTarget: self selector: @ selector (onCallFuncN :)];
CCCallFuncND * funcND = [CCCallFuncND actionWithTarget: self selector: @ selector (onCallFuncND: data :) data :( void *) self];
CCSequence * seq = [CCSequence actions: tint1, func, tint2, funcN, tint3, funcND, nil]; [label runAction: seq];

Synchronization operation
CCSpawn, there is nothing to say about it. I believe that we all know how to make some animation effects, such as the color gradient of one side of a circle, and the side grows from small to small.
You only need to understand that the final completion time of synchronization execution is determined by the time spent in the basic action.

Author: Nono_Love_Lilith