DEMO CODING IN GNU/LINUX by Smoke of ECFh in June of 2000 +++ Introduction +++ Please send feedback about this article! Suggestions, example code, anything is greatly appreciated. Let me know if you think this is useless or useful. * contacting the author You can reach me by mail at , or visit the open source demoscene irc channel #demoscene at the open projects irc network (http://openprojects.nu/ for a list of servers). * atmosphere The opensource demoscene is very friendly, but small. I'm too tired at the moment to explain anything about it. All I like to say here is that it's fun to be part of it. +++ Index +++ No index in this version. If you think you're smart enough, you can skip the first sections and read about the audio+video syncing only. +++ Tools +++ * pixeling If you want to brush, use gimp or boot to Windows for photoshop. For the real elite, there are a few pixelers. The worst pixeler is probably crapStation, which i wrote myself. It needs libggi and can read and write 8bpp .png files. Awkward interface, but I managed to do all the graphics for our intros with it. Then there's Satan Paint which is also completely useless, and there are some commercial products, but as I'm a big fan of opensource demos, I'm not going to help with that. * tracking There are about ten trackers for Linux, each equally useless. The best of all is probably Soundtracker, but it uses the Gtk+ widget set, and looks more like Microsoft Excel than a tracker. Then there's ocsatracker by Viznut of ocsa or pwp or whatever, and it's as useless as Funktracker Gold. Both aren't maintained, their ncurses look is so cool that you really have to try them once. Sed wrote a tracker for X and he managed to beat all user interfaces in usability. Sadly enough, tracking in Linux gets you back to the level of Modedit in DOS a few years ago. So the tools for pixeling and tracking may seem quite bad. But that's no problem. Just get out your amiga and track and pixel on that. Nobody is gonna find out you cheated. On the other hand, some people want to write new tools, and it may well happen that we end up with some new opensource projects for pixeling and tracking in the near future, now that more and more graphics artists and composers are trying Linux too, for odd reasons. * coding Coders are more fortunate, since GNU/Linux (and unix in general) has great tools for the programmer. Probably the best editor ever is very well supported by Linux. I don't think this is the right place to start a religious war about emacs vs vi though. +++ Programming languages +++ * assembly The most important assemblers for Linux include NASM and GNU as. The latter uses the AT&T syntax, which may look awkward to those used to the intel syntax used by MASM or TASM. Nasm uses the intel syntax, which might be appealing for old DOS or Windows coders who're trying to switch. Except for the syntax, there's no real difference though. I wrote a 4k intro using only GNU as, and it was great fun. I suggest trying to learn the AT&T syntax, as it may gain some insight in assembly language on other architectures, like amiga and risc machines. * C/C++ When optimizing C code, it is often useful to view the generated machine code. Using 'gcc -S' will produce a .s file containing the code you need. You can now hand optimize this code and use 'as' to assemble it. Note that the the .s file is in AT&T syntax, so it might be useful to learn this syntax and forget about nasm There are zillions of optimization switches for gcc, but generally -O3 is the best it can do. Trying weird options such as -funroll-loops might be a great way to spend a night, but speed increase is generally zero. * other languages I don't know anything about Java, and you'd better ask Jmagic or some other java guru. Perl, Python, Awk and other languages are completely useless for doing demos with, but it may be fun to use them to generate code or effect data. Investigate in all languages and learn. +++ Video +++ Because there are so many incompatible videoboards, it makes little sense to address hardware directly. But of course we're democoders and speed is important. When limiting to a certain standard, it is possible to gain acceptable speed using svgalib. However, not all videocards are supported by svgalib, and you'd want to write X11 fallback support too. For this reason it's best to use a library that supports multiple 'display targets'. The first to do this was libggi, and it does this with virtually no overhead. The various display targets for Linux include svgalib, the kernel framebuffer devices, X11, KGI, and aalib. * GGI The design of libggi is very clean and it extends great. The ggi project is maturing, and input device support is great. Other parts of the ggi project include writing hardware device drivers to be used in operating system kernels: this is the KGI project. It's progressing very slowly and it may be a great field for democoders who like direct hardware accessing. * PTC PTC basically only offers a framebuffer, and does not handle input -- might be nice for demos, but if you want to add a nice menu, you'll have to spend some more time searching for input methods. In the near future it may be possible to use the ggi projects' general input interface library (libgii) for this, without using libggi. * SDL SDL is meant to be a gaming library, which would suit demos quite well. Its design is not as extendable as libggi, but since the focus is on gaming, and not on general use as libggi is, it may appear to be better suited for demos in the future. * X11 Nearly all videocards are supported by the XFree86 X11 implementation, but X isn't the greatest for demos. First of all, the default for X is to display an application in a window, and you have to get out of your way to circumvent the windowmanager in order to display the demo fullscreen. The nice and clean way would be to request drawing in the root window and trying to make the windowmanager shove off, but this is nearly always impossible, and the screen resolution is probably too high for demo standards. Changing the resolution and bitdepth is practically impossible. Using DGA might solve some speed problems, but all in all X11 is just not meant to be a demo platform. X11 is portable, but in my opinion it's stupid to only support X11 and no other targets, better suited for demos, like svgalib or fbcon. +++ Audio +++ * OSS sound drivers The main kernel drivers are buggy, oldfashioned and badly supported. For demos the interesting devices are /dev/dsp and /dev/sequencer; the first is used for sample playback, the second for MIDI or hardware mixing with the gravis ultrasound. * ALSA The Advanced Linux Sound Architecture stems from the Ultrasound Project, and is trying to takeover the OSS drivers' job. Just as libggi for video, it consists of a driver part and a set of libraries. The drivers are supporting more cards every day, and are to be used by means of the library API. +++ combining video and audio +++ The main problems I've had with writing demos in Linux deal with syncing video and audio. I prefer demos to run at a constant framerate, say the refresh rate of the monitor. The easiest way to do this is to poll the vertical retrace of the VGA card, and playback a little chunk of audio at every frame. Using multithreading doesn't work, since then audio playback may occur just when you wanted to wait for the vertical retrace. Setting up an IRQ handler for the vertical retrace is only possible with some videoboards, and this may prove useful, but I haven't checked yet. Let me know if you think this works. * audio software mixing Too lazy to write our own mod player, we've used libmikmod to write most of our intros. Since the player can be polled every frame, it's great for 70fps demos. The main CPU wastage is in the audio drivers trying to send out the audio; libmikmod's mixing routines are not to be blamed! Perhaps ALSA's mmaped sound output solves this problem, but I wouldn't know yet. * audio hardware mixing Another drawback of libmikmod is that it doesn't support hardwaremixing on my trusty old GUS. The modplayer 'xmp' does do hardware mixing, but it's written in a way that does not support a polling scheme, and is thereby useless for demos. I rewrote a part of xmp to make it polling, but then I ran into problems with /dev/sequencer syncing. Every so many frames it takes up all the CPU to send out and sync the sequencing data to the soundcard. A way to get around this is to use music at 175 bpm. Most amiga demos used to playback modules at 125 bpm, at a video refresh rate of 50 Hz. With the IBM vga's 320x200x8bpp mode at 70 Hz, we get 125*70/50=175 bpm. It worked great for me, but I still have trouble finding a musician who's comfortable with this speed :-) +++ URL's / links +++ GGI Project - General Graphics Interface http://www.ggi-project.org/ ALSA Project - Advanced Linux Sound Architecture http://www.alsa-project.org/ Open projects irc network http://openprojects.nu/ #linuxscn/ircnet homepage http://www.linuxscn.org/ ECFh homepage http://die.die.ms/intro.html crapStation pixeler for libggi http://www.casema.net/~smoke/crapstation.html Soundtracker tracker project for X11 http://www.soundtracker.org/ -- smoke of ECFh, , http://die.die.ms/intro.html