What Accelerated 2D Performance To Expect?

[trabitboy]

Hi,
I've been doing 2D gl
for 2 years to port easily my game projects once I get my real pandora

so I've been working 800 X 480 32bpp ,
blitting a lot of 2d quads ( textured )

however I began developping on a netbook recently ( commuting ... ),
and I realised that netbooks can't push that many surfaces!
frame rate is very sluggish on an intel chipset.

so , since I have no idea of the performance of the hardware before receiving it,
I was wondering if someone has attempted to do a 32 bit 640 480 game on the pandora,
and how smooth it runs ? ( or even a demo )
EDIT: using gl es

 

[sebt3]

For all that I know 32bits will be hard to try (not supported by the driver...)

 

[skeezix]

32bit .. probably means RGBA as a texture, which is supported; not 32bit colour in framebuffer mode.

I've not done too much gles2 myself so I can't note per se, but it really depends - _how many_? You didn't say how many objects you're trying to push per frame.

I've done a hundred sprites roaming around without a problem... but of course, you can do that in software in 200mhz without assembly too So what size quads, what sort of textures, how many of them, etc; ie: if you're doing a particle engine with 1000 very tiny alpha blended particles on top of some basic RGBA (transparent-or-not sprites), thats a different question.

jeff

 

[Exophase]

Hopefully we'll get 32-bit pretty soon, this is a rather sad state of affairs >_>

Your netbook might be artificially restrained, depending on the chipset and operating system. I have an Atom N270 netbook and I couldn't elevate the Intel GMA950 performance to anywhere beyond useless in Linux; but I was using a distro that's pretty old now. It was most likely operating purely in software mode.

There are some things you'll want to know and watch out for when it comes to 2D on Pandora:

- OpenGL ES 2 doesn't support quads directly, you'll have to use triangle strips instead to simulate quads.

- You also have to do your own shaders, which for 2D is usually very simple - a pure passthrough shader will work fine really. You can add effects to the pixel shader, and I suppose you could rig up some transforms in the vertex shader like sprite rotation and scaling, but that only really makes sense if you pass these things as attributes, and then you have to repeat them for every vertex instead of per-primitive. It's not really a bad idea, but doing these things on CPU probably won't hurt you very much.

- Uploading textures using standard methods can be pretty slow, and reading back the framebuffer can be especially slow. This normally isn't a big deal, but you shouldn't expect to do much in the way of CPU pre or post processing. If you really need faster texture uploading you can use the texture stream extension, but you'll still be somewhat limited in performance. Pandora has a decent amount of RAM, so this probably won't be a problem.

- SGX works best when drawing opaque primitives, and worst when using "alpha test." For 2D sprites, alpha test is the most natural way to accomplish pixel transparency to make objects that are non-rectangular in shape, but you should probably avoid the temptation to use it because it cuts performance in half just by having it on, regardless of whether or not anything has alpha rejected pixels. You don't want to do this because it has a massive performance penalty on SGX; instead it's best to do alpha blend. The problem with alpha blend is that you have to set primitives to either update the depth buffer or not; what this means is that if you draw primitives in the wrong depth order and rely on depth buffering to correct this you'll either end up with fully transparent pixels occluding opaque ones or opaque pixels not properly occluding pixels drawn later with a higher depth. So you have to draw things in proper depth order to get transparency, which is usually not a big deal for 2D.

- If you end up with a lot of completely opaque rectangular areas and you want to improve performance you can optimize out these areas and draw them in a first pass with alpha blending off. With alpha blending on you lose the overdraw elimination benefits of the SGX, even if it's drawing a bunch of fully opaque pixels on top of each other over and over. I would only do this if you have really huge opaque areas, like for particularly large sprites or backgrounds.. you might want to have an auto-pass which splits up quads this way but only if there's a large enough opaque region in the center (resulting in 5 quads instead of 1)... You may also want to optimize edges to use triangles where possible instead of quads, or even increase the geometry complexity in general to work around edges.

- Last I've heard, non-power of two textures are very slow. Rectangular textures should be OK.

- Use VBOs and address vertexes indirectly by index. Use 16-bit indexes. Use triangle strips with degenerate edges to move between disconnected quads (degenerate strips share the same vertex).

- Avoid having a bunch of draw calls, this murders the drivers pretty quickly. A draw call consists of a bunch of primitives that all use the same uniforms, bound textures, attached shaders, and OpenGL state - the only thing that changes between the primitives are attributes, which will contain position (xyzw), color (rgba), texture coordinates, and whatever other parameters you want to pass the vertex shader (you get up to 16 floating point attributes per vertex on SGX). You want to either employ texture atlasing or texture stacking - in both cases all primitives use the same texture and vary texture coordinates, either in x/y or in z.

 

[darkblu]

- Avoid having a bunch of draw calls, this murders the drivers pretty quickly. A draw call consists of a bunch of primitives that all use the same uniforms, bound textures, attached shaders, and OpenGL state - the only thing that changes between the primitives are attributes, which will contain position (xyzw), color (rgba), texture coordinates, and whatever other parameters you want to pass the vertex shader (you get up to 16 floating point attributes per vertex on SGX). You want to either employ texture atlasing or texture stacking - in both cases all primitives use the same texture and vary texture coordinates, either in x/y or in z.

was that reported in a new driver version? last time i saw those queried, they reported:

GL_MAX_VERTEX_ATTRIBS: 8

note that these are a 4-component vector each, so you get 32 [strike]floats[/strike] scalars worth of per-vertex attributes, altogether.

 

[Exophase]

Oh, oops, I assumed it because Apple says that for 3GS+, but they could have doubled it specifically for SGX535.. I doubt it'd be a driver limitation.

 

[darkblu]

Oh, oops, I assumed it because Apple says that for 3GS+, but they could have doubled it specifically for SGX535.. I doubt it'd be a driver limitation.

FWIW, 16 is what the ipad drivers report as well.

 

[trabitboy]

thanks for all detailed info so far !

32bit .. probably means RGBA as a texture, which is supported; not 32bit colour in framebuffer mode.

I've not done too much gles2 myself so I can't note per se, but it really depends - _how many_? You didn't say how many objects you're trying to push per frame.

I've done a hundred sprites roaming around without a problem... but of course, you can do that in software in 200mhz without assembly too So what size quads, what sort of textures, how many of them, etc; ie: if you're doing a particle engine with 1000 very tiny alpha blended particles on top of some basic RGBA (transparent-or-not sprites), thats a different question.

jeff

game is 640 480 ,
I blit 8x8 tiles with alpha = 4800 8x8 quads
then the player and the ennemies is like 10 128x128 quads with alpha

at the moment I upload the textures as rgba ( 32bits )

turning off alpha when necessary ( for most of the tiles ) seems a good idea,
I'll try ( on netbook )

I do a lot of state changes ( enable disable )
which might also cost a lot

 

[notaz]

For all that I know 32bits will be hard to try (not supported by the driver...)

By what driver? Framebuffer can be set to 32bpp just fine..
Don't know much about SGX or it's driver though.

 

[ledow]

game is 640 480 ,
I blit 8x8 tiles with alpha = 4800 8x8 quads
then the player and the ennemies is like 10 128x128 quads with alpha

Slightly off the topic of your post, but is it just me or does that not seem very much?

I've written a new game recently that blits 2500+ tiles (48 x 50-100 depending on the tile) to a backbuffer several times (for several layers in 2D isometric) before finally blitting that buffer to a 32-bit screen and the entire screen-drawing time is nothing - less than 1% according to profile times (200+ simultaneous A* searches, on the other hand, kill the CPU but, hell, what do you expect?).

It seems to me that you are probably spending just as much time getting everything into a GL-compatible format and blitting it via GL than you would do if you just 2D blit the thing to the screen in the first place. Or is Pandora SDL not up to that yet?

2500 tiles doesn't seem to be that much. What language are you using and why are you using OpenGL? Have you tested the alternatives?

 

[trabitboy]

game is 640 480 ,
I blit 8x8 tiles with alpha = 4800 8x8 quads
then the player and the ennemies is like 10 128x128 quads with alpha

Slightly off the topic of your post, but is it just me or does that not seem very much?

I've written a new game recently that blits 2500+ tiles (48 x 50-100 depending on the tile) to a backbuffer several times (for several layers in 2D isometric) before finally blitting that buffer to a 32-bit screen and the entire screen-drawing time is nothing - less than 1% according to profile times (200+ simultaneous A* searches, on the other hand, kill the CPU but, hell, what do you expect?).

It seems to me that you are probably spending just as much time getting everything into a GL-compatible format and blitting it via GL than you would do if you just 2D blit the thing to the screen in the first place. Or is Pandora SDL not up to that yet?

2500 tiles doesn't seem to be that much. What language are you using and why are you using OpenGL? Have you tested the alternatives?

I used C++ sdl when contributing a tiny bit to pandora panic,
I was schoked that on my relatively new laptop ( dual core from 3,5 years ago ),
I could not get 60 fps.

So I found a 2D gl blitting example 1 year and a half ago, and went from there for my following project ( c++ gl on PC ):
seemed fast and smooth without touching the gl code itself , could throw a lot of things at it .
Since then I've been writing a painter using render to tex, so I've just stayed with what I know .

I'll write a simple sdl blit to test the performance in the coming days ( might at least tell me if the netbook hw accelerates gl at least a little bit )

But eventually I'd like silky smooth 60 fps and transparency as it is an arcade game ( strider tribute ),
so HW acceleration seems mandatory?

Fact is I considered switching to SW render, but I think I would need to palettize the graphics
to make it really fast, and it doesn't really suit my drawing style that much.

 

[darkblu]

I blit 8x8 tiles with alpha = 4800 8x8 quads
then the player and the ennemies is like 10 128x128 quads with alpha

make sure those 4800 quads are not individual draw calls - that amount of draw calls would easily kill many GL pipelines, let alone an embedded one.

I do a lot of state changes ( enable disable ) which might also cost a lot

minimise GL state changes. state changes are increasingly expensive the weaker the CPU is.

 

[Rockthesmurf]

I'm not sure I understand the question, but I have a game that uses 32 bit textures ( 8 bits per channel, RGBA channels ), and the performance is better on the Pandora than on the first generation IPhone and HTC Desire. I have one full screen draw, and a bunch of sprites drawn on top, and the frame rate is a constant 60. That said, if you then do another full screen draw, with alpha, the frame rate starts to come down a bit. I haven't got around to testing, but I assume it'll be the usual story of being fill rate limited. The reason I am even using 32 bpp textures is compressed textures appear to crash on Pandora, but I've already started a thread about that!

I'm actually more disappointed performance wise with the audio implementation, it seems to be a lot worse than first generation IPhone of HTC Desire based on my tests (the number of voices I can play simultaneously at 60 is only 3-4).

Steve