# Surprisingly, in SpriteKit game engine, “deltaTime” is not frame time?

In Apple's cocos-like 2D enginer, SpriteKit, they have what they call a custom field:

testField = SKFieldNode.customField{
(position: vector_float3, velocity: vector_float3,
mass: Float, charge: Float, deltaTime: TimeInterval) in

print("deltaTime \(deltaTime)")
return vector_float3(0,0,0)
}


the values printed out are simply the cumulative time, not the frame delta time!

Interestingly the documentation is ambiguous or just wrong:

https://developer.apple.com/documentation/spritekit/skfieldforceevaluator

1. notce there it uses the argument name "time", however

2. however, the documentation-writer wrote "time that has passed since the last time the simulation was executed" (ie, the usual frame time you'd expect), and

3. each Apple code fragment I've dug up uses "deltaTime" as the argument name, and the author treats it as a normal frame time like you'd expect in any game engine setting

I've tried it on as many devices/OS as at hand - has anyone found the definitive resolution of this? Is it really meant to be (fairly uselessly) time rather than deltaTime?

Question, Does anyone definitively know if the value returns cumulative time, or, delta time?

(If the former it would appear that the doco is completely wrong.)

Question, In the so-called "deltaTime" argument of Apple's spriteKit, what is returned?

• It's been my experience that anything Apple can get away with NOT doing, they don't do. There was a really weird defence of not using deltatime made for physics games on iOS around the time SpriteKit was introduced... here: learn-cocos2d.com/2013/10/… ... Since then, nobody has bothered using SpriteKit (for other reasons) and therefore Apple's never been queried on why they have a physics engine that mostly ignores deltaTime problems. Perhaps even worse, the SKRenderer seems wilfully & absolutely ignorant of the time since the last drawn frame. – Confused Nov 15 '17 at 16:10
• There are some distractions, but I eventually get to the point in the comments here: stackoverflow.com/questions/47299191/… – Confused Nov 15 '17 at 16:23
• hi @Confused, totally understand what you mean - that is GREAT information. the simple fact is, it looks like in fact yes, the documentation is simply wrong (ie, "utterly wrong" :) ) and indeed same for their code samples, which are normal game code (ie using delta time). Perhaps, you should put in an answer, it would help googlers .. – Fattie Nov 15 '17 at 16:57
• here's a link that might interest you: atastypixel.com/blog/experiments-with-precise-timing-in-ios – Confused Nov 15 '17 at 18:46

Your observations are accurate: the last parameter to SKFieldForceEvaluator is the total time elapsed since the simulation began. That doesn't mean "delta time is not frame time" across all of SpriteKit, just that the evaluator callback doesn't get a delta time value.

The documentation on Apple's website is wrong; it states that the last parameter is

The amount of time that has passed since the last time the simulation was executed

but the actual value provided to the block is definitely not a delta (the @param for the parameter in the header is "The current time step," which isn't any better).

But this is because SKFieldNodes can be sampled on-demand (via sampleFields: on a SKPhysicsWorld for example) potentially many times per frame, and they aren't meant to be the place where you implement the usual delta-time-based game logic. You should put that in SKScene's update:, which gives you the elapsed system time (which is also not a delta, but from which the delta can be trivially computed by storing a previous time in your scene subclass).

The time/deltaTime name discrepancy is just because the block parameters you make can be called anything; “bob” would be fine.

• "The documentation on Apple's website is wrong" Phew - thanks for that decisive answer, Josh! Good one. – Fattie Dec 6 '17 at 12:44
• (Just BTW I usually leave a bounty - in fact I think I left one here but it expired - I have low points presently so can't. Thanks again.) – Fattie Dec 6 '17 at 12:44
• @Fattie Yes, it expired. I intentionally waited for it to do so before posting. – Josh Dec 6 '17 at 14:59
• Here in Galt's Gulch, that is your right @joshpetrie :) – Fattie Dec 6 '17 at 15:05