Demoscenes can be simply explained as music videos generated in real time by computers, but they have such a rich history that it's almost insulting to describe them as such. As a computer scientist, I naturally focus on the more technical aspects of demoscenes, that being the coding. They are essentially a careful melding of music and visuals, generally 3D, with code, generally assembly or C, to stitch them together. Now there are so many catches to this I don't know where to begin. The jist is the creators impose restrictions on themselves which makes development incredibly complex--such as restricting the end result file size to only 4kB!
Let's start with some visuals.
This is a sample of visuals from demoscenes, but they have been removed from their environment with their music stripped away. Not doing justice to the originals
Generally the visuals use a lot of particles and implement fluid movements, sometimes flashing or jerking with the music. The majority of the visuals are generated using mathematical functions if I understand correctly because manually positioning every object and programming in it's roll, pitch, yaw, dx, dy, dz, dcolor not to mention textures changing is just infeasible for the memory and hard drive space limitations. There are resources which exemplify mathematical functions found in nature which I imagine would be a useful resource for demoscene developers but I am not sure if they use such things.
Elements are sometimes repeated within a demoscene but are generally shown at different angles and it seems more common to focus on an individual element, interact with it for between 20 seconds to a minute and a half and put a new element in the spotlight.
Some of the systems for which these demoscenes were designed, such as the Amiga, were not packing much punch. They were often relatively primitive, so when someone discovered a new effect they would show it off like in Hardwired by Crionics & The Silents Amiga
Keep in mind the video to the left ran on an Amiga using 256 kB of RAM and a 7MHz processor
Here's an example of what a more modern PC demo might look like
Chaos Theory by Conspiracy, a 64kB intro
The community behind demoscenes spawned a lot of contemporary communities. It's comparable to tagging except incredibly nerdy. Much like in the world of hip hop in which creators will pay homage to each other, so do demosceners. It's also a way to show off their coding and composing skills, making a name for themselves by discovering new ways to abuse the hardware. These sort of hobbies are tantamount to modding games today in that if you make something people like, or really push the boundaries of an engine, you get noticed. And when you get noticed, you get job offers. The video game industry is notorious for hunting down demosceners and scooping them up. I'm told Microsoft did this to stop other companies from getting their hands on such elite coders. The demoscenes who weren't hired into the gaming industry founded their own gaming companies and paved the way for some of the techniques used in modern video games.
You've likely noticed a recurring auditory theme. The music is exclusively electronic music. One of the interesting components of the music is that it isn't stored in a conventional format, like a WAV or MP3 which is a sequence of differential noises being delivered at 4.3 GHz. In stead, individuals samples, such as a particular drum hit, are stored and played at specific times during the demoscene.
An old school tracker. I searched for amen break and tracker so this MAY be the infamous amen break which appears in virtually every drum'n'bass song.
This process is similar to composing music with a sequencer, but I've heard it compared to making music with an excel spreadsheet. Trackers aren't used as much in modern demoscenes, but I believe the audio is still not stored in a conventional format.
As for the coding, well, I would argue you have to be just as creative in this field as in the music composition of designing/theming. As previously mentioned, most demoscenes have size restrictions on them. 4kB and 64kB are common, but a few are less than 1kB which forced development in assembly language, a 'programming language' which consists of a small set of labels which represent direct instructions to the processor. Writing in assembly is the equivalent of an architect creating the hand tools to make the crane that is going to build his building. It's a great way to do things, but realistically no one is going to do it unless things are mission critical or they're a huge nerd.
For the record, this single image is 64kB, imagine creating a 4+ minute movie which takes up no more space than this compressed image.
This compressed image of a QR code is 4kB, the same size of the executable which renders cdak, a demoscene by quite & orange.
Compression is encouraged, I believe UPX is the standard, so nothing special going on there, but I wouldn't be surprised if some of the sub 1kB demoscenes used the code for creating music and visuals as data, which could allow for a much more densely packed demoscene. This reminds me of biological viruses which encode genes on both the Watson and Crick strand of their genomes. This means that the information coding in one direction, which completely restricts the information on the opposing strand, has meaning when read in either direction. They aren't necessarily palindromes, just incredibly complex, but I digress.
If you'd like to watch a demoscene rendered live on your computer, or live in an emulator on your computer for some of the Amiga videos, you can head over to Scene.org which is the largest public repository for them. Or you can play Farbrausch's .kkrieger, a first person shooter for PC which has graphics similar to Half Life 2 which is around 1019904kB, but .kkrieger weighs in at a shocking 96kB. It's not a fair comparison
|Top, Half Life 2. Bottom, .kkrieger|