Perfomance - sprites' visibility « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Perfomance - sprites' visibility

(40 posts) (9 voices)

Started 1 year ago by Achmes
Latest reply from Achmes

Tags:

12 Next »

Achmes
Member
Hey

I'm rendering 3200 sprites (alle aded to 3-4 CCSpriteSheets)in my game - the whole map.
But of course there are only few sprites on the screen (about 100)

The most optimistic result on my iPhone 3G is 30 FPS but it often goes to 25.

I thought that it's quite strange that my 2D platform game has more FPS than other 3D games on iPhone....So I must do sth wrong.

I guess I shouldn't render sprites which are not visible on the screen....
So that is what I did:
```
for(int i=0; i<number_of_sprites; i++)
	if(
	   obiekty[i].obiekt.y[0] >= yyy ||
	   obiekty[i].obiekt.y[0] <= yyy-200 ||
	   obiekty[i].obiekt.x[1] >= xxxx+400 ||
	   obiekty[i].obiekt.x[1] <= xxxx-400)
	{
		if(obiekty[i].texture.visible == YES)
		      obiekty[i].texture.visible = NO;
	}
	else
	{
		if(obiekty[i].texture.visible == NO)
		    obiekty[i].texture.visible = YES;
	}
```
But this operation made my game slower rather than boost it.
Now the highest value is 20-25 FPS

Why it's so slooow.....?

//By the way - Could you tell me what's your efficiency while rendering about 3k sprites? I don't really know how many FPS is a good result on the mobile phone
Posted 1 year ago #
araker
Moderator

What you're doing is very brute force. You could optimize your code by creating a spatial hash (dividing your world in smaller cells and keeping track to which cell a sprite belongs) and check only the visibility of the sprites in the cells that are currently visible. That way you only need to change a couple of hundred sprites at a time. If you're planning on using a physics engine, chipmunk has this already built in and box2d uses a similar method.

Posted 1 year ago #
Achmes
Member

Hey.
Hm.... Which part of code is brute force.

You mean that checkinfg about 3k objects if they are out of screen is waste of perfomance (so the if statement) or maybe changing texture visiblity to YES/NO.

I'm not sure but I think that simply math calculation (if statement) isn't so harmful.....

Posted 1 year ago #
araker
Moderator

Isn't the result you're seeing enough evidence? When this is the only piece of code you've changed and then your performance drops, where would the problem be?

If you don't believe me, use the time profiler instrument to see where the bottleneck in your code is.

Iterating over 3k elements is brute force, all those checks add up when they need to be performed that often. Changing the visibility by the way involves more than just setting a simple bool, it also updates the quad in the textureAtlas and it sets the dirty bool, which causes updateTransform to be called for itself and all its parents.

Posted 1 year ago #
Stepan Generalov
Moderator

I solved the same problem in iTraceur with more than 3K sprites. On iPhone 2G i get 60fps on cocos2d-0.7.3
I use only one static background image with size from 512x512 to 1024x1024.

Common level is 16000x2500 with 3K or more sprites in it. Sprites rendered through AtlasSpriteManager (CCSpriteBatchNode) with a little trick.
1 atlas = 1 atlasSpriteManager, but i created atlases for level sectors dividing level by 16 in width and 2 in height. Also i added additional property for spriteManager - activeRect (like boundingBox but static - set once and for all)

Keypoint is to visit only visible spriteManagers. Main level node calculates screenRect in node's coords once for self visit and visits only that children, which have their activeRect intersected with screenRect.

Also i optimized a little spriteManager's visit, mostly copypasting different atlasSprite updates right in visit to reduce object messages.
If you need an example - feel free to ask, i think i can find it for you.

P.S.
But i think that using 3K+ sprites isn't a good thing at all. In iTraceur HD i use 256x256 tiles from one big divided image. I found it a lot easiear to create a level as one image, not as parts or objects.

By the way, code that runs on 60fps with 3K sprites on iPhone2G is running on iPad 3.2 with 24-30fps, so... ;)

Posted 1 year ago #
Achmes
Member

Hey.
Thanks a lot for your answers and sorry I didn't reply but I've just success to install app on my device (I had some problems after upgrading iOS)

I've tried to change my code as you had said, but I'm still not sure if I understand it....

I have 2D map with 3k sprites. Let's say it's 3000 width.
Now, I "cut" this room to 10 rooms (300 px width).
Then I check if the particular sprite, from the room when my player is, and from adjacent rooms, if the sprite is visible or not?

Edit:
I dont know if it has changed or maybe it always was like that, but today I make an experiment. I make all my sprites invisible, so there was 0 sprites displayed (mm...just 4 HUD and control sprites - but actions,animationes etc. was still running - I dont know if it has any influence on perfomance if sprite is invisible). I stop calculating most of my colisions.
And I had about 40 FPS (sometimes it went down to 25 fps, but just for a second)

I'm not sure but 40 fps seems quite too less if you renember that nothing is rendered... It's preatty obvious that if I will render 100 fps and run colisions, fps goes down...
So, what do you think?

Ow. How can I check which function is taking the most time to do?
I find some instruments - CPU Sampler etc. but I dont know how to use them

Edit:
I have level built from 3000+ sprites.
Do you mean I should "connect" them into few big images and then render?

Posted 1 year ago #
Achmes
Member

Hey,
I'm writing it in the second post to make this more clearly.

Three situations:
A) I've created 500 CCSprites and add them to the CCSpriteSheet. 500 sprites were visible. FPS - 60 (guess it could be more without vsync).

B) I've created 4000 CCSprites and add them to CCSpriteSheet. 500 sprites were visible. FPS - 40.

C) I've created 4000 CCSprites and add them to CCSpriteSheet. 4000 sprites were visible. FPS - 35.

So the most interesting I think is situation A and B. The same amount sprites is visible, but there's essemtial difference in FPS.
Kepp in mind, that I DO NOT calculate if these sprites are visible or not on the screen. I just make first 500 sprites visible in init() function.
So there's no additional calculations in tick() function.

What do you think about it?

Posted 1 year ago #
araker
Moderator

There are two main reasons why B is more computational intense than A

1) 4000 visit methods are called every frame. Each object has a visit method, it applies all the transformations on a object and draws it.

2) Even though 3500 sprites aren't visible, their data (vertices) are still send to the GPU every frame. In the drawing phase the GPU tests if the object is visible or not and even though this has only a small performance penalty, the more objects the longer this will take of course.

This also explains why there isn't much performance difference between B and C.

Posted 1 year ago #
Achmes
Member

So there isn't any way to boost it?
Is It possible to not send this data to GPU?

Well, tell me if I'm wrong, but untill I have 40 FPS while only rendering scence, there isn't really way to "make it better". It's obvious that other caluclations will make FPS go down abouot 5-10 FPS.

Maybe iPsi has a good idea to make put level in few large textures and then render it.... I don't know how to do it now, but maybe I could work it out.

Posted 1 year ago #
Ozden79
Member

This topic is one of the weakest parts of the Cocos2D framework and needs to get attention as after a while, you got stuck on what to do and everybody tries to create his own solution for it.

In your case, which I'll probably follow in my next game as well, is to write your own tilemap class, whether it might read the tilemap editor format or one of your own. Without touching any of the classes in current Cocos2D implementation, your tilemap class can create just enough CCSprite to fill out the screen + 1 row and 1 column. This should be equvalent to 176 sprites in a 32x32 tile size with a 480x320 screen. Depending on the position of your CCSpriteBatchNode which renders those CCSprites, you'll change the rendertexture,visibility,rotation,etc. of the sprites. This should cutdown the processing power a lot (visit calls, etc.) as well as the quad count sent to the GPU. Each tile can be represented with a custom tile class which has some propeties you need such as scaling, visibility, rotation, etc. where you can reflect to CCSprites you use as well.

I wish that we could see some optimization in CCSpriteBatchNode actually. I've my own ideas on how to optimize it in same way but sadly my Objective-C knowledge is not as strong as some other language I used for a decade so can't find the courage to change all the codes in Cocos2D for that :).

Posted 1 year ago #
riq
Key Master

@Achames: See the performance tests: http://www.cocos2d-iphone.org/wiki/doku.php/perf_test:0_99_5

If your sprites are static (they don't move), then do as @iPsi said:

A)
- divide your map in "layers" (CCSpriteBatchNode). Each "layer" is responsible for rendering a part of your map
- Only set visible the "layers" that are visible.
- This is a simple & fast solution. Only valid if you know beforehand the position of all the sprites.
- Scenario: Tile maps, or background landscape composed of many sprites

If your sprites are not static (they are constantly moving), then do as @araker said:
B)
- Implement an spatial hash
- Scenario: You have to render many dynamic sprites.

Posted 1 year ago #
araker
Moderator

@Achmes, since the visit method is responsible for drawing a sprite (including sending data to the GPU), iPsi and Riq suggestions let you send less data to the GPU. When a CCSpriteBatchNode is not visible, none of the visit methods of its children will be called.

Posted 1 year ago #
Benihana
Member

2) Even though 3500 sprites aren't visible, their data (vertices) are still send to the GPU every frame. In the drawing phase the GPU tests if the object is visible or not and even though this has only a small performance penalty, the more objects the longer this will take of course.

Are you certain of this? I tried to walk through the code, but don't quite understand how the drawing part of batch nodes work. Not like non-batch nodes where they simply return if they are not visible, so of course no data is sent to the GPU.

Posted 1 year ago #
araker
Moderator

This is true, let me explain it in more detail. The batchNode calls -updateTransform of each child in its -visit (= where the magic happens). If the sprite is not visible it replaces its quad in the textureAtlas of the batchNode with a empty quad (line 487 in CCSprite). This empty quad still occupies the same amount of data, but will be discarded faster than a normal quad by the GPU. This is also the reason for the difference in FPS between case B and C.

@Ozden, if you have ideas on how to make a CCSpriteBatchNode more efficient, try explaining them in a new topic. When the idea is considered good I'm sure someone will step up to implement it in a future version.

Posted 1 year ago #
Achmes
Member

Agh...I have to sit down in peace and read few times what you've written, becouse I still don't feel confident in obj-c, and especially cocos2d classes.

But what I should do next is to merge these thousands of sprites into few images.... but in fact - I do not know how....
Take a look at this screenshot:

This is how my map is built. (Level edytor is on PC, and it uses OpenGL)
Maybe you know if there is any way to merge this in easy way? :/

Posted 1 year ago #
Achmes
Member

@rig, I was wondering about what you had said.

A)
- divide your map in "layers" (CCSpriteBatchNode). Each "layer" is responsible for rendering a part of your map
- Only set visible the "layers" that are visible.
- This is a simple & fast solution. Only valid if you know beforehand the position of all the sprites.

What's the difference between CCSpriteSheet and 'layer"?
Do layers work faster?

Posted 1 year ago #
riq
Key Master

@Achmes:
I was referring to "layers" as a concept, and not to the CCLayer object.
So in this case, CCSpriteBatchNode == "layers".

in v0.99.5: CCSpriteSheet == CCSpriteBatchNode

Posted 1 year ago #
mmehdi
Member

For merging multiple sprites(pngs) use.
http://zwoptexapp.com/

and for counting vertices use this one
https://github.com/jfahrenkrug/VertexHelper

Posted 1 year ago #
Achmes
Member

I think I've done it! :)
I have about 50-60 FPS, and there's still a lot to optimize.

I just have one more question about this layers.
So, as you adviced my, I divided my map in layers.
Everythink works fine, but there's some "bug" in the place, where layers are linked.
As you know, Sprites are rendered in a particular order so some of them are under the other.
But when we divided map to layers, we can't sort this sprites....
It looks sth like that:

How can I fix it? Maybe you have any solution for this problem?

Posted 1 year ago #
araker
Moderator

zOrder isn't going to work indeed, since it is relative to the parent. You need to use vertexZ, which is the opengl z-coordinate, to sort objects from. different sheets. It requires some more setup, like initializing your eaglview manually with a depth buffer. There is a vertexZ example in spritetest.m.

Posted 1 year ago #
Achmes
Member

Hey araker, I'm not sure if I understood you corectly.

Dou you mean that if I add z-coordinate to my Sprites, they will be displayed accurately, even if I DON'T render them in order: the farthest to the nearest?

Posted 1 year ago #
araker
Moderator

That's exactly what I'm saying, if you give your sprites a vertexZ coordinate the GPU will sort your sprites accordingly. Note that this can break the zOrder, all sprites in cocos have a default vertexZ of 0, so for example you will have to give all the objects in your HUD layer a higher vertexZ than the in game objects to make them appear in front of everything (or in case of the HUD layer this is also convenient).

Posted 1 year ago #
Achmes
Member

So...It was easy, I think,
just change projection to 3D:
[[CCDirector sharedDirector] setProjection:CCDirectorProjection3D];

and add only z pos when adding sprite to scene.
[sheet addChild: Sprite z: z_pos];

But...it doesnt work..
I think Z-coordinate works fine becouse I tried to set z_pos to random values and the map was "mixed".
But it seems it doesnt work with CCSpriteSheetS.
Sorting sprites in one Sheet works fine, but z-vertex doesnt work with two sheets together

Posted 1 year ago #
araker
Moderator

Try to look at the previously mentioned example in spritetest.m, then you'll see this is not the way to use vertexZ.

Posted 1 year ago #
Achmes
Member

I found e.g "SpriteSheet: OpenGL Z vertex" or "SpriteSheet: openGL Z vertex".
He also set "Z" position in this way:

sprite.vertexZ = z_pos;

And it's the only diference I could find between SpriteTest and my code...

I didn't mean z-vertex doesnt work completely.
They do, but only within one SpriteSheet. It looks like each spritesheet has separate coordinate system, and they cant penetrate each other...

There are no tests in SpriteTest.m with two or more spritesheets :(

Posted 1 year ago #
araker
Moderator

I thought the outline would be clear by now, let me explain it further then. To get vertexZ working you need to set a 3D projection, initialize the EAGLView with a depthBuffer and turn the depth test on (a method of the director).

I'm not sure if the zOrder is still going to work as expected when you use vertexZ, you'll find that out soon enough. With vertexZ, the sprite with the highest number will be on top. So for example give all the sprites in the sheet furthest away a vertexZ of 5, all the sprites in the sheet closest to the camera a vertexZ of 10. Now you can give the sprites of the furthest away sheet that need to lay on top a vertexZ higher than 10. Give all the sprites the same zOrder as before.

Posted 1 year ago #
Achmes
Member

yippe, yippee!! :D
It works, lol.

I just had to change
depthFormat: 0
to
depthFormat: GL_DEPTH_COMPONENT24_OES

Awesome! :-)

Thanks araker soo much :)

Posted 1 year ago #
GreasyNewfie
Member

On the other hand, I didn't change anything, but I got it working properly now too with 2 sprite batches in play. I must have made a small error somewhere down the line when I initially tried it this way.

Thanks for sending me here araker! I skimmed this post yesterday when I first started looking for a solution...but never made it down this far, lol.

Posted 1 year ago #
Achmes
Member

Mm...I think I should refresh this topics, becouse there're some issues...

arakaer, as you said, enabling z-buffer and give sprites also z-pos solved the problem but only in some cases.
I mean - it works OK, but only if sprites doesn't have alpha color.

All sprites on the map are added in particular order - from furthest to nearest. But as it was previosly said, on the bound of two CCSpriteSheets, few sprites are rendered in different order - from nearest to furthest. It cause things like this:

Au... :/ Is it even possible to fix it?

Posted 1 year ago #
araker
Moderator
When sprites have transparency you need to sort the sprites yourself from a low to high vertexZ. The GPU can't sort it anymore when transparency is involved. In your case you can't sort them this way directly, since they are in multiple sheets.

The only thing left is that you take the sprites with a different vertexZ out of the spritesheet and render them one by one.

ie
```
//pseudo code
[self addChild:sheetWithLowestVertexZ z:1];
 [self addChild:spriteWithHigherVertexZ z:2];
 [self addChild:sheetWithHighestVertexZ z:3];
```
Posted 1 year ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.