The one part of cocos that really benefits from this are tilemaps. If it's worthwhile for you to optimize this, depends if your bottleneck is the tiler. Check it using the OpenGL ES instrument in release mode.

A simple implementation is to give static and dynamic geometry their own batch node and add a check in the textureAtlas class to see if any of the quads have changed.

You could go a step further and keep track of which indexes in the quad array have changed and perform a ranged/partial update. Though testing is needed to see if ranged updates really give better performance. From what I've red in most cases it's more efficient to just flush the buffer, instead updating a part of it.

araker, you say "Cocos on the other hand doesn't handle static and dynamic geometry differently".
so cocos updates the VBOs at each frame, even though some coordinates don't change ?
Do you think it could be worthwile to spend some time optimizing for that ?
Like checking if sprites have moved or not, and marking them static (either a flag for background elements
or a dynamic test that checks if things moved or not).

I'd like to try this, when I find some free time, but I don't know if this will have a great impact
on fps...

Interesting topic, I didn't know this was discussed here.

It is correct that the tiler benefits from a smaller vertex format. To go into more detail, on older (MBX) devices the performance will linearly increase with the reduction of the vertex size (in case you're tiler limited). Caching of vertex data (VBO's) doesn't work (a broken implementation), so the data needs to be send to GPU every frame and the amount of data quickly becomes the bottleneck.

Newer devices (SGX) can use VBO's to cache the vertex data for the GPU. To use this optimally sorting static and dynamic geometry is needed, so that the static geometry can be cached for the GPU. Though this means that reducing the vertex format won't have the same impact as for the MBX devices.

Cocos on the other hand doesn't handle static and dynamic geometry differently, so the performance in cocos will scale similarly for MBX and SGX.

To get back to the performance benefit, the current vertex format is 24 bytes, CJ's proposed format is 20 bytes, which will give a performance benefit around 16,67%. When I implemented this I used a smaller format with shorts for texture coordinates as well. Then the format is reduced to 16 bytes, a reduction of 33.3%, which is the performance benefit seen in the stackoverflow topic.

Hey CJ,
did you ever find anything out?

I'm working on a full writeup on how to get the most performance from Cocos2D and OpenGL, but the prelim results for this aspect are... If you reduce the data size sent to openGL (by using shorts in this case to represent the positions) you reduce the utilization of the openGL Tiler. I will delve into what this means further when I post the full writeup, but the other factor to openGL performance is the Renderer, so if you happen to have a case where your utilization of the Renderer is low but your use of the Tiler is high this is a performance win for your app. (The Tiler/Renderer utilization stats can be seen by running with the OpenGLES instrument).

It turned out that in my game I am using like 99% of the renderer and only 15% of the tiler, so I've spent the last few days trying to optimize for this case. (And making Cocos2D run with GLshort vertex types is a bit of work at this stage, but I will post a patch later if people are interested in trying it)

Hope that all makes sense, I will post back here again when I have a full report.

They mentioned that at the iPhone tech talks, I meant to try it out, but forgot :)

Any results yet? I'm curious to see how much of an impact this has.

I got an answer about the padding from none other than Jeff LaMarche (http://iphonedevelopment.blogspot.com/)

Basically I just do this to take care of the struct with 3 shorts in it (6bytes=24bits) to make it (8bytes = 32bits):

typedef struct _ccVertex3S
{
    GLshort x;
    GLshort y;
    GLshort z;
    GLshort padding;
} ccVertex3S;

Note that he also recommended using GL data types because it defines the size of a short to be 16 bits, but just a regular short could actually be dependent on the system.

Re: the short vs. float thing I found this post on stackoverflow as well:
http://stackoverflow.com/questions/1287811/what-does-the-tiler-utilization-statistic-mean-in-the-iphone-opengl-es-instrument

He claims to get 30% increase in performance by making the change.

But I'm hoping someone can help me with this bit... padding to a 32bit boundary as described in that link. Practically, what is involved in achieving that?

In preparation for testing all this, I made some new struct types:

typedef struct _ccVertex3S
{
	short x;
	short y;
	short z;
} ccVertex3S;

typedef struct _ccV3S_C4B_T2F
{
	//! vertices (3S)
	ccVertex3S		vertices;			// 6 bytes
	//	char __padding__[4];

	//! colors (4B)
	ccColor4B		colors;				// 4 bytes
	//	char __padding2__[4];

	// tex coords (2F)
	ccTex2F			texCoords;			// 8 bytes
} ccV3S_C4B_T2F;

typedef struct _ccV3S_C4B_T2F_Quad
{
	//! top left
	ccV3S_C4B_T2F	tl;
	//! bottom left
	ccV3S_C4B_T2F	bl;
	//! top right
	ccV3S_C4B_T2F	tr;
	//! bottom right
	ccV3S_C4B_T2F	br;
} ccV3S_C4B_T2F_Quad;

Great, thanks Riq. Will do.

1. Batch Geometry
2. Texture Atlases
3. Interleaved Arrays
4. Indexed triangles
5. Floats vs shorts (turns out shorts are good to feed into openGL)

cocos2d uses:
1,2,3,4 but not 5.

But if you want to make some performance tests with 5, please, post your results here.

hmm. ok. +1 bump for Riq being back :)

Bad time to bump since Riq is away! It looks like good advice on optimizing though.

+1 week. Maybe no one saw this thread. Bump.

I was listening to this podcast from Stanford's CS course which had a developer from NGMoco talking about performance optimization with OpenGL for iPhone. Here's a link which includes a demo project and the presentation slides: (you can also search itunes-U for the audio) http://gamemakers.ngmoco.com/post/111712416/stanford-university-and-apple-were-kind-enough-to

His example is a particle system that he optimizes by doing the following:
1. Batch Geometry
2. Texture Atlases
3. Interleaved Arrays
4. Indexed triangles
5. Floats vs shorts (turns out shorts are good to feed into openGL)

And I was hoping Riq or some other Cocos2D guru here can see if there's anything that could improve rendering performance of Sprites or AtlasSprites or Particles Systems using some of these techniques.

:)