My first twenty years on the demoscene

Since I have been somewhat inactive in computer art for a while, I felt it might be a good idea to sum up the first twenty years of my demoscene career. Besides, my previous summary is already a decade old.

Back in 1994, I got involved in some heated BBS discussions. I thought the computer culture of the time had been infected by a horrible disease. IBM PC compatible software was getting slow and bloated, and no one seemed to even question the need for regular hardware upgrades. I totally despised the way how PC hardware was being marketed to middle-class idiots and even declared the 486 PC as the computer of choice for dumb and spoiled kids. I was using an 8088 PC at the time and promised to myself not to buy any computing hardware that wasn't considered obsolete by consumption-oriented people. This decision has held quite well to these days. Nowadays, it is rather easy to get even "non-obsolete" hardware for free, so there has been very little need to actually buy anything but minor spare parts.

In the autumn of 1994, I released a couple of silly textmode games to spread my counterpropaganda. "Gamer Lamer" was about a kid who gathered "lamer points" by buying computers and games with his father's money. "Micro$oft Simulator", on the other hand, was a very simple economic simulator oriented on releasing new Windows versions and suing someone. I released these games under the group title PWP ("Pers-Wastaiset Produktiot" or "anti-arse productions") which was a kind of insider joke to begin with. The Finnish computer magazines of the time had been using the word "perusmikro" ("baseline microcomputer") for new and shiny 486 PCs, and this had inspired me to call them "persmikro" ("arse microcomputer").

At that time, Finnish BBSes were full of people who visited demoparties even without being involved with the demoscene. I wanted to meet users of my favorite boards more often, so I started visiting the events as well. In order to not being just another hang-around loser, I always entered a production to the PC 64k intro competition starting from 1996.

(The demo screenshots are Youtube links, by the way.)

Of course, I wanted to rebel against the demoscene status quo. I saw PC demos as "persmikro" software (after all, they were bloated to download with 2400 bps and didn't work in my 8088) and I was also annoyed by their conceptual emptiness. I decided that all PWP demos should run on 8088 in textmode or CGA, be under 32 kilobytes big and have some meaningful content. The afore-mentioned "Gamer Lamer" or "Pelulamu" character became the main hero in these productions. PWP demos have always been mostly my own solo productions, but sometimes other people contributed material as well – mostly graphics but sometimes music too.

The first three demos I released (the "Demulamu" trilogy) were disqualified from their respective competitions. Once I had developed some skill and style, I actually became quite succesful. In 1997, I came second in the 64k competition of the Abduction demoparty with "Isi", and in 1998, I won the competition with "Final Isi".

My demos were often seen as "cheap", pleasing crowds with "jokes" instead of talent. I wanted to prove to the naysayers that I had technical skills as well. In 1997, I had managed to get myself an "obsolete" 386 motherboard and VGA and started to work on a "technically decent" four-kilobyte demo for that year's Assembly party. The principle of meaningful content held: I wanted to tell a story instead of just showing rotating 3D objects. "Helium" eventually came first in the competition. Notably, it had optional Adlib FM music (eating up about 300 bytes of code and data) at a time when music was generally disallowed in the 4k size class.

My subsequent PC 4k demos were not as succesful, so I abandoned the category. Nevertheless, squeezing off individual bytes in size-optimized productions made me realize that profound discoveries and challenges might be waiting within tight constraints. Since Unix/Linux I was starting to get into wasn't a very grateful demo platform, I decided to go 8-bit.

In 1998, there was a new event called Alternative Party which wanted to promote alternative demoscene platforms and competitions. The main leading demoscene platforms of the time (386+ PC and AGA Amiga) were not allowed but anything else was. I sympathized the idea from the beginning and decided to try my hands on some VIC-20 demo code. "Bouncing Ball 2" won the competition and started a kind of curse: every time I ever participated in the demo competition at Alternative Party, I ended up first (1998, 2002, 2003 and 2010).

Alternative Party was influential in removing platform restrictions from other Finnish demoparties as well, which allowed me to use the unxepanded VIC-20 as my primary target platform just about anywhere. I felt quite good with this. There hadn't been many VIC-20 demos before, so there was still a lot of untapped potential in the hardware. I liked the raw and dirty esthetics the platform, the hard-core memory constraints of the unexpanded machine, as well as the fact that the platform itself could be regarded as a political statement. I often won competitions with the VIC-20 against much more powerful machines which kind of asserted that I was on the right track.

In around 2001-2003, there were several people who actively released VIC-20 demos, so there was some technical competition within the platform as well. New technical tricks were found all the time, and emulators often lagged behind the development. In 2003, I won the Alternative Party with a demo, "Robotic Warrior", that used a singing software speech synthesizer. The synth later became a kind of trademark for my demo productions. Later that year, I made my greatest hardware-level discovery ever – that the square-wave audio channels of the VIC-I chip actually use shift registers instead of mere flip-flops. Both the speech synth and "Viznut waveforms" can be heard in "Robotic Liberation" (2003) which I still regard as a kind of "magnum opus" for my VIC-20 work.

Although I released some "purely technical" demos (like the "Impossiblator" series), most of my VIC-20 productions have political or philosophical commentary of some kind. For example, "Robotic Warrior" and "Robotic Liberation", despite being primarily technical show-offs, are dystopian tales on the classic theme of machines rising against people.

I made demos for some other 8-bit platforms as well. "Progress Without Progress" (2006) is a simple Commodore 64 production that criticizes economic growth and consumption-oriented society (with a SID-enhanced version of my speech synthesizer). I also released a total of three 4k demos for the C-64 for the German parties Breakpoint and Revision. I never cared very much about technical excellence or "clean esthetics" when working on the C-64, as other sceners were concentrating on these aspects. For example, "Dramatic Pixels" (2010) is above all an experiment in minimalistic storytelling.

A version of my speech synth can also be heard on Wamma's Atari 2600 demo "(core)", and some of my VCS code can be seen in Trilobit's "Doctor" as well. I found the Atari 2600 platform very inspiring, having many similar characteristics and constraints I appreciate in the VIC 20 but sometimes in a more extreme form.

When I was bored with new technical effects for the VIC-20, I created tools that would allow me to emphasize art over technology. "The Next Level" (2007) was the first example of this, combining "Brickshop32" animation with my trusted speech synth. I also wrote a blog post about its development. The dystopian demo "Future 1999" (2009) combines streamed character-cell graphics with sampled speech. "Large Unified Theory" (2010), a story about enlightenment and revolution, was the last production where I used BS32.

Perhaps the hurried 128-kilobyte MS-DOS demo "Human Resistance" (2011) should be mentioned here as well. In the vein of my earlier dystopian demos, it tells about a resistance group that has achieved victory against a supposedly superior artificial intelligence by using the most human aspects of human mind. I find these themes very relevant to what kind of thoughts I am processing right now.

In around 2009-2011, I spent a lot of time contemplating on** the nature of the demoscene and computing platforms, as seen in many of my blog posts from that period. See e.g. "Putting the demoscene in a context", "Defining Computationally Minimal Art" and "The Future of Demo Art" (which are also available on academia.edu). I got quoted in the first ever doctoral dissertation about demos (Daniel Botz: Kunst, Code und Maschine), which also gave me some new food for thought. This started to form basis on my philosophical ideas about technology which I am refining right now.

Extreme minimalism in code and data size had fascinated me since my first 4k demos. I felt there was a lot of untapped potential in extremely simple and chaotic systems (as hinted by Stephen Wolfram's work). The C-64 4k demo "False Dimension" (2012) is a collection of Rorschach-like "landscape photographs" generated from 16-bit pseudorandom seeds. I also wanted to push the limits of sub-256-byte size classes, but since real-world platforms tend to be quite problematic with tiny program sizes, I wanted a clean virtual machine for this purpose. "IBNIZ" (2011) was born out of this desire.

When designing IBNIZ, I wanted to have a grasp on how much math would be actually needed for all-inclusive music synthesis. Experimentation with this gave birth to "Bytebeat", an extremely minimalistic approach to code-based music. It became quite a big thing, with more than 100000 watchers for the related Youtube videos. I even wrote an academic article about the thing.

After Bytebeat, I had begun to consciously distance myself from the demoscene in order to have more room for different kinds of social and creative endeavours. The focus on non-interactive works seemed limited to me especially when I was pondering about the "Tetris effects" of social media mechanisms or technology in general. However, my only step toward interactive works has been a single participation in Ludum Dare. I had founded an oldschool computer magazine called "Skrolli" in autumn 2012 and a lot of my resources went there.

Now that I have improved my self-management skills, I feel I might be ready for some vaguely demoscene-related software projects once again. One of the projects I have been thinking about is "CUGS" (Computer Underground Simulator) which would attempt to create a game-like social environment that would encourage creative and skill-oriented computer subcultures to thrive (basically replicating some of the conditions that allowed the demoscene to form and prosper). However, my head is full of other kinds of ideas as well, so what will happen in the next few months remains to be seen.

The 16-byte frontier: extreme results from extremely small programs.

While mainstream software has been getting bigger and more bloated year after year, the algorithmic artists of the demoscene have been following the opposite route: building ever smaller programs to generate ever more impressive audiovisual show-offs.

The traditional competition categories for size-limited demos are 4K and 64K, limiting the size of the stand-alone executable to 4096 and 65536 bytes, respectively. However, as development techniques have gone forward, the 4K size class has adopted many features of the 64K class, or as someone summarized it a couple of years ago, "4K is the new 64K". There are development tools and frameworks specifically designed for 4K demos. Low-level byte-squeezing and specialized algorithmic beauty have given way to high-level frameworks and general-purpose routines. This has moved a lot of "sizecoding" activity into more extreme categories: 256B has become the new 4K. For a fine example of a modern 256-byter, see Puls by Rrrrola.



The next hexadecimal order of magnitude down from 256 bytes is 16 bytes. Yes, there are some 16-byte demos, but this size class has not yet established its status on the scene. At the time of writing this, the smallest size category in the pouet.net database is 32B. What's the deal? Is the 16-byte limit too tight for anything interesting? What prevents 16B from becoming the new 256B?

Perhaps the most important platform for "bytetros" is MS-DOS, using the no-nonsense .COM format that has no headers or mandatory initialization at all. Also, in .COM files we only need a couple of bytes to obtain access to most of the vital things such as the graphics framebuffer. At the 16-byte size class, however, these "couples of bytes" quickly fill up the available space, leaving very little room for the actual substance. For example, here's a disassembly of a "TV noise" effect (by myself) in fifteen bytes:

addr  bytes     asm
0100  B0 13     MOV AL,13H
0102  CD 10     INT 10H
0104  68 00 A0  PUSH A000H
0107  07        POP ES
0108  11 C7     ADC DI,AX
010A  14 63     ADC AL,63H
010C  AA        STOSB
010D  EB F9     JMP 0108H

The first four lines, summing up to a total of eight bytes, initialize the popular 13h graphics mode (320x200 pixels with 256 colors) and set the segment register ES to point in the beginning of this framebuffer. While these bytes would be marginal in a 256-byte demo, they eat up a half of the available space in the 16-byte size class. Assuming that the infinite loop (requiring a JMP) and the "putpixel" (STOSB) are also part of the framework, we are only left with five (5) bytes to play around with! It is possible to find some interesting results besides TV noise, but it doesn't require many hours from the coder to get the feeling that there's nothing more left to explore.

What about other platforms, then? Practically all modern mainstream platforms and a considerable portion of older ones are out of the question because of the need for long headers and startup stubs. Some platforms, however, are very suitable for the 16-byte size class and even have considerable advantages over MS-DOS. The hardware registers of the Commodore 64, for example, are more readily accessible and can be manipulated in quite unorthodox ways without risking compatibility. This spares a lot of precious bytes compared to MS-DOS and thus opens a much wider space of possibilities for the artist to explore.

So, what is there to be found in the 16-byte possibility space? Is it all about raster effects, simple per-pixel formulas and glitches? Inferior and uglier versions of the things that have already made in 32 or 64 bytes? Is it possible to make a "killer demo" in sixteen bytes? A recent 23-byte Commodore 64 demo, Wallflower by 4mat of Ate Bit, suggests that this might be possible:



The most groundbreaking aspect in this demo is that it is not just a simple effect but appears to have a structure reminiscent of bigger demos. It even has an end. The structure is both musical and visual. The visuals are quite glitchy, but the music has a noticeable rhythm and macrostructure. Technically, this has been achieved by using the two lowest-order bytes of the system timer to calculate values that indicate how to manipulate the sound and video chip registers. The code of the demo follows:

* = $7c
ora $a2
and #$3f
tay
sbc $a1
eor $a2
ora $a2
and #$7f
sta $d400,y
sta $cfd7,y
bvc $7c

When I looked into the code, I noticed that it is not very optimized. The line "eor $a2", for example, seems completely redundant. This inspired me to attempt a similar trick within the sixteen-byte limitation. I experimented with both C-64 and VIC-20, and here's something I came up with for the VIC-20:

* = $7c
lda $a1
eor $9004,x
ora $a2
ror
inx
sta $8ffe,x
bvc $7c

Sixteen bytes, including the two-byte PRG header. The visual side is not that interesting, but the musical output blew my mind when I first started the program in the emulator. Unfortunately, the demo doesn't work that well in real VIC-20s (due to an unemulated aspect of the I/O space). I used a real VIC-20 to come up with good-sounding alternatives, but this one is still the best I've been able to find. Here's an MP3 recording of the emulator output (with some equalization to silent out the the noisy low frequencies).

And no, I wasn't the only one who was inspired by Wallflower. Quite soon after it came out, some sceners came up with "ports" to ZX Spectrum (in 12 or 15 bytes + TAP header) and Atari XL (17 bytes of code + 6-byte header). However, I don't think they're as good in the esthetic sense as the original C-64 Wallflower.

So, how and why does it work? I haven't studied the ZX and XL versions, but here's what I've figured out of 4mat's original C-64 version and my VIC-20 experiment:

The layout of the zero page, which contains all kinds of system variables, is quite similar in VIC-20 and C-64. On both platforms, the byte at the address $A2 contains a counter that is incremented 60 times per second by the system timer interrupt. When this byte wraps over (every 256 steps), the byte at the address $A1 is incremented. This happens every 256/60 = 4.27 seconds, which is also the length of the basic macrostructural unit in both demos.

In music, especially in the rhythms and timings of Western pop music, binary structures are quite prominent. Oldschool homecomputer music takes advantage of this in order to maximize simplicity and efficiency: in a typical tracker song, for example, four rows comprise a beat, four beats (16 rows) comprise a bar, and four bars (64 rows) comprise a pattern, which is the basic building block for the high-level song structure. The macro-units in our demos correspond quite well to tracker patterns in terms of duration and number of beats.

The contents of the patterns, in both demos, are calculated using a formula that can be split into two parts: a "chaotic" part (which contains additions, XORs, feedbacks and bit rotations), and an "orderly" part (which, in both demos, contains an OR operation). The OR operation produces most of the basic rhythm, timbres and rising melody-like elements by forcing certain bits to 1 at the ends of patterns and smaller subunits. The chaotic part, on the other hand, introduces an unpredictable element that makes the output interesting.

It is almost a given that the outcomes of this approach are esthetically closer to glitch art than to the traditional "smooth" demoscene esthetics. Like in glitching and circuit-bending, hardware details have a very prominent effect in "Wallflower variants": a small change in register layout can cause a considerable difference in what the output of a given algorithm looks and sounds like. Demoscene esthetics is far from completely absent in "Wallflower variants", however. When the artist chooses the best candidate among countless of experiments, the judgement process strongly favors those programs that resemble actual demos and appear to squeeze a ridiculous amount of content in a low number of bytes.

When dealing with very short programs that escape straightforward rational understanding by appearing to outgrow their length, we are dealing with chaotic systems. Programs like this aren't anything new. The HAKMEM repository from the seventies provides several examples of short audiovisual hacks for the PDP-10 mainframe, and many of these are adaptations of earlier PDP-1 hacks, such as Munching Squares, dating back to the early sixties. Fractals, likewise producing a lot of detail from simple formulas, also fall under the label of chaotic systems.

When churning art out of mathematical chaos, be that fractal formulas or short machine-code programs, it is often easiest for the artist to just randomly try out all kinds of alternatives without attempting to understand the underlying logic. However, this easiness does not mean that there is no room for talent, technical progress or rational approach in the 16-byte size class. Random toying is just a characteristic of the first stages of discovery, and once a substantial set of easily discoverable programs have been found, I'm sure that it will become much more difficult to find new and groundbreaking ones.

Some years ago, I made a preliminary design for a virtual machine called "Extreme-Density Art Machine" (or EDAM for short). The primary purpose of this new platform was to facilitate the creation of extremely small demoscene productions by removing all the related problems and obstacles present in real-world platforms. There is no code/format overhead; even an empty file is a valid EDAM program that produces a visual result. There will be no ambiguities in the platform definition, no aspects of program execution that depend on the physical platform. The instruction lengths will be optimized specifically for visual effects and sound synthesis. I have been seriously thinking about reviving this project, especially now that there have been interesting excursions to the 16-byte possibility space. But I'll tell you more once I have something substantial to show.

Defining Computationally Minimal Art (or, taking the "8" out of "8-bit")

Introduction

"Low-tech" and "8-bit" are everywhere nowadays. Not only are the related underground subcultures thriving, but "retrocomputing esthetics" seems to pop up every now and then in mainstream contexts as well: obvious chip sounds can be heard in many pop music songs, and there are many examples of "old video game style" in TV commercials and music videos. And there are even "pixel-styled" physical products, such as the pictured watch sold by the Japanese company "&design". I'm not a grand follower of popular culture, but it seems to me that the trend is increasing.

The most popular and widely accepted explanation for this phenomenon is the "nostalgia theory", i.e. "People of the age group X are collectively rediscovering artifacts from the era Y". But I'm convinced that there's more to it -- something more profound that is gradually integrating "low-tech" or "8-bit" into our mainstream cultural imagery.

Many people have became involved with low-tech esthetics via nostalgia, but I think it is only the first phase. Many don't experience this phase at all and jump directly to the "second phase", where pixellated graphics or chip sounds are simply enjoyed the way they are, totally ignoring the
historical baggage. There is even an apparent freshness or novelty value for some people. This happens with audiences that are "too young" (like the users of Habbo Hotel) or otherwise more or less unaffected by the "oldskool electronic culture" (like many listeners of pop music).

Since the role of specific historical eras and computer/gaming artifacts is diminishing, I think it is important to provide a neutral conceptual basis for "low-tech esthetics"; an independent and universal definition that does not refer to the historical timeline or some specific cultural technology. My primary goal in this article is to provide this definition
and label it as "Computationally Minimal Art". We will also be looking for support for the universality of Computationally Minimal Art and finding ur-examples that are even older than electricity.

A definition: Computationally Minimal Art

Once we strip "low-tech esthetics" from its historical and cultural connections, we will be left with "pixellated shapes and bleepy sounds" that share an essential defining element. This element stems from what is common to the old computing/gaming hardware in general, and it is perfectly possible to describe it in generic terms, without mentioning specific platforms or historical eras.

The defining element is LOW COMPUTATIONAL COMPLEXITY, as expressed in all aspects of the audiovisual system: the complexity of the platform (i.e. the number of transistors or logic gates in the hardware), the complexity of the software (i.e. the length in bits of the program code and static data), as well as the time complexity (i.e. how many state changes the computational
tasks require). A more theoretical approach would eliminate the differentiation of software and hardware and talk about description/program length, memory complexity and time complexity.

There's little more that needs to be defined; all the important visible and audible features of "low-tech" emerge from the various kinds of low complexity. Let me elaborate with a couple of examples:

• A low computing speed leads to a low number of processed and output bits per time frame. In video output, this means low resolutions and limited color schemes. In audio output, this means simple waveforms on a low number of discrete channels.


• A short program+data length, combined with a low processing speed, makes it preferrable to have a small set of small predefined patterns (characters, tiles, sprites) that are extensively reused.


• A limited amount of temporary storage (emerging from the low hardware complexity) also supports the former two examples via the small amount of available video memory.


• In general, the various types of low complexity make it possible for a human being (with some expertise) to "see the individual bits with a naked eye and even count them".

In order to complete the definition, we will still have to know what "low" means. It may not be wise to go for an arbitrary threshold here ("less than X transistors in logic, less than Y bits of storage and less than Z cycles per second"), so I would like to define it as "the lower the better". Of course, this does not mean that a piece of low-tech artwork would ideally
constitute of one flashing pixel and static square-wave noise, but that the most essential elements of this artistic branch are those that persist the longest when the complexity of the system approaches zero.

Let me therefore dub the idealized definition of "low-tech art" as Computationally Minimal Art (CMA).

To summarize: "Computationally Minimal Art is a form of discrete art governed by a low computational complexity in the domains of time, description length and temporary storage. The most essential features of Computationally Minimal Art are those that persist the longest when the
various levels of complexity approach zero."

How to deal with the low complexity?

Traditionally, of course, low complexity was the only way to go. The technological and economical conditions of the 1970s and 1980s made the microelectronic artist bump into certain "strict boundaries" very soon, so the art needed to be built around these boundaries regardless of the artist's actual esthetic ideals. Today, on the other hand, immense and virtually non-limiting amounts of computing capacity are available for practically everyone who desires it, so computational minimalism is nearly always a conscious choice. There are, therefore, clear differences in how the low complexity has been dealt with in different eras and
disciplines.

I'm now going to define two opposite approaches to low complexity in computational art: optimalism (or "oldschool" attitude), which aims at pushing the boundaries in order to fit in "as much beauty as possible", and reductivism (or "newschool" attitude), which idealizes the low complexity itself as a source of beauty.

Disclaimer: All the exaggeration and generalization is intentional! I'm intending to point out differences between various extremities, not to portray any existing "philosophies" accurately.

Optimalism

Optimalism is a battle of maximal goals against a minimal environment. There are absolute predefined boundaries that provide hard upper limits for the computational complexity, and these boundaries are then pushed by fitting as much expressive power as possible between them. This approach is the one traditionally applied to mature and static hardware platforms by the
video game industry and the demoscene, and it is characterized by the appreciation of optimization in order to reach a high content density regardless of the limitations.

A piece of traditional European-style pixel graphics ("Frog, Landscape and a lot of Clouds" by oys) exemplifies many aspects of optimalism. The resolution and color constraints of a video mode (in this case, non-tweaked C-64
multicolor) provide the hard limits, and it is the responsibility of the artist to fill up the space as wisely and densely as possible. Large single-colored areas would look "unfinished", so they are avoided, and if it is possible to fit in more detail or dithering somewhere, it should be done. It is also avoidable to leave an available color unused -- an idea which leads to the infamous "Dutch color scheme" when applied to high/truecolor video modes.

When applied to chip music, the optimalist dogma tells, among all, to fill in all the silent parts and avoid "simple beeps". Altering the values of as many sound chip registers per frame as possible is thought to be efficient use of the chip. This adds to the richness of the sound, which is though to correlate with the quality of the music.

On platforms such as the Commodore 64, the demoscene and video game industry seem to have been having relatively similar ideals. Once an increased computing capacity becomes available, however, an important difference between these cultures is revealed. Whenever the video game
industry gets more disk space or other computational resources, it will try to use it up as aggressively as possible, without starting any optimization efforts until the new boundaries have been reached. The demoscene, on the other hand, values optimality and content density so much that it often prefers to stick to old hardware or artificial boundaries in order to keep the "art of optimality" alive. The screenshot is from the 4K demo "Artefacts" by Plush (C-64).

Despite the cultural differences, however, the core esthetic ideal of optimalism is always "bigger is better"; that an increased perceived content complexity is a requirement for increased beauty. Depending on the circumstances, more or less pushing of boundaries is required.

Reductivism

Reductivism is the diagonal opposite of optimalism. It is the appreciation of minimalism within a maximal set of possibilities, embracing the low complexity itself as an esthetic goal. The approach can be equated with the artistic discipline of minimal art, but it should be remembered that the idea is much older than that. Pythagoras, who lived around 2500 years ago, already appreciated the role of low complexity -- in the form of mathematical beauty such as simple numerical ratios -- in music and art.

The reductivist approach does not lead to a similar pushing of boundaries as optimalism, and in many cases, strict boundaries aren't even introduced. Regardless, a kind of pushing is possible -- by exploring ever simpler structures and their expressive power -- but most reductivists don't seem to be interested in this aspect. It is usually enough that the output comes out as "minimal enough" instead of being "as minimal as possible".

The visuals of the recent acclaimed Flash-based platformer game, VVVVVV, are a good example of computational minimalism with a reductivist approach. The author, Terry Cavanagh, has not only chosen a set of voluntary "restrictions" (reminiscent of mature computer platforms) to guide the
visual style, but keeps to a reductivist attitude in many other aspects as well. Just look at the "head-over-heels"-type main sprite -- it is something that a child would be able to draw in a minute, and yet it is perfect in the same iconic way as the Pac-Man character is. The style totally serves its purpose: while it is charming in its simplicity and downright naivism, it
shouts out loud at the same time: "Stop looking at the graphics, have fun with the actual game instead!"

Although reductivism may be regarded as a "newschool" approach, it is possible to find some slightly earlier examples of it as well. The graphics of the 1986 computer game Thrust, for example, has been drawn with simple geometrical lines and arcs. The style is reminiscent of older vector-based arcade games such as Asteroids and Gravitar, and it definitely serves a technical purpose on such hardware. But on home computers with bitmapped screens and sprites, the approach can only be an esthetical one.

Optimalism versus Reductivism

Optimalism and reductivism sometimes clash, and an example of this can be found in the chip music community. After a long tradition of optimalism thru the efforts of the video game industry and the demoscene, a new kind of cultural branch was born. This branch, sometimes mockingly called
"cheaptoon", seems to get most of its kicks from the unrefined roughness of the pure squarewave rather than the pushing of technological and musical boundaries that has been characteristic of the "oldschool way". To an optimalist, a reductivist work may feel lazy or unskilled, while an
optimalist work may feel like "too full" or "too refined" to a reductivist mindset.

Still, when working within constraints, there is room for both approaches. Quite often, an idea is good for both sides; a simple and short algorithm, for example, may be appreciated by an optimalist because the saved bytes leave room for something more,, while a reductivist may regard
the technical concept as beautiful on its own right.

Comparison to Low-Complexity Art

Now I would like to compare my definition of Computationally Minimal Art to another concept with a somewhat similar basis: Jürgen Schmidhuber's Low-Complexity Art.

While CMA is an attempt to formalize "low-tech computer art", Schmidhuber's LCA comes from another direction, being connected to an ages-old tradition that attempts to define beauty by mathematical simplicity. The specific mathematical basis used in Schmidhuber's theory is Kolmogorov complexity, which defines the complexity of a given string of information (such as a picture) as the length of the shortest computer program that outputs it. Kolmogorov's theory works on a high level of generalization, so the choice of language does not matter as long as you
stick to it.

Schmidhuber sees, in "down-to-earth coder terms", that the human mind contains a built-in "compressor" that attempts to represent sensory input in a form as compact as possible. Whenever this compression process succeeds well, the input is perceived as esthetically pleasing. It is a well-studied fact that people generally perceive symmetry and regularity as more beautiful than unsymmetry and irregularity, so this hypothesis of a "mental compressor" cannot be dismissed as just an arbitrary crazy idea.

Low-Complexity Art tests this hypothesis by deliberately producing graphical images that are as compressible as possible. One of the rules of LCA is that an "informed viewer" should be able to perceive the algorithmic simplicity quite easily (which also effectively limits the time complexity of the algorithm, I suppose). Schmidhuber himself has devised a system based
on indexed circle segments for his pictures.

The above picture is from "Superego", a tiny pc demo I made in 1998. The picture takes some tens of bytes and the renderer takes less than 100 bytes of x86 code. Unfortunately, there is only one such picture in the demo, although the 4K space could have easily contained tens of pictures. This is because the picture design process was so tedious and counter-intuitive --
something that Schmidhuber has encountered with his own system as well. Anyway, when I encountered Schmidhuber's LCA a couple of years after this experiment, I immediately realized its relevance to size-restricted demoscene productions -- even though LCA is clearly a reductivist approach as opposed to the optimalism of the mainstream demoscene.

What Low-Complexity Art has in common with Computationally Minimal Art is the concern about program+data length; a minimalized Kolmogorov complexity has its place in both concepts. The relationship with other types of complexity is different, however. While CMA is concerned about all the types of complexity of the audiovisual system, LCA leaves time and memory complexity out of the rigid mathematical theory and into the domain of a "black box" that processes sensory input in the human brain. This makes LCA much more theoretical and psychological than CMA, which is mostly concerned about "how the actual bits move". In other words, LCA makes you look at
visualizations of mathematical beauty and ignore the visualization process, while CMA assigns an utmost importance to the visualizer component as well.

Psychological considerations

Now, an important question: why would anyone want to create Computationally Minimal Art for purely esthetical reasons -- novelty and counter-esthetic values aside? After all, those "very artificial bleeping sounds and flashing pixels" are quite alien to an untrained human mind, aren't they? And even many fans admit that a prolonged exposure to those may cause headache.

It is quite healthy-minded to assume that the perception mechanisms of the human species, evolved during hundreds of millions of years, are "optimized" for perceiving the natural world, a highly complex three-dimensional environment with all kinds of complex lighting and shading conditions. The extremely brief technological period has not yet managed to alter the "built-in defaults" of the human mind anyhow. Studies show, for example, that people all over the world prefer to be surrounded by wide-open landscapes with some water and trees here and there -- a preference that was fixed to our minds during our millions of years on the African savannah.

So, the untrained mind prefers a photorealistic, high-fidelity sensory input, and that's it? No, it isn't that simple, as the natural surroundings haven't evolved independently from the sensory mechanisms of their inhabitants. Fruits and flowers prefer to be symmetric and vivid-colored because animals prefer them that way, and animals prefer them that way because it is beneficial for their survival to like those features, and so on. The natural world is full of signalling which is a result of millions of years of coevolutionary feedback loops, and this is also an important source for our own sense of esthetics. (The fish in the picture, by the way, is a Synchiropus splendidus, photographed by Luc
Viatour.)

I'm personally convinced that natural signalling has a profound preference for low complexity. Symmetries, regularities and strong contrasts are important because they are easy and effortless to detect, and the implementation requires a relatively low amount of genetic coding on both
the "transmitter" and "receiver" sides. These are completely analogous to the various types of computational complexity.

So, why does enjoying Computationally Minimal Art require "mental training" in the first place? I think it is not because of the minimality itself but because of certain pecularities that arise from the higher complexity of the natural world. We can't see individual atoms or even cells, so we haven't evolved a built-in sense for pixel patterns. Also, the sound generation
mechanisms in nature are mostly optimized to the constraints of pneumatics rather than electricity, so we don't really hear squarewave arpeggios in the woods (although some birds may come quite close).

But even though CMA requires some special adjustment from the human mind, it is definitely not alone in this area. Our cultural surroundings are full of completely unnatural signals that need similar adjustments. Our music uses instruments that sound totally different from any animal, and
practically all musical genres (apart from the simplest lullabies, I think) require an adjustment period. So, I don't think there's nothing particularly "alien" in electronic CMA apart from the fact that it still hasn't yet integrated in our mainstream culture.

CMA unplugged

The final topic we cover here is the extent where Computationally Minimal Art, using our strict definition, can be found. As the definition is independent from technology, it is possible to find ur-examples that predate computers or even electricity.

In our search, we are ignoring the patterns found in the natural world because none of them seem to be discrete enough -- that is, they fail to have "human-countable bits". So, we'll limit ourselves to the artifacts found in human culture.

Embroidery is a very old area of human culture that has its own tradition of pixel patterns. I guess everyone familiar with electronic pixel art has seen cross-stitch works that immediately bring pixel graphics in mind. The similarities have been widely noted, and there have been href="http://www.spritestitch.com/">quite many craft projects inspired by old video games. But is this just a superficial resemblance or can we count it as Computationally Minimal Art?

Cross-stitch patterns are discrete, as they use a limited set of colors and a rigid grid form which dictates the positions of each of the X-shaped, single-colored stitches. "Individual bits are perceivable" because each pixel is easily visible and the colors of the "palette" are usually easy to tell apart. The low number of pixels limits the maximum description length, and one doesn't need to keep many different things in mind while working either. Thus, cross-stitch qualifies all the parts of the definition of Computationally Minimal Art.

What about the minimization of complexity? Yes, it is also there! Many traditional patterns in textiles are actually algorithmic or at least highly repetitive rather than "fully hand-pixelled". This is somewhat natural, as the old patterns have traditionally been memorized, and the memorization is much easier if mnemonic rules can be applied.

There are also some surprising similarities with electronic CMA. Many techniques (like knitting and weaving) proceed one complete row of "pixels" at a time (analogous to the raster scan of TV-like displays), and often, the set of colors is changed between rows, which is corresponds very well to the use of raster synchronization in oldschool computer graphics. There are even peculiar technique-specific constraints in color usage, just like there are similar constraints in many old video chips.

The picture above (source) depicts a pillow knitted with the traditional Fair Isle technique. It is apparent that there are two colors per "scanline", and these colors are changed between specific lines (compare to rasterbars). The patterns are based on sequential repetition, with the sequence changing on a per-scanline basis.

Perhaps the most interesting embroidery patterns from the CMA point of view are the oldest ones that remain popular. During centuries, the traditional patterns of various cultures have reached a kind of multi-variable optimality, minimizing the algorithmical and technical complexity while maximizing the eye-pleasingness of the result. These patterns may very well
be worth studying by electronic CMA artists as well. Things like this are also an object of study for the field of ethnomathematics, so that's another word you may want to look up if you're interested.

What about the music department, then? Even though human beings have written music down in discrete notation formats for a couple of millennia already, the notes alone are not enough for us. CMA emphasizes the role of the rendering, and the performance therefore needs to be discrete as well. As it seems that every live performance has at least some non-discrete variables, we will need to limit ourselves to automatic systems.

The earliest automatic music was mechanical, and arguably the simplest conceivable automatic music system is the musical box. Although the musical box isn't exactly discrete, as the barrel rotates continuously rather than stepwise, I'm sure that the pins have been positioned in an engineer's accuracy as guided by written music notation. So, it should be discrete enough to satisfy our demands, and we may very well declare the musical box as being the mechanical counterpart of chip music.

Conclusion

I hope these ideas can provide food for thought for people interested in the various forms of "low-tech" electronic art as well as computational art or "discrete art" in general. I particularly want people to realize the universality of Computationally Minimal Art and how it works very well outside of the rigid "historical" contexts it is often confined into.

I consciously skipped all the cultural commentary in the main text on my quest for proving the universality of my idea, so perhaps it's time for that part now.

In this world of endless growth and accumulation, I see Computationally Minimal Art as standing for something more sustainable, tangible and crafty than what the growth-oriented "mainstream cultural industry" provides. CMA represents the kind of simplicity and timelessness that is totally immune to the industrial trends of fidelity maximization and planned obsolescence. It is something that can be brought to a perfection by an individual artist,
without hiring a thousand-headed army of specialists.

As we are in the middle of a growth phase, we can only guess what kind of forms Computationally Minimal Art will get in the future, and what kind of position it will eventually acquire in our cultural framework. We are living interesting times indeed.

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.