Update: Comparing Sprite Kit Physics and Direct Box2D Simulation Times

In a previous post I compared Sprite Kit physics to using Box2D directly. In that comparison I used frames per second as measured by Instruments, but it is useful to look at straight simulation time (ignoring rendering time), which I present here.

The code used to time the physics simulation in Sprite Kit is given here:

-(void)didEvaluateActions {
    physicsStartTime = [NSDate timeIntervalSinceReferenceDate];
    if (sampleStartTime == 0) {
        sampleStartTime = physicsStartTime;
    }
}

-(void)didSimulatePhysics {
    physicsEndTime = [NSDate timeIntervalSinceReferenceDate];
    frameCount++;

    simulationTime += (physicsEndTime - physicsStartTime);
    if (physicsEndTime - sampleStartTime > 1.0 - EPSILON) {
        NSLog(@"Average simulation time = %f", (simualtionTime / (double)frameCount));
        simulationTime = 0;
        sampleStartTime = 0;
        frameCount = 0;
    }

}

These are methods of SKScene and part of the Sprite Kit event loop. didEvaluateActions is called just before

and didSimulatePhysics is called just after the physics simulation. physicsStartTime, etc., are member variables on my SKScene implementation, and are intialized to zero at startup.

Again, the project used for these tests is available as a GitHub project. The tests were conducted on an iPhone 5, iOS 7.0.4. The project was built in Xcode 5 with the -Os optimization level (Fastest, Smallest). The Box2D version used for the simulations is version 2.2.1.

The only difference in these results from the previous post is that these provide physics simulation times (in milliseconds) directly instead of frames per second, which incorporates rendering time as well. The average simulation time is computed and output approximately once per second. This breaks down when the time for simulating one frame takes more than one second, but at that point the simulations are too slow to be useful in a game anyway.

The two tests shown here are the same as those shown in the previous post, namely, elastic and inelastic collisions involving small boxes. These tests were conducted using 50, 100, 150, 200, 250, 300, 350, and 400 boxes. The results are summarized in the following sections.

Test 1 – Elastic Collisions

This test involved boxes bouncing off the sides of the screen and each other. The collisions were elastic, meaning the colliding boxes don’t lose energy and thus never stop. See the previous post for screenshots and a better description.

The tow tables summarize the average simulation times for the first 16 seconds of each test run. Each row represents the samples at a given time in the test for all the test runs (50 boxes, 100 boxes, etc.).

The first table shows the results for the direct Box2D simulations.

The simulation times look very good until at least 200 boxes, and for the most part look good up until 300 boxes.

The second table represents the test runs done using Sprite Kit physics.

The first thing to notice here is that the simulation times are about twice that of the direct Box2D implementation. The Sprite Kit physics simulations also tend to get unusable around 250 boxes.

Test 2 – Inelastic Collisions

This test involves inelastic collision (collisions where colliding objects lose energy and slow down after collisions). Of particular interest here is how the various APIs handle sleeping, which is when an object has slowed down enough that it is considered at rest, and no longer needs to be simulated (until something else collides with it). This can have a big impact on performance.

Here are the simulation times for the direct Box2D implementation:

The performance is similar to that of the previous test (elastic collisions), but we see as the simulation progresses (and the falling boxes stack up), the simulation times decrease as most of the boxes go into sleeping mode.

Here are the simulation times for Sprite Kit physics

The simulation times are already high by 150 boxes, and certainly unacceptable by 200 boxes. Again, the times are typically at least twice as long as those of the direct Box2D implementation. Another thing to notice is that the simulation time does not seem to benefit from sleeping boxes.

Conclusion

The data presented here makes it clearer that Sprite Kit physics does not perform as well as a direct implementation of Box2D. There may be many reasons for this (setting up collision handlers that aren’t being used, perhaps), but at face value it does not look good. Of particular concern is the seeming lack of response to sleeping objects. This coupled with the repeatabilty problems discussed in the previous post confirm my earlier conclusion that Sprite Kit physics is not quite ready for production use.