Double Helix is now an Android Experiment, and it’s open source, so you can take a look at how it works. Email me if you have questions about it. Code comments are sparse now, but I may add to them if there’s interest.
One part of what makes live wallpapers fun to design is that the camera isn’t expected to move all over the place (as is usually the case with games) and the scenery can therefore be quite limited. That gives me the opportunity to make approximations of effects that might otherwise be too taxing for a phone. For example, in Double Helix, the helix shape itself is what enables the thickness calculation in the shader from the mesh’s tangent vectors (as mentioned in my previous post).
Here’s my first new live wallpaper in over a year! Hopefully I’ll have a few more new ones coming out in the near future.
The neat thing about this one is that it has a customized shader for sub-surface scattering. This simulates a translucent, glassy sort of material in which light bounces around before it exits the surface toward the camera. Traditional methods of simulating sub-surface scattering would be too heavy for a modern phone. They involve calculating the thickness of the material relative to the light direction for each pixel on the surface. But I found a GDC talk from DICE about the fast alternative used in their Frostbite engine, and adapted that.
Their method involves baking local thickness into the model, which is an adequate approximation in most cases. However, the helix shape consists of a lot of long cylinders (some twisted), so the effect is broken as you look down the length of a cylinder and the light still acts like it’s passing through a thin section.
To get around this, I made sure my textures on the model are all oriented the same way in relation to the axis of the nearest cylinder. Then the shader can use the tangent vector as an axis vector to calculate how much to scale up the perceived material thickness relative to the light.
It has been way too long since Neon Microcosm got an update (almost 3 years), so I decided to do a complete refresh. I rewrote it using shaders that draw each cell in one pass with one texture lookup, instead of three passes like it used to with the OpenGL ES 1.0 fixed function pipeline. With the fill rate savings, we can afford to draw enlarged background blur, which looks more like bokeh.
I also added a animated, bump mapped background that fits in better with the depth-of-field look. And I dropped in the optional post-processing effects from Lifeblood (scan lines, vignette, and film grain). Here’s a before-and-after comparison.
Unfortunately, due to new rules Facebook is imposing and enforcing as of May 1, CheckIn will cease to function on that date. I have already removed it from the store. If you have purchased it since January 1, 2015, or if you feel you weren’t able to use it enough to be worthwhile, please log into Google Wallet and request a refund. I will approve all refund requests for purchases after that date.
I apologize for any disappointment. Facebook has a set of guidelines that third party apps must adhere to, and their newly updated guidelines will be enforced as of May 1. As of that date, all apps are reviewed by Facebook before they are permitted to function. The guidelines that CheckIn would likely be rejected for should I submit a revised version of it:
No duplication of functions already in the Facebook app. The basic task that CheckIn is used for is making a Facebook post with a tagged place. Since these functions are already in the Facebook app (although CheckIn tends to be a faster method to do this specific task), I think it is likely they would reject the app for it. I believe their intended use for posts with tagged places in third party apps is for situations where there is game involved (like in Four Square or some video game that involves geolocation) or when specific businesses are being promoted.
No auto-filling of Facebook posts. The auto-check-in feature in CheckIn could be seen as automatically creating a Facebook post without user input, which is strictly against the rules.
I feel either of these might be debatable, and there’s a small chance they could get approved, but I don’t want to risk the time investment to overhaul the app for the new API for a small shot at getting through.
Sorry again for any disappointment. I’m disappointed myself, as CheckIn was my first published software of any kind, and it has been exciting to see how many people have enjoyed it.
If you wrote to contact at cyphercove dot com recently, I apologize for the lack of response! I didn’t realize the email address wasn’t responding (and chalked up the lack of incoming email to the Thanksgiving holiday). It’s fixed now.
It’s been a long time since I did a new release! Too many projects at once…
This new one, Tunnel Blocker, provides a work-around for a problem on many Galaxy devices. The problem is that music apps that use the audio-tunneling feature will bypass music visualizer apps like Audio Glow. I found out about the cause of this issue from developer Haruki Hasegawa, and he has an explanation here.
Tunnel Blocker creates a music player in the background that is paused, but attempts to use the audio tunneling feature so other apps won’t. Give it a try if you have a Galaxy device haven’t been able to get Audio Glow to work consistently.
Now you may have noticed a similar issue on your Nexus device. This is a different problem, and I unfortunately don’t have a work-around for it. Haruki Hasegawa speculates it happens to apps that use the low latency feature in Android.
There’s a new Audio Glow update out that adds a swipe controls feature, as well as a new visualization that’s available as an in-app purchase. Android Police did a nice quick write-up about it. Here’s a video: