The Lab

Spending Your Cache Wisely

Tue, 30 Aug 2011 12:09 GMT

Back in the day, computers were much simpler things. They had a CPU and they had some memory. Getting data to/from memory took a fairly reliable amount of time, and when optimising you’d just try to make sure that memory speed wasn’t the block in the pipeline that caused your application to slow down. Today however, things have changed, primarily due to the fact that CPUs have gained speed at a much faster rate than memory has. Where a CPU might go up in speed by 10x over a few years, the speed of the memory it’s paired with might go up by just 3x, making it become a much larger culprit for slowing games down…

The hardware solution to this is the use of caches – a small amount of super fast (and pricey) memory that sits in between the main CPU and RAM. A cache is made up of a set of small cache lines (usually 128 bytes) that at any point in time represent some 128 byte block of main memory. Cache lines can be flushed back to RAM (writing back any changes to the memory they represent), and read from RAM (refreshing or loading a new cache line from memory). It’s the hardware’s responsibility to keep the memory and the cache in sync, and make sure the bits of memory of you want to fiddle with are in the cache.

Nowadays when you read/write memory you’re really reading/writing what is in the cache. This is exceedingly quick (generally on the same scale as the cost of a few instructions). However, if you attempt to read/write data that isn’t in the cache, the CPU must stall, flush a bit of the cache that’s not been used for a while back to memory, and replace it with the memory you want to read/write. It’s not uncommon for the cost of accessing memory that isn’t in the cache to be 30x the cost of your average instruction!

So lets jump straight into some code…


struct Person
{
       char Name[58];
       int FavouritePrimeNumber;
 
       Person() : FavouritePrimeNumber(0) { Name[0] = 0; }
};
int NumPeople = 0;
Person GPeople[1000];
 
Person* AddPerson(const char* name, int favourite_prime_number)
{
       strcpy(GPeople[NumPeople].Name, name);
       GPeople[NumPeople].FavouritePrimeNumber = favourite_prime_number;
       NumPeople++;
}

This type of code should be fairly familiar to any games programmer. We’ve got a nice big buffer to store people in (in this case their name and favourite prime number). The AddPerson function simply inserts a new entry and increments the NumPeople counter. In this case I’ve conveniently made the Person structure be 64 bytes, so we can fit 2 people in a 128 byte cache line.
Now suppose our game wants to inspect a property of the people – what if we want to know the biggest favourite prime number…

int GetBiggestFavouritePrimeNumber()
{
       int biggest = 0;
       for(int i = 0; i < NumPeople; i++)
              if(GPeople.FavouritePrimeNumber > biggest)
                     biggest = GPeople.FavouritePrimeNumber;
       return biggest;
}

That all works fine. We iterate over all the added people and track the largest chosen number. However, this article is about memory access, so let’s look at how much data has to be read from memory. FavouritePrimeNumber is a 4 byte integer, so you might be forgiven for assuming that the total memory read is:
Total read (in bytes) = NumPeople * sizeof(int) = NumPeople * 4

Wrong! Think back to how a cache works. On a modern platform there is no such thing as reading a few bytes – if the data you want isn’t in the cache, you need to load the entire cache line. In hardware, the loop will actually do something like:
1. Read GPeople[0].FavouritePrimeNumber – load the whole 128 byte cache line containing GPeople[0] (costs about 30 instructions worth of time)
2. Read GPeople[1].FavouritePrimeNumber – it’ll already be in the cache as it’s in the same line as GPeople[0] (pretty fast)
3. Read GPeople[2].FavouritePrimeNumber – load the whole 128 byte cache line containing GPeople[2] (costs about 30 instructions worth of time)
4. Etc etc ....
When we want to read that 4 byte property of a person, we’re having to actually get the entire person from memory into the cache before doing so. As a result, from the hardware’s point of view GetBiggestFavouritePrimeNumber has to read 64 bytes just to get at that 4 byte integer!
So how to fix this? Well, it all depends on what you want to do regularly with your data. If in my game I very regularly needed to get the biggest favourite prime number from a large set of people then I might re-organise data as follows:

struct Person
{
       char Name[58];
       Person() { Name[0] = 0; }
};
int NumPeople = 0;
int GFavouritePrimeNumbers[1000];
Person GPeople[1000];
 
Person* AddPerson(const char* name, int favourite_prime_number)
{
       strcpy(GPeople[NumPeople].Name, name);
       GFavouritePrimeNumbers[NumPeople] = favourite_prime_number;
       NumPeople++;
}
 
int GetBiggestFavouritePrimeNumber()
{
       int biggest = 0;
       for(int i = 0; i < NumPeople; i++)
              if(GFavouritePrimeNumbers > biggest)
                     biggest = GFavouritePrimeNumbers;
       return biggest;
}

I’ve updated the code so the favourite prime numbers are stored in a separate array that I can iterate over nice and quickly (the technical name for this is SOA – structure-of-arrays, as opposed to AOS – array-of-structures). An int is only 4 bytes, which means the GetBiggestFavouritePrimeNumber now only has to load a new cache line for every 32nd person! Given memory was almost certainly the blocker in the pipeline here, my code now runs at roughly 16x its original speed!

The moral of the story - avoid loading data into the cache that you don’t need. Or to put it another way, spend your cache wisely :)

Two Uses of Voxels in LittleBigPlanet 2’s Graphics Engine - Anton and Alex at Siggraph 2011

Wed, 24 Aug 2011 11:30 GMT

Alex recently voyaged over land and sea to attend Siggraph 2011 in Vancouver. There he gave a talk entitled ‘Two Uses of Voxels in LittleBigPlanet2’s Graphics Engine’ as part of the Advances in Real-Time rendering in 3D Graphics and Games course.

The slides from that talk are now available to interested people, along with some other talks on the same subject matter too, from Bungie, Crytek, EA and DICE!

Using EBS Snapshots with Fog

Mon, 01 Aug 2011 12:41 GMT

Making use of Amazon for our server hosting gives us access to a host of neat features that allow us to do good stuff with our server environments.

We make use of a feature in Amazon called EBS (Elastic Block Store), you can think of it like a hard drive that exists on the network. While it is true there has been a lot of doom and gloom surrounding the EBS devices (http://aws.amazon.com/message/65648/) they can give you some advantages if you are careful how you use them.

One of those advantages is the ability to create snapshots and then create new EBS volumes based on those snapshots. Snapshots are quite quick to take, get saved in S3 (Amazons Simple Storage Service) and protect the data for long term durability. Using these techniques you could quickly copy data from one environment to another, for example from your production to staging environments. Or while snapshots are *not* a backup solution, you could snapshot a volume, create a new volume from the snapshot, attach it to a machine and take a backup from that volume. Allowing you to backup from a certain point of time without affecting the running of the main server (of course depending on your applications and technologies this may not be appropriate and you might need to take extra steps to ensure you got a consistent data backup).
Lets take a look at how snapshots can be taken, since server side we’re mostly a ruby shop, we’ll use ruby and the fog library (http://fog.io). Fog will be used to interact with the Amazon API.

The steps are:

Connect to the region in AWS where we want to snapshot the volumes

Get a list of the volumes to snapshot

Create the snapshots for each volume

Tag the snapshots with an id and the type of snapshot

First off we connect to AWS and get a list of our volumes:

# Load up fog and an internal library to handle loading in AWS keys require 'fog' require 'access_control' # Load in AWS IAM user credentials fog_creds = MM::AccessControl.new('production', 'snapshot') region = 'eu-west-1' # Make a connection to AWS @fog = Fog::Compute.new(:provider => 'AWS', :region => region, :aws_access_key_id => fog_creds.access, :aws_secret_access_key => fog_creds.secret) # Grab an unfiltered list of all of the volumes volumes = @fog.volumes.all

Now we’ve got the volumes we can run through them all creating a snapshot from them. Snapshots need a few bits of information:

Volume id to take the snapshot from

Description of the snapshot

At the same time we will assign a tag. The tags in amazon are handy identifying resources or adding other bits of information.

So using the volume list that we have taken, we could use the following sort of code to take snapshots of the attached volumes:

# Set up a time stamp for naming the snapshots t = Time.now stamp = t.strftime("%Y%m%d.%M%H") day = t.strftime("%Y%m%d") volumes.each do |vol| # Skip volumes with no attachment. Each attached volume will have a server_id next if vol.server_id.nil? description = "#.#" # Create a new snapshot transaction. It needs a description and a volume id to snapshot snapshot = @fog.snapshots.new snapshot.description = "#" snapshot.volume_id = vol.id # Now actually take the snapshot snapshot.save # To tag the snapshot we need the snapshot id, so reload the snapshot info to get it snapshot.reload # To tag something you need a key, value and resource id of what you want to tag # In this example we will demonstrate tagging just by creating a tag called "SnapshotDate" and applying the current YYMMDD to it. # This tag is slightly redundant as amazon gives you the time the snapshot was started at, but shows an example of how to tag @fog.tags.create(:resource_id => snapshot.id, :key => "SnapshotDate", :value => day) # To add more tags simply make another tagging call @fog.tags.create(:resource_id => snapshot.id, :key => "TakenBy", :value => 'snapshot user') end

Awesome, we can now take snapshots. Our next step is to clean this code up, put it into a script and run it on a regular basis. Now we’ve got a service that is creating snapshots for us every hour, we quickly notice that our snapshot count is growing quickly, we need to clean up old snapshots.

We might decide that we only want to keep the last 8 hours of snapshots, and that everything else before that isn’t required. To clean up the snapshots we’d want to:

Connect to AWS

Get a list of all the snapshots

Check the time the snapshot was created at

Delete it if it is over 8 hours old

# Assuming we have connected to AWS and have a @fog connection object # Also we assume that as part of our snapshot script we decided to tag the snapshots as hourly # Grab the hourly tags, we do this by applying a filter against a tags search tags = @fog.tags.all(:key => "SnapshotType", :value => "hourly")

Now we can load the snapshot information for each of the tags, check the time, and delete if required:

# Time limit in hours time_limit = 8 # Current time t = Time.now tags.each do |tag| # The resource_id of the tag equates to a snapshot so we can load the snapshot information snapshot = @fog.snapshots.get(tag.resource_id) # Using the current time and the time when the snapshot was created we can work our out the age of the snapshot age = t.to_i - snapshot.created_at.to_i hours = age / 60 / 60 # Finally delete the snapshot if it is too old. Deleting a snapshot requires the snapshot id if hours > time_limit @fog.delete_snapshot(snapshot.id) end end

This example code should then remove all of your old snapshots. Again we’d want to clean this up, put it into a script and have it running on a daily basies.

In a future post I’ll talk about how to use these snapshots to create new EBS volumes in the same, or a different, AWS account.

Doing exactly the right amount of work

Mon, 25 Jul 2011 14:57 GMT

The other day I was writing some code that needed to build up a list of strings in a large file, and identify any duplicates that occurred. On average, the file would contain about 10000 unique strings, and I’d be looking at finding at least 500 duplicates per string. That means that throughout the parsing of my file, I’d have to add about 10000 strings to the list, and probably do about 5000000 lookups on them. This needed to be a fast process…

This blog entry is about an awesome trick that Mr Alex Evans taught me when I went and asked him for advice about this problem. It’s such a good lesson I thought I’d write it up and shove it on the blog. I’d come up with various ways I could approach this – hash tables, maps, binary trees, specialised string trees and couldn’t pick how to attack it. His advice was that if an algorithm can do anything at all that you don’t need it to do, it’s probably slower than it needs to be.

A perfect solution to a problem will do exactly what it needs to – no more, no less. That way you know that even if the code isn’t perfectly optimised, it’s not spending time doing things it doesn’t need to. It occurred to me that even nature follows this approach – a perfectly evolved creature for some scenario will be exactly as good as it needs to be at things – anything extra is a waste of valuable resources. Cheetahs don’t run at 150mph because 70mph is enough! Clearly it’s a good way of thinking of things, so I set about this approach for my string searching.

First, my requirements:
I only ever add to the list – I never remove

I never need to extract any sorted data from it or anything fancy like that

I never need to iterate over the list

I’m going to be doing on average 500 times more lookups than I am adds, and the majority are likely to be successful (i.e. they will find an entry)

The strings themselves will always be in memory (as they’re loaded when I load the file), so they don’t need copying when adding

I have loads and loads of memory to burn!

I started off with a std::map, which could do:
Adds, gets, deletes

Any sort of types for the key and value, with any sort of comparison function

Easy iteration of the list

Easy extraction of sorted data from the list

Automatically manages memory allocation

Clearly the map does way too much – it supports lots of operations I don’t need, and can deal with any arbitrary types, whereas I just need a null terminated string for a key and a single unsigned int for the value. To cut a long story short, after several rounds of following Alex’s advice, I found myself with:
A custom hash table – uses a very simple 64 bit hash algorithm on the string, then uses the bottom 20 bits as an index into a table

Each entry in the table is a list of strings, their full 64 bit hash, their length, and their corresponding unsigned int.

This means my lookups can identify mismatches very fast – only in the event of 2 strings having exactly the same hash and length will I need to do an actual strcmp to verify they’re identical. The odds are I’ll end up doing 1 strcmp per lookup

All memory in the table is allocated linearly in one big mega chunk (which gets bigger if it really has to). This avoids lots of dynamic allocation, but prevents me being able to delete things.

Specialised to deal with strings + unsigned ints – doesn’t handle arbitrary class types at all

It’s only 150 lines of code

The result – parsing my file and doing all the string lookups goes from 22.5s to 1.8s.
Anyway, the moral of the story and the lesson this blog post is all about:

If an algorithm is capable of more than it needs to be, it’s probably doing more work than it needs to!

Shaun and Vivi’s project

Tue, 04 May 2010 11:28 GMT

Shaun and his partner Vivi have embarked upon a new art project!

These photos are an ongoing project that extends our interests first developed in a series of video/gallery installations begun in 2005. We’re fascinated by the potential for confusion, discomfort and other emotional responses to environments (and images of environments) that blur the distinction between actuality and simulation. In these photographs we’re using commercially available doll’s house furniture, which are carefully painted, composed and lit, combined with other “found” bits and pieces.”

Tetris on the ceiling: chapter 1

Mon, 19 Apr 2010 14:29 GMT

Mm is excited to be moving towers soon, to a new shiny office inside a new shiny tower… and in the new tower, for reasons too pedestrian to recount here, the boring standard office ceiling tiles are being replaced with clear acrylic ones. This, of course, is awesome. But in what particular way?

Over a few cocktails and glasses of champagne at Guildford’s entirely un-legendary and slightly creepy The-Shining-esque hotel-bar-blue-light-travelling-salesman-horror-venue ‘The Mandolay’, the Molecules put their heads together. ‘What’, slurred Paul ‘Aggie’ Davis, ‘about adding coloured lights above the tiles?’

What indeed! I feel a lab project coming on…

A little drunken 3 am googling session later, whilst contemplating how one might wire up and control 2000 ceiling tiles with coloured lights, I discovered this rather wonderful chip: the Allegro A6281.

Are all my dreams answered?

PWM brightness controller with constant current LED output stage? CHECK.

Serial input of data to reduce number of wires? CHECK.

Really simple to wire up because I’ve forgotten all my electronics? CHECK.

Easy to solder…. oh wait its surface mount only.

Never mind! It was late, I was drunk, details like circuit boards et al can be sourced later. Next: LEDs! Oh wait, no-body seems to want to supply LEDs to me in Europe, much less tell me which of the bewildering LED selection available on the whole of the internet’s six billion pages to order. Curses.

But then… America saved my ass. Specifically Macetech and their oh-my-god-it-was-made-for-me-surely-this-is-too-good-to-be-true, shiftbrite product.

Basically, shiftbrite is a cute little, 1 inch by 1inch, mini prefabricated circuit board with a little RGB LED and one of those Allegro chips all wired up and ready to go. On two of its edges are six pins, just like the ones you plug PC cpu fans into on your motherboard, to allow you to chain them together like fairy lights. Then you plug one end into a COMPUTER MACHINE, some JUICY FAT POWER, and it can control all the lights to be any colour you want. Witness 81 one of them gaffer taped to an ikea coffee table. so much win, we had to have them.

At this point, excitement was brewing. Ideas were flowing. If we could light all 2000 tiles of our ceiling under computer control, we’d essentially have a huge crazy RGB display on the ceiling… we could animate it in any way we wanted, we could run movies on it… we could play games on it… tetris or pong across the ceiling. If someone broke the build, we could put a red light explosion above their desk. What else could we do?

An order for eight was made, and duly despatched. Maplin was raided for parallel port bits, my dodgy soldering iron was dug up, and this entirely safe monstrosity was created:

(Where Aggy found a pc with a working parallel port in 2010 is another story – but that’s what IT managers do, right? Find stuff that no-one else can find. It’s a kind of genius) The plan was, rather than using a fancy microcontroller as macetech advise, we’d plug eight chains of LEDs into the eight data pins of a linux based pc’s parallel port, and then use all the power of the pc to generate and play ‘awesome stuff’ over the internets.

A few lines of dodgy C later, we had the first 8 lights up and running:

Tune in next time, when I actually plug in for the first time, the first chain of 100 lights:

(despite epic temptation, unfortunately LBP work has prevented me from having time to try it. But oh, my blog reading friends, you’ll be the first to know when we switch on… well second I guess, we’ll know first!

Adventures in Austin at SXSW

Sat, 27 Mar 2010 16:00 GMT

Whilst some Molecules were out in San Francisco at this years Game Developers Conference, I was a lone ranger out in the not-so-darkest-depths of Texas. Every year, Austin plays host to South by Southwest (SXSW) - a huge festival merging the worlds of music, film and interactive in one big melting pot of win. I was mostly there for there for the Interactive bit (SXSWi), to discover what’s cooking in the land of the internets and maybe discover some new stuff. It’s nicknamed spring break for geeks.

So, what is hot? What’s buzzing in the land of the internets? Commence Tom-rant-rabble! :)
Probably the most significant thing I noticed at SXSWi was the use of geo-location services Gowalla and Foursquare. I’m sure many of you have heard of these before, but for the benefit of those who haven’t - they’re both essentially games which work using your GPS-enabled mobile phone as you move around in your day-to-day life. When you reach a destination, you can choose to “check-in” there, thereby showing your friends where you are and what you’re doing. There are gameplay elements too: Foursquare lets users who check-in often to a location become “Mayor” of that location, and Gowalla displays leaderboards of each location. With Gowalla you can also pick up virtual items or drop them in places - some virtual items are even redeemable for real-world discounts or services.
The thing about SXSWi, is that there is such a high concentration of geeks in one place, it’s the perfect testing ground for services like Gowalla and Foursquare. It was four years since Twitter “hatched” at SXSWi, and 3 years since it’s potential was realised by the masses there - mass live tweeting of events as they happened.
There was a real sense of Gowalla and Foursquare picking up some speed at SXSWi, so many people were using them that they became a truly viable way to meet new people, see where the hotspots were in town and what people were saying about talks, venues and gigs. The most memorable moment came when I saw a girl walk straight to the front of a queue at a venue, approach the bouncer and show him a virtual wristband displayed on the screen of her iPhone (something she could have been given, or unlocked through a series of challenges). “I’ve got this wristband, can I get in here?” she asked - “Oh yeah, you need to be in the VIP section over there” the bouncer replied.That was pretty awesome. And there weren’t just wristbands - there were other virtual items being dropped around town, exchangeable for their real world counterparts. Someone got their mitts on a digital camera!

The connection between virtual world and real world items/people/places was made regularly throughout SXSWi. If you wanted to exchange contact details with anyone, you could simply use your smartphone to scan the QR code on the event pass around their neck. This instantly loads a webpage on your phone showing who they are and how to contact them. A host of other products and services were using QR codes to make the connection between physical and digital. And it even looks like Facebook may be integrating them soon too.

It’s a pretty hectic schedule at SXSW - the hour-and-a-bit long talks run from 9am to 6pm with any one session having up to 27 other talks running at the same time (you have to choose your talks wisely!). And there’s plenty of stuff going on in the evenings too :)

Amongst the talks I enjoyed most were Jonathan Stark’s Hold the Cocoa (#holdthecocoa)- building web apps for iPhone. Many people are interested in building apps for the iPhone these days, but there are clear barriers to entry. Firstly, You need a license for the iPhone SDK and secondly, you need to learn Objective C to code the thing. If you’re primarily a web developer, that might not be too appealing. More importantly though - you’d be investing time and energy developing for the walled garden that is the iPhone. By building an HTML5 web app, you can easily port your code to any of the not-insignificant number of webkit enabled smartphones out there.
So, you make your HTML5 web app but how can you make it look and feel like a native iPhone app? Easy: jQtouch.
jQtouch is an awesome jQuery library available for iPhone which lets you rapidly develop iPhone web apps. It comes bundled with a whole host of super-easy-to-use and awesome features, like oooohhh-aahhhhhh animated CSS3 page transitions, super-simple ajax usage, customisable themes, support for offline caching, geo-location and plenty more. If you’re thinking about making an app for iPhone then *you need to check this shit out*!
The Part 2 of Awesome is PhoneGap (this is where geeks really start to drool). PhoneGap will bundle your web app in to a native app, so you can deploy your iPhone application to Apple’s iTunes Store. It’ll even let you plug in to the phones API so you can use, say - the contacts manager or camera. Epic win! I really enjoyed this talk, so mad love to Jonathan Stark (@Jonathanstark).
Oh, and If you know any similar Android or Symbian toolkits out there like jQtouch, let us know in the comments!

Other interesting talks included Beauty in Web Design (#beautyinwebdesign), a talk from Clearleft‘s Cennydd Bowles (@cennydd) - a throughly interesting talk about how web designers need to start thinking bigger and getting more emotional with our designs to engage audiences.
ActivityStrea.ms: Is it getting Streamy in Here? (#gettingstreamy) was a talk from Chris Messina (@Chrismessina) about the new Atom feed format for activity streams detailed over at activitystrea.ms.
Get Stoked for Web Typography with a highly enthusiastic Samantha Warren (@swarren), looked at basic principles of typography and showed use of @font-face in CSS3 (something I talked a little bit about following the launch of this here new Mm site). She rocked it.
Interactive Infographics (#interinfo) has a great panel showing off excellent examples of data mashup visualisations out there (try Mapumental, crimespotting.org and walking-papers.org). @jenniferconley shared some nice slide pics and notes, posted over here.
Gaming the Crowd: Turning work in to Play (#gamingthecrowd) was a really interesting talk by Andy Baio (@waxpancake) about how simple gameplay mechanics can be applied to websites to make them more fun and enjoyable for users. I really enjoyed the example from Panic on their blog showing how they improved customer service efficiency.
The Can the Real-Time Web be Realized? (#realtimeweb) Panel talked about some of the existing services out there right now which are making the most out of the realtime web and what you could be doing to take advantage of it too (In short: just go ahead and make webpages realtime, don’t create walled gardens, integrate fully with existing realtime services).
I thoroughly enjoyed the BBC’s Digital Planet Live Quiz. A special quiz edition of the Digital Planet show (broadcast on World Service and you can hear it on iPlayer), which had the audience interacting with the panel through a special web app made for the event. Apart from being a great laugh and damn good fun, I also came away feeling like other panel sessions were seriously missing a trick by not making more of audience interaction. I got to meet the team later a bit later on and they are a really fine bunch of people :)

I need to shout out to Tweeture too - such a fun idea from Pervasive Media Studio. Here’s a clip from the the Digital Planet team’s coverage of SXSW explaining Tweeture rather nicely and what it was all about:

I first noticed Tweeture, albeit a bit later on, at the thoroughly enjoyable Pervasive Games and Playful Experiences: Rendering the Real World.

Keynotes I went to included Evan Williams (@ev) talking about Twitter’s expansion with the announcement of the @ anywhere platform and Daniel Ek (@Eldsjal) talking about the future of music delivery, Spotify and it’s successes in Europe. Live graphical notetaking of all the keynotes was brilliant - read over the ones below for an insight in to all the keynotes at SXSWi.

Danah Boyd - Making Sense of Privacy & Publicity

Valerie Casey - The Designers Accord

A conversation with Evan Williams, co-founder and CEO of Twitter

Daniel Ek - The Future of Music Delivery

It was a busy week of rushing around seeing new things, learning new things, meeting great people, and ‘bumping’ with someone for the first time. If you’ve ever wondered about heading to SXSW - music, film or interactive - then don’t wait around any longer and get out there and go. It’s freaking awesome.

Anyway, I’m back with some handy new skillz, some energy from all the inspiration - plus I’ve had my never-been-to-the-U.S status officially removed. I was the biggest noob imaginable when I arrived. Now? Um, not quite as much :)

One Hour Fiction: Rain Patrol

Fri, 19 Mar 2010 15:29 GMT

I set myself a task last week: write 750 words every day. I have not succeeded. However I’m getting married in 8 days so I have an excuse I think.

The story “Rain Patrol” was my first effort under this short-lived regime, a piece of flash fiction written in an hour. It was inspired by this painting:

It’s called In The Rain and it’s by Vitaliy Smyk, a Ukrainian artist. It turns out that the painting itself was a two hour speedpaint, so it seems pretty fitting!

One Hour Fiction: Rain Patrol

For days, it had rained. He had forgotten when it had started and forgotten what being dry was like, becoming accustomed to the mud, the constant companion of damp and the sheer brown of his existence. And then, as suddenly as it always started, the rain had stopped. The clouds parted just long to let the twin suns of this barren, forgotten rock peek through to remind him they did in fact exist.

Three stinking months. That’s how long he had been here, this time round. He still wondered quite why he had signed up to return, knowing that the promises of forging new worlds and bringing hope to oppressed peoples were nothing but empty marketing drivel. Instead, all that awaited him was foot rot, tepid meals consisting mostly of rainwater and a near statistical certainty that he would return in one or more body bags.

His company of men lived in close proximity in what seemed to be a plughole for the whole planet. How did all the water drain here, from both the ground and the sky? Last week a mobile command post had been washed away. Three guys now missing – dead, really – after the building had been torn from its moorings and swept down the valley. He had heard them yelling for help on the radio, but what could be done?

Click me to read the full story, and a few others too.

Jesse Schell’s talk on the future of games

Tue, 23 Feb 2010 15:59 GMT

This is the most interesting/entertaining talk by far from DICE (wot Siobhan and I wos at last week)

Shaun’s iPod paintings

Thu, 18 Feb 2010 16:36 GMT

Shaun has been painting these incredible self portraits on his iPod touch - how? - using an app called Brushes.

I’d also like to use this opportunity to welcome Shaun back to Mm Towers, welcome home sir!