How do SKAction durations work in relation to frame rates? - ios

Question

I am trying to understand how SKActions work. Specifically with SKAction.runAction(), one of the parameters is a duration for the animation. However it seems that whatever I put in as the duration, the animation will render every frame. I have tried to put the SKAction.runAction() line in other places, but it seems to only work in the update() override method in SKScene. I have tried the SKAction.repeatActionForever, but this does not seem to be able to run parallel to other processes.
My question is, if there is a required parameter for the duration of the animation, where would one place the SKAction.runAction() method to have the animation run based on the given duration rather then on the frame rate?
This is my code:
GameScene.swift (The Player class is a subclass of the Character class. Refer to the code below.)
let player = Player()
class GameScene: SKScene {
override func didMoveToView(view: SKView) {
//Code here to recognize user inputs
scene?.addChild(player.sprite)
}
override func update(currentTime: CFTimeInterval) {
player.sprite.runAction(SKAction.runBlock(player.move))
}
}
CharachterClass.swift move() function
func move(){
switch(direction){
case "up":
sprite.position = CGPoint(x: sprite.position.x, y: sprite.position.y + speed)
case "down":
sprite.position = CGPoint(x: sprite.position.x, y: sprite.position.y - speed)
case "right":
sprite.position = CGPoint(x: sprite.position.x + speed, y: sprite.position.y)
case "left":
sprite.position = CGPoint(x: sprite.position.x - speed, y: sprite.position.y)
default:
break
}
SKAction.moveTo(sprite.position, duration: 1)
}
Note: the direction variable is the direction that the sprite is moving in and speed variable is the amount of pixels the sprite should move each time the SKAction is run.

Answer 1

I don't know what you intend to do with this:
override func update(currentTime: CFTimeInterval) {
player.sprite.runAction(SKAction.runBlock(player.move))
}
But in effect you can quite simply do the following instead:
override func update(currentTime: CFTimeInterval) {
player.move()
}
The difference between the two methods is that runAction will schedule the block execution and depending on when the scheduling occurs, it may not run in the current frame (update cycle) but in the next one. So quite possibly the run block solution introduces a 1-frame delay.
Next, this will run a move action for the duration of 1 second (not: 1 frame):
SKAction.moveTo(sprite.position, duration: 1)
Since you run this in every update method, you effectively null and void the SKAction's primary purpose: to run a task over a given time (duration).
Worse, you run a new move action every frame so over the duration of 1 second you may accumulate about 60 move actions that run simultaneously, with undefined behavior.
If you were to call runAction with the "key" parameter you could at least prevent the actions from stacking, but it would still be rather pointless because replacing an action every frame that is supposed to run over the time of 1 second means it will have little effect, if any.
Coincidentally, with the way the code is set up right now, you could as well just assign to position directly ... but ... wait, you already do that:
sprite.position = CGPoint(x: sprite.position.x - speed, y: sprite.position.y)
But immediately afterwards you run this move action:
SKAction.moveTo(sprite.position, duration: 1)
So all in all, you try to run an action over the course of 1 second that ends up being replaced every frame (60 times per second) - and that action does ... nothing. It will not do anything because you've already set the sprite to be at the position that you then pass into the move action as the desired target position. But the sprite is already at that position, leaving the action nothing to do. For one second - or perhaps it may quit early, that depends on SK implementation details we don't know about.
No matter how you look at it, this move action is over-engineered and has no effect. I suggest you (re-)read the actions article in the SK Programming Guide to better understand the timing and other action behaviors.