Hi guys. I'm one of the programmers behind Elevated, Inigo Quilez. I was responsible for the programing of the visuals. Christian Ronde made the music and Rune Stubbe made the synthetizer and music player.
Apparently some people cannot believe this, but I will say it myself so there is no more useless speculation going on: this is a 4096 bytes executable demo. Not 4096 of source code. ItÂs a 4096 bytes executable (actually, a few less bytes), x86 binary, with plays a realtime animation and music demonstration without using any external data file. It uses a few d3d functions to generate a rectangle, to compile a hlsl shader and to set a projection matrix. That's it. I have read some people claiming there is "3d engines" built in in directx; I must presume those were assertions coming from people who actually know little about computer graphics today. Also, obviously, Microsoft didn't make any RenderCool( D3DX_MOUNTAINS, D3DX_PLEASE ) function in any of their APIs nor LoadTerabytesOfTextures( D3DX_ROCK_AND_SNOW, D3DX_FROM_HIDDEN_SYSTEM_FOLDER );
The demo doesn't use any external library for sound or whatever. The demo could be recompiled in OpenGL/Linux very easily (it was Opengl in fact, just ported to DX in the last minute), and be something around 4300 bytes. We went for DX to fit in 4096 bytes to complain with the competition rules of Breakpoint, the party where we presented Elevated.
Regarding the music, the demo not only encodes the music track, but also implements the instrument synthesis and track playback. The complete sound system takes about 900 of the 4096 bytes, it's mainly FPU code. To see how this is possible, you can have a look for now to sound synthesis and DSP.
The "textures" are infinite, just as the terrain itself. You can travel as far as you want on the terrain, this never ends, and same for textures. The rock, vegetation, snow, texturing takes about 100 bytes, although it uses some Perlin noise functions that take about 350 bytes. So in essence, we encoded mega, tera, peta and hexabytes of texture in few hundred bytes. The prize, of course, is that they are just too fractalish. But it made the job. Cameras are based on simple sinus and cosinus functions, the playback code is 150 bytes or so, and the camera data itself is exactly 4 bytes for each shot (a 16 bit random seed to feed the sin/cos functions with random frequencies and phases), a velocity and a FOV value. The rest of the sequencing data and playback code (to fade in, fade out, summer/winter transitions, brightness/contrast and color correction parameters) are around 400 bytes. The rendering is done in a "deferred" way, for those who know about computer graphics a little bit, which means the zbuffer if filled first and then a full-screen rectangle is drawn with a shader invocation. This shader computes the surface normals, does the texturing (lakes and sky included) and then does some tonemaping and motion blur. The shader is huge, around 1500 bytes. Another 800 bytes are used for basic operations as opening a window, initializing the rendering surface, sending the synthetized sound to the sound card, implementing the rendering loop and listening for the ESC keypress.
All this code is written in assembler (nasm), for those who were saying we donÂt know what hardware means. We spoke to the machine in this demo, as much as you can do in a modern OS at least from user code. The C version of the demo (which we used during development and debugging) is close to the 4200 bytes. The demo is also selfcompressed, and in fact the first thing the demo does at runtime is to allocate some memory (350 megas), self decompress there, and ask windows to run from that memory location. The uncompressed demo as it comes from visual studio (cl+nasm) is 7 kilobytes if I remember well.
Making a full selfcontained 4 minutes audiovisual piece like this is possible if you know computers, progaming, maths, rendering technologies, you apply a bit of imagination, and you are lucky to be the first to do it. So, those who say "no way this can be done" I say, "well, itÂs in front of you". You need a powerful graphics card, mainly because we are using a very heavy pixel shader that really needs all the teraflops of your shading units. Demoscene has always been about exploiting the hardware in strange ways, and this is a good example. Otherwise the demo should run fine, because the CPU or memory don't really matter, as the demo uses only 350 megabytes and the CPU basically gets idle during runtime (it only has to interpolate few values here and there), so probably as fasr as cpu is concerned even a 486 could run this. The Windows 7 fix will come.
Also, for all those people who might not know about hardcore optimization and coding, here goes a reference of not another one, but another few hundreds of such demos in 4096 bytes (most of them for Windows, as this is a very easy to program platform):
http://www.pouet.net/prodlist.php?type[]=4k&order=views
Hope this helped to clarify things. Basically, what you see is real, no cheats, we are doing this since the 80s, and we know doing it. Also, it's easier that it looks once you know the "how"s. I hope we can setup a website soon with the details of the making of so those with a technical background can enjoy the details of Elevated.
pd. we might release a OpenGL version (around 4200 bytes) even a Linux version why not.
Inigo -
http://www.iquilezles.org