sprites render optimization for SGX (ipad)

This topic contains 2 replies, has 2 voices, and was last updated by  Aktion 7 years, 5 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #30155

    Aktion
    Member

    Hello!

    We working on game port from PC to iPad and experienced heavy performance issues, after some tests (we made different app), we’ve found that 200 sprites gives stabile 30fps and increasing sprites kills fps significantly (average game run on 10-15) .

    iPad seems have only 50Mb of video memory and we running at 1024×768 resolution.

    Could someone please suggest us possible optimizations ways. I’ve asked couple experts around, the results are: use compressed textures, decrease textures size (which is impossible), make atlases, turn off blending when not using it and texture swizzling. Not sure if swizzling works on iPad but know it gives 4x performance up on PSP. Anything else might help?

    Please advice,

    Here is the image how the test looks like http://img35.imageshack.us/img35/5607/photoa.png

    Thanks in advance,

    Alex

    #33958

    Xmas
    Member

    Are you using OpenGL ES 1.1 or 2.0? Are you using point sprites or drawing quads?

    The two important steps are to keep the number of draw calls low and to minimise the fillrate requirements. Ideally you should have as many sprites as possible in a texture atlas and draw them with just a few draw calls.

    Minimising the fillrate requirements might require some changes in the way you draw your sprites. It’s important to understand that the GPU does not treat opaque or fully transparent pixels any differently from semi-transparent pixels when blending is enabled. The GPU also can’t treat objects “below” a blended sprite as hidden, so every layer adds to the fillrate requirements.

    Because of this, it might make sense to use more complex geometry than a simple quad (or a point sprite) for sprites. As a first step, you should make sure the geometry you are using (even if it is just a quad) is tightly fitting the sprite image outline. Avoid drawing large transparent areas as part of the sprite.

    Furthermore, if you have sprites with large opaque areas (like the round one in your test), try splitting those areas into separate geometry and render them without blending.

    Ideally you’d have two draw calls, one for all the opaque areas and one for the semi-transparent ones. You can use the depth buffer, assigning a different depth value to the vertices of each sprite, to guarantee that sprites interleave in the right order. With the right depth comparison mode, you also don’t need to cut holes into the blended geometry where the opaque areas are.

    By the way, having UI elements on top of a GL view can have a significant performance impact. But I guess this only applies to your test app.

    #33959

    Aktion
    Member

    Hi George, this is ES 2.0 and drawing quads i think. Engineers added texture compression which is increased fps 2x time, scaled down some textures 2x time also increased fps but still not enough.

    The problem is that 90% of sprites in the game have transparency and many of them are semitransparent so I bet we try make this geometry complexity trick. Many thanks!

Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic.