Render nodes in single drawing pass with spritekit?
Asked Answered
P

1

7

As I was looking around for information about spritekit textures, and I stumbled upon this quote:

If all of the children of a node use the same blend mode and texture atlas, then Sprite Kit can usually draw these sprites in a single drawing pass. On the other hand, if the children are organized so that the drawing mode changes for each new sprite, then Sprite Kit might perform as one drawing pass per sprite, which is quite inefficient.

But check this out:

Tiles with same texture (I assure you it's a texture, not just a color) Untextured tiles

Tiles with their own texture Textured tiles

The draw count has a difference of 40, although all of the textures used came from the same atlas.

Am I interpreting the word 'atlas' wrong?

This is where I store my images:

texture atlas

Is my example a 'texture atlas,' or is the definition of 'atlas' here a single .png that contains all the images needed, and individual tiles are sliced from it?

Or is the problem probably in how I am loading/something else?

Thanks!

Poisonous answered 4/4, 2014 at 1:35 Comment(0)
C
7

The problem here is most likely because of the node graph itself. Say you have 100 sprites as children of the scene, with not sub-children of their own, and they all use textures from the same atlas and default blend modes, then Sprite Kit will batch-draw these 100 sprites in a single draw call.

However if these tile sprites have children of their own, perhaps shape or label nodes for debugging, then this will "interrupt" the batch drawing operation.

Check your node graph. Make sure all tile sprites are children of the same parent, and have no children of their own, use the same blend modes and textures from the same atlas. Then batch drawing will definitely work.

If that doesn't work, verify that the tiles.atlas folder is correctly converted to a texture atlas in the bundle. If you open the compiled app bundle you should find a folder named 'tiles.atlasc' with a plist and one or more png files in it, containing all individual images of the folder. Furthermore none of these individual images should appear in the bundle - if they are added to the bundle as individual files using the same names as in the atlas, then Sprite Kit will default to loading the individual image files rather than obtaining them from the texture atlas.

Corsetti answered 4/4, 2014 at 8:3 Comment(6)
Hm, this still isn't working. The sprite nodes are children of node, not of the scene, is this the issue? None of them have children. EDIT: I AM AN IDIOT. One of my tile types was referring to an image in the images folder... And that one tile was screwing it up. It happened to be my solid ground tile...Poisonous
Um... help me out with one more thing. Loading textures this way seems incredibly inefficient. Initializing sprites takes a lot longer for me now, because the tile map needs to be constantly cycled through and being generated as it goes on. What's the fastest way to initialize such a sprite?Poisonous
well, if you run the ..imageNamed: method a lot (both for sprite and texture/textureatlas) that may potentially create a lot of overhead. For my tilemap i keep both the atlas in a strong ref, and the textures in an array (indexed by GID) for quick access. Have a look at the tilemap renderer in kobold kit.Corsetti
Thanks! That system is performing the best out of all of them. You're an enormous help.Poisonous
@LearnCocos2D I have a question, if i keep blendFactor of all my nodes to any specific number , 1.00, will it still affect batch drawing?Rik
I don't know but it's easy to find out. Add like 10 sprites or so to an empty project and note the draw call number (say it's 1). Then change some in-between sprite's (say, the 5th) blendFactor to 0.5 and check if draw calls changed. If it affects batching, you should have 3 draw calls for the set of sprites (first half, sprite with different blend factor, second half). You can enable draw call, fps, etc labels via SKView, though some of them are private vars but I believe draw call is in the public debug drawing properties.Corsetti

© 2022 - 2024 — McMap. All rights reserved.