But demoscene programming is still the one thing that leaves me totally in awe, feeling like I wouldn't even know where to start to achieve what these guys pull off. Even if I could imagine fitting all those drawing and sound generation routines into 4k, how on earth would you script the whole thing in that little space? How would you encode and execute the sequence of camera paths, music events, and synchronize light flashes with the music? And make it consistent in time, as opposed to depending on the speed of the CPU? I just can't even imagine what the main loop would look like.
Alcatraz use an interesting system based on Clang and llvm to export all that from Maya as source code
This means that instead of learning sizecoding, the opengl/d3d pipeline, mesh uploading, textures, getting along with the video bus speed, index buffers, geometry shaders, and so on, and so on, you can just learn GLSL and how a raymarcher works. Much like 20 years ago, getting something on screen quickly became easy again. It's not as easy as Processing, but it's not too far off either.
For example, check out this video about the Russian demogroup Quite (who made the amazing 4k intro "cdak". The video briefly shows (scroll to 20 minutes) how unc starts with the shader instead of with the C code, using vvvv, a tool for live prototyping realtime graphics. They only turn the non-shader parts of the vvvv "code" (block diagrams and envelopes) into C code when the intro starts looking like it's going to be releaseable. With such an approach, you get motivated real fast; focus on getting something on screen, worry about getting into a demoparty compo later.
Or just don't worry about the C version at all, and make something cool that you'll never be able to pull off with any animation studio, and put it on vimeo :-)
Oh, also check out this Pouet thread  about how Quite made "cdak" (but first see the intro!). It's one of those things that make you even more amazed when you get it.
 http://www.pouet.net/prod.php?which=55758 | http://www.youtube.com/watch?v=RCh3Q08HMfs
Here's a series of really good blog posts from someone who decides to make a shiny procedurally-generated city. The result is an amazing how-did-he-do-that demo, but the steps he went through and the way he thought about the problem are understandable.
Of course the OP is brilliant too. Kudos to all these guys!
Very little of modern programming can replicate what it was like to work on old systems outside of these kinds of competitions.
For those interested in the music side of these productions, many of the composers use this to write the music. http://4klang.untergrund.net/
Interesting side note: demos tend to use music with pentatonic (ambient) or whole-tone (dreamy) scales. They’re easy to harmonise, which makes it easy to procedurally generate decent-sounding music.
All the magic of the demo is in the synth (pure x86 fpu code) for the music, and the sphere tracer / camera choices / colors / fractal equation, for which precisely 0 'API' is used.
Put another way, the really amazing thing these days is that we have hardware (cpu, gpu) capable of so many FLOPS that you can do brute force things like sphere tracing complex fractals. the goal, seen in this light, of the demoscene, is to expose the wonder of all that power in visually interesting or arty ways.
Seriously, you couldn't have picked a worse example of someone 'leaning on an api'. :)
When making 4k intros for Linux (may apply to other platforms) you have to do your own startup and runtime linking code because otherwise the executable will go over the limit before it does anything. Because of this, you will have to minimize the amount of libraries you use and the amount of functions you use. The name of every function you use must be included as a string in the (uncompressed) binary. So even though you can use peripheral libraries, there is an incentive to minimize the amount of library functions you use.
And what are the libraries that are used? You need to get something on the screen, so many demos use SDL or similar, like this:
SDL_SetVideoMode(width, height, 32, SDL_FULL_SCREEN);
xor eax, eax
mov al, 13h
int 10h ; I wonder if I still remember this correctly
Then there's OpenGL and Direct3D, which are used to talk with the GPU. These days a GPU is basically a method of drawing triangles really really fast. But it draws only triangles and you have to program all the lighting and whatnot. Then there are fancy shader tricks you can do, but they're not (a lot) easier than it was when poking pixels directly to video memory.
It's arguably easier to do 3d graphics using a GPU than writing your own triangle fillers and perspective correct texture mappers. But this is a double edged sword. Getting shit done with triangles only is a constraint that did not exist back in the pixel pushing days.
And finally, audio. Writing a software synth consumes quite a big chunk of your byte budget. Back in the day, there were dedicated synth chips in computers, from the SID to the OPL-3 in SoundBlasters and Ad-Libs. Programming them was not super easy either, but I'd guess it takes a few bytes less than writing a PCM-emitting synth from scratch and sending that data to the sound output.
So what you say is correct, library implementations don't count to the byte limit. But if your message is that it makes stuff easier and it was 2000% more hardcore in the 1990's with DOS, I disagree.
But then came VESA which was a little bit more complex and of course, screen sizes bigger than a segment (ouch)
About audio, IMHO it's much easier now, dealing with those interrupt handlers and dma controllers wasn't easy. Of course, once the library worked it was ok.
10h is correct. The contents of ax register might not be. Is the graphics mode (13h) supposed to be in the al or ah part? That I can't remember.
> But then came VESA which was a little bit more complex and of course, screen sizes bigger than a segment (ouch)
Yeah, early VESA Bios extensions were hairy. With VBE 2.0 you can get a simple linear framebuffer with a high resolution quite easily.
> About audio, IMHO it's much easier now, dealing with those interrupt handlers and dma controllers wasn't easy. Of course, once the library worked it was ok.
Interrupt handlers and DMA controllers were used for PCM audio. I agree that writing that stuff by hand was harder than doing it today with libraries. And you'd still have to write the PCM-emitting synth.
But chip synths were generally programmed with simpler memory mapped I/O and they did the actual audio synthesis for you, not only PCM output.
mov ax, 13h
(I tested using "nasm -f bin")
This is not a very interesting point to me because of how it forgets that in any case, software never exist into a vacuum, and hardware is needed for it. And that hardware does perform a great deal of duties.
The subtext often is that for some reason it's less noble or impressive to code against APIs. However hardware also is a sort of API of its own. Even on a ZX-81.
As a matter of fact, demo producers are offered more and more API choices. Compare what you had to accomplish with tinkering around with bare-metal BIOS interrupts in the 90s, compared to a full-fledged DirectX API including GPU-raytraycing almost out-of-the-box.
The ray tracing going on in this demo has nothing to do with the APIs he is using; indeed, that demo could be implemented, pixel perfect, on any platform with floating point arithmetic. it just uses the 'advanced api' to display the resulting image on the screen...
now, the point you make is still a valid one, in that we have more api's than before, but this demo is not an example of using such apis. Better 'grey area 4k' examples that would support your point, are the ones that (for example), loaded the general midi file from windows, and used it as a source of samples (that was a trend a few years ago); or the ones that make use of D3DX's truetype font->extruded mesh routine, to create almost all their geometry out of extruded Arial letters. In both cases, these are such ingenious hacks that despite being in the 'grey area', and definitely (ab)using data available in the host OS, they represent such crazed creativity you can't help but admire them.
either way, such tricks were not used here; you're just seeing the result of a very large number of multiply-add instructions, artfully composed; and that's nothing to do with 'demo producers making more and more API choices'
One pointlessly bouncy (but fun to make) experiment I ported from desktop GL to WebGL a short while ago:
Set quality to 4 or 8 as fast as you can unless you already got one of them 2014 GPUs.
That being said, none of those are 4K =)
I mean if these guys are able to do this in 4K, what else could be done in operating system terms if we achieved that same level of excellence?
Once your program started executing you were on your own, graphics, sound, memory management, everything. People still managed to get the first level of descent into 4K.
My point was that modern 4K demos are still fun, but they should not be looked at as though they are great examples of efficient uses of resources. You have to watch out for Man on the Moon Syndrome where people start asking "Why can we get infinite 3D fractal explorations in 4K of space, but Ruby's binary is 10MB!!?".
If you wrote a 4K DOS demo today against modern hardware you wouldn't be able to reach anywhere near the look of these other demos which sit ontop of OpenGL/D3D/Win32 etc, because you'd need to build the equivalent of those API's functionalities into your demo.
YouTube 1080p version seems to have pretty terrible quality.
 maybe http://scene.org also ?
I understand lots of the scene is still active on IRC if you hunt around.
well worth the watch...
If you want to play with this type of code right now in your browser, check this out... http://glsl.heroku.com/e#2431.0
I heard a story at my company about fixing a bug a couple years ago. Memory was full, so in order to do that, the engineers rewrote the UI messages to allow the extra instructions to fit into memory.
Particular impressive results may not fit into severe constraints.
Do not confuse the two.
Even a small "that's great, but it needs to do..." can change 4KB into 4GB.
Good game coders like Carmack have little to feel intimidated about.