I’ve been working on version 1.1 for around a month now. Updating an app who’s primary goal is simplicity is challenging to say the least. The update needs to add substantial value to the app without destroying the very simplicity that defines it. I think I’ve managed to pull this off.

Version 1.1 introduces three new features:

1. Editor tweaks and settings

Something I overlooked for 32×32 was a coordinate readout. Counting pixels just became second nature at some point, and I kinda didn’t realize how useful it would be. All sorted out now. The text fades quickly fades away when there are no fingers on the screen so it doesn’t get in the way.

If you want to leave things the way they were there’s a setting to turn off the coordinate readout. There’s also a setting for turning off the auto-erase functionality. I use auto-erase very frequently, but I understand that it feels unintuitive to some. This way everyone’s happy.

2. Image tools

These tools manipulate the entire image. Again, the idea is to keep this simple, so I put some careful thought into adding just two image tools.

It’s always frustrating when you start drawing something only to realize you didn’t leave enough space on one side. Move Canvas lets you shift the entire image around. It wraps the pixels around the canvas so it’s non-destructive.

Clear Canvas, you know, clears the canvas. It’s not totally necessary, but I find that when starting to draw something I often go through several “false-starts” where I erase everything before settling on the right look. It also gave me an excuse to use a superfluous curl animation:

The Image Tools menu is accessed by shaking the device. I’m not a fan of “shake” in general, but it feels right in this case. Shaking the device accidently doesn’t cause any harm (it just brings up the menu), and the image tools aren’t accessed often enough for shaking to be an inconvenience. By using the shake gesture I can extend the functionality of 32×32 without cluttering the editor screen with infrequent (but useful) options.

3. Share on Twitter

This is the one I spent most of my time working on. I’ve had one or two people forward me their pixel art on Twitter, so I figured, “why not built the functionality right in?” 32×32 will upload your images to TwitPic, append them to your message, and post the tweet onto Twitter. It also adds a #32×32 hashtag to the tweet, which will allow you to browse all the images people have uploaded using 32×32. I’ve been very impressed with the stuff people have produced with 32×32, so I’m hoping you guys will continue to share your fantastic work on Twitter.

Finally, the ETA: 32×32 v1.1 is code complete. I just need to do some further testing before submitting it to Apple. So, maybe two or three weeks from now?

Check out the official page, or go straight to the App Store.

Happy pixel plotting!

To eat one’s own dogfood means to test an app by using it like a customer would. I had been doing this through the development of 32×32, but this last week was going to be a more concentrated approach.

I’m pretty pleased with the results:

While I realize I’m not the greatest artist, I think my work shows that you can put complex pieces of art together rather quickly with 32×32. I spent around 15 minutes on each piece, mostly done on my commute to university and back. Oh, and maybe a couple were done when I should have been paying attention during lectures too.

Really looking forward to seeing what proper artists are going to make with 32×32.

It looks like a lot, but each page has just a couple of lines of text at most. Users are more willing to digest several short snippets of information over fewer pages filled with “walls of text”. But trying to communicate even simple interactions with such little text is tricky. Originally (as you might be able to make out) each page was suppose to have an animated, screencast-esque image to go along with it, but that ended up being too much work for me to handle. Images and animations definitely help though. To keep the work manageable, I used fewer images and instead of animations I used static images which convey motion (a skill in itself).

Once I decided what to say, and how to say it, the next question was: do I really need to say it? Help screens should not discuss each and every feature of an app. It ends up being a very tedious user experience. A good rule of thumb is to teach users the basics, and to give them enough knowledge to discover the advanced features.

The final help screens for 32×32 was trimmed from the 7 pages I have up on the wall. I ended up using 4 help pages (covering 6 topics) with 3 images in all.

It was never going to work though. I decided that the minimum size of the canvas would have to be 32×32 pixels which, in order to fit on the iPhone screen, would mean a 10×10 px on-screen representation for each pixel. There’s no way you could accurately tap on a 10×10 px space on the iPhone screen. I gave the idea of a zooming/scrolling canvas a brief thought, but dismissed it due to being too fiddly. (A later prototype found this assumption to be true) But then the crosshair occurred to me. I’ll talk about exactly how the crosshair works in a later post. But the idea is what made me think, “maybe, just maybe, this’ll actually work.”

So one night, lying on the couch watching a re-run of America’s Next Top Model with my sister, I started working on the prototype. After an hour of hacking away at it I had something usable. And it worked. The rest, as they say, is history.

32×32 is my next project, and it isn’t a game at all. It’s a pixel art editor for the iPhone/iPod touch.

The mantra behind 32×32 (read as: “32 by 32″) is simplicity and usability. Basically, I took the idea of drawing pixel art and stripped it down to its core actions. After that I stripped it down even further. The resulting app is joyfully simple to use, but still pretty powerful.

(click to enlarge)

The canvas has a fixed size of 32 pixels across by 32 pixels down, thus the name. The drawing tools are simply pen, erase, fill and undo/redo. Full RGB support got the axe pretty early on. It would be clunky and pointless, and not about drawing at all. Instead, 32×32 provides 5 shades of grey, a neutral set of colours.

Clearly, 32×32 isn’t interested in being the ultimate pixel art editor. It would end up being bulky, complicated and slow to use. Instead, it is a quick and painless way to get all that pixel art goodness onto a digital canvas, wherever you are. The idea is that you’ll create pixel art on your iPhone, but more advanced work (such as animation) can be done on your computer.

Check out the 32×32 page for more details. I’ll be posting more about 32×32 on here, so stay tuned. The tentative release is July 2009 for only $0.99.

When I first implemented the drop shadows I talked about earlier, it wasn’t very promising. It looked good, but it caused a very noticeable drop in performance. Like, I lost 10 frames per second. Geomex didn’t feel as snappy as it used to. For a while I just decided to (err) drop the drop shadows, but then I decided, “what the heck, let’s get optimizing!”

I did a lot of good stuff. In this article I want to talk about how I optimized one function in particular: drawSubtile. A sub-tile is a quarter of each tile that the shapes are made out of. In this section of the function, we’re figuring out the coordinates for a sub-tile. The simple answer is that they start at (x, y) and end at (x+TILE_SIZE/2, y+TILE_SIZE/2). The twist is that we’ve got two variables, xflip and yflip, which swap these coordinates around on their respective axes. So, for example, if xflip=YES, then the coordinates are (x+TILE_SIZE/2, y) and (x, y+TILE_SIZE/2).

Here’s what we started off with:

    short int x0, y0, x1, y1;

    if (!xflip)
    {
        x0 = x;
        x1 = x + TILE_SIZE/2;
    }
    else
    {
        x0 = x + TILE_SIZE/2;
        x1 = x;
    }

    if (!yflip)
    {
        y0 = y;
        y1 = y + TILE_SIZE/2;
    }
    else
    {
        y0 = y + TILE_SIZE/2;
        y1 = y;
    }

    short int verts[] = { x0, y0,  x1, y0,  x1, y1,  x0, y1 };

It’s pretty much what you’d expect the code to look like. If the axis isn’t flipped, store the smaller value in index 0 and the larger value in index 1, otherwise store them the other way around. It’s simple to read, but actually quite slow. If-statements tend to do that. Of course, you never really put effort into eliminating if-statements because it’s just not worth losing the readability for an insignificantly minor speed boost. However, this is a special case. When a function is called more than 10,000 times a second and it’s running on a handheld device, every little speed boost counts!

So I set off to eliminate the if-statements still in disbelief that I was actually bothering to do this. Result:

    short int xx[] = { x, x+TILE_SIZE/2 };
    short int yy[] = { y, y+TILE_SIZE/2 };

    short int x0 = xx[ xflip];
    short int x1 = xx[!xflip];

    short int y0 = yy[ yflip];
    short int y1 = yy[!yflip];

    short int verts[] = { x0, y0,  x1, y0,  x1, y1,  x0, y1 };

I looked at my implementation and laughed. It’s completely correct, but it’s just so silly! The way this works is by exploiting the fact that a boolean (true/false) value can be used as an array index (where true=1, false=0). So if xflip is set, x0 = xx[1], which is the flipped value. Similarly for x1, we use the index !xflip (read as: not xflip, or the opposite of xflip) which, in this example, gets us xx[0].

It’s simple, it’s silly, but it worked really well. I actually felt a noticeable speed boost! My frame-rate counter proved this as well. I was pretty pleased.

I should have left it at that. But no, I just had to have another go at it. I knew I could do it just a little bit better. I knew further optimization wouldn’t give me a significant performance boost (see: Law of diminishing returns), but I had to do better. I had to over-optimize the solution. And so, an over-optimized solution was produced:

    short int xx[] = {x, x};
    short int yy[] = {y, y};

    xx[!xflip] += TILE_SIZE/2;
    yy[!yflip] += TILE_SIZE/2;

    short int verts[] = { xx[0], yy[0],  xx[1], yy[0],
                          xx[1], yy[1],  xx[0], yy[1] };

The previous solution eliminated if-statements. This one minimizes the number of assignments. I’ll leave it as an exercise to the reader to figure out how this one works. If you “got” the last solution, this one shouldn’t be difficult to figure out.

I stared at my code, stroked my chin, sipped my tea. I’d optimized, I’d over-optimized, and I finally concluded this couldn’t be optimized any more.

Here’s to another year of exciting releases!

(click to make them bigger)

I’ve also cut the price on Geomex once again to the super-cheap price of $1.99. Tell your friends, etc.

The Hiscores page for Geomex is also up. Of course, you can also check the scores from within Geomex. Some incredible scores have started trickling in! Hope to see more of this soon.

As usual, please let me know if you’ve got issues with the update or have suggestions.