Past tense is evil

When talking about old video games and mature technology, it is quite common to use the past tense rather than the present one. People are more likely to say, for instance, that Uridium WAS a Commodore 64 game, than to state that it IS one.

In most cases, of course, this supposed mistake can be explained by the subjectiveness of the point of view. The C-64 hardware and software have obviously disappeared from the speakers' subjective world and are now something that belong entirely to their past.

Objectively speaking, however, stating that "Uridium was a Commodore 64 game" is just as wrong as saying that "George W. Bush was an American man". The statement about Dubya will not become valid until he either dies or changes his gender or nationality, and likewise, the statement about Uridium will not become valid until it is no longer possible to reconstruct the binary sequence that constitutes the Commodore 64 version of the game.

Yes, yes, but isn't this whole topic just meaningless nitpicking? How is the choice of temporal form supposed to matter so much?

Well, it is a known fact that language shapes the world, and a different choice of words promotes a different set of ideas and values. In my personal opinion, referring to a still-existing cultural artifact in the past tense promotes some quite ugly ideas, such as cultural disposability, planned obscolescence, pre-dictated consumption patterns and a general narrow-mindedness.

So, unless you deliberately want to promote these despisable and dangerous values of the dirty imperialists, you should definitely avoid referring to Uridium in the past tense.

Finding the sinners

Now that we have declared the sin, we need to find some sinners to bash and/or evangelize.

The first place where I looked into for sinful use of the past tense was, of course, the good old Wikipedia, the supposed mecca of objective and neutral knowledge.

In Wikipedia, I expected to find a lot of inconsistent use of temporal forms as well as many articles completely written in the past tense. However, I was positively surprised that it actually seems to prefer the present tense, at least for the more popular titles. For example, the Commodore 64 and Spectrum articles discuss the actual hardware platforms nearly uniformly in the present tense. There are still some problems, however, such as the VIC-20 article which uses the temporal forms inconsistently, but the overall state of the articles isn't nearly as bad as I expected.

Much more of this "past tense sin" can be found, surprisingly, on sites operated by people who actually play the old games, sometimes even with the original hardware. These people, some of which are clueless enough to refer to disk and tape images as "ROMs", often use the past tense even when referring to their favorite platforms they still use. I call these people "retro-morons".

The retro-morons

As I have already mentioned in an earlier post, "retro" is a swearword. Reading an old book does not make me a "retrobooker", or watching an old movie doesn't make me a "retrofilmer". Still, playing an old video game is supposed to make me a "retrogamer". In my opinion, the mere existence of such a category just reflects how immature the computing culture still is compared to many other forms of culture.

By using the past tense, retro-morons not only admit that they consider themselves reliving the past, but also promote the kind of thinking where objects are bound to their respective "golden ages", that is, the periods of time when they have been commercially exploited. Whenever the commercial lifeline of a product ends (after the magical finger-snap of some dirty capitalist pig), it moves from the "present tense world" into some kind of a "past tense" or "retro" world. In this strange imaginary world, the time is frozen still. No new things are possible with the "obsolete" technology anymore, no more fresh aspects can be found in anyone's creations. There's no creativity left, only endless collection, recollection and preservation.

The optimist in me hopes to see the "retro-moron" phenomenon as a temporary intermediate stage, a step towards the maturization of computing and gaming culture. In the future, I hope, old games and hardware platforms will become an integral part of our cultural heritage without being exclusively associated to certain periods of history. Just like it is possible to read a book written in the fifties without being a "fifties freak" or something, it will be possible for ordinary people to play an "eighties game" or to use an "eighties computer" without dwelling in the eighties nostalgia at all.

There's still much work to do before this stage can be reached, however. So, fire up your Interweb browser and start the holy crusade!

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.

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 Pouet.net 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".

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

• "Post-technical" demos don't need to push the technology: the platform doesn't need to look or sound any better than what it is. The Spectrum may look just like the Spectrum traditionally looks, there's no need to hide the color-block clashes in the visuals or the square waves in the music.


• Most "post-technical" demos seem to be technically based on an animation player. Inward's "Your Song is Quiet", for example, seems to be mostly doing primitive graphics operations (like pixel-plotting and line-drawing) in a pre-defined order. Of course, the platform dictates quite a lot about the graphical style and what kind of animation is feasible.

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.

"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.

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.

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-code all the sound in assembly language 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.