this space intentionally left blank

August 20, 2009

Filed under: tech»innovation

Not So Literal

Android's swelling collection of "augmented reality" applications got a boost the other day when Layar hit 2.0. Layar's probably the most advanced example of its type, combining live video from the phone's camera with data overlays for local points of interest. Part of what makes Layar so interesting compared to its competitors is that it has an open API for developers to create their own overlays. I'm sure you're as excited as I am for the eventual branded or ad-driven layers.

This kind of thing is a deeply attractive technology just because it's so visceral--people love to consider the implications of digitally remixing (or obscuring) their surroundings. But the current fashion of doing so in a literal sense is probably a dead end. At the very least, it prompts a vision of annoying tourist hordes wandering around the city holding cell phones in front of their faces, like superstitious villagers waving the cross at their surroundings to keep the evil eye at bay ("evil eye" is actually not a bad term for the abuse of AR tech). Worse, to restrict the term "augmented reality" to that kind of hallucinogenic literalism misses the point, and squanders the potential of AR as a sixth sense by cramming it on top of our visual range. I'd argue that we've had augmented reality for a while now--and that it comes wrapped in a more appropriate level of abstraction.

Take Astrid for example. Astrid's another Android program--in this case, it's a to-do list/reminder system. On its own, Astrid lets you set timed tasks, tag events, and synchronize your reminders with Remember the Milk. But if you combine it with Locale, Android's location-sensitive alert system, now you can have reminders triggered by physical proximity, like entering the grocery store or coming home from work. Although there's no camera involved, and no sexy floating map, this is also augmented reality. Indeed, if you look through Locale's plugin selection in the marketplace, there's a wide range of intriguing possibilities: from waking your computer when you walk through the door, sending an HTTP request at certain locations, or keeping people posted of your location via Twitter or SMS.

Not to mention the concept of networked notation: really, I should be able to "tag" my current location and read tags posted by other people (see also: GeoBuzz or, to some extent, Ushahidi). This includes recommendations/warnings for nearby businesses, event recordings, historical information, and helpful hints ("Don't try the brown acid!"). It's the virtual equivalent of a message board, wherever you go, but sortable, searchable, and omnipresent. And that's the kind of sixth sense that's actually useful, because it gives you a local's situated knowledge no matter where you go.

If this still sounds kind of boring compared to the Virtual Light fantasy that Layar and other visual AR programs are pitching, that's because it is. But it's undeniably more effective than waving a phone around and hoping to spot a clue. Likewise, if I'm in Paris and looking for a good bakery, being able to see the relative position of my destination doesn't help me when the AR overlay neglects to mention that it's across the Seine. What I need in that situation is a good digital map--a less futuristic, but undoubtably more versatile form of augmented reality (and one that's available to anyone with a smartphone right now).

A while back, BMEzine ran a story (subsequently picked up all around the Web) on living with magnetic implants (note: link contains disturbing images). In this scenario, crazy people have neodymium magnets embedded in their fingers, giving them the ability to "feel" electromagnetic fields from computers, security sensors, and power cables. The author describes it as a relatively subtle perception, but one that gives access to a rich array of new information. To me, that's the model we should be using when building augmented reality applications. It's not about giving you a window into a garish world of digital overlays, but about simply providing context and knowledge in a given area.

Sometimes the best technologies are a lot less flashy. The cyberspaces of Gibson and Stephenson are a lot cooler than the textual Internet, but in a pinch I'm pretty sure which one would be more adaptable and innovative. So it goes with the augmented reality craze: when the dust settles, I think we'll find that we've been doing this in better, less literal ways all along. We're symbol-using creatures--abstractions are our friends. Let's use them.

August 10, 2009

Filed under: tech»activism

Is the Pushbutton Web Good for Activists?

The denial-of-service attack that took down several social networking sites (including Facebook, Twitter, and Livejournal) certainly seems to have caught some attention, especially after the revelation that the attack was primarily aimed at a political writer called "CYXYMU," which I assume makes more sense in Russian. Evgeny Morozov calls him the first digital refugee, and points out the very real danger that other digital activists could be silenced this way--not by direct attack, but by removal from social networks for terms-of-service violations (you know, for all the bandwidth they're "using").

It's in this environment that I've been thinking about PubSubHubbub, an HTTP/RSS-based push distribution system. Anil Dash calls it the start of the "Pushbutton web." Here's how it works, as far as I can tell:

  1. A content site publishes an RSS feed per usual, but includes in the metadata addresses of several "hub" sites that subscribers can use.
  2. After fetching the RSS for the first time, clients can send a message to one of the hubs asking to be notified of further updates via HTTP POST.
  3. Hubs take care of the dirty business of keeping up with feeds. Publishers can notify their hubs of new content by HTTP ping.
  4. When hubs are notified of new content by the publisher, they take care of sending it out to clients--thus distributing the publication bandwidth across many hubs, reducing load on the original content publisher, and reducing latency compared to polling models.
This is pretty cool stuff. At heart, it continues the trend of developing HTTP between servers as a high-level communication layer, and spreading the role of "servers" into clients to make them first-class citizens on the web, just as Opera's Unite was a system for creating a peer-to-peer web.

What interests me about all this is that it's potentially a really smart, high-level proxy/federation system, one that's built for the modern web, and that might have real implications for activists. Under PubSubHubbub, any given node in the distribution network can play multiple roles--a publisher or hub can also be a client, and vice versa. As this develops, it might be possible to build hubs that are capable of talking to each other to locate publisher feeds, thus adapting to outages or blocks--similar to the way that peer-to-peer protocols may share lists of working leaf nodes with each other upon connecting to the network for the first time. At the very least, it will be possible to enable realtime communication/distribution on a decentralized platform--one that's harder to block with a single rule, and can't necessarily be shut down by DOS attacks on the central distribution point.

Of course, right now, none of this is part of PubSubHubbub's plans. Right now, this is a technology for making sure that your shared items in Google Reader get pushed out to FriendFeed as fast as possible--thus fulfilling the golden rule of Web 2.0 technology: all the interesting stuff will be invented primarily to buff up the shiniest service (Twitter, Facebook, etc.) in the room. Indeed, this particular pushbutton protocol may never develop the way I'm hoping it will--and it probably doesn't solve the problem of DOS attacks entirely (seems like the original source is still vulnerable)--but it looks to me like the Internet zeitgeist is taking steps in the right direction. Potentially, that's good news for prospective digital refugees.

July 9, 2009

Filed under: tech»os

Chromatic Veil

I don't get it.

So Google is introducing a Linux operating system with a new windowing layer based on its Webkit browser, Chrome. It's the thin client reinvented for the HTTP age. I guess from Google's perspective this makes sense: the more they can do to convince people that the Web is a valid application platform, the lower the resistance to their browser-based services, particularly in the lucrative enterprise market. If nothing else, it works as a proof of concept.

That much I get. What I don't understand is: who is this for on the user end? It's not a substitute for a full-sized OS stack--the browser is still, even with HTML 5, incapable of supplanting many basic applications, like listening to MP3s or doing serious document editing. It's certainly not for people who really leverage their CPU power, like gamers or media producers. Perhaps some day it will be--but I remember this idea from when it was the JavaPC and the Audrey, and somehow it has never had quite the mainstream appeal that its developers assumed it would. Ultimately, thin clients seem to leave even the most undemanding users wanting, for good reason.

Is it for netbooks? Most people seem to be following that line. But then, netbook manufacturers have been offering stripped-down Linux installations on these machines since their introduction, usually with a decent browser (Firefox) included. Certainly both Canonical and Microsoft see netbooks as target platforms--there are Netbook Remix editions of Ubuntu, and a major selling point of Windows 7 is its ability to run on low-end hardware. Either way, if I install ChromeOS, I just get a browser. If I install Linux or Windows, I get a browser that's equally good (if not identical), plus all the native applications my poor eyes can stand. Why would anyone, much less a hypothetical Windows user, switch to the former instead of the latter?

Does anyone think Google's going to do a better job than Ubuntu has done in the Linux space anyway? Or that Canonical will sit by and let it happen? I'm not a real Linux fan, and even I will admit that they've developed it into a usable desktop alternative. Ubuntu is a competitor, no doubt, and I simply don't see what Google can offer that they don't already have--or won't develop in response. And make no mistake: this is as much a threat to traditional Linux as it is to Windows, or Google would have simply worked with one of the existing distributions.

So yeah: I don't get it. When the company introduced the Chrome browser, that made business sense. Google is so intimately tied to the technology of the web, they needed to have a hand in its development. A browser gives them a platform for standards-based HTML/Javascript, as well as a place to experiment and advocate. And while it's hardly taken the world by storm, it's been a reasonable success in a world dominated by IE and Firefox. But stepping into the OS space, in such a strange way--and forking Linux to do it--doesn't seem to have any such business advantage. It certainly doesn't seem to offer anything that a simple port of the browser wouldn't. Clearly, Google wants ChromeOS. But if you think about it, does anyone else?

June 15, 2009

Filed under: tech»web

A Surprising Depth

This weekend, the total number of posts on Twitter exceeded the possible range of a 32-bit number--

...hang on a second, and let's marvel at the sheer size of that. It is easy to forget that a 32-bit number is actually mind-bogglingly huge, since hey, there's only 32 bits. Remember, however, that bits are like the pennies on the chessboard in that old mind-teaser: each one doubles the size of the digit before it. So in binary, you may start out counting 1, 2, 4, 8... but by the time you hit your 16th bit the total is 65,536 and it just keeps doubling from there. 32 binary digits is enough to encode more than 4 billion: 4,294,967,295, to be exact. Even in the signed integer format Twitter uses, which reserves one bit for negative numbers, it's still more than 2 billion. That's a lot of work for only 32 bits.

Anyway! So the service passed the 2,147,483,649 mark this weekend with, hilariously, a post claiming ungrammatically that "The Tweets must flow" and linking to a lolcat--

...sorry, I have to make another digression here regarding the terminology in question. There's a widespread idea, encouraged by Twitter itself, that updates should be referred to as "tweets." This is, pardon my curmudgeonliness, really stupid. First of all, Twitter is nothing more than a microblog, and we already have a term for the basic units of a blog: we call them posts. Where Twitter primarily diverges from something like Blogspot is only in the speed and hothouse intensity of its ecosystem, and you can even see examples of this in people who write both long-form blogging and Twitter. The kind of person, for example, who writes polished, slightly-pretentious management advice on his or her blog will also tend to write polished, highly pretentious posts on Twitter. In my own case, it's more of a sidechannel for links and petty commentary, but the voice is not radically different.

For another thing: just because it's the Internet, you don't have to leave all your dignity at the door. "Tweets?" Really? Do you know how embarrassing that sounds, like when you're in the middle of an editorial meeting, and a bunch of middle-aged journalists start talking about the tweets they've written lately? Because I do, and it'll turn your hair white.

Right! Back on topic: Twitter passed the 32-bit overflow mark this weekend. Doing so is not just a landmark number, it's also a potential bug for Twitter clients coded to use only a 32-bit integer in their data structures. Of course, such clients are relatively rare: modern high-level programming languages often express their numbers in 64-bit formats (the range of which I find almost incomprehensibly vast). But older languages, such as C++ and Java, may default to 32-bit integers unless told otherwise--I remember learning them as "long" integers, which says a lot about the progress that we've made. Coders these days should know better than to use the int type for something like a Twitter post ID, but it's an easy mistake to make.

Sure enough, a few clients did not handle the overflow well. On the iPhone, Twitterrific began to crash for people. My favorite Android client, Twit2Go, also threw exceptions when it went to retrieve posts. I like Twit2Go quite a bit (it's fast and acts like a real Android app, with good long-press and menu-button behavior), so this was annoying.

But it was also an interesting study in distribution methods. The developer of Twit2Go started working on the problem on Saturday morning, soon after the problem surfaced. Five hours later, he uploaded the fixed version to the Android market, and it was immediately available for users. The developers of Twitterrific, IconFactory, were actually on the job even earlier: a Friday post on the company blog noted the bug, including details about a previous update that, unfortunately, had not caught all the errors. At 6PM on Saturday (almost exactly the same time as Twit2Go), IconFactory submitted an update to the App Store that fixed the remaining bugs. As of this moment, the free version has only made it through to end users this morning, and the paid version is still in approval limbo. Drama ensued.

The problem overwhelmingly faced by open platform advocates is that abstract dilemmas are hard to transfer into mainstream, non-geek experience. Try discussing DRM with the average person, or explaining the "shallow bugs" principle to them, and watch eyes glaze over faster than Krispy Kreme. But this is a great, easy-to-translate example of the walled garden problem: because control is centralized and accountability is non-existent, paying customers have been unable to use updated software for two days now, for no other reason than the arbitrary whims of a large corporation. No appeals, no alternatives.

To sum up: "binary numbers are very large, think twice before coining a neologism, and make sure you own your hardware." Not a bad range of topics for a service with a 140-character limit, but I suspect it lacks flavor by comparison. As usual, it's more interesting to write about Twitter than to write something interesting using it.

June 8, 2009

Filed under: tech»mobile

Electric Sheep

When I first got a cell phone, and for several years afterward, I stuck with the classic Nokia 6010, which is one of those phones that they now use on TV shows to indicate "low social status" for a character, like a cop or a high school English teacher. Even back then, the phone was practically a relic--no camera, monophonic MIDI ringtones, barely any MMS support, even. I didn't think there was any real point to those kinds of features. It's funny how fast I got used to them, not to mention all the other advantages, when I picked up a smartphone.

So last week I bought an Android Developer Phone (basically an unlocked HTC Dream/G1) to see how it suits me, and I decided to write a little bit about it here. After all, most of the reviews I've seen of the phone are from its launch, and don't take into account the improvements made since. Also, the vast majority of that commentary is from Professional Technology Bloggers, making it largely unsuitable for human consumption (my favorite: Jason Chen at Gizmodo gets the USB storage mode wrong (twice!), then writes: "pressing the power/end button, which you'd think would power up the screen, actually just hangs up the call." No, really? The end button ends the call, just like on every other cellphone ever made? Who'd've guessed?). This isn't a review per se, just some thoughts spurred by the device.

With this being the month that so many new phones are being released--the Pre, the N97, and the HTC Magic among them--why go with the old G1? The answer, like my botched attempt at origami self-portraiture, is threefold. First, I prefer hardware keyboards, and the Magic is touchscreen only. Second, although Palm's new OS looks intriguing, it also looks largely locked-down at the moment, and Symbian has the same problem. Android's hackability is a big advantage. Finally, I need a GSM phone for a variety of reasons, and the Pre is CDMA-only at the moment.

Another thing I've been thinking about since the reviews for the Pre started rolling in: building a platform based on AJAX with hooks into the OS is clever, but it's also short-sighted. After all, developers on any of Palm's competitors--iPhone, Android, and soon Qt on S60--have the ability to easily embed a Webkit view into a native environment, complete with hooks in and out of that view. I'm guessing within a year of the Palm SDK release, I'll be able to run WebOS apps on other smartphones, either via a dedicated emulator or clever tools like Oilcan, Jeff Sharkey's port of Greasemonkey to Android.

The Android's Dream

My first reaction to the ADP was that it's a remarkably solid device. It's mostly plastic, but it doesn't feel cheap at all. The one thing that jumps out, after reading commentary online, is how unobtrusive the "chin" is. The actual angle for the trackball area is only about 10 degrees--really very subtle. It quickly becomes obvious that for prolonged web browsing or interaction the natural way to hold the phone is very similar to a Sidekick, with the screen flipped up so that one hand can type or use the screen while the other supports the device and manipulates the trackball for fine selection. Going between the trackball, touchscreen, and keys is flawless, and each has its uses--Google's done a great job there.

The battery life is not fantastic, compared to S60 devices that are exceptionally frugal with power. I usually charged the Nokia E51 every three and a half days, when its power meter dropped to three bars out of seven. With similar usage, it looks like I won't have any problems making it through the day with the ADP, but I'll probably want to charge it every night, since I've been hitting around 40% by the time I go to bed. Luckily, it charges via standard USB cable, and I spend my entire day surrounded by USB ports, so I shouldn't have any problems.

Power drain's a very personal thing, however, and someone else's experience might differ. For example, I work in an office all day, usually in front of a computer with my webmail open. So I don't usually set the phone to fetch e-mail automatically--what would be the point? Likewise, I don't use GMail, so I've unchecked its synchronization option to save a little bit of energy. The radio is always the most expensive part of the phone, power-wise, and I try to be smart about how I use it. While I do a fair amount of browsing, checking Twitter, and (since Belle loves being able to send me instant messages) GChat, it's possible that I'm not pushing the battery as hard as others would.

Speaking of radio, though, one of the interesting differences in outlook between S60 and Android is the way they treat the data connection. On Nokia's phones, connections are discrete channels initiated in response to a request. So if you want to go online, the phone opens a connection, letting you know which radio is in use, or asking you which one you'd prefer. When you're done, it shifts the radio back out of packet data mode. Android, in contrast, is online all the time, whether it's using the connection or not. It'll switch to the WiFi if a known network is available, but otherwise keeps the packet radio warmed up for you. Apparently it doesn't require much power to let the radios idle this way, but it does take some adjustment to stop worrying about it.

Another radio note: I'm using the phone on AT&T, and since it's set for T-Mobile's 3G frequencies, I'm back on EDGE for the time being. I don't really miss the bandwidth so much as the response time: 3G connections have a lot less lag, which is noticeable when browsing and particularly so in an SSH session. A lot of mobile-optimized websites nowadays disguise this with some client-side Javascript, which is a nice touch, but they bring their own problems: Facebook's Android/iPhone site is very clever, for example, but it's much less functional than the low-tech mobile version.

To Live in Fear

For Windows Mobile or S60 users, the hubbub around tethering seems misplaced. It's built into those two platforms: plug them into a laptop, or pair them via Bluetooth, and the laptop can almost instantly go online using the phone as a modem. US carriers don't usually care for this, since they'd prefer to be able to charge twice for the same bandwidth, just because it's being piped to another machine. On the iPhone, when someone created an application for tethering, Apple pulled it from the store to keep AT&T happy, and a user can't get it from anywhere else. There's no option for consumers/hackers outside of the walled garden. When Apple adds the option to the OS itself, it'll probably in a way that enforces AT&T's bottom line.

Google also has an application marketplace on Android phones, and although they're not as arbitrary as Apple, they also don't allow tethering applications to be sold. But here's the difference: Google doesn't stop you from distributing Android packages outside their store, either via a connected computer or directly through the browser. So there's nothing to prevent me from installing TetherBot on my phone and using it as a web proxy (a poor man's tether), or running PdaNet for a slightly easier ride (technically-inclined users have additional options). This is the simple value of an open platform: the device is owned by the users, not by The Man.

The ADP, and Android by extension, reflects a tension between openness and ownership. Google ultimately profits from open standards, something it knows well and reaffirms at every opportunity. So while it removes offending software from the official marketplace with a wink and a nod to free development, it's hard to miss the way that almost everything on the device also connects back to Google. Contacts, calendar, maps, the ever-present search (which includes the address bar in the browser, doing dual duty as a Google search field with autocomplete)... all of these are feeding back into Google, and being fed from it. It's understandable to be a little paranoid about that.

As Bruce Schneier says, computing has always been about trust, and cloud computing hasn't changed that any. So how much can you trust Google with all the information that a mobile platform can provide to them? And really, how much choice do you have, even on other smartphones, without giving up many of the advantages of these devices? It's not like there's another, better local map search, or a webmail service that comes close to Google's offerings. It's probably not technically a monopoly, per se, but it does indicate just how much power the company has amassed. One day we may have to nationalize those guys, just for our own protection.

I've Done... Questionable Things

You can array smartphone platforms into a spectrum between two extremes: those that trust users, and those that protect them--protection being a synonym for "limit." The iPhone, for example, does not let users touch the filesystem or run multiple applications at once. I've seen this described as a way of safeguarding the experience: apparently, people find the idea of closing programs to be confusing. At the other end of the spectrum is Windows Mobile, which is ironically the most user-hackable of the consumer options. Everything's pretty much open to interference, and you can run as many simultaneous applications as you want. Android is not quite at that level, I think, but it's definitely at the more trusting part of the spectrum. What's I find interesting about this is that while defenders of the protectionist model claim that it keeps things simple for users, once you step out into more complex applications, it's actually a huge obstacle.

For example, thanks to the open development platform, I'm got ScummVM on the ADP. Loading my old Lucasarts games is as simple as hooking up the USB cable and dragging the data files onto the SD card. On a stock iPhone, there are no easy facilities to do this--ScummVM would have to have its own conduit for getting the information over somehow. Even on a jailbroken device, you've got to resort to hacks like SFTP. And the advantages of multitasking are obvious: if nothing else, location-based applications like Locale wouldn't be possible without it.

Ultimately, the protectionist model does an interesting thing: it conflates applications and data from the user perspective. The e-book formats used by Stanza and Eucalyptus might be exactly the same, for example. But you'll never be able to read your Stanza books in Eucalyptus, and vice versa. The applications and their files are inextricably linked. It creates a world where code is often just host for a single set of data, each locked in its own little cabinet. There's no real incentive for interoperability or standards, and the platform itself is training users not to expect any. Some people may prefer that, but I think it makes Jonathan Zittrain's warnings look a lot more prescient.

Anyway, apart from ScummVM and Locale, there's a lot of very nice software on Android already. I'm impressed with ShopSavvy, which finds prices online and locally based on product barcodes. ConnectBot and AndFTP are great for logging onto Mile Zero--the latter is especially a relief, since S60 never did get an SFTP client. There are a few augmented reality applications that show a lot of potential: SkyMap uses the compass, accelerometer, and location services to provide a live star guide, and Wikitude overlays the camera view with local travel information like something out of Virtual Light. I've been using Twit2Go for Twitter posting, and PicSay for image editing.

The built-in applications are largely great. Browsing, maps, and YouTube work pretty much as you'd expect. I do wish there were an easier way to connect Contacts and Calendar to their Outlook counterparts. Loading phone numbers from the latter required uploading a CSV file--it worked pretty well, but not something I really want to do on a regular basis. The one exception to the high level of quality is the POP3 email program, which is patently awful. It doesn't remember which messages are already downloaded, refuses to delete items from the server, and regularly fails to connect. I'm using K9, an open-source client, instead.

In general, the OS is sturdy and tasteful, but not flashy. One feature I do like a lot is the unlock screen: it presents a 3x3 grid of dots, and you draw a pattern between them as your "passphrase." Ironically, this is not terribly secure since, like all touchscreens, it eventually ends up with fingermarks all over it. If you don't wipe it down after locking it, the pattern is often still smeared across the screen, especially if you're a heavy trackball user. The notification shade is also pretty genius, and key to the multitasking implementation. Someone needs to invent a quick task switcher that sits in the windowshade, and then it'll be pretty much perfect.

Overall, I'm comfortable replacing the E51 with this phone, but I'm probably not going to get rid of it entirely. There are still uses where Nokia has the edge: real tethering, speed, battery life, and size among them. And I hope their steps toward open-source models, and their sense of corporate social responsibility, will provoke Google as well. After all, someone needs to do it.

May 26, 2009

Filed under: tech»mobile

Hope Phones

Joshua Nesbit's Mobiles in Malawi (now Jopsa) is a very cool bottom-up health development project: using a copy of FrontlineSMS and a bunch of cheap cell phones, it allows community health workers in Africa to network with patients and each other, producing more efficient checkups, patient-tracking, and emergency response. Nesbit says in six months, a hospital using this system saved 1,200 hours of staff time, as well as $3,000 in motorbike fuel.

Jopsa has now launched a side-project called Hope Phones, allowing people in developed countries to contribute, both ecologically and financially. The program takes in discarded phones, recycles them, and uses the cash from the recycling to buy multiple appropriate (read: cheaper, more durable, and longer-lasting) phones for health clinics. They even pay for the postage. It's a fantastic win-win situation, as Trackerblog writes: the recycled phones not only reduce the number going into a landfill, but they reduce the industry's dependence on "conflict minerals" like coltan and tin.

Americans and other developed nations throw away a massive number of cell phones every year. Recycling helps--but Hope Phones, I think, is even better. Something to keep in mind the next time I upgrade.

Update: Jopsa has a post about the progress made by the program since its launch a week ago.

May 14, 2009

Filed under: tech»coding

Tribal Procedures

Again, click in the window and press space to begin playing. This time, I've added player controls: arrow keys steer and move forward, A jumps and double-jumps, and holding Z while jumping will switch from strafing to turning. Press space again when you're done, to pause rendering and keep it from hammering the CPU.

This time, the landscape is made up of 16 procedurally-generated tiles, each colored differently so you can tell between them. I apologize if there's a pause while you load the page--the noise functions I'm using tend to lock Flash for about two seconds on my machine. There's also some primitive gravity operating on the stars that you can see at the beginning.

I'd been thinking about various game-related uses for this while working on it, and the frontrunner was a kind of "jetpack delivery service" that combined Tribes with Crazy Taxi--hence the control scheme. The problem is that A) it would require an enormous landscape, and B) I'm not really sure how to balance it. For a game like that, players need to enjoy the process of movement itself, while still being limited in ways that don't have a steep frustration curve. You could do it with platforming, but I'm not really sure this engine is well-suited for that kind of thing. More importantly, implementing it well would require building levels by hand, a process for which I probably don't have the tools or temperament.

It occurred to me tonight that a better setting might be underwater--like Seaquest, without the annoying dolphin voice. That would be ideal for use with procedural height and texture maps. It'd be a natural fit for the look of a voxel engine, while still providing a good excuse for fog. It'd be kind of a neat change from the usual genres. And it would bypass one of the pitfalls of doing a first-person game in Flash, which is that mouselook is expected but not really possible due to limitations of the plugin. So I'm going to fork the code and start playing with a different control scheme, as well as a different method of generating the heightmaps that provides a bit more natural variation.

May 1, 2009

Filed under: tech»mobile

Area Code 575

So you've gotten yourself a mobile device that does e-mail--a smartphone, Blackberry, tablet, whatever. Now, how do you let everyone know how important and technologically-savvy you are? The mobile signature line, of course!

This being DC, about half the e-mail in my work inbox contains the phrase "Sent from my Blackberry." "Sent from my iPhone" has yet to show up, but it's probably only a matter of time. And although I mock them, these postscripts are obviously useful as a way of preemptively apologizing for the short length, SMS-style spelling, and typos that inevitably result from text entry on a tiny keyboard. Or, as one Lifehacker post advises, maybe they're just lazy.

I actually try to keep my mobile messages grammatically-correct, but there's no doubt that my typical outpourings are a bit reduced when I have to tap my way around predictive T9. So while I wanted a signature line, I'd prefer something that's less branded, less bland, more... haiku?

Nine keys for typing
Brevity thus expected
Sent from my cell phone

What's your signature selling?

April 29, 2009

Filed under: tech»coding

Voxel Populi

Behold, the mighty voxel terrain engine:

Click on the Flash window to give it focus, then press space to start/stop the animation thread. The two numbers at the top are the framerate and the level-of-detail (LOD) constant. You can adjust the LOD, and thus the framerate, by pressing the [ and ] keys. The ' key cycles through three post-processing options: poor-man's light bloom, simulated drunkenness, and none.

I've been working on this in my spare time for a couple of days now, just as a kind of mental exercise. Also, the techniques that I figure out on problems like this could be useful for work--I'd love to do a scatter plot or density map of the US using this kind of approach. Finally, it's a chance to get back to the kind of frame buffer-centric graphics hacking that I used to do.

So why voxels? Well, for one thing, they're easy to debug. An engine like this works by casting rays out from the viewpoint for each pixel of the display, stopping when they intersect the landscape, and drawing a texture point at that position. The heightmaps are pulled straight from images that I can make in Photoshop (thus keeping my toolset fast and simple). There aren't any BSP trees or polygon normals to compute (usually). Voxel engines may have fallen out of popularity with professionals because they can't be easily hardware accelerated (although some coders hope that will change), but they have relatively few points of failure and mistakes tend to be pretty obvious.

Getting this to work was easy. Getting it to run at 30fps or more was a bit harder. A few notes:

  • Actionscript 3 is a surprisingly fast language with a nice built-in graphical library, but its methods for working directly with framebuffers are very limited. In C, I would have loaded the map data into an array and run through it with pointers, poking values into screen memory as I went. Actionscript, being a managed language, has no pointers, and its arrays kept giving me fits. When I did get the code running using data structures, it was often too slow, because the code had to be more complex (to add bounds-checking, casting, dereferencing, and index-manipulation). In the end, I went back to doing data retrieval using BitmapData.getPixel(). In comparison to array operations, getPixel offers two nice features: it fails gracefully when my rays overshoot the map, and it accepts floating point values. The end result is actually faster, even though getPixel itself is almost twice as slow as simple array lookup. As always, avoid premature optimization.
  • Likewise, I tried a lot of different methods to see if I could beat setPixel(), without any success. It's odd, but there doesn't seem to be any speed advantage to populating a ByteArray and then copying it into the BitmapData, either for the entire frame or for each column. And the bookkeeping's a lot easier this way.
  • You may notice that there's not much penalty for opening the SWF at full size. This is counterintuitive: voxels don't scale to high resolutions well, since they have to cast a ray for each pixel of the screen buffer. So figuring that it was always going to be pretty blocky anyway, this version renders internally to a 320x240 bitmap, then uses Flash's native scaling bring it up in size.
  • In fact, generally speaking, I try to write for the parts of the Flash API that are clearly implemented in native code. It just makes sense to let the VM do the heavy lifting. In this case, bitmap scaling and copying is very fast, and the blur filter is optimized for powers of 2. Put an 8-pixel blur on a 50% transparent bitmap copy, and voila! instant bloom effect with practically no performance penalty.
  • Actionscript may not have pointers, but some of the same rules apply. For example, property lookup on an object (dereferencing, if you will) is a lot slower than making a local reference variable. Also, creating objects (allocating memory) is expensive. I got a pretty significant boost early on by switching from "ray.x" to "rayX" for casting, initializing variables outside of loops, and storing references to object properties (particularly those behind two or three dot operators) whenever possible.
  • Most of the program is spent in a single loop, incrementing rays and checking for intersections with the landscape, so that's where optimization was really needed. I spent some time tweaking the operations there, but by far the most effective addition was LOD: effectively, lowering the accuracy of the ray as it gets farther from the viewpoint. Implementing level-of-detail alone was responsible for a 400% speed increase. It works by increasing the casting distance each time through the loop. To get a logarithmic increase, the increase is equal to the ray's length shifted to the right by a set number of places. When you change the LOD above using the [] keys, you're changing the amount of the bitshift. At 10, the ray is accurate out to 1024 units (which is the maximum view distance). On my laptop with the debug player, setting it to 7 (meaning that detail drop-off begins at 256 units) seems to be a good tradeoff between speed and accuracy. A setting of 5 or 6 is faster but with visible jumpiness. Below 5, some wacky (but fun) behavior emerges.
  • Another increase comes from being smart about the ray behavior. I render each column of pixels from the bottom up. Since the heightmap can only contain one height value, any given pixel's ray will never intersect the map in less distance than the pixels under it, so it can continue from the same X and Y coordinates as the previous ray, adjusted to a new height and vertical angle. Also, once a ray hits nothing but sky, all rays above it will do the same--so there's no need to bother with them.

Although it's simple, coding this was a lot of fun. The next goals are to add support for tiled heightmaps (for building bigger worlds), multiple landscape textures, and sprites. If the framerate would support it, I'd put a second, inverted landscape on the "ceiling" for creating more complicated structures. One thing I didn't anticipate was how much I like the look of the bold colors and gradients in the current "programmer art" texture--maybe that's a look I'd like to preserve. And of course, somewhere along the line, I'll have to figure out what I'm doing with it. Any ideas?

April 23, 2009

Filed under: tech»green

Juicebox

After almost two years, my laptop's 7-cell battery has gone from a total capacity of ~65Wh (watt-hours) to around 35Wh. That's a drop of about 50%, and translates to a run-time of just under two hours (down from four or five when I bought it). It sounds drastic, but it's not unexpected: lithium-ion batteries that are kept at room temperature should be expected to lose that much. And everyone should know at this point that batteries are wear-intensive items (hence my preference for user-removable/replaceable batteries when possible). But it's still a little shocking to see it happen right before your eyes.

So I really, on a very primitive level, wanted a new laptop battery.

I don't need one, mind you. Two hours is not uncommon for many new laptops. And this is part of why I bought the bigger battery anyway: there's more buffer against capacity loss. Moreover, I rarely use the machine unplugged. It's almost always either docked, or at work with the adapter plugged in. I simply suffer from the fear, similar to my chronic overpacking habit, that I might at a moment's notice need to work for more than two hours in the middle of a frozen, powerless wasteland. This despite the fact that I'm an urban creature who rarely travels more than 15 miles from a Krispy Kreme donut shop.

My actual behavior completely contradicts my consumer impulse. So why was my first thought to look at new batteries, instead of being glad that I bought the smaller power adapter? Consider the information I was given. When I open up Lenovo's power manager, I'm not presented with statistics on the percentage of on-battery use, or the average length of those sessions. I'm only told about the loss of functionality, not whether I need it, or if I really use it.

It goes without saying that this is very bad for greening efforts. And it raises the question of whether efforts like Lenovo's greening/recycling initiatives are really as sincere as they should be. Lenovo even includes a link for buying more batteries in its power manager software. Sure, they recycle the old ones for you. But did you need a fresh set in the first place? If they are really serious about reducing their environmental footprint, the information presented needs to be more reflective, even if it means they sell slightly fewer.

In any case, it's got me thinking about laptops and sustainability in general. This is not an idle question: laptop sales were up 21% in 2007, while desktops dropped 4%, and the gap probably increased in 2008. That's a lot of portable computers being sold--many with replaceable batteries and modular drives, but the majority a sustainability time bomb of non-upgradeable innards and custom-built parts. And then there's netbooks, one of the fastest-growing portable segments. Oh, sweet heavens, there'll be a price to pay for netbooks in the future. Their value as affordable technology is undeniable for helping to bridge to digital divide and reach new market segments. But ecologically, they're all the negatives of a laptop, compounded: cheap construction, proprietary parts, and marketed (within the nerd community, at least) as a convenience purchase.

The obvious solution is that laptops need to become more serviceable. This was one of the original goals of the OLPC project hardware (which was always pretty clever, even if the educational mission was less so), and it was an admirable one. But even this won't really be enough. After all, desktop computers have been generally user-serviceable for years, and yet most people never open then up, due to a combination of unfriendly design and (more importantly) a consumer culture that encourages a perception of computers as disposable appliances.

This has to change. It means that the design of upgrading--connectors, casing, and drivers--will need to be rethought, particularly with an eye toward the portable segment. I shouldn't have to recycle an entire laptop just because the CPU and GPU have fallen behind, for example. And I shouldn't want to. It's time to start building a culture of re-use in the developed world--Last Year's Model is a good start, but I don't think it goes far enough. Our values should demand at least a year of use (and more like five or ten) from our electronics, and require us to spend less money on shiny junk (ironically, it helps to stop reading the very tech/gadget blogs who have plugged LYM. Trust me, you're not missing much).

Finally, this cultural change applies to software as well--just from familiarity, I'm looking at you, PC gaming industry. Although there are other factors, a heavy driver of both upgrades and new purchases is the ever-increasing demand of game engines. Companies like Valve and Stardock that target older machines should be applauded for both the business savvy and the ecological impact of that choice. And those like Crytech, who seem to see it as their mission to justify expensive, cutting-edge rigs, should be ashamed. Have we learned nothing from the Wii and the continuing sales of the PS2? The bleeding edge may not be a sustainable path for game developmers after all, and it's certainly not sustainable for the rest of us, economically or ecologically.

Future - Present - Past