Hacker News new | comments | show | ask | jobs | submit login

Perhaps the following question should have its own Ask HN topic, but: Why isn't there a Linux demoscene?

First of all, there is. There's people making Linux demos. There's plenty cross-platform demos, too. Search http://www.pouet.net for Linux demos.

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.

I was actually hoping that, with the release of documentation on AMD's graphics cards, we'd see demos coded "on the metal", without passing through the standard graphics stack. That won't be possible on windows, since you can't just boot to console and then bang the pci bus yourself, but would be possible on linux. It could even be written as a kernel module for maximum effect.

That would be nice, but I think the issue is less one of documentation (lots of demosceners into reverse engineering) but that there are (a) just too many different graphics cards out there (b) the platform lifetime is very short (c) less motivation for hw specific tricks as "everything is already possible"; GPUs these days are parallel general purpose computing hardware, at most you'll speed up something a bit.

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.

DirectX is pretty efficient already. I don't think you would be able to push many more polygons going to the metal.

The impressive graphics (for the hardware) on current gen consoles showns what is possible when going to the metal, bypassing several layers of WDM, scheduler, drivers and DirectX.

No it doesn't. It takes a lot of effort with Cell just to reach parity, Xbox is basically DX9.

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 believe, on the Xbox 360 at least, you have to go through the scheduler, drivers and DirectX. There is no direct hardware access.

DirectX on the Xbox 360 is very lightweight and exposes a lot more of the hardware than what you get on Windows.

Another angle - pain with audio on linux. With traditional demoscene computers, you could easily get access to the audio hardware and expect it would work on every computer you shipped it to. (This second bit is important. You want to distribute your stuff.) You could generate wave form data dynamically with your graphics.

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.

In my opinion there have been two great non-commercial (counter-commercial) software movements: The Cracker/Demoscene and the Open Source/Free Software Movement. Both movements came out of solving the same problem, commercial software is expensive and not as available (in several different senses of the word) as each movement would like. How both movements attempted to solve that problem is where that difference lies:

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/

Nice writeup!

Also, I never knew that "yin" meant boring and "yang" meant super awesome!

I guess it depends on from what angle you look at it. Yin has been far better for my paychecks over the years, and that's pretty awesome IMHO!

Hah, you win :)

Quite nice description how it used to be in the scene.

I share a similar experience.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact