Digging a bit further into SpriteKit

A few throw-away prototypes later, and a few things about SpriteKit have become apparent to me.

First -- SpriteKit is highly optimized for image data.  That is -- sprites.  It is very efficient, put your images in a ".atlas" folder and a texture atlas is built reducing your costly draw calls from dozens (or hundreds depending on your app) to one.

Caveat, that is what SpriteKit does best.

As of writing, a text node will defer to core text   Core text will create a texture.  That will be slapped onto, what I guess is, an SKSpriteNode.  Each text element will incur an additional draw call (even if the text is duplicated - each duplicate will make a new texture.  Copying the SKTextNode results in a copy of the texture as well).  For a simple HUD, this is perfectly acceptable.  I dreamt of a text adventure recently, and SpriteKit would need a bitmap font rendered as SKSpriteNodes even though another framework would be just as good.

The other is drawing filled rects.  My best guess is that they are there as placeholders for an actual image-based sprite object.  They too don't batch that well together, which did surprise me.

How to track the draw calls?  Two ways.  One is to do a frame capture while the application is running on device.  The other, which I find more convenient, is to set the "showDrawCount" property of the "SKView" to true.  Turning on that property was an eye opener.

If we return to the colour-based SKSpriteNodes, be sure to give them a separate zPosition so they blend properly with the other nodes.  I have noticed that the drawing order differs when batching becomes possible.

Speaking of "zPosition"; it is safe to assume that each "zPosition" will result in an additional draw call.  The furthest are drawn first in one call, the nearer in subsequent call.  The mental model that I create for myself is that of creating a bin for each "zPositon" and dispatching each bin at the end.

Before making an image for each possible colour combination, tinting does not affect the number of draw calls.  If you were a stubborn person, you could make a white rectangle, create a sprite, and tint it to your heart's desire.

Notice that I have not delved into physics.  None of my little experiments needed (sophisticated) physics so far hence I can't comment on how that part of SpriteKit behaves.

Overall, I'm actually quite happy with SpriteKit.  The caveats I mention are minimal.  Implementing (or finding an implementation of) a bitmap font for SpriteKit is rather trivial with building the font being the time consuming part.  And as mentioned, coloured blocks can be simulated with flat textures.

And, in most real-world use-cases, I would guess that the caveats I mention are neglible.  For example, when will you display 100 SKLabelNodes?  Or do heavy pixelation with 10,000 SKSpriteNodes?