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."

4 of 255 comments (clear)

  1. libraries by Anonymous Coward · · 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

  2. KC explored by eddy · · Score: 4, 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.

    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.
  3. No, they wouldn't by Sycraft-fu · · Score: 4, 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.

    1. Re:No, they wouldn't by tepples · · Score: 4, 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.

      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.