runAction is too fast

Hi All,

I’m struggling with a runAction in tweaked version of the HelloHTML5World sample. I added my own class TileSprite, and I want to move a TileSprite instance for several seconds using runAction, but the sprite moves suddenly. Any guesses as to what I’m doing wrong? Calling runAction on an instance of the CircleSprite class, which came with the sample, works fine.

Thanks,
Roy

var TileSprite = cc.Sprite.extend({
*path:“”,
ctor:function {
this.*super();
cc.associateWithNative( this, cc.Sprite );
},
createWithPath:function (path) {
this.*path = path;
this.initWithFile;
},
getPath:function {
return this.*path;
}
});

// runAction on TileSprite class. Takes way less than 5 seconds. Sprite zips right to 200, 0
var mySprite = new TileSprite();
mySprite.createWithPath(“res/graphic.png”);

var action = cc.MoveTo.create(5, new cc.Point(200.,0.));
mySprite.runAction(action);

// runAction on CircleSprite class. works. Sprite takes 5 seconds to get to 200, 0
this.circle.runAction(action);

I’ve narrowed down the problem. I do a position lookup which returns a cc.p, and it causes some problem downstream with the runAction:
return cc.p(something.x, something.y);

If I change the return to this (dividing x & y by 1.0), then runAction works correctly. What is up with that?
return cc.p(something.x/1., something.y/1.);

Here is the method….
lookupCoordinates : function ( a, i , j ) {
//return cc.p(a[i][j].x, a[i][j].y); DOES NOT WORK
return cc.p(a[i][j].x/1., a[i][j].y/1.);
},

typeof() indicated that the arguments to cc.p were strings. You can see the behavior with code similar to this…

@
var strX = new String(x);
var strY = new String(y);

// Position on canvas will be correct with string arguments in cc.p,
// but it causes problems later with sprite.runAction
sprite.setPosition( cc.p(strX,strY) );

// …
// Do other stuff
// …

// Duration of 5 seconds has no effect. Sprite moves to 200,0 in less than 1 second.
var action = cc.MoveTo.create(5, new cc.Point(200.,0.));
sprite.runAction(action);
@

Was this resolved by passing integers to cc.p? or is there still an issue here?

This was resolved by passing integers to cc.p. :wink: