Thunderstorm v1.1

- New Feature: Rain and its preferences
- Bug Fix: Camera speed pref
- Update: Background image is higher res
- Update: Lightning depth range further from camera

Yeah, kind of obvious in retrospect, but the initial release didn't have rain!  Well, it's here now, exercising the particle system I've been writing on and off over the last few weeks.  Some meaningful optimizations went into this one, as the system will now avoid updating fields that don't need to change, and can detect which ones to ignore fairly well.

The default rain effect simply plays overtop the camera - this is the least expensive one.  Fancier than that is rain that actually falls from where the clouds are, which is noticably more complicated as it means there's something like a dozen systems all updating at once.  Fancier still, you can enable both the global rain and the cloud-spawned rain all at once.  If you have framerate problems, I recommend sticking with the default 'everywhere' rain, though all of them behave fine on my HTC Incredible.

The depth range thing is a bit non-obvious... when a bolt of lightning strikes, it's placed randomly within the scene.  This includes depth, and previously it could get as close as 25 units from the camera.  This showed as noticeably low res sometimes, so now the close-range threshold is something like like 40.

Flowers v1.1

- New Feature: Particles in the wind
- Bug Fix: Camera Speed Pref

This is a fairly minor update that's partly a maintenance release, and partly to make use of a particle system I've been gradually getting working over the last few weeks.  The dandelion seeds blowing in the background are a simple particle effect making use of the new system, that I think help lend some additional motion to the scene.

The camera speed pref has been working incorrectly this whole time, a bug that apparently worked its way into a few other wallpapers as well.  I'll be fixing this as updates get made.

Thunderstorm Live Wallpaper v1.0

Update: YouTube video!
Update: Marketplace link!

This one actually went pretty quick, thanks to some artistic help from Joel Mejia and several hours trapped at an airport. :)

The most time consuming aspect of Thunderstorm was the clouds, which I guess is obvious in retrospect. The number of them needs to be minimized as these phones are very fill-rate limited, but at the same time you need several layers to get any kind of good motion.  I ended up defaulting to 9, spacing them out evenly along the Z plane (Z = up), and randomizing their depth between the camera and background layer.  The image distribution is random.

A lot of time went into tweaking the color ranges and nature of the alpha to allow them to blend together somewhat and create an amorphous shape when possible, as having sharp edges didn't play well in practice.  The phones I have access to also tend to knock the alpha channel to 4-bit (it looks like), which really hurts here.  It creates some pretty visible banding, so it was necessary to keep a fairly busy color channel to help hide that.  There's still a few artifacts here and there on a couple of the images, but for the most part the remaining banding isn't too bad.

To minimize fill-rate cost, both the lightning and clouds all have custom models that cut out the empty space so we're not rendering unnecessary invisible pixels... it's still a little expensive at times but it's about as minimal as is possible, I think.  The models themselves have normals forced outwards on the edges, so the clouds will directionally shade smoothly based on the light source in the scene.  The light direction very slowly orbits the periphery, but blips to the X origin of the lightning bolt when a bolt is spawned, then lerps back to its correct position.  The flash is accomplished by keeping the diffuse light as-is and spiking the specular light to the bolt's user-defined color, then fading that back down as the bolt fades out.

All this worked out pretty well.  There's still the occasional spot where the clouds kind of stand out as a cut-out sprite... that's really hard to eliminate completely without more layers of blending, but as updates happen I'll probably reduce it further.  As a whole the results here turned out really cool, and I'm happy to be able to release it.

I'm trying a different sort of approach to the free version with this one... the free version doesn't have an app icon, instead the settings button links to a pop-up dialog that explains the range of settings available in the full version, with a marketplace and web page link.  I'm hoping this is unobtrusive while still letting people know the full version's available if they want it.

Checklist

Things to get done on various projects:

* Sanity check app names for all wallpapers.
* Add Albania to EU Flags.
* Seahorse for Aquarium
* Popup menu when selecting fish for Aquarium
* Cleanup flare overlays for Thunderstorm clouds
* More prefs for Thunderstorm
* Confirm whether Motorola fixed their filtering bug with the 2.2 update They DID!

* Flowers update

European Flags Live Wallpaper v1.0

There's now an EU Flags Live Wallpaper to go along with the North American one!  This one features a collection of 8 picturesque backgrounds along with 33 national flags from throughout Europe.  As before, there's prefs for flag speed, camera speed, flag rendering style, and performance.  It's been localized into French, German, Italian, and Spanish as well.

We did make use of some Creative Commons Attribution images in this case.  There's a fantastic italian vineyard shot by Francesco Sgroi, a beautiful shot of the swiss alps by Problemkind, and a portion of a super-wide panorama shot by NathanMac87.  These all worked out great, and are much appreciated.

Check out the YouTube video!

NA Flags v1.05

 - Update: Sharper backgrounds
 - Update: Nicer preferences screen organization
 - New Feature: Puerto Rico and Greenland flags

Not a lot to be said on this one.  The background improvement is actually a bit of a bug fix -- originally landscape mode had more horizontal travel to the camera than it does now, and because of the width of the screen it was necessary for the background image to be wide enough to encompass the camera's full width.  At some point during development the landscape camera's motion got cinched up from a 90 degree arc to a 60 degree arc, but we never thought to fix the background model.  This means that about 25% of the background image was actually going to waste, because you couldn't ever see it!

So, the big change there cinching up the width of the background, so you can see more of the image now.  This has the happy side effect of getting a lot more pixels on-screen, and it's now visibly sharper.  On top of that, the canyon and mountains images were resaved with a higher compression quality, so they're outright sharper even without this change.  The sum total is a significant improvement in background quality.

Aquarium v1.85

 - New Feature: Sea turtle!
 - Update: Better framerate on Motorola Droid
 - Bug Fix: SD card support

I've been doing most testing on an HTC Incredible lately, and when I fancified the overhead light rays everything seemed cool... until I got a couple mails from Motorola Droid owners asking why things seemed so slow on Android 2.2.  Looking at it, the 2.2 update was just a coincidence, the real problem was that I'm now doing two passes with the default overhead light.  I'd forgotten how fill-rate limited the Droid was, and it came back to bite me here.  To make up for it I set the default back to one pass (like it was before), and additionally cinched up the edges of both the overhead light model and the bubbles model to eliminate any empty space.  The default settings now should be faster than before I changed things a week ago.  Sorry about that, Droid users.

SD card fix is the same as outlined below -- I turned off the copy protection flag.

Sea turtles -- well, who doesn't love 'em, and people ask about them pretty regularly.  It's making a bit of a wreck of the already questionable fish sizing, but ah well.  :)

Galactic Core v1.53

 - Update: More color selections
 - Update: Nicer prefs listing
 - Bug Fix: 2.2 SD card support

This is primarily a maintenance update to fix an issue with SD card offloading -- basically, while I've had support enabled for months now, I just recently discovered that it wasn't actually working for several of my wallpapers.  I tested this locally on a Motorola Droid running 2.2 and it seemed to work fine, so what gives?

A couple questions to the Android Development mailing list taught me that the market can't modify my signed APK file in any way, and the configuration between the working and non-working apps is exactly the same... plus, they work when I test them locally.  This means it has to be something with the market listing.  I did a couple of experiments with one of the folks who reported the bug to me, and eventually worked out that the 'copy protection' flag that the market allows you to enable on a listing doesn't play nice with SD card storage.  The install-location documentation doesn't mention this anywhere, so while I thought I'd been good to go for months, I've actually been sabotaging the feature by enabling copy protection.

So, half the point of this update is to disable that flag.  As mentioned with the City at Night entry below, I'm not a fan of completely invisible updates, so cleaned up the prefs listing using PreferencesCategory (which I just learned about) and additional color selections as a bonus.

As a side note, anyone with a leaked ROM isn't able to see anything flagged as copy protected, and that happens often enough to be meaningful in my experience.  Worse than that, Samsung just released an official update for the Galaxy S in some regions that also can't see anything flagged as copy protected.  Between the SD storage issue and the fact that it seems to frequently mean potential customers can't see the software, I think it's time to ditch the copy protection feature on all my listings.  As a bonus, it'll trim the amount of storage space required, so really everybody wins.

Sea Turtle!

Issues of scale aside, people really want a sea turtle... so here we go.  I'm starting with an existing model and reducing the polygon count down to budget, but he's looking pretty good so far.  This is based on an original model by Ajunip.  He'll probably have 200-300 triangles trimmed by the time I'm done, then it's on to animation.

City at Night v1.07

 - Update: More blinking lights

Sounds silly, I guess, but there's several more animated lights in the new version.  It's small, but a little more motion is always a plus, and I wanted to get a couple framework updates integrated without doing one of those completely invisible what-did-I-get-out-of-this style updates.  Enjoy!

Generala v1.57

 - Bug Fix: White text on Droid X
 - Update: SD card storage support

I think one or two other things might've snuck in there too, it's been a while since Generala got an update.  Of the above items, the interesting one is the Droid X bug.  Let's discuss that.

Basically, what I was doing to control the color of the score text was to use a 'style'.  These are defined in an xml file and work basically like a CSS style, in the sense that you bundle up a font, font size, font color, and a number of other things all into a single object -- say, one called "BlackScriptBold".  Then, when you define your text fields, you simply hook that field up to BlackScriptBold to give it all those properties.

In general,  this is good practice, because that way if you need to do something like change the font, you only change the one style entry and everything using that style automatically uses that new setting.  Otherwise, you'd have to visit every place where you were using your script font and change them all individually, which in a decent size project could be dozens or hundreds of locations.  Obviously, there's a lot more margin for error when making a hundred scattered changes.  Thus, good practice.

So, this is what I was doing for the score boxes in Generala.  I got a bug report a week or two ago saying the scores showed up in white on the Droid X, which was nearly impossible to read against the paper-grain background.  I double checked that everything still looked right, which considering it works everywhere else I was pretty sure of, and ultimately ended up forcibly setting the color to black for each individual score box instead of in the style.  This fixed the issue.

The moral of this story is that if you're having weird issues with Android UI display on a Droid X, it's possible Motorola has munged up their handling of styles somehow.  Between this and the live wallpaper filtering bug (which I hope and pray gets fixed with the Droid's 2.2 update) Motorola's been a bit iffy with their handling of standard functionality so far...

Silhouette v1.45

 - New Feature: Camera zoom pref
 - Update: Greater range of camera motion
 - Update: SD card storage support

The primary work feature here is wider camera motion, which required rework of some of the background graphics, as, frankly, they didn't go all that far before.  Widening the landscape and sky models allowed for more horizontal camera travel in both landscape and portrait mode, which definitely helps the feel in this brave new world of 5 and 7 home-screen phones.

Along those same lines, I've had a couple folks request the ability to reduce the amount of black at the bottom of the screen.  After trying a couple approaches, I settled on one that moves the camera up and bit and zooms in its' field of view by about 20 degrees.  This frames the scene a bit differently and works very well, I think, while reducing the amount of dead space at the bottom of the composition.

Aquarium v1.8

 - New Fish: Clown Triggerfish
 - Update: Better overhead light
 - Update: Closer bounds on fish movement
 - Update: Mipmapping off by default
 - Update: Fish take an interest more often

Big credit goes to cliff1066™ for his (Creative Commons Attribution licensed) clown triggerfish image, which worked quite well as source material.  Check out his photostream for a bunch of cool stuff!

Closer bounds on fish movement is probably the most mysterious thing here.  Basically, the fish periodically select a destination to swim to, and upon approaching that destination slow down, begin turning, and select a new destination.  As they travel they'll occasionally re-evaluate and change to a new destination.  The destination position itself is randomly selected within a range of X and Y, roughly encompassing the background area.

As I've noticed occasional comments about fish leaving and not coming back (which is impossible given the way the system works, they simply cannot try to go anywhere outside the specified X and Y bounds), I'm guessing this just means the fact that they'll sometimes leave the visible area before turning and swimming back.  To that end I pulled in the left and right edges of their range by about 10%, so they shouldn't leave the edge of the visible area as much.