It was internally nagging me all summer that I ought to release something at Sundown, but apart from some brief excitement around a brainwave I had involving three iPhones, Javascript and some cardboard (which sadly didn’t work out in practice), it didn’t really amount to much. Then Evoke happened, and inspired me to decide that, in the words of Haujobb’s invitation, I should make a demo.

Or, to be precise, a Javascript 64K intro. Unfortunately, there was only one week to Sundown by that point, and in a classic case of demoscene project management fail, I spent most of that week building an audio framework, leaving about 24 hours to write the actual demo. The end result is 9K of rather-flaky-performing code, hastily improvised plinky ambient music, and dreadful coder art (except to the extent that I’ve ripped it off from Fairlight demos).

• Fake Plastic Cubes – online version
• Fake Plastic Cubes – download (10Kb)
• Fake Plastic Cubes on Pouet

Still, even if the execution this time didn’t work out, I think it’s been a worthwhile exercise in bringing pieces together. Jacob Seidelin’s PNG compression hack (where JS code is stored in a PNG image to take advantage of the compression, then unpacked on a canvas using getImageData) has created a bit of a buzz in the JS development world, but this is the first time it’s been used in an actual demoscene production (which is surprising, given how the demoscene is the spiritual home of size-coding hacks). Ben Firshman’s JSNES has been dynamically generating audio for some time now, ardently chasing the moving target that is Mozilla’s Audio Data API (with a trusty Flash snippet as a fallback), and Mathieu ‘p01′ Henri was experimenting with softsynths long before then. Not even my own code is safe from this cherry-picking exercise of doom – the 3D routines are a mishmash of Gallions Reach / Canvastastic (for the lighting model) and Antisocial (for the full scene / movable camera handling). Finally, node.js makes a cameo appearance, because having an actual web server on hand makes development go a lot smoother.

Put them all together and you have the ingredients for a delicious 64K Intro cake. This time it came out a bit half-baked, but I’m passing on the recipe in the hope that someone else can make it work:

• Fake Plastic Cubes source code / framework, on Github

Visit the Antisocial microsite…

With my characteristic lack of organisation, I found myself with two weeks to go to the Sundown party, having promised a demo release, and with nothing specific in the pipeline. So, I decided to take a chance and run with an idea that had been sitting on top of my “demos to write when I have more free time than I do right now” pile for the best part of a year. I had it all planned out in my head, right down to the soundtrack: a mysterious track from an unlabelled CD I picked up at a ZX Spectrum Orchestra gig in 2005 (which turned out to be Round, from their Clive Live^3 EP). A quick bit of permission-getting later, and I was at the point of no return.

I knew it would be an ambitious job, and a bit of a leap artistically and technically from my usual stuff. I pencilled in a rough project plan in my diary. I drew up storyboards. I read up on the maths that was too nasty to contemplate on previous projects. And shockingly enough, I actually enjoyed all of the above.

As it happens, browser technology (as far as the <canvas> element goes at least) has not moved on one jot in the last two years, so I was able to dust off the Canvastastic codebase and found it still pleasantly usable and not too affected by code rot. I gave it a slightly more OpenGL-ish API (within the limitations of my “someone at the pub described it to me once” knowledge of OpenGL) and patched up the more glaring omissions (like Z-plane clipping, so that you can have polygons going behind the camera. Proper frustum clipping would have been a better idea, so that I didn’t end up with it trying to plot 20000×40000 pixel triangles and sending Windows into a stroboscopic flashing fit and having to hack up a fix after the party. Macs are fine with it…).

The demo code was only half the job though; to handle the camera paths and synchronisation and the million other details where hard-coding wouldn’t cut it this time, I joined the big league of the demoscene by building a demo tool (still all in Javascript) that probably only I can understand. (It’s included in the final release, so have a play. I dare you.) As I didn’t have any meaningful experience in 3dMAX, or Flash, or Werkkzeug, or Quartz Composer, or any of the other things I really ought to have been using as reference points, it was a grand exercise in Making It Up As I Went Along. I’d almost forgotten how much fun it is to code that way, but naturally a fair few bad decisions came out of that as well. Firstly, it turns out that organising things around a timeline interface doesn’t really fit all that well; it means that every object and event is treated as independent of everything else, so things get a bit clunky when they have to share resources (such as lots of camera shots of the same scene). Looks like you can’t beat the good old boxes-and-arrows-all-over-the-place approach.

Secondly, and what probably comes as no surprise to anyone but me – Javascript is a bit horrible for building demo tools in. The demo itself, no problem – but for the user interface widgets I found myself constantly wishing for nice, sensible class-based inheritance. Yep, I know the language boffins will say that prototype-based OOP is more powerful, but I guess I’ve just had my mind addled by programming in the real world. I know of a few attempts to graft class-like behaviour onto Javascript, and that should probably be at the heart of any attempted rewrite of this. Alternatively, there’s a growing-but-not-quite-there-yet buzz around alternative scripting languages in the browser (just like there’s a buzz in the opposite direction for server-side Javascript), so perhaps it wouldn’t be out of the question to have a browser demo tool written in Ruby or Python. Or have the browser environment embedded in a ruby/python desktop app – at which point, why stop at browser demos? Could it be designed as a more general tool, where the browser is just one of many platforms that can be swapped in? It’s tempting. Onward and upward!

Download: Canvastastic beta_1 (20K, .tar.gz)

If you’re anything like me, you’ll probably be turning your nose up at having to download the thing just to see what the fuss is about, so I’m happy to oblige with some online demos…

• Boxes (demonstrates lighting and camera movement)
• Robot (demonstrates transforms and animation)
• and finally, the library source itself, for those wanting a spot of light bedtime reading.

• Canvastastic beta 0
• Tales From The Third Dimension – slides from the talk (PDF, 220K)
• Additional (pre-<canvas>) examples were taken from my 2004 demo Mooncheese

You shouldn’t have to wait too long for proper documentation, especially in view of the valiant effort Simon has already made. That Willison is a crafty one, as anyone who witnessed him pretending not to be a werewolf will testify. I borrowed his laptop for my talk, and within half an hour of getting it back he’d trawled through the code I’d left on it and more or less written up the complete API documentation – and promptly set about drawing diagrams to explain 3D coordinate transformations. Zero-day w4r3z, anyone?

(technorati fodder: barcamp, barcamplondon, barcamplondon06)