Hey guys.

Currently wrapping up an game project I'm involved in with Android and because of the crunch at the end, I unfortunately don't have the time to test and profile this myself. So I thought, heyh, I'll ask here and see if someone already did this and knows the answer.

I got roughly ~120 tiles to render per every render loop, on top of that I have to render all enemies and such.

How my current structuring works is that all of the tile have their own texture coordinate buffer and I've got one global vertice buffer with four vertices on it. Rough pseudo-what-ever-code follows:

Code: Select all

// start of render loop
tell opengl that we are using THIS vertice buffer to render.

for( all tiles ) {
   tell openGL to use tile's own texture buffer
   render
}

for( all other stuff ) {
   render
}


First idea:
Could it be more efficient to store all the texture coordinates in a one "big" Array/List and access it by using offsets instead of switching the actual texture buffer all the time? Because now I'm switching the texture buffer instead of using offsets to get to the correct texture coordinate position. At the minute all tiles have their own texture buffer of four texture points.

Second idea:
My tiles are ALWAYS on the same place and my camera does not move (because of the game type). Could I draw "one quad" as the actual "level" and then just map all the 120 tile coordinates on that quad (two triangles actually.. but yeah..) ? So basically calling the gl.drawWhatEver() only ONCE and mapping all the 120 tile texture coordinates on those two triangles. Does that make absolutely any sense? Is it possible? If that didn't make any sense, do mention it and I'll try explaining it a bit more.


Further explanation:
Currently when I draw a tile, it draws two triangles per tile. 120 tiles * 2 triangles = 240 triangles. And that also is 120 openGL calls to render something and 120 times I swap the texture buffer. So is it possible to match all the 120 texture coordinates to two BIG triangles that cover the whole map area? And this way reducing the actual gl draw calls to.. one? Instead of 120 to draw the level.


Cheers guys.


// SkyWhy


EDIT # 1:
OR now that I thought about it a bit more, I think I need to match the amount of vertices and texture coordinates, right? So instead of having only two triangles, what if I have all the 240 triangles in one array and have another big array of texture coordinates to match those but draw them all with one sweep (one call to openGL). Is that idea any good? I'm drawing same amount of triangles as in the original but instead with one draw call, is this any faster because we only make one draw call?

Meh, I decided hell with the small amount of sleep I already am getting and decided to pull an all nighter to find this out.

Best results came out by having the same triangle amount , two triangles per tile BUT just having one rendering call. glDrawElements or glDrawArrays.

So to conclude, the Android can take up a pretty good beating when it comes to rendering triangles on the screen but what it "cannot" take so well is the amount of rendering calls. When you call the rendering loads of times, change buffers and so on, it'll start crying. But if you can drop the glDraw* calls to as few as possible by taking advantage of big vertice buffers and indice buffers, you can increase the triangle count on screen by.. well.. a lot.

To come up with the algorithm to turn our tile data from the tool to GL_TRIANGLE_STRIPS was pretty horrible experience... But, works now. No FPS issues anymore and can do even more stupid stuff with the device, hooray