SpriteKit : BLOCK MAIN THREAD

1

Normally one never wants to block the main thread, but I cannot figure how to manage multiple Spritekit animations.

example :

 if !abort {
            swap_tiles(tile1,tile2)  // execute players move
            abort = processBoard()
            if abort { swap_tiles(tile1,tile2) } // if not valid, restore tiles to original location
    }

swap_tiles performs an animation… works just fine… HOWEVER it has a duration of 0.5 seconds
the function processBoard() takes less than that… And it either returns TRUE rather quickly in the case of an “invalid move”, or may take another fraction of a second (where it then fires off MORE animations)

So in the case for example where abort returns TRUE. the 2nd swap tiles begins BEFORE the first one has completed… where it is false, there could be up to 50 animations in progress, and some of THOSE also need to complete before the next set fires.

If I could block the main thread until each animation completed, then the problem would be solved (note the block wold be <1 second I’m guessing)

Right now, all the animations run, but because the end up concurrent, the information some animations need isn’t there, because a previous animation is still in progress.

Using completion closures doesn’t seem to work, since there is a lot of logic between firing an animation, the logic decides what if any to fire, and what parameters are involed…

2

Isn’t there some kind of (a)wait / whenall() sort of metaphor or a way to check the completion status of the tasks processBoard() kicks off … or is that designed to be opaque to you as the client? Haven’t done sprite programming before, so that’s all I got.

3

there is async and await, which I tried to use, but it insisted that I add them to override functions that then failed because they didn’t match the class signature (these are UIKit classes like Touchbegan)

4

SwapTiles is an SKAnimation or some other animation? If the first, couldn’t you group and/or queue the necessary animations with an SKAnimationGroup and have its completion block trigger processBoard?

5

Sure and I’ve tried that…

The problem as stated is the processboard completes with either True or False in a split second.
As a result thus either triggering the 2nd Swap (with undoes the 1st one) or a cascade of up to 50 other animations. All of which start before any previous ones complete. The END result is correct, but visually it is chaos.

6

Yeah I agree blocking the main thread is ugly but … if you don’t have a way to get a callback when all the underlying animations are done – a way that WORKS – you may just be stuck with that. Like you, that would keep me up nights, though. It “feels” wrong.