A fast, easy to use, free, and community supported 2D game engine
cjl
Member
I'm experiencing an intermittent problem with RotateTo.
I have a sprite that moves to and rotates to a touched point on its layer.
90% of the time it does the right thing, but occasionally it rotates the "long way", meaning it rotates towards the touched point more than 180 degrees.
It still rotates and moves to the correct point and direction, but I expected it would always rotate in the shorter direction.
Anyone else experience this?
cjl
Member
The third touch in the bottom right corner results in a rotation of more than 180 degrees:
| Get the Video Widget |
cjl
Member
Codemattic:
If you look closely, the final rotation is greater than 180 degrees.
I'm narrowing down the problem, which is probably in my own code:
float o = convertedPoint.x - [ladybug position].x;
float a = convertedPoint.y - [ladybug position].y;
float at = (float) CC_RADIANS_TO_DEGREES( atanf( o/a) );
if( a < 0 ) {
if( o < 0 )
at = 180 + abs(at);
else
at = 180 - abs(at);
}
NSLog(@"Ladybug angle: %f", [ladybug rotation]);
[ladybug runAction: [RotateTo actionWithDuration:0.3 angle: at]];So I'm using code that I swiped from the Cocos2d test app, and the 'rotation' that it logs is crazy. It often shows negative values, and values greater than 360. I'm sure this is causing the problem I am seeing. Shouldn't all rotation values be positive, and between 0 and 360?
I really need to review Trig. My 14 year old brain could have done this easily.
-cjl
Codemattic
Moderator
"Shouldn't all rotation values be positive, and between 0 and 360?"
according to:
http://www.mkssoftware.com/docs/man3/atan.3.asp
atanf() returns in the range [-Pi/2, +Pi/2]
You are logging [ladybug rotation] whereas to debug you probably should be logging the variables a and at (as well).
It's not clear from your code there even what you are trying to do. The whole if(o < 0) and taking abs(at) and all that. So printing out values might help you.
-- David
cjl
Member
OK -- I had time to dig a little deeper. I might or might not be a bug, depending on your expectations. My simple summary:
1) Start with an instance of a Sprite named sprite. Default rotation at initialization is 0.0.
2) Execute the following statement:
[sprite runAction: [RotateTo actionWithDuration:0.3 angle:270.0]];
3) After the action completes, log the sprite's rotation:
NSLog(@"sprite angle: %f", [sprite rotation]);
4) What would you expect the result to be? I would expect 270.0. I would be wrong. The actual result is -90.0.
5) This is because the RotateTo interval action rotates the sprite in the direction that results in the fewest degrees of rotation. In doing so, it can set negative rotation angles, and result in angles lesser than -360 and greater than 360.
6) This seems very counter-intuitive to me. I can see how you might want to RotateBy an angle greater than 360, but to me anyway, a sprite's rotation should always be between 0 and 360.
So, is this a bug? I guess I could just extend Cocos2d to always return a positive rotation, modulo 360.
Typically I consider any rotational value valid. And if I have helper functions that will normalize rotations into either 0..360 or -180 to 180.
When you are dealing with an object that moves in a given direction based on it's heading, it is helpful to think of rotation in the -180 to 180 space. This means that negative of a value is turning left (CCW) and a positive value is to the right (CW).
Other times it does make sense to think of things in 0..360. And even in the same application it makes sense to look at angles both ways.
Therefore I always normalize my angles into the space that makes sense for the operation I'm doing. In this sense, the behavior is not a bug but just one of several ways of expressing the same thing.
The reason you might consider it a bug is that you said 270 and got -90. Even though these are the same thing. But hell, even with floating point values, setting a value and getting it right back can given different results. :)
-- David
cjl
Member
nsxdavid:
Thank you for the detailed response, it helped me better understand the problem. I can certainly take responsibility for normalizing my rotation angles. Also, I can see how it isn't the frameworks responsiblity to do it for me, because this would constrain other to my expectation.
However, I am more convinced than ever that there is a bug or inconsistency in the RotateTo interval action.
The action is designed to rotate the target to the desired angle, in the direction that results in the least degrees of rotation. This doesn't happen, because, as you pointed out, a target's rotation is not normalized.
Let's consider the following sequence:
1) Sprite's rotation is 0
2) Tell sprite to RotateTo -90
3) Sprite rotates CCW. Sprite's rotation is now -90
4) Tell sprite to RotateTo 180
5) Sprite rotates CCW. Sprite's rotation is now -180
6) Tell sprite to RotateTo 90
7) Sprite rotates CCW. Sprite's rotation is now -270
8) Tell sprite to RotateTo 0
9) Sprite rotates CCW. Sprite's rotation is now -360
10) Tell sprite to RotateTo -90
11) Sprite rotates CCW. Sprite's rotation is now -450
12) Tell sprite to RotateTo 180
13) Sprite rotates CW, rotating 270 degrees. Sprite's rotation is now -180.
So, since RotateTo does not normalize the target's rotation, it eventually makes a mistake if you keep rotating in the same direction.
-cjl
cjl
Member
Patching the "start" implementation of RotateTo with the following worked:
-(void) start
{
[super start];
startAngle = [target rotation];
// My code starts here
if (startAngle > 0)
{
startAngle = fmodf(startAngle, 360.0);
}
else
{
startAngle = fmodf(startAngle, -360.0);
}
//My code ends here
angle -= startAngle;
if (angle > 180)
angle = -360 + angle;
if (angle < -180)
angle = 360 + angle;
}I'm sure there's a better way to do this.
-cjl
cbakker
Member
I did have an issue on the project i am working on where something would rotate when it was tapped. The rotation would start to get slightly off if you tapped really fast.
I think i had like 0.1 on the rotate but if the rotation was not finished the touch would start a new rotation on the object that would be slightly off and just get more out of wack.
What i did to fix the problem was lock the touches out until the rotate action was finished. Which seemed to fix the problem.
Not sure if this relates to your problem or not.
-- cbakker
cjl
Member
cbakker:
Thanks for the reply.
No, I think the problem I am experiencing has to do with rotations greater than 360 degrees. Basically, the algorithm that figures out which way to rotate the sprite doesn't work correctly if the target's rotation is greater then 360 or less than -360.
I"m going to check into it some more, then maybe I'll open an issue to see what Riq thinks.
-cjl
andyburke
Member
I am seeing this same issue (a sprite rotating more than 180 degrees when its rotation becomes sufficiently negative and a positive point is selected).
Has any decision been made on how this should be handled by cocos2d?
On a separate note: cjl, if you ended up getting your code to work, is there any chance you could share it? I'm interested in making something work just how you have with your ladybug.
andy
cjl
Member
The problem I was experiencing was fixed in a patch to trunk some time last fall. I don't remember which release had the fix, but it basically used the changes to RotateTo (now CCRotateTo) that I outlined above.
So, if you're experiencing a similar problem and you're using a newer release of Cocos2d, maybe my patch didn't handle all cases? Not sure.
As far as moving and rotating the ladybug to the touched location, the code is not too complicated. Fair warning, I am a really bad programmer, so check anything I write carefully. Also, I'm pretty sure I borrowed some of this code from elsewhere, and I can't remember where. Anyway, here it is:
- (BOOL)ccTouchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
UITouch *touch = [touches anyObject];
if( touch ) {
CGPoint location = [touch locationInView: [touch view]];
// The touches are always in "portrait" coordinates. You need to convert them to your current orientation
CGPoint convertedPoint = [[Director sharedDirector] convertCoordinate:location];
// First we stop the all running actions
[ladybug stopAllActions];
// Move at a constant speed to the touched locations
float speed = 200.0;
CGPoint startPosition = [ladybug position];
float newDuration = ccpDistance(startPosition, convertedPoint) / speed;
[ladybug runAction: [MoveTo actionWithDuration:newDuration position:convertedPoint]];
// Rotate to the touched location if distance is greater than 20 pixels
if ( ccpDistance(startPosition, convertedPoint) > 20.0)
{
float opposite = convertedPoint.x - [ladybug position].x;
float adjacent = convertedPoint.y - [ladybug position].y;
float at = (float) CC_RADIANS_TO_DEGREES( atanf( opposite/adjacent) );
if( adjacent < 0 ) {
if( opposite < 0 )
at = 180.0 + abs(at);
else
at = 180.0 - abs(at);
}
NSLog(@"Opposite: %f", opposite);
NSLog(@"Adjacent: %f", adjacent);
NSLog(@"Ladybug roation: %f", [ladybug rotation]);
NSLog(@"AT: %f", at);
[ladybug runAction:[RotateTo actionWithDuration:0.3 angle: at]];
}
// no other handlers will receive this event
return kEventHandled;
}
// we ignore the event. Other receivers will receive this event.
return kEventIgnored;
}Hope that makes sense. If not, feel free to post follow-up questions.
CJ -- great idea!
Wow... I am trying to implement it, but I am getting confuse... How to do it? Seems simply, but I am stucked on it...
You must log in to post.
