Demoscene: 64k Intros At Revision Demoparty
An anonymous reader writes "Last week-end at Revision demoparty, demosceners have pushed further the limits of what can be done in a single 64kb executable file. Using extensive procedural techniques and compression, Gaia Machina (video capture) and F — Felix's Workshop (video capture) are realtime animations, featuring high quality rendering, sound, 3D models, and textures."
Get off my lawn!
in Saarbrücken, Germany
For some reason they never have demo parties like this in North America. Why is that?
Demoscene? Demoparty? 64kb executable?
Ya, i wish there was a website that you could like, search for the meaning of stuff and maybe websites about it and crap.
Be seeing you...
...you're not part of the intended audience. Admittedly, there's a lot of necessary hardware support to get these kinds of results, but still... full A/V in a space less than the banner image of most websites. Makes you wonder what could be done with similar techniques and, say, a megabyte of space.
PHEM - party like it's 1997-2003!
I can't seem to make heads or tails of this post. It's techno-babble and word salad. I guess I should remember this feeling when I talk about programming with my non-programming friends.
Sort of sad as a programmer you have no knowledge of some of programming history.
Be seeing you...
Makes me wonder if he really IS a "programmer" and not just a "HTML/CSS" scripter.
You would be surprised at how many HTML/CSS monkeys, calls themselves "programmers" these days.
- Don't do what I do, it's probably not healthy nor safe. -
/. is really making me feel old these days -- I was writing demos in the early 90's. I don't know if its my overall grumpy old-man mentality or not, but as impressive as these are, they're powered by a crap-ton of software running behind them. There's not 64k of assembly pumping bytes into a framebuffer and twiddling the PC speaker port to synthesize digital audio.
One thing I couldn't find in there (and I've been out of the scene for a LONG time, so I don't know how this works on new-fangled fancy computers...) -- do these write directly to the video hardware? Or do they use OS services like DirectX11, etc? When they say 64k, is it a 64k executable using up another dozen meg of OS DLLs?
I have to give it to them, they are very impressive. But are people still getting down and counting clock cycles?
Anyway, for you youngins, this might explain the demoscene a bit better: http://www.youtube.com/watch?v=iRkZcTg1JWU
But in your days it was easy, you could count the clock cycles on the fingers of one hand and if you wanted a bit flipped you just climbed inside the computer with a hammer!
Anyway, you weren't all that impressive, you relied on a blacksmith for a hammer and a miner for the coal to fire your machine. You were just the slave master benefiting from the slave labor of others.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I was wondering why it's "demoscene" and not "demo scene"
Because English puts spaces in its compound words more often than German does.
To be worthy of posting on slashdot? Yes.
Here's the blurb I posted on my facebook page:
I forgot to mention. This stuff is also all rendered in real time. It's not a movie. The music is also composed/tracked. It is not a recording. Here's another impressive entry in the 64K competition: http://www.youtube.com/watch?v=6CiF034IhgY&hd=1 It's mind blowing where these guys have gone over the years. I thought the demoscene would have died as computers became more powerful and anyone could create effects without having to be an artistic assembly programming god. I apparently, and thankfully, was wrong :-)
Actually, there is structure and discipline. But it's not academic structure or discipline. It's the structure and discipline of hard limitations and necessity. For example in 4, 16 and 64KiB compos, where every single byte matters, pretty much. In the 4KiB compos, a huge focus is on the packers and all the math surrounding that, where the packer is optimized for two things: Size and speed. And since you're not showing just one or two static effects, but animations, preferably with multiple effects, there's a lot of code that needs to go into that limited footprint.
In fact, I think demos should be required study in comp.sci etc, especially these limited footprint demos, specifically to teach the role of creativity in problem solving, instead of just wasting resources to sidestep them.
A prime example is that the demoscene, if we look at it as an entity, pushed the boundaries of real-time procedural content generation before the games industry or academia did, and still continue to do so. The ones in the game industry who do look into procedural content generation often have a background in the demoscene
During the nineties, I've done a lot of scene-related assembly code (mostly graphics and infrastructure - extenders, memory managers, etc), so I'm well aware of the limitations imposed and the usual workarounds. Most sourcecode I've seen is an ugly mess, even if it works. There are some true clever and elegant algorithms in the lower categories (128/256b and 4k), but what I've learned since then is that computer processing power is cheap, but software lasts. One of my favourite demos of all time is Heaven7, mostly because it implements a realtime raytracer than runs smoothly on a P200. But probably many of the optimizations that allowed it to run smoothly in such a limited processor aren't valid for a P3. Or a P4 (handcode optimization for any of the P4 lines is a _nightmare_). So, if it was a maintained application, the highly optimized algorithms would probably have to be rewritten, to take advantage of the latest features, and keeping "pushing the boundaries".
As an example (and more in line with the nineties), a lot of effort was put into highly optimized bresenham line algorithms, because traditional implementations implied a div operation per pixel, and integer division was awfuly slow (like 40 cycles on a 486). So, even if bresenham's requires extra instructions, it would still be a lot faster. Well, on a pentium, not only the div instruction took 1 clock cycle (like most of the other instructions), some instructions could be paired for execution (the processor had 2 execution pipes), so the bresenham implementation is usually a lot slower than using the div instruction. If you had to write maintainable software, would you worry about implementation details that could double your development time, but be obsolete on the next processor to be released? I guess not.
Demos are a kind of development on its own. They require no user interaction, no external data pulling (other than already packaged resources), have no error checking whatsoever and usually are buggy as hell - slightly different hardware may give you completely different results, or just don't run at all. So, that's why I don't like to call scene coders "real programmers". They are more of a class of "code artists", and yes, they should deserve more merit than "regular" coders, not only because their algorithmic skills, but also because of their creative way of implementing them.
one. I met him once in a pub. he's a right cunt.
I wrote my first program at the age of six, and I still can't work out how this website works.
oh you bastard! I helped code gaia machina! download the other one! we won ffs!
I wrote my first program at the age of six, and I still can't work out how this website works.