Stealth Target: Day 31 – iPad cleanup
It took a bit of messing with provisioning profiles, but I got it to deploy to the iPad, eventually.
I also add to add setup for the depth buffer into ES1Renderer.mm .. This is not included for whatever reason.
Then I got to do some iPad specific tweaks – since the game was first for the desktop, some of the code is specific to the mouse interface. I’ve wrapped some #ifdefs around those things to check for BUILD_DESKTOP or BUILD_TOUCH so I can have some code that checks for certain mouse buttons and some code that doesn’t.
There’s a pretty good list of things I need to do however:
– Get music and sound effects working
– Get the mini-level preview screens working better.
– Do some smarter backface culling
– Avoid overdraw as much as possible
– Smarter touch interface
But in general, the game seems to work alright 🙂
So by changing my rendering to use GL_ONE (additive) blending, I can easily see where I have overdraw happening in my scene.
That shot has GL based backface culling enabled, but I’m going to disable it so I can do my culling on the software size so I don’t use so much memory in my buffers. Not sure if that will give me a performance gain or not, but it’s something to try out.
To get the music working, I converted my .wav file to an .aac file using this command on OS X:
afconvert music1.wav -f adts
That seemed to produce an .aac file.
From investigating speed issues on the rendering, it seems my use of GL_LIGHTs is slowing down things considerably. If I disable all my lights it renders much faster. I may have to investigate some other options here.
Anyway, it’s nice getting this game started on the iPad. I think it’ll come together pretty quickly with another day of tweaks.
-Phil
November 9th, 2010 at 10:07 pm
nice!
-Rox
November 10th, 2010 at 8:10 am
GL_LIGHTs indeed bring some slow-down on iOS devices, especially if you have many. If your lights aren’t moving all the time, consider doing the lighting yourself and baking to vertex colors or something?
Also, make some rough estimate of how many draw calls you have. Is it just a few big batches, or one or more calls per tile or something? This may be a big issue. Especially if you change material parameters and/or textures between each call.
Don’t care about the overdraw. If you’re drawing just solid stuff, the mobile 3D hardware handles that quite nicely since they’re tile-renderer architectures. For a single tile, if single opaque polygon eats it up totally, it really renders only that one and not any of the ones behind it, so some overlapping opaque polygons isn’t a problem. (On the other hand, on “desktop gfx adapters” sorting opaque stuff front-to-back yourself can actually bring speed improvements since then same pixels won’t be rendered more than once, making the end result work similarly to that tile-renderer-hw thing… but if your stuff is scaled to be minimalistic enough for mobile devices, you probably don’t need to care about desktop performance, everything will just be super fast anyway).
November 10th, 2010 at 10:23 am
@tonic – thanks for all that!
Yeah – some of the lights are fixed but some of the move. I’ll have to look into pre-calculating those on my end.
I do batch my GL calls, which really (after doing that) seems easier than not batching them 🙂
As for overdraw – that’s really interesting, I didn’t know that! I’m not sure I quite understand, but I guess I won’t worry about it too much. I found on the desktop that when I z-sorted my data, I actually had a 20% performance decrease due to using qsort!
-Phil