At one point we decided to host a demo contest (which Tom Rokicki pronounced with a long 'e' sound) it was the hottest ticket in the Bay Area for a while, we even had Commodore and Newtek offering up gear for prizes. Some amazing stuff watching people pull every ounce of performance they could out of the chips.
I don't think it's possible to get "a few groups" of sceners together in the Netherlands. It's even hard to find people enthusiastic about FOSS, though there are some more of those.
It's a very welcoming place for the newly interested, I assure you.
I always prefer the "limited" compos because you don't usually need a team (hard to come by, helps if they're local) and because IMO it shows more of the scene spirit: pushing the boundaries. I mean, a PC demo nowadays can pretty much do anything, and even back in the day I felt it was too much freedom.
Are there still parties not all the way down in Eindhoven? :) I'm still located all the way up North :) Although if I'm heading somewhere for 3-4 days, NL is small enough. I do need some peeps to meet up with there and have a good time, cause I doubt I can get my local friends to clear their schedule on short notice like that :P
I believe that there's an oldschool party in Northern Germany every summer, too: http://nordlicht.demoparty.info/
That said, I won't be able to make it to Outline myself, unfortunately.
I wonder if there is a site that explains copper bars, vertical bars, endless blob, glenz vectors etc.? Would be interesting to read about that again.
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)
Zooming I mostly did with applying Bresenham to drawing bitmaps instead of lines (And then obviously repeating lines with BLPxMOD).
That site would be awesome.
I used to just load the demo and listen to that track over and over, it was awesome.
Which I could find it now.
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".
considering how hard it is for most groups to find a decent graphician, they're almost as important
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.
If you make your demo to work on one ATI card you will have a small audience at most, and the card will be out of the market in a year and all the tricks you learnt were for nothing. And if you want it to work on more hardware you get into the device driver business, and that rules out special tricks for specific hardware to do non-standard rendering anyway...
Back in the days of home computers there was one longer-lived hardware platform that many people were using. There is a faint hope that initiatives such as the Raspberry Pi may bring people to "standardize" on one more or less ubiquitous platform for longer time, but I'm afraid this ship has sailed. So it makes sense for demosceners to focus on what is possible on the higher, portable API level.
You program the GPU by writing shaders that run right on the GPU, the only perf increases to be had involve how fast you can move data on and off the GPU. Eliminating all abstraction might give you a few percentage points, not enough to do anything that we would consider amazing under current circumstances.
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.
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  which fortunately is a beautiful demoand has a nice behind the scenes writeup  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.
Also, I never knew that "yin" meant boring and "yang" meant super awesome!
I share a similar experience.
Also, see Pouet.net for all things demoscene.
Otherwise this is the best I could find for US demoparties
Q: Really? What made you not want to be a programmer? This is curious.
A: "I had a bunch of friends who I loved dearly, but in many ways were exhibiting all the traditional programmer stereotype themes of being just overly focused on things I didn't think mattered and at that time programming perhaps also was a little bit different. Growing up, programming was assembler and C. I had a lot of friends in what was called the 'demo scene', which is mostly an European thing where you had all these guys on the Commodore 64 and on the Amiga writing these really awesome visual displays of various kinds, and all that stuff was usually in assembler. I had absolutely zero interest in learning or doing anything with assembler, it just didn't make any sense to me at all.
I only really got interested in programming when I stumbled across languages that made sense to me on the level that makes sense to me, which is at the very least high level languages like Java, PHP, or whatever have you, anything that's above the 'I have to dick around with pointers' or I actually have to move memory spaces around; that stuff has absolutely zero interest to me at all.
I didn't start programming until I was in my late twenties, and even then I didn't start programming because I wanted to be a programmer. I started programming because I wanted a few programs. And that was apparently the easiest way to get there because the other way of getting programs is that you actually have to talk to programmers, which is surprisingly painful at times. I found that the easiest way was just to pick it up and learn it myself."
It's pretty heavy on East Coast demosceners right now, but North American Party announcements pretty regularly go up.
EDIT : is some demo code source available somewhere ? i knew a site back then , but it went offline.