- Update: Better handling of custom backgrounds
This is inheriting the same set of changes a couple of the recent updates have, namely proper local caching of custom images. This functionality got a minor update yesterday to fix an issue with repeately browsing for the same image, but it's not a big deal on either of the current wallpapers using it.
Saturday, April 30, 2011
Thursday, April 28, 2011
KF Hearts v1.11 & KF Flames v1.16
- Bug Fix: Better handling of repeated custom image browsing
This fix applies to both products, and both are a side effect of the image caching that went in last week. Basically, the preferences were keying off of the filename to determine when to reload, but if the image was cached it was repeatedly using the same filename, so that's no longer valid. This meant that if you browsed repeatedly for a custom image, it wouldn't reload it properly until you reapplied the wallpaper.
That's awkward and no good, so it is fixed now in both cases. In addition, the image caching now stores the original size and ratio of the cached image, so the locket hearts should behave a bit better now.
This fix applies to both products, and both are a side effect of the image caching that went in last week. Basically, the preferences were keying off of the filename to determine when to reload, but if the image was cached it was repeatedly using the same filename, so that's no longer valid. This meant that if you browsed repeatedly for a custom image, it wouldn't reload it properly until you reapplied the wallpaper.
That's awkward and no good, so it is fixed now in both cases. In addition, the image caching now stores the original size and ratio of the cached image, so the locket hearts should behave a bit better now.
Wednesday, April 27, 2011
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.
- 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.
Monday, April 25, 2011
Thunderstorm Live Wallpaper v1.5
- New Feature: Randomize colors
- New Feature: Selectable background image
- Update: Higher res cloud art
- Update: Better background art
- Update: Better Xoom performance
- Update: Better blending (less color banding)
- Update: Higher res icon/thumbnail art
Quite a big list of changes there, but most of them are all in the name of getting Thunderstorm to hold up better on a large screen. Especially with the cleaned up artwork, new backgrounds, and blending improvements I think it's worlds better than it was previously on a Xoom or similar device.
We had a request to be able to randomize the color of the lightning bolts, so that's in there now -- the color dice get rolled every time a bolt strikes. In addition, we made a couple of different background images instead of just the single one that was available before. Pick your favorite!
- New Feature: Selectable background image
- Update: Higher res cloud art
- Update: Better background art
- Update: Better Xoom performance
- Update: Better blending (less color banding)
- Update: Higher res icon/thumbnail art
Quite a big list of changes there, but most of them are all in the name of getting Thunderstorm to hold up better on a large screen. Especially with the cleaned up artwork, new backgrounds, and blending improvements I think it's worlds better than it was previously on a Xoom or similar device.
We had a request to be able to randomize the color of the lightning bolts, so that's in there now -- the color dice get rolled every time a bolt strikes. In addition, we made a couple of different background images instead of just the single one that was available before. Pick your favorite!
Friday, April 22, 2011
Friendly Bugs Live Wallpaper v1.25
- New Feature: Butterflies cast shadows!
- Update: Two new backgrounds!
- Update: Higher res icon/thumbnail art
- Bug Fix: Custom background disappearing upon reboot
The new backgrounds are Creative Commons images with some minor photoshopping, and look quite good I think. Credit for Driftwood goes to L.C.Nøttaasen, and credit for Tree Stump goes to Aah-Yeah.
Ladybugs is inheriting the cached custom image support that yesterday's posts are talking about as well, so that should behave all around better. In addition, butterflies now have shadows! This is the classic old-school Quake 1 squashed-model style of shadows, which works pretty well here due to the simplicity of the butterfly form. :)
- Update: Two new backgrounds!
- Update: Higher res icon/thumbnail art
- Bug Fix: Custom background disappearing upon reboot
The new backgrounds are Creative Commons images with some minor photoshopping, and look quite good I think. Credit for Driftwood goes to L.C.Nøttaasen, and credit for Tree Stump goes to Aah-Yeah.
Ladybugs is inheriting the cached custom image support that yesterday's posts are talking about as well, so that should behave all around better. In addition, butterflies now have shadows! This is the classic old-school Quake 1 squashed-model style of shadows, which works pretty well here due to the simplicity of the butterfly form. :)
Thursday, April 21, 2011
Flames Live Wallpaper v1.15
- Bug Fix: Custom backgrounds disappearing on reboot
- Bug Fix: Switching to 'orange' hotspot works properly
- Update: 'reset to default colors' now resets hotspot as well
- Update: Higher res icon/thumbnail art
This is inheriting the image caching that just went into Hearts as well. Basically, when you select a custom image, we're saving a resized version of that image locally so it doesn't matter if you delete it or remove the SD card or what have you. Otherwise it leads to a lot of user confusion about why their background didn't show up properly.
Somehow I'd missed this previously, but due to the way the logic worked internally reverting back to the default 'orange' flame image didn't work properly once you'd switched away. After a reboot it was fine, but it didn't take affect immediately. That's fixed now.
- Bug Fix: Switching to 'orange' hotspot works properly
- Update: 'reset to default colors' now resets hotspot as well
- Update: Higher res icon/thumbnail art
This is inheriting the image caching that just went into Hearts as well. Basically, when you select a custom image, we're saving a resized version of that image locally so it doesn't matter if you delete it or remove the SD card or what have you. Otherwise it leads to a lot of user confusion about why their background didn't show up properly.
Somehow I'd missed this previously, but due to the way the logic worked internally reverting back to the default 'orange' flame image didn't work properly once you'd switched away. After a reboot it was fine, but it didn't take affect immediately. That's fixed now.
Subscribe to:
Posts (Atom)