The development process of a new VIC-20 demo

Greetings to everyone, once again! As you can see, Countercomplex wasn't destined to become a one-post wonder, despite the six-month gap between the first post and the second.

[A photo of a VIC-20 running the demo]

What broke this wonderful silence was my urge to tell something about my latest creation, a Commodore VIC-20 demo called "The Next Level", released at the Assembly Summer 2008 demoparty a week ago. The demo ended up second in the oldskool demo competition, the winner of which (albeit with a relatively small margin) was Byterapers' 486 PC demo called "Renaissance". There were four demos in total in the competition, and mine was actually the only one for an 8-bit platform.

I'm not hyping "The Next Level" as the best thing the VIC-20 demoscene has seen since "Robotic Liberation", as it is just one step towards something greater. There's nothing in the final product that hasn't been witnessed before -- actually, there aren't any rasters or realtime effects at all. Instead, what makes this production important was the development of a set of development tools that will hopefully shorten the creation cycle of future VIC-20 demos.

First of all, the link to the video capture on YouTube. I'm also embedding it here in order to maximize the accessibility for the ADHD internet generation:

Of course, you can also go to the page of the production and download the actual VIC-20 binaries. A h264.mp4 video file (16 MB) prepared by the Assembly organizers is also available for download.

The five years in between

"The Next Level" is my first actual VIC-20 trackmo after Robotic Liberation, which won the oldskool demo competition at Assembly 2003. By "trackmo" I refer to a demo that does not consist of separate memory-resident "parts" but constantly loads new material from the disk. Just like Robotic Liberation, The Next Level uses a disk drive but runs without memory expansions. That is, we have the good old 5120 bytes and 1024 nybbles of RAM available.

After finishing Robotic Liberation five years ago, I decided that I'm never going to do certain things manually anymore. A large percentage of the development time was wasted in loader-linking, that is, making sure that all the required resources get loaded in the memory just in time. Finding small slots of free RAM, splitting chunks of code and data so that they fit in these slots, possibly reordering some previously allocated areas, etc. were clearly something where automation would be much more sensible.

I also felt that I had already reached everything I could on the VIC-20 platform. On one hand, I wanted to move on to a more extreme platform where technical exploration would still be possible (like Sinclair ZX81 or Atari VCS), and on the other hand, I wanted to move on to a slightly less restricted environment where I could concentrate on the content instead of technical details. I released some small demos for the Commodore 64, but the platform didn't really respond to my needs at the time (as it proved to be more os less just as demanding as the VIC-20).

I was also thinking about trying some "PC" stuff for a chance ("PC" referring to all the (semi-)modern 32/64-bit platforms in general). There are some appealing aspects in "PC", like the virtually endless amount of processing resources (even with dumpster-dived hardware) and the possibility to slip away from the chosen set of restrictions if the art demands it. However, "PC" requires a larger amount of initial work, and using "PC" also always feels a little bit "lame" because of the unreachability of certain hard-core values as well as the absence of the strong statement of using an 8-bit platform.

The post-technical level

A kind of enlightenment arrived to me in 2007, as I was watching some demos from some Russian Spectrum groups I had already adored for a couple of years. Groups such as Cyberpunks Unity, Inward and Skrju have, in my perspective, evolved beyond the usual "technowanking" stage often associated with the harder-core branches of the demoscene. In the new "post-technical" level, the hardware platform is no longer primarily used for bragging but for self-expression, just like in "real art".

[A screenshot of Your Song Is Quiet by Inward

Perhaps the two most important realizations for me were the following ones:

In August 2007, I released "Impossiblator 3", a ultimate "technowanking" piece revealing some previously unused hardware tricks. After this, opening the door to the post-technical level became an important goal in my VIC-20 work.

Development tools

Although I had done some initial planning already in 2007, the actual development work of "The Next Level" and the related custom tools didn't start until Summer 2008.

The most important tool that needed to be made, naturally, was the automatic linker-builder system that would liberate me from manual loader-linking.

[A part of the build log generated by Bob20]

"Bob20" is a Python script that gets a bunch of assembly source files that are divided in "chunks" using special directives. Inter-chunk dependencies and positioning constraints can be separately defined for each chunk. The linking process is based on a special chunk type called "SC" or "StreamChunk", which are executed in a chronological order by the VIC-20-based stream interpreter routine. Bob20 attempts to find an optimal position for each chunk so that it can be loaded as early as possible. In the final loader stream produced by Bob20, the loader is synchronized with flag commands that basically say things like "wait until we have reached frame 123".

Another important part of the demo, of course, is the animation system, consisting of a couple of "PC"-based tools written in C (namely, an SDL-based graphics editor and a rawdata-to-sourcecode converter), and of course, a VIC-20-based decompressor/player routine. The editor was named "Brickshop32" after the native VIC-20 graphics editor I had created five years ago for drawing the still graphics for Robotic Liberation.

[A screenshot of Brickshop32]

While the original Brickshop is a combination of a character mode editor and a pixel editor, BS32 is "only a pixel editor" and thus only stores the bitmap and color data. The character allocation task is left for the post-processing tools. In addition, BS32 supports a drawing mode I've dubbed "1bpcaa" (1 bit per character, anti-aliased), which is taken advantage of in the stream format.

I already used the "1bpcaa" concept in some of my 2002-2003 work ("Impossiblator 2", "Robotic Warrior"). The basic idea is to store pictures in a 1-bit-per-character fashion and to render them context-sensitively -- that is, the shape of a "zero" depends on its upper, lower, left and right neighbor.

[A text editor showing a piece of the source code

The BS32 converter, while converting animation frames, basically first tries to represent the frame in the "1bpcaa" format and then uses bytes and nybbles to "patch" the result. It may also ignore the 1bpcaa phase completely if it is not suitable for rendering the frame. At least a dozen different combinations of algoritmhs are attempted on each frame, and the method producing least data is chosen.

Much of the development work went to these development tools rather than the actual creation of content and native code. But I'm sure that the percentage of the tool development is going to diminish dramatically once the tools reach a certain level of maturity.

The Next Level

I decided quite early that the basic visual style of my demo would be similar to that of Robotic Warrior: a very limited number of effects, no raster tricks at all, simple silhouette-based graphics, cartoon-like characters and a shameless use of a "traditional early 1980s video game look". This was a kind of antithesis to the boundary-pussing effect demo I had made a year before.

The speech synthesizer and the music player are mostly derived from those in Robotic Liberation. The synth may even sound worse to some ears because I decided to only assign a single melody channel and the volume register for it (instead of the two+volume in RL). I didn't want to cut out any of the drum and bass tracks this time, but I don't know whether this was a wise choice or not.

The process of creating the actual content was quite rapid (apart from finding the voice parameters which was as tedious as always). Most of the content was actually made during the last week, and I also finished the demo unusually early (on Monday, while the compo deadline wasn't until Thursday).

As for the concept, I didn't want to get too far from the "winning PWP style" this time, despite having a totally new set of tools. The singing speech synthesis, the audiovisual style, the story and the humor are all there. Some have even argued that "The Next Level" is actually too close to Robotic Liberation in how it looks and sounds. However, there are also some things that I hadn't tried before, such as the brief "surrealist" parts. Also, I've deliberately put in far more hidden references and alternative ways of interpretation than ever before, but I'll leave them to the audience to find out.

The most entertaining part of the development process was creating the graphics. It seems that I managed to find a graphics-making concept that works for me better than anything anything I've tried prior to this. Sketching the silhouettes with "big living pixels"; using characters for finetuning the sketches; drawing backgrounds with big color blocks, almost like legos; importing some small bitmaps from the outside world, etc. etc. Not too much pixel-level work, but still enough room for perfectionist satisfaction. Overall, quite an enjoyable experience, and I hope someone (apart from myself) likes the resulting visual style.

The future

As it would be a pity to only use the development tools for a single demo, I've already decided to use them for something more. The tools will still improve a lot, as I've been planning to support a couple of general-purpose effect routines and new compression schemes.

Despite taking a step towards the "non-technical", I still have some technical ideas I'd like to try out. Audio streaming is one of them. I don't want to reveal much about it yet, I just mention that it is probably going to replace the five-year-old speech synthesis routine altogether.

I also need some actual audio tools because I don't want to hard-core all the sound in assembly code anymore. A flexible audio tool would also provide a much more satisfying means for musical experimentation, and that's something I think my musical output really needs at this time.

I have been planning to release a totally different VIC-20 demo on the next Alternative Party held in October, so look forward for it.

There are still so many things that haven't been tried out yet.