5260813
story
Comments: 255 +- Technology: Hacking Hi-Def Graphics and Camerawork Into 4Kb on Monday July 20 2009, @10:49AM
Posted
by
timothy
on Monday July 20 2009, @10:49AM
from the thumbdrive-could-hold-the-entire-world dept.
from the thumbdrive-could-hold-the-entire-world dept.
background: url(//a.fsdn.com/sd/topics/topicgraphics3.gif); width:69px; height:62px;
graphics
background: url(//a.fsdn.com/sd/topics/topicsoftware.gif); width:65px; height:65px;
software
background: url(//a.fsdn.com/sd/topics/topicprogramming.gif); width:80px; height:48px;
programming
background: url(//a.fsdn.com/sd/topics/topicit.gif); width:75px; height:61px;
it
background: url(//a.fsdn.com/sd/topics/topictech2.gif); width:60px; height:80px;
technology
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."
Related Stories
Submission: Hacking hi def graphics and camerawork into 4Kb by Anonymous Coward
It is sweet to let the mind unbend on occasion.
-- Quintus Horatius Flaccus (Horace)
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
Wow (Score:5, Funny)
It takes a 64MB avi to store the 4KB demo!
I wish (Score:4, Insightful)
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.
Re:I wish (Score:5, Informative)
Parent
Re: (Score:2)
Re:I wish (Score:5, Interesting)
Try Left 4K Dead [mojang.com]
The fact is that cramming a lot of game into a small space is still worth doing.
Parent
Re: (Score:2)
One problem that is easily foreseeable: this would require very distinct and very specific libraries to be installed on all computers you want it to run on. That may work if all you use is DirectX, but if you use any other libraries of code... well, this really severely limits it. (example: I the exe I downloaded for the 4k demo crashed).
I would rather have to have an entire CD (incidentally, I wouldn't be able to use a floppy anymore) and be able to run it without downloading this, that, and one other li
Re: (Score:2, Insightful)
Of course, the downside is that it'd be all too easy to snag tiny files like that on a torrent site.
That, and games would take 4 hours to start on today's processors.
Re: (Score:2)
Would libraries on the host system count? I can see how it would be easy to make a really small game, if you have hundreds of megabytes of libraries on the host system to leverage. Much harder if you have to do it all from scratch. What are the rules for these kinds of things?
Re: (Score:2)
No extra download on top of a fresh installation of your (proprietary) OS.
On linux, it's much harder to define what's in and what's not, so it's a genuinely less interesting playing field for competitions.
Roboblitz does this (Score:2)
Re: (Score:2)
It's already easy to snag gigabytes of stuff on a torrent site, I doubt making games smaller is going to make people any more inclined to pirate them unless they were truly gargantuan to begin with.. besides, having all your games generate the levels, characters, animations, sounds, AI etc procedurally would create some rather annoying loading times - not worth it unless you then save the uncompressed game so you don't have to go through the same procedure every time you run the game.
No, they wouldn't (Score:5, Insightful)
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.
Parent
Re:No, they wouldn't (Score:5, Insightful)
All graphics are completely procedural, as in mathematically described. That means you don't get to have an artist sit down and draw them.
Then give the artist a dataflow diagram, similar to GraphEdit, to build procedures.
Puts limits on how they can look and demands a fair bit of self similarity.
Nature is self-similar.
You use a MASSIVE amount of memory in relation to your file size.
But it doesn't have to be pushed over the wire or the optical disk, which becomes important as Xbox 360 games begin to run up against the 7 GB/disc limit and PC games begin to run up against monthly download caps [wildblue.com].
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.
I forget: how big was the S.A.M. synthesizer on the old 8-bit home micros?
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.
Sure, demos aren't intended to be maintained much past the party, but some of the procedural techniques apply just as well to C or Lisp or ML or whatever if you want to trade off some efficiency to gain maintainability.
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.
Specifically, there are places where disk space is still a lot cheaper than bandwidth.
Parent
Re: (Score:2)
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]
Re:YouTube version (Score:5, Funny)
Parent
Re:YouTube version (Score:5, Informative)
Parent
Re: (Score:2)
I watched the YouTube version, and all I can say is... fuck me, that's incredible.
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:For those w/o Windows - video (Score:4, Insightful)
On second viewing, two things come to mind:
1) the opening scene from LOTR: The Two Towers, an amazing piece of design and rendering.
2) Audio player visualizations. The giveaway is the contrails appearing in sync to the music.
Is it possible RGBA are using a built-in visualization library, possibly from WMP? That would explain the high level of detail and apparent use of texture maps, which I'm guessing wouldn't fit into 4kb, algorithmic or not.
This (admittedly weak) theory can be verified by disabling the visualization library for Windows Media Player [techspot.com].
Anyone want to volunteer to verify this?
Parent
Re: (Score:3, Insightful)
I recant my rant. It really does look possible to do what RGBA did in 4KB. This thread forced me to go learn up ...
Producing mountain-like terrains with Perlin noise [iquilezles.org].
More by the same author (Inigo Quilez.) [iquilezles.org]
Truly awesome and impressive. My eyes are opened, and I'm intrigued enough to try my hand at an implementation.
Re:For those w/o Windows - video (Score:4, Insightful)
You were actually serious about the WMP thing?
It comes down to a few things:
- those common device drivers can do a hell of a lot these days
- that 4k executable expands to over 300 MB in memory when you run it
- these techniques have been perfected over decades of work
- mountain landscapes are one of a handful of real-world things that can be realistically generated with small equations
- these people are exceptionally talented
You are right to notice the similarity as there is a lot of overlap between music visualization and demoscene work. I would guess that the former arose as a result of work being done in the latter.
It's 4096 bytes, whatever you want to call that. A typical (self-imposed) demo limitation.
These things were being made long before there was a Windows or a WMP. And there are always those ones that make you feel like "this shouldn't be possible," but I suppose that's the point.
Parent
Re: (Score:2, Insightful)
>The only way to access fancy features like shaders is through the driver's API.
The API gets there somehow other than magic.
Meh (Score:3, Insightful)
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.
Re: (Score:2)
It seems to me you would also forbid a demo to use a 3d accelerator in the name of having a metric you can understand.
That's alright, but that's not really pushing your hardware to its extents.
Re: (Score:2)
Yeah, I'll have to agree. It's still impressive, but when using DirectX it just isn't the same. I don't have the D3D SDK installed now, but I recall it was possible to get a teapot to render in a few lines of code, so I'd think by not including any dependencies in the binary the filesize could be very small without getting into any extreme measures.
A few more things:
Re:Meh (Score:5, Interesting)
No, it just raises the bar. Back when all you had to work with was CGA in 320x200 it was impressive to show a rotating cube in 4k. Today, this demo nicely shows where the virtual bar is when even considering making a 4k demo. As you couldn't do "Elevated" on your 100 MHz 486 in *no* condition or with any libraries, so would you be laughed at if you presented a rotating cube or a wormhole today.
Here's an excerpt from TFA:
If you can do better, show your work :)
Parent
libraries (Score:5, Insightful)
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
It's not only about techinical skill (Score:2, Insightful)
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 [pouet.net]
Link (Score:5, Funny)
Torrent anyone ?
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: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.
Parent
Re: (Score:3, Insightful)
What is wrong today with this burst of people taking others for imbeciles ?
I did not quote the GP while saying it was 4 KB ! There was some confusion on this thread about 4kb vs 4KB so I just mentioned:
"By the way, the article says it is 4 KB not 4 kb".
You need to understand that some people may write comments in a different way that some others do when they try to prove the other poster is stupid.
To summarize I wrote :
1) The "executable" is 4KB but it must require much more memory than what is needed to di
Re: (Score:3, Interesting)
Re: (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
Re: (Score:2)
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.
Parent
Re: (Score:2)
Compression does not work that way.
KC explored (Score:5, Insightful)
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 [wikipedia.org].
Remember also that, if the judges die of old age before your demo appear, you're unlikely to place well in the compo.
Parent
Its easy to do with quantum computers (Score:3, Funny)
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.
Re: (Score:3, Insightful)
How else do you expect people to access the graphics card? They're cheating if they don't write their own GPU driver and OpenGL implementation? Should they even be allowed to run on an existing OS, or should they have to write their own?
To be fair, the old C64 demos probably overwrote a lot of the OS with their own code. DOS demos wrote directly to the graphics hardware (and hence often had very specific hardware requirements).
However, I think it's entirely fair to set competition rules that allow you to use OpenGL / DirectX etc.
Re: (Score:3, Insightful)
The difference is, the old C64 demos would run on any C64.
This '4K' demo requires gigabytes of other code to run, so you need to install a hell of a lot of other software before it will work.
It will only work on certain PCs with the right configurations too, and will break when the external libraries it uses change.
Re: (Score:2)
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.
Parent
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.
Parent
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.
Parent
Re:TROJAN?! (Score:5, Funny)
Funny is 4 KB app manages to do HDTV and your AV solution being thousands (if not millions) times bigger can't figure the difference between a trojan and packed executable. That is in case it is even packed.
Parent
Re: (Score:2, Insightful)
Indeed, it's not exactly hitting the hardware at a register level like all the proper old-school 8/16/32 bit demos in the 80s and 90s.
It's an OpenGL or DirectX demo at best, not a hardware demo.
It is still impressive of course. Especially when you consider the music engine that's taking up some of that 4KB.
Re:finally! (Score:4, Insightful)
No, don't. Then we'll have to listen to the "THEY JUST USED BUILT-IN DIRECTX FUNCTIONS FOR THIS THEY TOTALLY SUCK" crowd all over again. There's no lack of people around here who don't have a single clue what it takes to do something like that, but will yak on and on about how it is nothing impressive.
Parent
Re: (Score:3, Insightful)
Get off my lawn!
4K = 4KB = 4096 bytes. Always will be.