Farbrausch has stood out to me for a long time as one of the strongest demo groups. They consistently produce demos that are not just technically impressive but really beautiful as well. I highly recommend checking out their back catalog if you haven't seen their work.
Another group I highly recommend is Andromeda Software Development. They are less about "check out these cool techniques" and more about putting together a cohesive, music-video-like experience. I've heard different perspectives on whether that's a good thing, but irrespective of where you come down on that they produce some demos that are really enjoyable to watch.
As this is my personal opinion, please take it with a big grain of salt - ASD's Lifeforce is the new benchmark for demo effectiveness. It is just so beautiful.
When I first saw Farbrausch's Debris I thought it was a bit boring. After all, it's repetitive. The soundtrack is like some cheap industrial techno, and the demo itself doesn't really show off that much.... Until you realise that the whole thing is less than 200kB. An amazing feat.
There is just one experience more profound the demoscene has given me. It must have been no later than 1995 or 1996, or about the time when the Amiga and PC groups had just discovered 3D toroids, vector castles and phong shading in general. Half of the demos shown in the party had some kind of floating/rotating phongs-shaded toroid, and about a third sported a zoom-in/zoom-out view of a castle. It got pretty dull, pretty fast.
And then finally Byterapers showed off how to outdo everyone by using the same effects with better timing. On C-64. Jaw, meet floor.
Oh my god! You're sagacity of threestate?! I'm swooning! "melrose space" is my all-time favourite demo! To this day, I still watch it regularly, I love it so much. (As well as the other 3s ones -- like enjoying a favourite album.) Thank you!
Good to hear! I never thought people would still be looking at these things such a long time after the fact but I guess that's the internet for you :)
Btw, the things we released as threestate were a clear testament to how important design is (and more accurately in this case, the design of Steven) when you're doing demos. Before that, some of us (me, sarix, inopia) did a bunch of releases as Quad that were also fairly impressive technically but had no design and...pretty much nobody cared.
Yeah, I can't tell you how much pleasure all those demos have given me over the years, so the opportunity to thank someone directly is really satisfying to me. Thanks again. :)
I recognise your/those names from other releases (like quad, and haujobb). And like you said, others may have been more impressive technically, but it's the threestate ones that have always stuck with me, for that amazingly perfect (IMNSHO) combination of technical impressiveness, visuals, and audio.
You know what they say: ASD -- Amusic's Soundtrack Dump
(That said, I'm actually part of the faction who likes aMusic's weird prog-rocky compositions. And, regardless of what you think of his work, you've got to respect aMusic for being one of the very few demoscene composers who incorporate real, acoustic instruments and vocals into their work. I really can't think of any others.)
Pretty much from the moment that I became interested in the demoscene about 12 years ago, Farbrausch has been my favorite group. It was something about 64k intros that intrigued me. Even in 2002, a 3" floppy held almost no data, but you can fit 20 or so of these amazing things on one.
How much of modern demos is in the system libraries? Like, if you didn't have D3D or OGL but had to write code that drew at the per-pixel level, how much larger would these demos have to be?
Most demos don't push pixels but vertices. Graphics hardware turns that into pixels. If you'd do all pixel rendering on the CPU your code size would maybe, what, double, but you usually don't want that because the GPU is multiple orders of magnitude faster than that. Also, given that most size in demos is taken up by data, not code (except in 4k intros and the likes), it wouldn't make a significant size difference, really - just an effort difference.
Additionally, many effects in modern demos run purely in shaders, written in HLSL or GLSL. The CPU part draws a single rectangle and the rest happens in a shader. Would you count that as depending on system libraries? Shader languages aren't much more high level than C, so its pretty close to the metal. In any case, you can't go more low level because GPU machine code (which HLSL etc compile down to) is pretty inaccessible in practice.
These few turn out to be the biggest in our bunch, totalling to 5.5MiB.
So there you have it, by linking a minimal graphics demo on Linux, you are implicitly linking to about 5.5MiB of direct system libs and 8.6MiB of indirect system libs. These numbers will vary wildly for other OS, but I guess the DirectX stuff would be larger.
The vast majority of that will be libstdc++ and libc, of which the app will be using a tiny corner. You could probably reduce that by half by sticking to C and then using a minimal libc.
Neat! Although if you were just writing to a framebuffer you would probably use much less code. OTOH, the graphics drivers are doing the rasterizing right?
It depends on how pretty you wanted those pixels to be and if you wanted to use the hardware (and which hardware) to it's fullest extent.
Back in the DOS days, everyone more or less had to write their own rasterizers and write that data directly to the graphics controller (their own graphics driver), which probably took a few KB to do. Modern demos with full GPU acceleration use whichever 3D API/stack the OS provides, which (as a complete guess) is several hundred MB. Even that number pales in comparison to the amounts of data that the procedural generation within some 64k intros produce.
Modern 64k intros typically use D3D or OGL but they still need to generate the meshes, textures and sound themselves. In the DOS days (mid/late 90s) this was no different except there also had to be all sorts of software rasterization code in there just to get the scenes rendered. OTOH there were plenty of effects done back then that were strictly 2d using clever lookup tables.
The DOS 64k intros typically didn't link to any stdlib but would just provide their own implementation along with a few of the symbols that the C/C++ compiler (typically Watcom) would require. Combine that with a tiny DOS extender like PMODE/W and a compressor like UPX and you'd be off and running. A minimal intro (just showing a bouncing pixel or whatever) could be had with only just a few kilobytes.
Nowadays intros typically rely on, as mentioned, D3D or OGL but also usually on the MSVC runtimes. Compression is still done using tools like UPX or kkrunchy but that actually's becoming difficult to do because virusscanners are usually flagging them as suspicious nowadays because of all the malware that also uses these compressors. Also, file size is not something that most people care about too much nowadays so the whole concept of the intro seems to have become less and less interesting over the years.
Well, that's what I'm asking. On a modern system, isn't most of the actual rendering being done by the gfx stack? Even lighting, right? So the app code might send out a definition of some polys and textures and the stack takes it from there. Right?
So the app code might send out a definition of some polys and textures and the stack takes it from there. Right?
That's how modern 3D programming works in a nutshell, whether it's a game, demo, or CAD. A program provides data, parameters, and maybe small GPU programs (shaders). The stack takes it away, and does the nitty gritty math to transform triangles in 3D space, map them to 2D space, split into pixels, and apply images, lighting, etc. to them.
If you really want to know what it does, I recommend you learn an API (Direct3D, OpenGL/WebGL). Everything underneath is handled by the stack.
As for examples of what the program does and the system doesn't: for some demoscene stuff, the program uses procedural generation to generate models from mathematical descriptions, and textures by using noise functions and image filters. Here's a presentation of werkkzeug, the tool that Farbrausch uses:
Right that was my point - if a 64k demo had to actually push pixels into a framebuffer or similar API (like it was 20+ years ago), how big would they have to be? That is, how many bytes are saved by having high level frameworks that can do T&L and more all in the stack?
Bytes are often added by the high level frameworks (see the megabytes of unused C library). Putting a pixel in a framebuffer requires a single instruction. You can do quite a lot of T&L in short bits of code.
It hasn't been possible to do that on PC since the DOS days. You have to go through a number of abstractions (APIs, drivers) to display anything on screen, or to play anything through your sound card.
Actually, your timing is really fortuitous: Just yesterday, the aforementioned Farbrausch member/NOWHERE developer posted a progress report[1] for the game. Somewhere near the end, he mentions that they had to delay the game's Steam Early Access release to finish a few things, that they had factored the release into this month's revenues, and that they are now borrowing money to pay the rent on their home (the developer and artist are married).
Please check the game out and do consider supporting Paniq (apparently Patreon[2] is the most convenient way to do this). There really could be no better time for a small bit of exposure!
Wow! Thank you for this - I had totally forgot this other type of ascii art! I remember seeing those in BBSes or (IIRC) when quitting shareware DOS games, when they showed an order screen.
I went to an art show of ACiD/iCE members in SF 6 or so years ago. Had boards hooked up to screens to show the ANSI, do autoscrolls, etc. Was pretty awesome.
It is still cool to see what demos the groups pull off nowadays, but we are far far away from C64, Spectrum, Amiga and Atari, PC days, doing algorithms considered impossible in such hardware.
That thing is like extremely well done stage magic. You know you're being fooled and mislead, you may even know exactly how it's done - and you still can't but admire the flawless execution.
Another group I highly recommend is Andromeda Software Development. They are less about "check out these cool techniques" and more about putting together a cohesive, music-video-like experience. I've heard different perspectives on whether that's a good thing, but irrespective of where you come down on that they produce some demos that are really enjoyable to watch.