0

Given one texture sheet is it better to have one or multiple CCSpriteBatchNodes? Or does this not affect at all the GPU computational cost in processing the non visible CCSprite quads?

I am thinking about performance and referring to this question and answer I got. Basically it suggests that I should use more than one CCSpriteBatchNode even if I have only one file. I don't understand if the sentence "Too many batched sprites still affects performance negatively even if they are not visible or outside the screen" is applicable also having two CCSpriteBatchNode instead of one. In other words, does the sentence refer to this "The GPU is responsible for cancelling draws of quads that are not visible due to being entirely outside the screen. It still needs to process those quads."? And if so it should meant that it doesn't really matter how may CCSpriteBatchNode instances I have using the same texture sheet, right?

How can I optimize this? I mean, how can I avoid the GPU having to process the non visible quads?

Would you be able to answer to at least the questions in bold?

Community
  • 1
  • 1
mm24
  • 9,280
  • 12
  • 75
  • 170

3 Answers3

2

First case: Too many nodes (or sprites) in the scene and many of them are out of screen/visible area. In this case for each sprite, GPU has to check if its outside the visible area or not. Too many sprite-nodes means too much load on GPU.

Adding more CCSpriteBatchNode should not effect the performance. Because the sprite-sheet bitmap is loaded to the GPU memory, and an array of coordinates is kept by the application for drawing individual sprites. So if you put 2 images in 2 different CCSpriteBatchNodes or 2 images in 1, it will be same for both CPU and GPU.

How to optimize? The best way would be to remove the invisible nodes/sprites from the parent. But it depends on your application.

user739711
  • 1,842
  • 1
  • 25
  • 30
  • I was advised not to remove any sprites from CCSpriteBatchNode at runtime as it will affect performance. I am developing a shooter game where enemies (Sprites) spawn at all times. – mm24 Sep 24 '12 at 12:35
  • 1
    But if they are accumulating its better to remove them from parent. You can remove them time to time (when you think too many of them have accumulated) – user739711 Sep 24 '12 at 12:41
  • That's a fair point. I hadn't considered removing them every so often. I could do it in the deadmoments of the level (when not many sprites are in the screen). Good idea :), thanks! – mm24 Sep 24 '12 at 12:43
  • Btw, I haven't figured out what the visible property is for. I mean, I was told that it is not used by CCSpriteBatchNode to compute the visibility. But when is it used then? Because if I add a sprite to a batch node and set the visible property to false it does not display and hence I thought it would affect the CCSpriteBatchNode computation – mm24 Sep 24 '12 at 12:45
  • 1
    I am not sure about the visible property. I have to look into cocos2d code. I will check and let you know. – user739711 Sep 24 '12 at 13:09
  • What I will experiment is this: I will create multiple sprite batch nodes (e.g. start, middle of level, end of level) with all needed Sprites. I will then add as child to the game scene only the first batch node and when the time counter reaches mid level I will remove the first batch ndoe and add the second one. And so on. In this way I should have already pre-loaded them in memory with all the sprites I need and I don't expect to have lags but only performance improvements due the the fact that the sprite positions are done only on batchnodes that are added to the scene, correct? – mm24 Sep 24 '12 at 13:40
  • can you show me little of your code? Where are you loading the batchnode and where are u using them? – user739711 Sep 24 '12 at 13:58
1

FPS drops certainly because of two reasons:

  • fillrate - when a lot of sprites overlap each others (and additionally if we render high-res texture into small sprite)
  • redundant state changes - in this case the heaviest are shader and texture switches

You can render sprites outside of screen in single batch and this doesn't drop performance singnificantly. Pay attention that rendering sprite with zero opacity (or transparent texture) takes the same time as non-transparent sprite.

brigadir
  • 6,874
  • 6
  • 46
  • 81
  • thanks! And what about the number of CCSpriteBatchNode instances sharing the same texture sheet? – mm24 Sep 24 '12 at 11:41
  • PS: also, if various sprites overlap each other and are invisible (self.visible=TRUE) will the fillrate be still affected? – mm24 Sep 24 '12 at 11:43
  • If you set `visible` to `NO` the quad size of the sprite is set to zero and it doesn't affect fillrate. This solution is better than exclude sprite quad from batch because in that case we should rebuild vertices array. – brigadir Sep 26 '12 at 06:38
0

First of all, this really sounds like a case of premature optimization. Do a test with the number of sprites you expect to be on screen, and some added, others removed. Do you get 60 fps on the oldest supported device? If yes, good, no need to optimize. If no, tweak the code design to see what actually makes a difference.

 I mean, how can I avoid the GPU having to process the non visible quads?

You can't, unless you're going to rewrite how cocos2d handles drawing of sprites/batched sprites.

it doesn't really matter how may CCSpriteBatchNode instances I have using the same texture sheet, right?

Each additional sprite batch node adds a draw call. Given how many sprites they can batch into a single draw call, the benefit far outweighs the drawbacks. Whether you have one, two or three sprite batch nodes makes absolutely no difference.

CodeSmile
  • 64,284
  • 20
  • 132
  • 217