A history of the Amiga, part 8: The demo scene

Copper bars: Copper wait-until-screen-vpos-hblank, change $dff180 (bankground screen color)

Vertical bars: create a single horizontal 1D bitmap (pref. hold-and-modify); set BLPxMOD to negative the number of bytes of a single row (so the same row of pixels repeats over and over again) and animate the 1D bitmap - there's a nice demo that does this under the pre-tense of an undocumented instruction (the joke being there's no need for an undocumented instruction)

endless blob: to draw endless BOBs, allocate as many framebuffers as memory will reasonably allow and flip through them, drawing a BOB on each framebuffer with some sine path motion as it is about to be displayed, net effect is the BOBs keep on coming and flowing perpetually like millions.

Glenz vectors: use blitter to draw lines & blit into bitplanes with polygon filling mode, you'd need at least three bitplanes, one for the silhouette of the shape, one for the front-facing faces and one for the back-facing faces, then set up the palette so it's "just right" for the combination of planes to give a semi-transparent effect.

A site that goes into old school amiga demo techniques would be awesome! Would love to read up about even basic stuff like dot record breaking techniques & bitmap rotation and zooming techniques (eg. Brian the Lion intro screen comes to mind, as do the rotating platforms in Turrican 3)

I should put my 4k's up myself, except that the best one (featuring a real-time software synth in ~1100 bytes of the 4096), I've only recently been able to get it to run on someone's ancient win98 laptop :) No luck with the DOS-box emulator, so far...

You'll find many specific half-English terms in the demoscene, in fact. One of my favourites is the role of "Graphician", which would be called "Graphics artist" in any other place. The term is inspired by "Musician", I suppose, though I like to think it's actually a play on "Magician".

However, indeed it's pretty thin compared to Windows demos. There's a bunch of reasons, but I believe that there are three big ones:

1. Linux, until fairly recently, required a significant amount of tinkering and tweaking config files before you could even use it decently, let alone code graphics on it. This does not match the average demoscener's mindset; most demosceners want to get stuff on the screen, now. A side-effect of this attitude, by the way, is really shitty code, which in turn has contributed to the small amount of open source demos out there (people are ashamed of the pile of dirt that's under the hood).

2. For most of the nineties and early zeroes, Windows was obviously the strongest platform for 3D graphics. All the graphics hardware just worked, you could choose between OpenGL and DirectX and typically both had decent drivers. You could say that that's unfair because the hardware vendors supported Windows, and Linux drivers were often homecooked by the community, but that's beside the point: Stuff. On the screen. Now.

3. Audience. You could give a Windows demo to your gamer friend and he could see it. Of course, you couldn't give the Windows demo to that classmate who only ran Linux, but you'd prefer not to get into a discussion with him anyway because It'd always turn into a rant about licenses and freedom. Or, well, that's how the common perception of "the average Linux user" was among much of the demoscene.

Nowadays, many active demosceners are game programmers by day, and Windows still is the strongest game dev platform. These people are used to Windows gamedev tools and switching for the evening hobby just sounds too much of a hassle.

The Open Source/Free Software Movement:

1) Prevent software from being closed in the first place with various licensing schemes

2) Recreate closed commercial software with open alternatives

3) Share the guts of what you've done with others

The Cracker/Demoscene (for those that don't know, the demoscene is a spinout of the software cracking scene):

1) For software you want to use, crack the copy protection on it so licensing is irrelevant

2) Do it in as creative a way as possible

3) Compete with other groups of people trying to do the above, that means trade secrets

Over time, these core philosophies dictated how the movements operated.

They're both social movements in a sense, but very different kinds of movements:

I also remember attending a few Linux User Group (LUG) meetings. A bunch of folks crowded quietly into a rented room, there were a few lectures, a bit of Q&A, discussions over various Linux distros, shared tips, lots of config discussions. A few people might show off how their desktops were configured or provide a demonstration of a properly configured piece of software and give a tour of the code. At some point some code might be copied and distributed on floppies (and later CD-Rs). Very collaborative, even if it didn't really excite the senses. Leaving a LUG so you could go home and try a tweak in some X.conf file wasn't exactly mind-blowing. It felt kinda like school. It was all very Yin.

Contrast with going to small demo parties in my teens and the sense of friendly competition was simply awesome. It was brash and bold, artistic flourishes were rewarded, and groups that could come up with something novel kept those secrets close to their chest as it was their competitive edge. The typical party was loud, intense, and touched the senses, you worked on your discipline (coding, music, graphics) till you dropped or the competition started, at the competition a bunch of people piled into a room and tried to blow each other's minds. Clever hacks were rewarded with praise and tales of glory. It was like a street racing community or playing hooky so you could watch two kids have a fight. It's the friendliest kind of war. The demoscene is very yang.

Getting together with your demo group or attending a demo party was exciting and fun, you weren't really trying to change the world, just carve out a meaningful piece of it for you and your friends. The goals of the scene were completely orthogonal to the goals of the open source movement. And there has historically been very little overlap between the two groups of people. In practice this has meant that demosceners find themselves fed into the commercial software world, which is where they're most comfortable anyway, while open source folks have gravitated towards service and system integration companies. A few times, in organizations with hundreds or thousands of software folks, I've asked the question of who there participates in the demoscene and not gotten a single affirmative answer (though a few are aware of it), while most of my old demoscene friends work in closed-source commercial software and games.

It's kind of a shame, lots of the problems the open source movement has about front end design and interfaces and well...the human facing part of software...might be better met by demosceners on the job.

I think it's undisputed that the open source/free software movement has been the most impactful, I'm not using a demoscene derived OS and demoscene tooling has usually been very hacky. But I like to think it's been very influential. I've often used demoscene productions as ways of pushing development teams to change their perceptions about what a computer is capable of. I remember one case where we were hitting a performance problem in a piece of code, the developers (all with backgrounds in free software) were insisting that a single system just couldn't manage more objects. I showed them Blunderbuss [1] which fortunately is a beautiful demoand has a nice behind the scenes writeup [2][3] with this gem:

Particle count. I want more. I want to be able to render sand or smoke or dust with particles. That means millions. 1 million would be a good start.

It was meant to embarrass a little bit but also to inspire. It's a totally difference kind of software, with totally different goals than what we were doing, but the point was there. Get creative, get clever, get a little "right brained". Find bottlenecks, find efficiencies. Small speedups are for late stage optimization, huge speedups are what I was looking for. They eventually pulled it off and found ways to dramatically speed their code up, but I had to keep a blunderbuss to their head the entire time.

[1] http://www.youtube.com/watch?v=ezltebzdgjI

[2] http://directtovideo.wordpress.com/2009/10/06/a-thoroughly-m...

[3] http://directtovideo.wordpress.com/2009/10/06/blunderbuss/

I've thought of a way around this for linux, but stalled each time I look at it. Imagine if your demo/game hosted a server socket. VLC would connect to this for streaming (as though it was web radio). Now the domain becomes well-defined: you look after the concurrency and generate the wave signal. But let VLC sort out the hardware issues - VLC has strong support from package management across linux distros.

I'll mention why I get stuck in case there's good advice. I've found that generating polyphonic wave data is easy. But I don't understand how to package the data for transport. I'm also expecting some gymnastics in trickling the audio data stream out at a steady rate.

Otherwise this is the best I could find for US demoparties http://magfest.org/demoparty

Also, see Pouet.net for all things demoscene.