tac: Graphics performance

Despite my game being 2D, I still want to use OGL to draw the graphics for analog zooming and - maybe - z-buffering (more on that later). The iPhone is powerful for a mobile device, but still pretty weak sauce for 3D graphics and crunching through triangles. How many triangles will I need? It'll be a function of map size. Just eye-balling it, 100x100 square tiles seems to be plenty for a typical X-Com map. Currently, using the array+atlas method, I can get about 15FPS for 100x100. Number of on-screen triangles affects FPS by ~5. Fill does not seem to be an issue. Some potential speed ups:

* Using GLbytes for color: This doesn't even seem to work...we'll save that for later. Disabling color gives me 17FPS.

* Using GLbytes for texcoords: This gets me to 21-24FPS! Cool.

* Using GLbytes for position: Initially, I thought I couldn't do this since my tiles are 5-wide, so I'd need 500 units of precision. However, I can just send in unit-squares (so 100-wide) and transform them with a matrix! Let's try this...hmm didn't help too much. We still get 21-24FPS. Simplifies a lot of the code though, so that's good.

* Using glDrawElements instead of glDrawArrays: I'm not sure if this will save me anything. Using indices (glDrawElements) allows you to re-use vertices, but all my vertices will be different anyway in texcoords (they will only share positions), so using indices will just add the overhead of transfering index-data. Kind of a bummer, cuz the positions get shared a lot obviously. Oh well. NOTE: I tried glDrawElements, and it was slower - about 18FPS from 21-24.

* Interleaving data in arrays: This could buy me a lot by making the data more cache-friendly. Trying now...it doesn't seem to help much. Maybe 1 or 2 FPS without color. Hard to say if this helps much, but I guess I'll keep it - makes code cleaner.

Welp, after all that, I get 40FPS with a 50x50 map. Pretty solid, and pretty flexible as well. If I need to make a tile larger (for a wall or something), I can easily do that. A remaining performance issue is overlayed sprites. Of course, I can group all those in with the main data array - I just need one data array per texture atlas. I may need to do a lot of shuffling when objects move, but that's OK since objects move very rarely. Color modulation also slows things down a lot. Maybe OGL's fixed function lighting is faster? That's an option.

There's the issue of depth-buffering. I can potentially do all sorting myself (not conceptually hard), but that limits how dynamic the geometry can be. For example, if a unit is moving between squares, its z-depth may change and be in-between two layers. Sorting would require everything to be re-sorted just because of that, whereas Z-buffering would handle that alright (the unit's depth will just be the average of the depths it's moving between). The downside of z-buffering, however, is that it limits alpha-blending for multi-layer transparency. I think that's something I can live without though, so I will use Z-buffering. Then for dynamic geometry, I can just modify the vert-position data precisely to animate position.

Next step: make texture atlasing work with the floor data array. Then, integrate TACtical Objects (TACOs) into the data array stuff, so I can start coding gameplay.