About the Ccactionease in Cococs (middle)

Compared to the previous speed sine change action (what is this thing better?) Gradient animation? Cceasein/cceaseout/cceaseinout is more flexible with the speed-to-magnitude change action. You can set the rate of movement, or even change the rate during the movement. They have a common base class--cceaserateaction. Do not use cceaserateaction directly, because it does not achieve any change effect.

7) Cceasein

Follow the Convention to post the source code of the update function, lest the version update cause irrelevant.

1 void Cceasein::update (Cctime time)
2 {
3     m_pother->update (POWF (Time, m_frate));
4}

Based on the implementation of this function, the following three formulas are deduced:

S (t) =t^r t∈[0,1]
V (t) =s ' (t) =r*t^ (R-1) t∈[0,1]
A (t) =v ' (t) =r* (r-1) *t^ (r-2) t∈[0,1]

S: Distance V: Speed A: Acceleration T: Time r: Rate parameter M_frate
are very basic derivative derivation, if there is unclear place, it is recommended to review the lower derivatives.

Below we focus on the rate parameter, that is, the value range of R. Because it is the discussion of the binary function, the image is three-dimensional, drawing after overlapping together instead of understanding, there is no mapping.

1.r<0

When r<0, V (t) will always remain negative, meaning that the direction of the velocity is exactly the opposite of the set direction.
And because s (1) = 1, this means that the sprite finally moves to the target point coordinates, but it moves from the extension lines of the preset trajectory to the sitting punctuation.
This is a very strange action behavior, and we expected the design does not match, so R should not be less than 0.

2.r=0

When r=0, S (t) is equal to 1, it is said that the action before the beginning has reached the completion of the state. We are talking about the performance of the action, the original execution time of the action is not affected by this.
Obviously, this does not match our design, so 0 is not a value for R.

3.0<r<1

When the value range of R (0,1), a (t) constant is negative, the acceleration is negative to indicate that the speed is more and more slow, and the cceasexxxxin action should be slow to fast settings do not match, so this is not the value of R should be range.

4.r=1

When R=1, a (t) constant equals zero, V (t) constant equals one, which indicates that the action at this time is a speed of 1 uniform motion. This seems to be the same as the set of slow to fast also does not match.

5.1<r<2

When the value range of R is at (0), the acceleration A (t) is more or less, but it is a downward trend.

6.r=2

When the r=2 is, a (t) is equal to 2, that is, the Uniform acceleration movement at this time.

7.r>2

When r>2, the acceleration A (t) is more than 0, and it is on an upward trend.

In summary, when you use Cceasein, the incoming rate parameter should be greater than 1.0f, and depending on the range of values, there will be 3 of different acceleration movements.

8) Cceaseout

Let's take a look at the update function of Cceaseout.

1 void Cceaseout::update (Cctime time)
2 {
3     m_pother->update (POWF (Time, 1/m_frate));
6?

The first step is to deduce the formula for distance, speed and acceleration:

S (t) =t^ (1/R) t∈[0,1]
V (t) =s ' (t) =1/r* (t^ (1/r-1)) t∈[0,1]
A (t) =v ' (t) =1/r* (1/R-1) * (t^ (1/r-2)) t∈[0,1]

The second step is to analyze the value range of R:

1.r<0

When R<0, the cceaseout is the same as Cceasein, the motion is not on the preset trajectory, excluded.

2.r=0

The divisor cannot be zero, excluding.

3.0<r<1

When the value range of R is (0,1), a (t) constant is greater than 0, which indicates that the speed is getting faster, which is inconsistent with the cceasexxxxout from the fast to slow setting, excluding.

4.r=1

When R=1, a (t) constant equals zero, which indicates that it is uniform motion, does not conform to the set, exclude.

5.r>1

When r>1, the acceleration A (t) is less than 0, but an upward trend.

In summary, when you use Cceaseout, the incoming rate parameter should be greater than 1.0f, and Cceasein different is that cceaseout only a class of acceleration change trend.

We'll do some extra thinking before we go back to the study. Why is the value of R in Cceaseout different from that of Cceasein? Is there anything unreasonable in its design?

Let's say we set R to 3, and we also draw images of Cceasein and cceaseout:

Color is a bit messy, but there is no way, it contains 3 sets of comparative data, I directly say the color, I hope you don't get confused.

The red curve is the V (t) function of Cceasein, the fraction of which is the V (t) function of cceaseout.
We all know that the difference between cceasexxxxin and cceasexxxxout action is that the former from slow to fast, the latter from fast to slow. If they are more precise, their performance should be symmetrical-the velocity function V (t) is axisymmetric in line with x=0.5.
But it is obvious that the red curve and the pink curve are not symmetrical at all.

If you think about the previous sinusoidal and exponentially changing images, there is a symmetry here. That is, the image of the distance function s (t) should be symmetric according to the center of Point A (0.5,0.5).
The blue curve is the s (t) function of the Cceasein, which is the cceaseout s (t) function.
It is obvious that they are symmetric according to the y=x linear axis, rather than the center of Point A.

We take the red curve as an axisymmetric image of the x=0.5 line and get the black parabola. Then the parabola of the anti-missile function image, get the black curve. Look, it is symmetrical with that blue curve not according to point a center.
So, I think the update function of cceaseout should be modified. If you have a different opinion, please leave a comment in the comments section.

Attached to my revised code:

1 void Cceaseout::update (Cctime time)
2 {
3     m_pother->update (1.0F-POWF ((1.0f-time), m_frate));
6?

If I modify this way, then the rate parameter value range is the same as in Cceasein, more than one.

9) Cceaseinout

Well, continue our research:

1 void Cceaseinout::update (Cctime time)
2 {
3     int sign = 1;
4     int r = (int) m_frate;

6     if (r% 2 = = 0)
7     {
8 Sign         =-1;
9     }

One time     *= 2;
     if (Time < 1)
     {
         m_pother->update (0.5f * POWF (Time, m_frate));
     }
+     Else
+     {
         m_pother->update (sign * 0.5f * (POWF (time-2, m_frate) + sign * 2));
+     }
20}

It must be noted that the implementation of this function is problematic.

First, does the engine designer just want us to pass the rate of the integer type?
The problem is on the POWF function call.
We know that the passed-in time parameter range is in [0,1], even if the middle does a multiply 2 operation, to the back of the time-2 is still less than or equal to zero. So in some cases, POWF can be problematic.
For example, when M_frate is set to a decimal such as 3.5f, the POWF returns " -1. #IND000".
Then, when the action is executed into the second half, the genie disappears until the action is complete and the genie appears at the end point.

Second, is that sign positive and negative symbol used to solve the problem? How it feels to be introduced complicates the problem.
In fact, the first half of the function is just a point (0.5,0.5) to do a midpoint symmetry can be, need not be so troublesome.
The code I modified is as follows:

1 void Cceaseinout::update (Cctime time)
2 {
3 time     *= 2;
4     if (Time < 1)
5     {
6         m_pother->update (0.5f * POWF (Time, m_frate));
7     }
8     Else
9     {
Ten         M_pother->update (0.5f * (2.0F-POWF (2.0f-time), m_frate));
One     }
12}

Because Cceaseinout and Cceasein use the same algorithm, the value range of the rate parameter here is the same as that of Cceasein, which is more than one.

Summary

So far, we have finished half of the study on Ccactionease.

We have studied 3 classes and 9 movements altogether. They were Cceasesinein, Cceasesineout, Cceasesineinout, Cceaseexponentialin, Cceaseexponentialout, Cceaseexponentialinout, Cceasein, Cceaseout, Cceaseinout.

The biggest difference between them and the actions that will be learned is that during the execution of these actions, the genie will move strictly according to the path specified in the internal action, never exceeding the range of the starting and ending points.

In Cceasein/cceaseout/cceaseinout, the range of speed changes is [0,m_frate],m_frate>1.

However, if the cocos2d-x needs to be in accordance with cocos2d-iphone in principle, even if there is a flaw can not undermine the principle, then I speculate that the official in a short period of time will not modify the problem. Because, about 6 months ago, some friends had asked this question, but seemed to be ignored.
http://www.cocos2d-iphone.org/forum/topic/20979
http://code.google.com/p/cocos2d-iphone/issues/detail?id=1248

So before officially fixing this issue, I recommend that you only use integers greater than 1 as the rate parameter to improve compatibility.

About the Ccactionease in Cococs (middle)