Hi folks,

After merely 2 weeks of work, I now have a very basic openGLES engine running with 100 sprites rotating, optionally billboarding, alpha-ing and the like. So far I've optimised by:

GPU:
- Creating and using texture atlases.
- Using only one draw call per texture atlas.
- Using drawElement to reduce the number of vertices created.

CPU:
- Using matrices to minimise multiplications.

Using sine and cosine tables was a waste of time: no discernable difference.

So, my question is - 100 sprites on screen seems pretty good to me.
Is it worth doing things like the following:

- Reducing data copying by changing all UV and RGB data to unsigned ints (somehow)?
- Aligning data (no idea what that would entail, to be honest. Sounds like it would need a major re-shuffle of my code.

As I have no basis for comparison, any thoughts would be appreciated.

If you are doing 2d then 90% of time you are going to be fill rate limited which means changing your vertex data to use shorts ( using unsigned ints won't buy you anything - the idea is to minimize the size of your vertex buffer) won't give you much.

Ah, right. Good to know.

But as a rule of thumb, is 100 sprites on-screen, many of which are 1/4 of the size of the screen or larger, with massive amounts of overdraw good/bad/average?

Madrayken Wrote:Ah, right. Good to know.

But as a rule of thumb, is 100 sprites on-screen, many of which are 1/4 of the size of the screen or larger, with massive amounts of overdraw good/bad/average?

Sounds good to me .... I can do about 400 32x32 alpha blended sprites in addition to a full screen dual-texture quad serving as the backdrop.

If I switch blending off , I can display about 1500 32x32 sprites while running at 30 fps.

That's on 2g devices ... on the latest iPhone ( 3gs) I can bump up my sprite count by about 5 times.

I am curious. What did you do with drawElements vs drawTriangles and how much did it help? I also have a big waste with my glcolors array. it has to be 2x the size of the vertex array and 90% of the time its all 1s, but you need it for that other 10% Also I am now curious what my render rate is compared to you guys. At some point i will have to do a test. I have about 50 things on screen at hectic times if not more, each thing being 2 triangles. I can hold 60 fps during a lot of the time on a 2nd gen ipod. This is with game logic though which uses a good chunk of cpu. I can do a render test at some point.

kendric Wrote:I am curious. What did you do with drawElements vs drawTriangles and how much did it help? I also have a big waste with my glcolors array. it has to be 2x the size of the vertex array and 90% of the time its all 1s, but you need it for that other 10% Also I am now curious what my render rate is compared to you guys. At some point i will have to do a test. I have about 50 things on screen at hectic times if not more, each thing being 2 triangles. I can hold 60 fps during a lot of the time on a 2nd gen ipod. This is with game logic though which uses a good chunk of cpu. I can do a render test at some point.

I am using unsigned int for my color values within the array.
There is no really way around it if you want to have multiple colors/effects for each quad while keeping them all rendered with a single batch.

warmi Wrote:I am using unsigned int for my color values within the array.
There is no really way around it if you want to have multiple colors/effects for each quad while keeping them all rendered with a single batch.

Having just checked, the size of a float is 4, as is an unsigned int. Is there really any benefit?

Madrayken Wrote:Having just checked, the size of a float is 4, as is an unsigned int. Is there really any benefit?

Well, to store a color value using floats you need 4 of them.

Madrayken Wrote:- Reducing data copying by changing all UV and RGB data to unsigned ints

It's fairly painless to change your RGBA data to unsigned byte but non-floating-point UVs require that you scale the texture matrix, which may or may not be worth the effort.

Frank C. Wrote:It's fairly painless to change your RGBA data to unsigned byte but non-floating-point UVs require that you scale the texture matrix, which may or may not be worth the effort.

Yeah ...

On the other hand, for my 2d module I let users specify texture coordinates using integer coordinates because most people are more comfortable using pixel coordinates when coding with 2d oriented APIs.

In other words I use something like this:

drawSprite(const RectangleI &screenRectangle, const RectangleI &textureRectangle, float scale,float rotate,int origX, int origY,const Color &tint=Color::White)

warmi Wrote:On the other hand, for my 2d module I let users specify texture coordinates using integer coordinates...

I do the same, but convert to floating point before OpenGL ES gets a hold of them. I hack at the texture matrix for effects and it's just easier to not have to deal with an extra transform at draw time.

Madrayken Wrote:...
So, my question is - 100 sprites on screen seems pretty good to me.
Is it worth doing things like the following:
...

imho before investing too much time in lots of careful optimisation, the question should first be: is the current performance good enough for my game?

aBabyRabbit Wrote:imho before investing too much time in lots of careful optimisation, the question should first be: is the current performance good enough for my game?

It certainly is for my first one, but you know how it is: if you know you're doing something sub-optimally, it niggles at the back of your brain. Being ignorant, that niggle is even more intense. :-)

As warmi said - from the sounds of things (sprites quarter screensize) most likely you will be fill rate limited, and so tweaking the vertex data isn't going to buy you much performance for a mere 100 sprites. But using unsigned bytes for colors and interleaving the arrays (is that what you ment by aligned?) should be a straightforward change.

I'm surprised that you can get good performance with sprites that size - so I'd say you're doing good

So, if I switch RGBs from four floats to four bytes, presumably that's nice and word-aligned automatically?

VertX, VertY, VertZ, R,G,B,A, UVX,UVY
4, 4, 4, 1, 1,1,1, 4, 4

See this (at the bottom) for the alignment details.