Jumpgate Live Wallpaper v1.15

  - Update: OpenGL 2.0 is now being used
  - Update: Much faster framerate on Xoom
  - Update: Better shading on character
  - Update: Animation smoothing always on
  - Update: Less memory usage
  - Update: Higher res icon/thumbnail

This update doesn't add a ton of new bells and whistles in the traditional sense, but does move the entire project forward to OpenGL 2.0 (from 1.1).  The big reason to do this is performance on the Xoom and other high-res screens -- those devices are seriously fill-rate limited and being able to collapse multiple passes into a smaller number of more complex passes makes a big difference.  Average framerate on the Xoom more or less doubled with this update.

As a bonus this means we can use ETC1 compressed textures and use less memory at the same time.

Now, in the process of doing this a few aspects of the visuals changed -- in particular the star streaks went from being scrolling textures to being a particle effect.  This strongly reduces the amount of fillrate used at the cost of more vertices.  It doesn't matter much on the Incredible, but on the seriously fill-rate starved Xoom it makes a big difference.

The most interesting part of this was the tunnel itself.  The tunnel under OpenGL 1.1 is two passes, the first being color and the second being a brightening/darkening overlay.  That alone was hugely crippling on the Xoom, and when I found that collapsing those into a single more complex pass didn't help much (as I still had to do two samples) I ended up moving the tunnel into a render to texture effect.  Basically, I rendered my complex shader onto a 256x256 tileable image, then when I draw the scene I take that and apply it to the tunnel.  This means the scene itself is rendering something very simple, and I only have to use the complex shader on a relatively small image.

This added several fps to the Xoom, but I discovered afterward completely tanks the Incredible.  After some timing and commenting out of things, I eventually discovered that binding a texture buffer on the HTC device is hugely expensive.  After some experimentation our theory is that they effectively call glFinish() somewhere inside their bindFrameBuffer call.  This more or less means you aren't able to use render to texture for anything performance-intensive on that device. Thanks, Qualcomm. :(

But I still needed it to work this way on the Xoom.  So, what I ended up doing is creating two paths -- one that uses the RTT approach, and one that renders the tunnel in the traditional fashion.  Upon startup I do a test that renders 20 frames in one style and 20 frames in the other.  I time how long this takes, and whichever one tests faster is the path it uses.

This strikes me as kind of awkward, but given the mess of different devices out there and the fact I really want this to work decently on the tablets, it seemed like the only reasonable approach.

Update v1.16:

Fixed a bug that affected folks who'd previously had mipmapping enabled... on a PowerVR device it was crashing due to some leftover code from before the 2.0 port.