Slashdot Mirror
Hacking Hi-Def Graphics and Camerawork Into 4Kb
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."
> which fits into the memory used by one of your PC's desktop icons.
I would assume that the source code may fit into 4 KB but that it requires a lot more memory to execute.
"Fitting into the memory used by one of your PC's desktop icons" would thus seem a little overstated...
I did not read the whole article but I did not see any mention of how much memory is required for execution of the code.
Everything I write is lies, read between the lines.
The demo executable contains the trojan W32/Smalltroj.NCSD!
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.
Does my bum look big in this?
Downloaded the exe.
Tried to run.
SAM quarantined the file, claiming it contains a trojan.
Damn! Photo-realistic rendering -and- a trojan in 4kb? _THAT_ is impressive!
The source is probably 40KB+, but you're right it probably uses multiple MBs of video memory at the very least once it is running. I don't keep up with the PC demo scene but I remember one of the 64KB Farbrausch demos needed around 200MB of RAM.
It takes a 64MB avi to store the 4KB demo!
I assume that 4K doesn't include the 3D libraries they used. It's still impressive but 4k of code can create a lot of procedural graphics if you have a few megs of graphics libraries to display it.
I wish more developers would try doing things like this. I can imagine a game along the designs of Doom3 or Quake4 that would fit on a floppy disc with some proper code crunching.
Of course, the downside is that it'd be all too easy to snag tiny files like that on a torrent site.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
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
Elevated by RGBA and TBC.
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.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
Did they forget to include the 300MB of code that actually draws all this amazing stuff on screen. I don't think a 4k demo was meant to be: draw.directx.3Dcircle(98,98), move 200,300; render.directx.3Dcircle,(Built in directx texture 22), shade; coolbuilding.directx.raytrace(); I think it's kinda silly to call these 4K demoes. I know people argue, but really 4K demos use to be ALL the code to do a cool demo, including not just the sound files, but the entire code for the player too. Now a 4k demo is list of command for some 300MB library to execute. The 4K demos today are more like a .bat script, not like it use to be which was "AMAZING! How did they fit ALL that Code, Graphics, and sound into 4K??!!?"
Here is a youtube video of the demo;
http://www.youtube.com/watch?v=ro5grR_efG0
Complete with applause and cheers! :) Must have been nice watching it live!
Suspicious#kkrunchy (Worm) in file rgba_195_95_256.zip
I don't deny these demos are impressive but the fact they use existing libraries lessens the achievement for me.
When DirectX basically has it's own 3D engine, you're basically turning the task of creating a demo into generating sounds, textures and models from formulae.
Libraries used should be limited to the minimum needed to create a window or change the display mode and shouldn't do any real grunt work or, there should be a second metric of RAM and swap files used.
!news == olds
Everyone going on here about how stupid it is that they used existing libraries mind you that typical compo rules state that it must run on a base install. Nobody here is linking to myuberleetcode.dll or anything. That and think about the freaking sound for a second or better yet try and write a 4k and then come back and talk about how stupid it is
Yes, and that'd be very neat and much much harder than you seem to think. Try it, go looking for that magical random seed that creates a 1MB blob of code that does something impressive. Maybe you should expand your idea to first generate a filtering program that can determine if a code sequence, when run over some data, creates a demo? :-)
4K demos are sort of an artistic exploration of Kolmogorov complexity.
Remember also that, if the judges die of old age before your demo appear, you're unlikely to place well in the compo.
Belief is the currency of delusion.
An indie game titled 'Roboblitz' uses procedural generation to 'unpack' game textures the first time the game is run. It makes the installer smaller, but the unpacking process is still time- and processor-intensive. It saves transmission bandwidth, but doesn't do the end user any other favours.
While i certainly admire the technical skill involved, the demoscene is more than that. It's a form of art.
Just look at http://www.pouet.net/prod.php?which=31571
This pushed me over my Comcast cap!
which fits into the memory used by one of your PC's desktop icons.
I use Gnome, you insensitive bastard!
While demos like this are extremely neat, there are also some real limitations to what you can do. This is by no means an all inclusive list but some of the major limitations of making something like this:
1) All graphics are completely procedural, as in mathematically described. That means you don't get to have an artist sit down and draw them. Puts limits on how they can look and demands a fair bit of self similarity.
2) You use a MASSIVE amount of memory in relation to your file size. You may have noticed it sits at a black screen for a bit before running. Why? It is doing all its calculations, decompressing in to memory. When running on my system, it took 350MB. Rather than storing lots on disk and streaming as needed, you store little on disk and have to use tons of RAM.
3) You can't have things like voices and such in the game, takes too much space. Even with extremely efficient compression (which produces audible artifacts) voices will quickly make your game larger.
4) All assembly coding. To do this, you are writing everything as efficient as you can. That's wonderful, but hard to maintain. For a large project that is going to need to run on a lot of systems, be patched and so on, you want a higher level language. Doing everything in assembly would be a nightmare to maintain.
I could go on, this is just an example. What it comes down to is that this is neat for demos. I -love- stuff like this, Farbrausch is one of my favourties for this sort of thing. However it is not a realistic exercise for normal applications. You do not want to sacrifice everything just to try and have a small program footprint. On the contrary, if increasing the on disk size makes it better or more efficient, then you want to do that. Disk space is extremely cheap. Better to use more of it than to sacrifice in another area.
finally some more demoscene stories! keep em coming!
It won't run in Wine...
Well, I don't know about you folks, but the first thing that I did was download the programs in Mac OSX and the scan them from windows in Parallels Desktop using AVG... The results were horrendous! Every file has a virus. EVERY FILE. Check your computers people... I am so glad that I only run windows in emulation these days! This could be a false positive, but I doubt it.
Qybix
Qybix ----- I do not have a belief system; I'm an Anti-theist and proud of it! Saying that not believing in anything i
Too obscure.
Um, pretty amazing, it's appears incapable of running in Vista Business SP1, and attempting to run it results in a "elevated_%resolution%.exe has stopped working" error message. Don't know anyone who is going to bother to troubleshoot a demo, and kind of annoying that a 4KB program is so buggy and/or badly written that it can't run.
Slashdot: Playing Favorites Since 1997
Too obscure.
For /.?
I was still impressed, but the demo is heavily dependent on existing libraries. If there were an OpenGL function to draw_glorious_mountainscape_and_fly_around_it_while_playing_majestic_music(), they could have packed this into less than 100 bytes.
Last post!
Elevated is packed down into a 4k package, but it clearly uses many many times that space when it runs. That's practically cheating... a real 4k demo would run in 4k of memory, total, usually including the screen buffer.
When we did our entry for the BADGE killer demo contest in the '80s (a version of Lunar Lander that ran on the Amiga workbench and required you to land on top of your open windows) I felt we were already pushing the envelope of what was really "fair", since we were getting the "terrain" for free.
Torrent anyone ?
When the precise size matters so much, it would be good for the submitter to use the correct abbreviations. There is no such thing as Kb. A capitol K is never used alone in measuring data amount. 4kb is four kilobits, or 4,000 bits. That's not what the competition's limit is. Neither is it 4kB, which is four kilobytes, or 4,000 bytes, or 32,000 bits. The actual limit is 4KiB, or four kibibytes. That's 4,096 bytes, or 32,768 bits.
Console gamers develop high expectations as the hardware reaches the end of its lifecycle
Microsoft and Nintendo virtually stopped developing and approving new software for their older consoles (Xbox and GameCube) once their replacements (Xbox 360 and Wii) hit the market. So I take it you're talking about Sony.
I wish not. They would fit in a floppy and you would need like 256-rack BlueGene cluster to render it! Generated textures are well... generated! It's a CPU intensive task, unlike loading raster from memory. Balancing the load on all resources gives the greatest performance. Demos are NOT balanced obviously, since that's their sole purpose. That's why you can't render complex scenes in demos. The simple demo mountain scene runs at less FPS than a complex, dynamic and beautiful Bioshock scene on my PC for example.
Besides, generated textures look synthetic. Organics by definition cannot be procedurally generated - to be more precise, thay can, but it would require nearly the same amount of data to describe them as a raster would. You can't describe complex things with few data, that's why their called complex after all.
And if the Universe could be described in equations, then rendering today's state of it or any part of it would require 14 billion years given all computational resources of the Universe... if you get what i mean. Still i can enjoy the picture of my girlfriend without making her body up from all the genetic and environmental data i don't have.
It saves transmission bandwidth, but doesn't do the end user any other favours.
Not everybody has the opportunity to live somewhere that can get cable or DSL. So a lot of people upgrade from dial-up to satellite or 3G Internet. These plans usually have burst performance not much better than ISDN and a 5 GB/mo transfer cap, which works out to a 14.4 kbps sustained throughput, for $60 per month plus equipment costs plus prohibitive overage fees. For them, saving transmission bandwidth becomes much more important.
Symantec Antivirus says it's a trojan.
Doesn't say which one, just that it is.
Kriston
Don't know if it is a false positive or not, but Comodo screams about "Win32.Garbage.xxxxx" malware when the file landed in my download folder. I prefer to remain paranoid rather than risk this thing being a nasty, so those that are likewise paranoid might just want to watch the video instead of running the .exe. Just FYI.
ACs don't waste your time replying, your posts are never seen by me.
Feeling nostalgic of the "good ol' demo era" with those really awesome demos that I watched again and again back in my DOS gaming days, I visited the links to d/l a few of these 4k demos. Wow! 4k: That's elegant programming! Then McAffee reported some trojan strings. Everything is probably clean but... (constructive comment here!) I wish the coders had scanned their stuff...! Again: everything is most likely clean but I am part of the legions of fans out there who are non-experts and who must rely on an anti-virus. The reputation of these truly extremely cool coding accomplishments shouldn't get tarnished over this kind of oversight. I can't risk it. I will be forced to look at the demos on an old expendable crap PC. I wish I could have used my current PC with cutting-edge graphics! :)
I used to wait anxiously each year for the demoscene to release it's winners and top demos. I would hit the ftp.cdrom.com archives (where they tended to dump everything in the day) and download all the demos on my 9600 baud modem.
//end reminiscing
The 4k demos and the much larger DEMOS were amazing -- it was cool to see what people could do with a bit of assembly language or C
There was a small clique of us (in jr high) that would get together and try run them on the latest 486 setups and be in awe of the likes of Future Crew (Props Skaven and Purple Motion).
"i lost my dignity on a slippery wiener"
http://www.pouet.net/prod.php?which=50688
By the same author a year ago, so no news there. Do you think the improvements are really worth the extra 3K?
Even if the size is only 4kb, it takes lots of work to write those things. The reason is that 4kb is LOTS of space. And if you're using just small primitives, you can fit LOTS of primitives to that space. Choosing correct primitives for that is LOTS OF WORK. Making it look great requires testing after testing, and knowing algorithms for graphics.
In competitions they have restricted the size to 4kb just to keep it suitable for one person. It probably takes one year to write one of those. The size limitations are not there to annoy programmers, they are there to keep the amount of work reasonable. If the size was bigger you'd have to use 10 years to write one or use 10 people working for a year...
Somebody tell these people that AVI's and Divx are dinosaurs and should never ever EVER be used again.
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
Try it, go looking for that magical random seed that creates a 1MB blob of code that does something impressive. Maybe you should expand your idea to first generate a filtering program that can determine if a code sequence, when run over some data, creates a demo? :-)
Its actually much easier than that with quantum computing. All you need are some trivial modifications to the Quantum Bogosort algorithm and some way to let the program know whether it has won the contest or not.
No problem is insoluble in all conceivable circumstances.
Awesome tracker artist right there, I love Satellite One.
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
Crash. Tinkle. Boom.
The executable that wouldn't execute.
I do not fail; I succeed at finding out what does not work.
That is actually one of the application`s developers who explains what actually goes on and talks about a Linux version.
While I hate doing it, MOD PARENT UP!
(it has been 3-4 hours since that comment posted)
I browsed scene.org a lot for Amiga demos but when I saw the x86/Windows demos requirements, I just said "DirectX is the true power of Microsoft on Desktop." The developers you see at scene.org aren`t your usual "Wizard" type people, if they use DirectX, they must have a real good reason. If Apple wants to become serious on gaming, they should speak with these people about the reasons about choosing directx and what could possibly replace it. I don`t say they should give up excellent OpenGL support. They should find a way to merge all those open technologies in some way. For example, they can ask them "Why don`t/wouldn`t you use SDL?"
Of course, one of the developers posting as AC (and scored 0, should be modded up) says they can code an OpenGL version for Linux if there is enough demand for it. See the last line of his comment: http://slashdot.org/comments.pl?sid=1308661&cid=28763745
I have an idea that'll solve everything.
Have every demo to be submitted as a VMWare image, you load the image and that renders everything. Pure stand-alone x86. Then you guys can argue about how it uses VMWare's internal drivers.
C64 demos can overwrite the OS by writing to addresses $E000-$FFFF (writethrough), then setting bit 1 of byte $0001 to 0, which flips that address range from pointing to the ROM chip to pointing to newly filled RAM chips.
Does my bum look big in this?
All our base belong to you.. This is truly awesome..
This stuff is truly amazing. Now if only we could get these geniuses to help fix our energy crisis..
I've always assumed soundtracks like the one in Elevated are done in a tracker -- but I'm guessing the tracker file has to be hugely modified or perhaps even just used as a guide to hardcode the note data for something like this. How do you guys work together for that?
By the way: Elevated's music is magnificent. Does Christian Ronde have any albums out?
Your mind is clear / The things that you fear / Will fade with how much you / Believe what you hear
Very interesting that Symantec says the download for this is a Trojan.
nt