My woefully late roundup of stuff I’ve made continues with this project from August 2011. As long-term followers of this blog may recall, since mid 2008 I’ve been undergoing a long-term exercise of trying to keep up a jet-setting demoscene lifestyle without flying – and that can lead to some pretty creative journey planning. One such occasion was my Week Of Geek in 2011, a round trip taking in the Assembly demoparty in Helsinki, then down to Berlin (via the sleeper train from Malmö, which unexpectedly involved the train being loaded onto a ferry. A train on a boat! A train! On a boat! But that’s another story) for the first two days of Chaos Communication Camp before whizzing off by ICE to Cologne for the Evoke demo party.
All visitors to CCC received a r0ket badge – a USB-powered gadget equipped with a 70MHz ARM processor, a whopping 32Kb of flash, a joystick switch, and a Nokia-3310-stylee mono 96×68 LCD. Ostensibly, this way a way of providing people with name tags that were suitably illuminated for the night-time activities at the camp; in reality, of course, it was a geek toy to hack around with, and for me it was a perfect opportunity to earn some major geek points by being the first person to show one off to a demoscene crowd on the other side of Germany, while the camp was still going on. So, what sort of eyecandy can you do in two days with a low-res display, a joystick, and a comparatively-beefy-but-floating-point-lacking CPU? Wolfenstein 3D, that’s what.
The principle is the same as it was in the 286 days: set up your viewpoint as position somewhere on a 2D map; send rays fanning out from that point, one for each pixel column of the screen, until it hits a wall; and draw a vertical slice of texture corresponding to the part of the wall it touches, scaled according to how far away that is. I first learned of this back in my Uni days from Tristam Fenton-May, who designed a hardware implementation of the Wolfenstein engine for his final year project, and came up with a brilliantly oddball way to avoid having to allocate memory for a full display buffer: the whole thing would be rendered column-by-column on a CRT display placed on its side. Lovely.
My initial experiments with the r0ket board showed that the screen was laid out in a peculiar vertical arrangement of bytes, which was reason enough to steal Tristam’s idea and do my column-by-column rendering straight to the screen in one swoop. In hindsight, this was probably a bit silly – mingling the display routines with the 3D calculations resulted in some horribly spaghetti-ish code – but then again, I think we’re allowed a bit of spaghetti code in fun projects like this. And, in fact, the overheads of the r0ket system software meant that we only had around 2.5K to play with, so being frugal with memory was probably no bad thing.
The end result received 4th place in the wild demo compo at Evoke. The video presentation was a bit rushed, so apologies for the shakycam…