The brilliantly-programmed graphic demos of Assembly Summer

Digital Tools offers a selection of the demos on show at Assembly 2011 Summer. For the uninitiated, demos are short multimedia hits similar to music videos, originally intended to demonstrate the potential of a computer's media capabilities. Pushing the limits of specific platforms' processing power and limited memory made for an enduring and highly competitive art scene—procedurally-generated textures and chiptunes ahoy! Pictured above is my favorite so far, Fairlight and Alcatraz's Uncovering Static, programmed so elegantly that it fits in a 64kb executable file. That's roughly equivalent in size to one frame of the YouTube video of it embedded above.


  1. > programmed so elegantly that it fits in a 64kb executable file

    As always with these things it comes down to what software libraries (including those embedded in HW) they rely on. 64K of compiled C using lots of 3rd party OpenGL calls is one thing. Writing your own screen driver – something else entirely…

    1. Too lazy to look it up right now, but if this is anything like (or even is) the contests I remember from over a decade ago, the executable is self contained and the upper bound (64k) is usually part of the contest rules.

      I also seem to remember there are no drivers per se. It’s a combination of algorithmic generation and direct memory writes to the video card. The samples for the music would take up a lot of space of that 64k, the score itself not so much. Everything is compressed up the hilt and decomped on the fly.

      It’s extremely impressive and displays a range of expertise not many have.

      1. I’m not sure if the rules have changed much over the years but these days it’s a Windows PC running the demos so the vast majority of them write DirectX based demos.  Lets them offload a lot of the stuff to the library. It’s very impressive though.

        1. Yeah, I guess it has changed.

          I’m dating myself, but I remember demos when they were self-contained COM files (64kb limit on COM file size) running on DOS. It’s possible my memory is not perfect, and overlay files (remember those?) could be used for data and procedure calls…

          Damn, so much for my not looking things up. Looks like I have some Google in my near future.

          1. Those are still around. I was involved with a group doing bootable 64k demos less than ten years ago, and I saw some nice C64 demos from 2007 recently. So, not all of the demoscene has gone soft.

    2. There are a lot of competitions like this wherein the demo must be bootable. In other words, it has to be a single 64k binary that runs with no OS and no bootloader, and depends on nothing but the code included. Some of them ban using bios routines but allow special instruction sets like sse. Others restrict you to running on an actual first-generation 386 (or even a 286 and ban protected mode) but allow you to use the routines that are loaded from ROM on startup. It’s up to the person running the competition.

      It’s useful to note that these are holdovers from the days when the C64 was new, and there’s a certain segment of the demoscene that now falls into the domain of retrocomputing.

      I don’t know what the ruleset of the above competition is, but suffice it to say that you can do pretty damned impressive things in 64k with no bios routines if you are clever and have a lot of free time, even if what you do it on is an Apple ][.

    1. It is? Damn, that’s disappointing and nothing like the old Demo Scene I may be mis-remembering.

      1. Yep.  OTOH making DX do that with only a 64Kb base executable (and a metric ton of compression) is still very neat.   But yeah, they’ve moved on a lot from the days of Future Crew & Second Reality. 

  2. I’m, personally, more impressed with the stuff that doesn’t use external graphics libraries in order to do “impressive” things inside of “64k”. This was not done entirely inside of 64k. As mentioned, it’s 64k b of graphics library calls (be it DirectX, opengl, etc).

    I’ve seen some neat things in the past that would actually work on much lesser systems, and actually did write directly to the hardware registers rather than making library calls to do the heavy lifting.

  3. Yes, yes, the code is very cool, but “brilliantly” is an adverb, and shouldn’t be followed by a hyphen because there’s no need to clarify which word it is modifying.

  4. Geeze people, it’s an entire ruined city regrowing and morphing, rendered in realtime, with music, crammed into 64k. And you’re dissing it because it MIGHT be using external libraries? You have no joy in your lives.

    And how do you know the whole scene isn’t generated on the fly via the same kinds of raymarching effects people were doing 3d fractals with last year? It has a lot of the same feel as that once the city starts morphing, and those are pretty much just blasting pixels to a display buffer…

  5. Regardless of whether it’s done by calls, realtime, fly, thorax or mandible, it’s very pretty in an I-didn’t-know-I-was-longing-for-something-lost way. But it needs a bit more tension.

  6. To be fair, in order to create any demo that utilises the 3D acceleration of a graphics card then you must use Direct3D or OpenGL.  There’s no other way unless you write for a specific graphics card, meaning very few people would be able to run it.  It doesn’t make a lot of sense to go that route really, does it?

    The other alternative is to do the 3D plotting in software, but if you’ve ever seen OpenGL in software mode then you’ll know what a bad idea that is.

    This may not be the best 64k demo I’ve ever seen, but on a technical level the coders have nothing to be ashamed of.

  7. So putting aside the whole D3D vs self-contained thing – when I see demos like this, and others like Debris by farbrausch, what I really want to know is what the f**k are Valve playing at making me download 6GB for Portal 2?!?

    1. On a serious note…

      Demos tend to push the limits of the hardware they’re running on (although I tend to find it hard to be impressed by PC demos, I tend to pay attention to oldskool stuff).

      A 6 gig game has a lot of textures that don’t have to be generated on the fly, eating more CPU time – it can just shove the textures into the GPU. There’s plenty of other stuff along those lines, too. Basically, you could procedurally generate everything, but it would end up taking more resources, reducing the install base that can actually run it well.

  8. > There are a lot of competitions like this wherein the demo must be bootable. In other> words, it has to be a single 64k binary that runs with no OS and no bootloader, and 
    > depends on nothing but the code included.

    If it’s bootable and writing directly into graphics memory then, yes, it’s pretty stonkingly impressive :-).

Comments are closed.