Which 2d rendering algorithms are popular for mobile game engines (specifically Android) and why? Are the same ones for the desktop and/or console world as effective here?
\$\begingroup\$
\$\endgroup\$
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
3
At first glance many consoles support the same OpenGL-like interface where you throw triangles at the hardware and it figures out how to do it best. In real life each hardware has been optimized for certain uses and modifying how you throw your triangles at it can make a difference.
For instance, the iPhone uses a deferred tile renderer, where the driver collects triangles until a certain limit, then renders them in small tiles (see http://developer.apple.com/iphone/library/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/OpenGLESPlatforms/OpenGLESPlatforms.html). For the iPhone you should research building texture atlases, since texture unit switches are not free. You can also disable the depth buffer and also lower the graphic resolution from 32bit to 16bit to reduce memory consumption.
I've heard that Gameboy-like hardware uses a more explicit tile renderer which you have to get at it at the low level to get good performance and is hard to do properly. PS3 consoles are multi-core, so there your algorithms work best if you are able to parallelize your load, I wonder how the PSP does in comparison, apparently it's between PS1 and PS2 tech level.
Then there are OpenGL characteristics which may be used, abused or underutilized. In the case of the iPhone one would be Vertex Buffer Objects, advertised as the best thing since sliced bread, but in practice worthless (http://www.idealbinary.com/ib/blog/kevin/2010/1/12/iphone-opengl-es-performance). Again, from personal experience I found that the iPhone hardware is very much bandwidth limited. If you want to darken the screen, you could create a sprite the whole size of the screen with translucency and blit it on the screen. Don't do it! It's better to create a smallish 4x4 sprite and let the hardware stretch it to the full size. The hardware has less pixels to read from the source, and that is faster than the stretching operation itself, which would be slow to do in software.
Long ago I played with GPX2 hardware but not at the lower level, so I don't know about more mobile consoles. But most definitely, each mobile platform can use fine tuning, so unless you specify more your question it is going to be tough to answer it.
answered Aug 31, 2010 at 7:56
-
\$\begingroup\$ Nice answer, lots of stuff I haven't thought about. I updated my question to reflect that I use Android \$\endgroup\$ Commented Aug 31, 2010 at 8:15
-
\$\begingroup\$ That's better. Still, Android, like iOS now, targets several devices, so you will definitely need to specify a hardware device for somebody else to comment on it. In general an algorithm where you put your polygons perpendicular to the camera, disable the depth buffer and trying to use triangle stripes to reduce vertex overhead should be a winner. Another trick could be scaling texture coordinates to use bytes instead of floats, which improves bandwidth. \$\endgroup\$ Commented Sep 11, 2010 at 19:59
-
\$\begingroup\$ Well, after seeing this: youtube.com/watch?v=U4Bk5rmIpic I have decided to use the DrawTexture call for all my Ui bits, and VBO's for the rest. He does some benchmarking, and what he finds is that up to 50 sprites the built in android.graphics library is just as fast as open gl. This might have changed in the newer versions of android though. \$\endgroup\$– NailerCommented Sep 12, 2010 at 10:55
\$\begingroup\$
\$\endgroup\$
I'm not sure what you mean by "rendering algorithm". The modern 2D rendering algorithm is "you feed some quads into OpenGL, and if the rendering is kind of slow, you sort them by texture first, and if they're transparent, you sort them by order before any of that". I don't know of any platform with a different process - at least, without getting into game-specific techniques.
