Aquarium Live Wallpaper v1.7

- New Feature: Interested fish!
- New Feature: Mipmapping w/ prefs
- New Feature: Roman Column prop!
- Update: Adjusted clownfish & triggerfish sizes

Fish have a new behavior!  When you tap on the screen, there's a chance (20% per fish) that they'll stop and look at the glass for a few seconds before continuing on.  This got a good reaction from test audiences  :P

Mipmapping is a rendering technique that reduces noise patterns in edge-on faces.  It also allows a texture to be rendered at a lower resolution when the higher-res version isn't needed.  It's generally a good thing both for framerate and rendering quality, and I had it enabled some time ago originally, but took it out when I discovered that some phones don't support OpenGL ES 1.1 style mipmap generation correctly... and there doesn't seem to be any way to tell the difference.  So, now it's re-enabled, and  if you have a problem it can be disabled on the customize screen.  Press menu and it's in the pop-up.

The implementation of the options pop-up itself should allow me to add in a few more options in the future, so it's useful having that groundwork out of the way.

There's a new prop available, it's a roman column sticking up out of the ground.  It seemed appropriate.

In response to feedback, the triggerfish is substantially larger and the clownfish a notch smaller.  This is a nod to their actual sizes in, you know, reality.

City at Night v1.06

- Bug Fix: Light streaks should no longer pixelate

I got a couple bug reports about this... basically, after the wallpaper's been running for a while (several days?) eventually the light streaks and clouds would become pixelated looking.  I haven't seen this on my Incredible, but my guess is that the scrolling values simply got very, very high after a while... so I'm now rounding them down periodically.  Hopefully that does the trick.

Next Aquarium update

This update is going to be something of a grab bag of changes.  Firstly, I'm re-enabling mipmapping by default, and have added an options menu to the customization screen that allows disabling it if there's problems.  This should give a bit of a performance boost but still allow problematic phones to disable it.

I've added a new fish behavior -- when you tap the screen there's a small chance the fish will stop and look at you for a few seconds before continuing on.

The overhead light got an improvement.  It now has three modes, the third of which is more active and better looking than the current 'on' does.  It's also a touch more expensive, so pick your favorite.

The clownfish were reduced in size a bit, and the triggerfish enlarged.

City at Night v1.05

- Bug Fix: Camera zoomed in too far after certain applications are run
- Bug Fix: Rendering stops too soon on the far left/right home screens
- New Feature: Pulsing lights on background building
- Update: Removed uses-feature:live_wallpaper from the manifest (please fix your bug, Motorola!)

I've got a bit of time to kill, so here's an explanation:

Running a forced-landscape application (The camera app, for example), then returning to the home screen, results in the camera being zoomed in too far.

When the OpenGL viewport is created, I'm handed a width and height by the operating system.  I divide the height by the width to calculate the ratio, which I then use to make sure field of view is correct on the in-engine camera.  Right after that I set a flag called IS_LANDSCAPE, which a few things here and there key off of (landscape requires less horizontal scrolling, for example, because the camera view is wider).  The place I set IS_LANDSCAPE looked like this:

if( screenRatio > 1.0 )

     IS_LANDSCAPE = true;

So what's the problem?  Well, if you switch to a landscape desktop, IS_LANDSCAPE gets set to true.  Then, if you switch back to portrait... well, nothing happens then, because those two lines of code don't ever try to set it to false, so it stays set to true.  Yes, this was a totally stupid bug.  This now looks like so, which sets the value at all times:

IS_LANDSCAPE = (screenRatio > 1.0);

On some phones the far left and right edges of the city image end about a tenth of the way from the edge of the screen.

This one was a little more interesting, though it wasn't complicated.  Basically, the way home-screen switching works is that when you swipe from one to another, a function called onOffsetChanged gets called.  It gets passed a 0-1 value.  The idea is, if you're on your far-left home screen, it's 0, if you're on your far-right home screen it's 1, and in-between it's whatever percentage across that space you're at.  Pretty simple.

What I do with this is set a value within my wallpaper renderer called desiredCameraPos.  Every frame, the actual camera position attempts to drift towards desiredCameraPos with some acceleration, so you get smoothly interpolated movement no matter what the offset changes to.

The person who reported this bug was using stock android, a Nexus One.  I've been testing on an HTC Incredible, which uses HTC's modified home screen.  HTC's home screens already try to do smooth interpolated movement, so their background parallaxes with the foreground icons.  On top of that, when you're on the far right home screen and try to swipe right again, the camera actually pushes a little further then springs back, like it's on a rubber band.  What does this mean?  It means that on an HTC Sense phone, the far left and right screens aren't 0 and 1, they're more like 0.05 and 0.95.  This means that when I was testing, I didn't see a gap, because the camera never got all the way to the end of the possible range.

So anybody testing Live Wallpapers on a phone running HTC Sense:  keep in mind that it doesn't go all the way to the end when scrolling, and make sure you test by forcing the value to 0 or 1 and make sure things still work okay.

The funny thing is, we did test this on a Motorola Droid, which runs stock Android, and didn't notice the problem there, either.  Why?  I'm guessing because the Droid has a 480x852 screen instead of 480x800, so its camera view ends up being a bit more tall and skinny.  Probably just barely enough that you don't see the edge.

Aquarium v1.6

- Bug Fix: Smoothing home screen scrolling
- New Feature: Angel fish!
- New Feature: Trigger fish!
- Update: Faster plant motion
- Update: More colors in default backdrop

Nothing too crazy, just progressing with more artwork mostly.  The smoother scrolling is the same code as Galactic Core for the same reasons, that's one that's snuck into most of my wallpapers and will get fixed as updates occur.  Beyond that I got some comments that the default background is too purple, so I pulled it a little more towards cyan and allowed more of the colors to show through.

android.Bitmap and premultiplied alpha

While working on City at Night, I had to work out how to get the streaks of traffic to blend cleanly with the photographic image.  I couldn't just stack them on top, because they need to be behind the signs and lamp posts that line the road.  I also wanted to keep my number of passes to a minimum.

After some consideration, I decided to render the streaks first, then draw the city image on top, with an alpha channel cutting out the roadway features.  The plan was to blend this using GL_ONE GL_ONE_MINUS_SRC_ALPHA, which would keep all the brightness of the source image, but mask out streaks based on the alpha channel.  Simple.

I made my alpha cutout, got the images loaded, and discovered that my road surface seemed awfully dark.  Holding  the phone side by side with my original, they were really strangely dark.  My first thought was to blame Gimp, which I used to create the alpha.  I've seen it needlessly throw away color data in places with 0% alpha before.

After double and triple checking Gimp and not solving the problem, I downloaded paint.net and tried it there, but got the same result.  Then I tried it with an out of date version of Paint Shop Pro that I know for an absolute fact didn't mess with the color channel when you changed the alpha.  Same problem.

At this point I was confident the image was fine.  That means that after the image gets loaded, my colors turned dark.  I conducted an experiment by making a java array of a 2x2 texture, with pure white colors but alpha values of 50%.  I used android.Bitmap to make a bitmap of this, and lo and behold discovered that when blended GL_ONE GL_ZERO, I got middle grey instead of white.  Ahah!

So, the question then was:  is this happening at load time or when I hand it to OpenGL?  I pack my color values into ints and hand the array directly to glTexImage2D, and when I do that, I get the pure white I'm expecting.  Some searching around online confirmed this - android.Bitmap premultiplies your alpha for you, and there's no way to stop it from doing so.

This identified the culprit but didn't solve the problem.  PNG itself is a relatively complex image format, but I've read TGA files before, so proceeded to get a TGA loader working.  Reading in a TGA and handing the resultant arrays to OpenGL finally got me proper colors on my city highways, at the cost of some bloated filesize

So, if you're trying to do any kind of special alpha blending and are having mysterious problems with the colors in your artwork, keep that in mind: android.Bitmap forcibly premultiplies your alpha, so your colors will be darker than you started.