- 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.
Tuesday, June 29, 2010
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.
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.
Angelfish!
Should be in the next Aquarium update, along with a touch sensitivity fix and a few other small things. A pic from the modelling program:
Monday, June 28, 2010
City at Night v1.0
Going back to my "Beautiful backgrounds, but better" philosophy, this wallpaper takes a gorgeous image of Kuala Lumpur at night and animates the clouds and the slow-shutter-speed traffic streaks. It's quite pretty and I'm very happy with the results!
Galactic Core v1.52
- Bug Fix: Smoother home-screen scrolling
- Bug Fix: Better enable/disable of the orientation sensor
I spent a substantial amount of time trying to problem-solve the orientation sensor option's battery usage, and while I did get the wallpaper to enable/disable the sensor more properly, the battery usage screen still reports very high usage by the wallpaper when this feature is enabled. I almost wonder if this is a bug, as even though I'm requesting the default sensor update frequency (which should be the same as the UI is already using, meaning it shouldn't cost any extra work), it seems much too responsive for that. Maybe default and ui speed updating is broken on my Incredible? Changing it seemed to make no difference at all to responsiveness or battery usage.
This update also included the removal of a 33ms delay when getting touch updates. This was actually sort of intentional, as it was inherited from Synergy. For whatever reason this was necessary in Synergy to avoid huge framerate hits when you touched the screen. As part of a wallpaper, however, it seems like the touch thread is the same one that's doing home-screen swiping as well, so that 33ms delay was making swiping from one screen to the next less responsive feeling. A stupid bug, but that happens sometimes.
I have gotten a couple from folks saying this update flickers for them sometimes, but it's rock solid on my HTC Incredible. I received a logfile from one user that didn't have anything suspect in it, and am currently wondering if it's only on a specific handset.
- Bug Fix: Better enable/disable of the orientation sensor
I spent a substantial amount of time trying to problem-solve the orientation sensor option's battery usage, and while I did get the wallpaper to enable/disable the sensor more properly, the battery usage screen still reports very high usage by the wallpaper when this feature is enabled. I almost wonder if this is a bug, as even though I'm requesting the default sensor update frequency (which should be the same as the UI is already using, meaning it shouldn't cost any extra work), it seems much too responsive for that. Maybe default and ui speed updating is broken on my Incredible? Changing it seemed to make no difference at all to responsiveness or battery usage.
This update also included the removal of a 33ms delay when getting touch updates. This was actually sort of intentional, as it was inherited from Synergy. For whatever reason this was necessary in Synergy to avoid huge framerate hits when you touched the screen. As part of a wallpaper, however, it seems like the touch thread is the same one that's doing home-screen swiping as well, so that 33ms delay was making swiping from one screen to the next less responsive feeling. A stupid bug, but that happens sometimes.
I have gotten a couple from folks saying this update flickers for them sometimes, but it's rock solid on my HTC Incredible. I received a logfile from one user that didn't have anything suspect in it, and am currently wondering if it's only on a specific handset.
Friday, June 18, 2010
Aquarium v1.55
- Update: Higher res background images
- Update: Localization into French, Italian, German, Spanish
The biggest change here is actually the default (blue) background. The original source image wasn't high res enough, so I had to go looking for alternatives -- a surprisingly time consuming process, as the backdrops for Aquarium require a fairly specific camera angle and layout. I did find a good candidate, and while it needs a bit more touch up think it's a solid improvement to the overall sharpness.
The other backgrounds already had source material of at least 1024x1024 in size, so they're not appreciably different.
This is in testing now, and will likely be uploaded Sunday.
- Update: Localization into French, Italian, German, Spanish
The biggest change here is actually the default (blue) background. The original source image wasn't high res enough, so I had to go looking for alternatives -- a surprisingly time consuming process, as the backdrops for Aquarium require a fairly specific camera angle and layout. I did find a good candidate, and while it needs a bit more touch up think it's a solid improvement to the overall sharpness.
The other backgrounds already had source material of at least 1024x1024 in size, so they're not appreciably different.
This is in testing now, and will likely be uploaded Sunday.
Subscribe to:
Posts (Atom)