Hacking Hi-Def Graphics and Camerawork Into 4Kb 255
TRNick writes "The old home-computing art of hacking elaborate graphics and camerawork into tiny amounts of memory has been lost, right? Not so. The demoscene is keeping ingenious coding skills alive, and TechRadar finds out the latest developments. Winner of the 4kb competition at 2009's Breakpoint party was RGBA's demo 'Elevated,' a gorgeous scrolling demo featuring photo realistic landscapes and music, which fits into the memory used by one of your PC's desktop icons. This is really impressive stuff."
Re:I assume the SOURCE fits into 4 kb (Score:5, Informative)
If you're not going to read the article, maybe you should at least have some idea of what the demo scene is about before rushing to first post.
What it is saying is that the executable file is 4096 bytes. The source code has little relation to that. If the program asks to use more memory beyond that after it's loaded, that's fine.
Re:I assume the SOURCE fits into 4 kb (Score:2, Informative)
You assume correctly, but in no way does that detract from how impressive their work (and others' in the DemoScene) is.
Here, read up some more about it: http://en.wikipedia.org/wiki/Demoscene
Even smaller - the BINARY is 4k (Score:5, Informative)
The source is much larger. The size counted is the size of the executable. Write as many comments as you like in your source code.
You can use as much memory as you like, but it's a very boring pile of memory if you don't then precompute a pile of pretty pictures using algorithms and data, which is what the 4kb is really counting.
You can use as many external libraries you like, as long as they're public; so you don't have to write your own OpenGL implementation, but you can't hide 200kb of your latest cool code somewhere other than the 4kb executable.
Feel free to hack the executable format to remove unnecessary headers and sections that an average compiler or linker would generate.
Re:Trojan (Score:5, Informative)
The compression techniques in demo code drive AV products nuts, that's just the way it is. They're not going to infect your system -- that would add too much bloat.
Shame it doesn't work on Win7 64-bit tho.
Re:I wish (Score:5, Informative)
YouTube version (Score:5, Informative)
I strongly suspect my video card won't be up to this, so I seeked out a capture of it on youtube:
http://www.youtube.com/watch?v=_YWMGuh15nE [youtube.com]
For those w/o Windows - video (Score:4, Informative)
Elevated by RGBA and TBC [youtube.com].
Impressive, though it seems the demo scene has evolved to include the use of platform libraries (graphics/synthesizer.) Impressive anyways - I'm assuming the imagery is all algorithmic.
When I last paid attention to demos, it seemed to be all in the executable, code dealing directly with hardware.
Re:Trojan (Score:4, Informative)
The loaders they use to uncompress the image are routinly also used by virus writers for their own non-3d distructive payloads. Sometimes the people adding the virus signatures get lazy and just target the loader rather than the payload.
I'm just happy these demos run with DEP enabled.
Re:YouTube version (Score:5, Informative)
Re:Even smaller - the BINARY is 4k (Score:2, Informative)
What the poster wrote is not compression. I could easily create a 4K program that can generate every possible 1MB long byte sequence (it may take a while to run). Heck, I can write that in well under 64 bytes. The rest of the 4K can be used for hueristics to stop the counter when needed and run the resulting program.
Your failure is you assumed the poster meant to compress every 1MB program into a 4K one.
Of course stopping at an arbitrary one is a problem. But of all 1MB sequences the one you may want to stop at could perhaps be identified using some heuristic or other identifier, making the original posters idea still valid.
This whole post seems to me an odd and convolute definition of compression...
BTW, information entropy prevents just what you are talking about (most of the times)
Re:Trojan (Score:5, Informative)
You need d3dx9_33.dll, which is not included on 64 bit systems.
With that DLL it works fine on XP x64.
Re:Meh (Score:1, Informative)
Well, if you ACTUALLY read the article (or at least skim to the end), you'll notice that the size they come down to is mere 45 bytes. However, that requires nasty tricks such as writing code inside the header. The minimal ELF headers people actually use are somewhere around 70 bytes in size.
Those minimum sizes are quite a lot if you consider that the smallest size categories on the demoscene are 256 bytes and less. That's why many of the folks specialized on that branch still prefer MS-DOS .COM executables which have no header overhead whatsoever.
Explanations (Score:1, Informative)
Hi guys. I'm one of the programmers behind Elevated, Iñigo Quilez. I was responsible for the programing of the visuals. Christian RÃnde 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
Explanations (Score:5, Informative)
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
Re:Music (Score:1, Informative)
Music for productions like this could be done in a tracker or some other sequenzer. Instead of using samples (classic tracker-style) you simply "record" note on/offs and store it in a map or something. Then - when replayed - the instrument and note-data is sent to the software synthesizer triggering notes, creating the sound you hear.
As far as I know, the synthesizer by Rune, that Christian used, features a homemade sequencer to use when composing the tunes. The sequencer is quite similar to trackers like ProTracker, Milkytracker or Renoise.
To my best knowledge, Christian has not released any albums, but I'm sure you'll be able to find quite a few of his tunes on http://www.scenemusic.eu by going to the artists-section and browsing to "Puryx". There's no download-link, but you can request it be played on the live-stream. The site features the music from both Elevated, Atrium and Receptor - all 4k productions to which he created music!