Slashdot Mirror
For Those Who Wish to Join the Demo Scene?
Sean Cope asks: "I've used a computer for a number of years, now. I've never been interested in programming, but after seeing the link to the demo DVD, my interest is in full bloom. If you were interested in creating a demo, where would you start? What books would you buy? Keep in mind, I've only used a computer for communication, and games up until this point."
I started learning about demo'ing back when it was popular, and done a few basic ones myself.
But these days it is very hard - watch some of the stuff by siggraph if you want to get depressed by the quality of stuff that is out there.
On the other hand, it is easy to do stuff that looks nice - even if you have to accept it has been done tons of times.
My favourite one that I did was when I tried to write a program that simulated how a brain works, with neurons etc. It produced some really wierd graphics.
In the old days you would have to write most of your routines in asm - although things like denther tutorials were a great help. However these days you don't need to know how to write the fastest putpixel routine. You can use opengl with sdl or whatever rocks your boat.
So inconclusion, learn a tiny bit about opengl, then start playing about. Try putting coloured squares randomly on the screen - this is quite a nice effect. Then fade it. Then texture the squares. Then make some opaque.
At really good one to do is the fire effect. Draw a row of pixels at the bottom of the screen in a random mix of red, orange and yellow, then on the row above that, for each pixel average the three pixels below it plus the three pixels that were in that position last frame ago. Draw the frame, then regenerate the bottom row randomly.
Play!
First, you should try to understand how computers work. There are many great books on the subject, but I find older tutorials just as informative. For graphics I would recommend the PCGPE, at least the VGA tutorial.
You also need to learn to program. This is done on two levels, first you learn one language, but when you try your second you will see the similarities and thus learn programming, and apprechiate the languages as tools (at least that is the ideal case). I would start by using C or perhaps C++ as these are the most commonly used languages today (they are however not the easiest languages, and for example, pointers require a good understanding in how a computer works). I would recommend Steven Prata's book on C (I don't remember it's title, but try amazon). For C++, just try Bruce Eckels homepage, he has lots of free books on line (google for Bruce Eckel).
The you will probably need a library that removes all the fuzz from programming, such as hardware details (you still need to understand the hardware though!). I would recommend SDL (www.libsdl.org) for general game/demo programming. But also directfb, if you intend writing software for Linux only. For applications I would recommend Qt (www.trolltech.com), a great UI/portability toolkit, but I have to mention GTK+/GNOME too (to avoid being hit by flames from their fans).
A general tip is that knowledge pays. Read as much as you can, howtos, tutorials, books, articles, etc. and try to understand it. If you see how things work, you will soon become a great programmer. It helps if your attitude is "difficult you say? I like challenges!".
A final warning, programming can be concidered a drug. It easily eats much of your spare time!
I was in the demoscene a long way ago (cbm64). The demoscene wasn't really seperated from the warez scene (then called swapping, exchanging floppies by snailmail :), so I will not call names.
The way to get into the scene is much the same as you get into any scene. Just do it.
1. Start making demos, simple demos, learning all the way. Do not expect to be top dog next month. Rather try to do a little better every time. Be critical. Add detail step by step. If you're a coder, empasise on that. If you're a designer, make graphics. Develop a neccessary skill.
2. Meet people. We've got the internet now, so publish your demos to a website. Most feedback you get will be negative. Don't be put off, but value all feedback to it's merits. Try to get more info. Try to get in contact with people that have skills you don't have. Cooperate.
3. Do not bitch. You do not have to help everybody, but behave normal. You will not have to be 733t. The less you piss people off, the easier you're going to get respect. Pissing off people sometimes seems the norm in the scene (or so it was one time. I suspect not much has changed). Don't be put off by it.
Hope this helps
the pun is mightier than the sword
Most demos/intros/scene productions are developed by self-taught 'coders', involving: - reverse engineering of existing demos / intros / etc; - gradual mastery of production through multiple repeated attempts; - reference books (algorithms, language reference, machine reference); - sometimes brain-smashing with other coders; One of the key features of a good demo/intro is the way that it pushes the machine somehow, by particular use of machine features (undocumented hardware features, novel algorithms [self modifying code, runtime code production, novel graphics algorithms, etc]). Basically, the better demos cause you to marvel in wonder somehow. There's also a need for an art/design element as well - good composition, structuring, arrangement of music, graphics, etc. Often you get this from a collaboration of a group (coder, grafician, musician, etc) more than one lone coder. I should know, I used to produce demos/intros in the C64 scene many years ago. I suspect the same culture lives on into PC/playstation/etc. The difference is the level of power available, and perhaps being able to use higher level tools. Anyone in the scene would treat so called 'games' or 'demo programming' books with horror and run a mile. Typically such books are aimed purely at trapping wannabe demo makers / coders and aren't really that useful. The advice is: look at existing demos/intros, start making your own, your first productions will possibly be not very good: improve, try again. If you are clever/intelligent/capable, then within a few iterations you'll start producing world class. Timeframe: 2 years.
The Demo Effects Collection. With full source, GPLed, done with SDL... What more do you want? :)
Try Assembly.org for some details about the 'demo scene' AFAIK. Two demo sceners' sites are; Byterapers (old group) and tAAt (new group).
:)
;)
Its too bad you missed the ASM Party 2002 BTW. It was cool and I had almost no English speaking demo-lovers to chat with!
Also, the 'intro scene' was where the fun was BTW.
Pixels keep you awake!
In case anyone was /seriously/ curious about this ...
g s. htmlx edo.org/~esr/faqs/loginataka.htmlo nical.org/~kragen/tao-of-programmin g.htmlm ll l abs.com/cm/cs/who/dmr/mdmpipe.html c onceptlabs.co.uk/alicebob.html
:-)
http://www-cs-faculty.stanford.edu/~knuth/musin
http://www.kohala.com/start/
http://www.tu
http://www.can
http://www.cryptonomicon.com/beginning.ht
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.htm
http://docs.freebsd.org/44doc/
http://cm.bell-
http://www.tuxedo.org/~esr/jargon/
http://www.
I snarfed most of these from one of my web pages (http://www.rospa.ca/folklore/). If there's other great Unix culture documents out there, please send me the link
"The purpose of argument is to change the nature of truth." -- Bene Gesserit Precept
> What exactly, is the demoscene?
A demo is a program which usually displays stunning animated graphics, 3D or 2D.
The demos were usually written in highly optimized assembly language, and showed very good graphics.
A few years ago, there were a lot of people who wrote demos, and competed with each other.
The object was something like: write a very spectacular demo, push the hardware to it's limits, etc.