About Tile based rendering

Hi!





I have several semi-transparent layers that will occupy almost all screen and I wondering about what is better for a tile based rendering engine: To Use big triangles or tiny triangles.





From the point of view of the TBR, should I create meshes that fits the 32x16 grid?


(I have understood that this is the size of the tiles)





or is it better to have only two triangles per layer?





Thanks in advance.





PD: I’m puzzled because it is too slow and I’m using only few triangles ([iPhone 2G] PowerVR MBX Lite)


Use big triangles. However, if your layers contain fully opaque regions it might make sense to manually “cut out” fully opaque polygons and render them with blending disabled. That way the GPU won’t have to process the layers below the opaque region.





lucera wrote:
PD: I'm puzzled because it is too slow and I'm using only few triangles ([iPhone 2G] PowerVR MBX Lite)


What is your performance target, and how many layers and which texture format are you using?
Quote:
What is your performance target, and how many layers and which texture format are you using?



I want to achieve 30 FPS.



With only 4 layers my iPhone goes too slow.



Layers:

- Background (2 big opaque triangles)

(SRC_ALPHA, ONE_MINUS_SRC_ALPHA)

- Enemies (multiple triangles, no more than 60)

- Big effect (2 big triangles)

- UI (multiple medium triangles at top and bottom)

What texture formats are you using for your graphics? If you’re bandwidth limited then this can make a big difference to your framerate.





Are you clearing before rendering each frame? The clear is free and saves the core from preserving useless data from the previous frame.





It sounds like cutting down the number of blended pixels that you are drawing will make the biggest difference to your framerate so if you can chop up your graphics to avoid drawing large areas of complete transparency then that should help.





If you can render any of the subsections of your graphics as opaque triangles then this would be even better: do you have the opportunity to implement what Georg has suggested and render any of your overlaid images as a combination of opaque triangles followed by rendering blended triangles.





For this to help performance, all the opaque geometry needs to be submitted first and then followed by the blended geometry so that obscure pixels can be rejected by the hardware.





Are you batching the calls for your graphics? Are you rendering each layer with a single drawcall (good) or are you making many texture binds(bad)?





Please take a look at Apple’s recommendations (and our own documentation at: https://www.imgtec.com/factsheets/SDK/POWERVR.%203D%20Application%20Development%20Recommendations.1.7f.External.pdf) and check that you are follwing these guidelines as well as you can.

Gordon wrote:
What texture formats are you using for your graphics? If you're bandwidth limited then this can make a big difference to your framerate.



32 bits (all)



Gordon wrote:
Are you clearing before rendering each frame? The clear is free and saves the core from preserving useless data from the previous frame.



yes



Gordon wrote:
It sounds like cutting down the number of blended pixels that you are drawing will make the biggest difference to your framerate so if you can chop up your graphics to avoid drawing large areas of complete transparency then that should help.



Then, are you saying that it's better to split the sprites in transparent and opaque zones?

This will be so difficult in most cases. Sometimes only the borders of the objects have transparency.



Furthermore I'm doing a global effect in the game thanks to a big transparent texture (big triangles, the texture is really tiny) in the first plane :(



Gordon wrote:
If you can render any of the subsections of your graphics as opaque triangles then this would be even better: do you have the opportunity to implement what Georg has suggested and render any of your overlaid images as a combination of opaque triangles followed by rendering blended triangles.



No, it's too difficult in this case, sorry



Gordon wrote:
For this to help performance, all the opaque geometry needs to be submitted first and then followed by the blended geometry so that obscure pixels can be rejected by the hardware.



yes, I know



Gordon wrote:
Are you batching the calls for your graphics? Are you rendering each layer with a single drawcall (good) or are you making many texture binds(bad)?



Many texture binds. It's a game, we can't do always the best for the GPU, hehe



Gordon wrote:

Please take a look at Apple's recommendations (and our own documentation at: https://www.imgtec.com/factsheets/SDK/POWERVR.%203D%20Application%20Development%20Recommendations.1.7f.External.pdf) and check that you are follwing these guidelines as well as you can.



Many thanks for this info and for your help!



Now I will read this pdf
lucera wrote:
Gordon wrote:
What texture formats are you using for your graphics? If you're bandwidth limited then this can make a big difference to your framerate.



32 bits (all)


Try using smaller texture formats for your graphics. Try the formats in increasing size until you are happy with the image quality: PVRTC 2bpp, PVRTC 4bpp, RGB565/RGBA4444/RGBA5551, RGBA888/RGBA8888. You don't have to have all your textures as the same format and the GL code to use them once loaded is identical so mixing and matching texture formats is fairly easy once the loading code is sorted out.



lucera wrote:
Gordon wrote:
It sounds like cutting down the number of blended pixels that you are drawing will make the biggest difference to your framerate so if you can chop up your graphics to avoid drawing large areas of complete transparency then that should help.



Then, are you saying that it's better to split the sprites in transparent and opaque zones?

This will be so difficult in most cases. Sometimes only the borders of the objects have transparency.



Furthermore I'm doing a global effect in the game thanks to a big transparent texture (big triangles, the texture is really tiny) in the first plane :(



Gordon wrote:
If you can render any of the subsections of your graphics as opaque triangles then this would be even better: do you have the opportunity to implement what Georg has suggested and render any of your overlaid images as a combination of opaque triangles followed by rendering blended triangles.



No, it's too difficult in this case, sorry


It's hard to know what optimisations you've already applied - some are more complicated to apply than others.



Cutting up individual sprites is tricky and may be unnecessary, but rendering completely opaque elements before transparent ones is easier to do. However, this more or less requires batching into opaque and transparent sets of draw calls.



lucera wrote:
Gordon wrote:
Are you batching the calls for your graphics? Are you rendering each layer with a single drawcall (good) or are you making many texture binds(bad)?



Many texture binds. It's a game, we can't do always the best for the GPU, hehe


I'm not sure many game developers would agree on that one... Removing redundant state changes and batching geometry into fewer drawcalls can benefit almost any graphics application and many game engines are very much designed around these concepts.





It's hard to know what is the specific bottleneck in your code - it sounds like you may be fill-rate limited so it may be that optimising the texture formats is all you need to increase your framerate because the bottleneck is there. I would try this first.



Which of the layers makes the biggest difference e.g. does missing out the effect layer speed the frame rate more than missing the other layers?