• New hacks, Splitflap and Romanboy. There are some fun, physical-glitch behaviors in splitflap. Keep looking.

• Better detection of user activity on modern (ha) GNOME systems.

• Sonar now does asynchronous host name resolution.

• Vastly improved Unicrud and Z̧"̘̖̫̱̖͉̬͈̥͔̳͎̝͜͡A"͍̹̮̺͓̤̺̺̖̤̥̖͍͎̙̫̫͙̜L͉̹̙͎̻̱̳̦͢͞Ǵ̶̷̛̠̠͕̯͖͈̟̝̮ͅǪ̩͔̪̲͍̹̩͕̕͠͝ͅ support.

• Performance improvements on MacOS and iOS.

• The Android port is coming along nicely. It's not quite to the point where it's time for me to post an .apk file yet, but it's getting there. If you have an Android development system, please give it a spin and let us know how it works for you. xscreensaver/android/README.

• And, you know, other stuff.

XScreenSaver 5.31

• Three new hacks this time, GeodesicGears, BinaryRing and Cityflow. And I figured out a way to make GLPlanet not look crappy.

• All of the text-displaying hacks support UTF8 input (even if some of them, like Apple2, can't quite display all of the characters on output), and all text is antialiased, even on Linux. (This means Zalgo Star Wars, as noted previously). To make this work I had to add a UTF8 parser to my VT100 implementation. Like you do.

• The problems that MacOS 10.10 had with loading text and images are fixed. I still haven't upgraded but I think it should be working.

• The iOS app has a search field (pull down the top of the list).

• iOS device rotation completely stopped working when I was forced to upgrade from the iOS 7 SDK to the iOS 8 SDK, so I had to rewrite a bunch of stuff to get it working again.

  Let me know if you have an iOS device/OS combo on which rotation doesn't work, or things are scaled wrong (don't fill the screen, or are too big for the screen.) Good tests are "Apple2" and "Endgame". Do they orient properly when you rotate? When you rotate and then drag in "Endgame" does the object track your finger properly?

• A fellow named Dennis made some good but very preliminary progress on a port to Android, so there's now an android/ subdirectory in there. If you have an Android development environment installed, give it a whack and let us know how that works.

• At some point "shake to run a new saver" stopped working. It works when the saver list is visible, but not when a saver is running. I can't figure it out. If you can, send me a diff!

• I would like confirmation from someone running XScreenSaver 5.30 on on MacOS 10.10 that eventually the "there's a new version available" dialog appears, and then successfully downloads and installs 5.31. So if you don't download it manually, lemme know how that goes.

That's a lot of changes this time. But really I want to talk about GeodesicGears because it's awesome.

Most of the time when I write a new saver, it kind of percolates around in my head for a few weeks, and then I knock it out in a day or two. Not this one. The math on this one kicked my ass for like a month. There were a few times when I was completely stuck and the answers literally came to me in dreams. Not like visualization dreams or anything, but extremely literal, "I am typing, adding struct fields, adding for loops" dreams where I crack the problem, wake up, and think, "Oh hey, that's gonna work." Then I basically type it in. That doesn't happen to me too often, but it does happen with some regularly, and I really enjoy it when it does because if I'm expected to spend a third of my life motionless and hallucinating I might as well be doing something I actually care about with that time.

Anyway, a while back I posted some cool gear animations by TaffGoch. As far as I can tell, he built those by hand in Sketchup, based on the extensive research by Bugman123, who figured out the large set of 32-gear and 92-gear tilings of a sphere that "work", more or less. So I implemented most of those. (I haven't done the 182-gear models yet.)

There are still a bunch of numeric constants in my code to make these layout work, and it bothers me that those numbers aren't all derived from something basic in the model, but most of the layout is done computationally, as is Good and Proper.

So the interesting thing about meshing gears on a closed surface is that because the connectivity graph is neither directed nor acyclic, all possible loops have to be an even number of hops, or the gears bind: clockwise gears can only touch counterclockwise gears. If you look at the animations, you'll see loops of four gears touching each other but you can never see three. It's almost a map-coloring problem, I guess.

The sizes of the various gears have to match in just the right way (outer disc edges tangent to the surface of the sphere, the right set of discs touching and the others not); every gear has to have the same size teeth; and tooth size and radius imply the number of teeth on a gear, which also have to be matching multiples of the rest of the system. There are not always solutions to all of these constraints!

In fact, the 92-gear models don't technically "work". The phase errors build up, and sometimes you see gears that don't mesh properly. If it was a real object, it would bind after a few turns. This bugs me, but it still looks "right" most of the time.

Anyway. Another fun way of looking at the the chirality of meshed gears is, instead of thinking of them as clockwise and counterclockwise, think of them as magnets, with one flat face being positive and one negative, so "In" and "Out" have different polarity. You get the same layout constraints, because "heads" can only be adjacent to and touching "tails".

That's the idea behind Kenneth Snelson's model of the atom:

He discovered the 5, 8, 10, 14 and 18-disc layouts that work, and I tossed those into the mix as well. (His 32 disc layout is the same as one of Bugman123's 32 disc layouts, because it's the case where the 20-count gears and the 12-count gears happen to be the same size).

My thanks and apologies to all of my friends who have had to listen to me drunkenly babble about trigonometry over the last few weeks. (Or possibly years or decades.)