Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Graphics

Demoscene: 64k Intros At Revision Demoparty 207

An anonymous reader writes "Last week-end at Revision demoparty, demosceners have pushed further the limits of what can be done in a single 64kb executable file. Using extensive procedural techniques and compression, Gaia Machina (video capture) and F — Felix's Workshop (video capture) are realtime animations, featuring high quality rendering, sound, 3D models, and textures."
This discussion has been archived. No new comments can be posted.

Demoscene: 64k Intros At Revision Demoparty

Comments Filter:
  • ...you're not part of the intended audience. Admittedly, there's a lot of necessary hardware support to get these kinds of results, but still... full A/V in a space less than the banner image of most websites. Makes you wonder what could be done with similar techniques and, say, a megabyte of space.
    • Well, Farbrausch did release .kkrieger [farbrausch.de] , which is a 96k FPS with Doom 3 graphics. Not much in the gameplay department, but it's still a revolutionary example of what can be accomplished within a small filesize.

    • by AmiMoJo ( 196126 )

      Makes you wonder what could be done with similar techniques and, say, a megabyte of space.

      Grab an Amiga (or emulator) and find out. Amiga floppy disks are 880k, and there are plenty of one or two disk demos. The results are damn impressive.

  • I saw a couple of demo files years and years ago. DOS-based stuff. I think they were probably 16k files. I was amazed at how long the animations and music lasted from a 16KB EXE file. The demo just went on and on, for like ten minutes. Had some fairly impressive animations too. But it was all line-based sorts of things, like old screen savers.

    But this... this is insane. I can't even believe what I'm seeing. I'm downloading the 720p version of the first video in MP4 format, and it's 91MB. A 91MB full-motion

  • by tgd ( 2822 ) on Tuesday April 10, 2012 @09:09AM (#39629705)

    /. is really making me feel old these days -- I was writing demos in the early 90's. I don't know if its my overall grumpy old-man mentality or not, but as impressive as these are, they're powered by a crap-ton of software running behind them. There's not 64k of assembly pumping bytes into a framebuffer and twiddling the PC speaker port to synthesize digital audio.

    One thing I couldn't find in there (and I've been out of the scene for a LONG time, so I don't know how this works on new-fangled fancy computers...) -- do these write directly to the video hardware? Or do they use OS services like DirectX11, etc? When they say 64k, is it a 64k executable using up another dozen meg of OS DLLs?

    I have to give it to them, they are very impressive. But are people still getting down and counting clock cycles?

    Anyway, for you youngins, this might explain the demoscene a bit better: http://www.youtube.com/watch?v=iRkZcTg1JWU [youtube.com]

    • do these write directly to the video hardware?

      No, that would be impossible on modern computers (unless you would only run the demo on one gfx card - and maybe even only on one specific firmware version at that). The closest I know of is the 4k demo Elevated [youtube.com] by RGBA and TBC. Everything except audio is done by shaders on the graphics card. Even the camera movements are done there (as the cpu don't even know how the terrain looks).

      IIRC they started with an OpenGL initialization to get the shader code to the GPU, but later switched to DirectX, because tha

      • by tgd ( 2822 )

        do these write directly to the video hardware?

        No, that would be impossible on modern computers (unless you would only run the demo on one gfx card - and maybe even only on one specific firmware version at that).

        Admittedly its been a while, but the VGA interfaces are still on those cards. If you needed higher rez, the VESA interfaces were pretty broadly supported ten years ago. I assume they're still buried down deep on those cards. But I grant you that utilizing more than just the framebuffer, you need to code to specific cards. But during the mid 90's, that was pretty common -- you saw lots of demos coding to specific cards like the early ATI Rage or (much more commonly) the 3DFX VooDoo cards. Same with audio har

        • Since modern operating systems won't let you directly access hardware, the only way to do what you want is to bypass the OS, and thus write drivers for any hardware you may want to use. And the resulting demo will only run on your particular machine, or one extremely similar to it. Good luck with that.

          As for counting cycles, I don't think it's even possible in modern CPUs due to how they run instructions out of order.

      • by bored ( 40072 )

        (per writing to the hardware)

        No, that would be impossible on modern computers (unless you would only run the demo on one gfx card - and maybe even only on one specific firmware version at that).

        If by "modern" you mean linux, there is fbdev which has a semi standard kernel interface for providing drivers that export the framebuffer. You mmap the local fbdev device into your process. Its fairly cross platform and cross video card (for many older ones it uses the VESA API). Sure it won't let you twiddle the PC

        • But even then you're sitting on top of the entire linux kernel, the video drivers AND the framebuffer API. Not really much different from DirectX.
          • by bored ( 40072 )

            yes... same with vesa, and another poster pointing out that even in the DOS days people depended on the DOS for file io, and setting up the initial execution environment.

            That said, the closest thing in windows (that i'm aware of) to the fbdev in linux is the deprecated directdraw hardware surface (which is a darn lot like SDL!). As I understand it, directdraw is completely emulated in software since vista. Even back in the w2k days it didn't give you full access to the hardware framebuffer, instead giving y

            • You don't want direct access to the hardware framebuffer, regardless if its over PCIe or not, unless you're a video driver.
              • by bored ( 40072 )

                I'm not sure I agree with this 100%. In general no, most apps don't need or shouldn't have access to an actual framebuffer. Thats assuming something that even makes sense as a framebuffer is available.

                On the other hand, the topic of mirror drivers comes up fairly frequently on ntdev, because windows lacks the ability to access the framebuffer directly. Sometimes people with legitimate needs want to know what parts of the screen are being updated, etc..

                So, there are reasons for lower level access to the vide

    • by Hatta ( 162192 ) on Tuesday April 10, 2012 @09:37AM (#39630037) Journal

      Or do they use OS services like DirectX11, etc? When they say 64k, is it a 64k executable using up another dozen meg of OS DLLs?

      That was exactly my question. If it's not 64K running on bare metal, it's cheating.

      • That was exactly my question. If it's not 64K running on bare metal, it's cheating.

        Running on bare metal is hardly feasible these days, as hardware is so varied. You need the driver APIs to get anything done. Or you can watch Amiga-demos from the same compo (some incredibly good stuff there as well), but remember that they're also "cheating", employing Denise, Paula and Agnus as they are. For shame, they probably even use the blitter instead of doing it in CPU!

        And - did you actually *see* "Gaia Machina"? As there is no way they can pack all that geometry pre-made in 64KB, far less texture

        • by Hatta ( 162192 )

          Running on bare metal is hardly feasible these days, as hardware is so varied.

          A tiny demo that runs on exactly one piece of hardware is more impressive than a 100mb demo that runs on everything.

          Or you can watch Amiga-demos from the same compo (some incredibly good stuff there as well), but remember that they're also "cheating", employing Denise, Paula and Agnus as they are. For shame, they probably even use the blitter instead of doing it in CPU!

          That's hardware. Fair game.

          Yes, they get a lot of 3d function

          • by k8to ( 9046 )

            You're out of date.

            The idea of demos and intros shifts over time. Originally, intros weren't even designed with any sort of 'competition' in mind at all, so the whole idea of 'cheating vs 'not cheating' couldn't even apply.

            Nowadays, the idea of "showing lots of polygons texture mapped etc" isn't very interesting, because the hardware can this so well that there's nothing interesting to show by being clever. So the demoscene has moved on: Demos are typically more about doing something visually creative, w

          • "No true Scotsman" fallacy? :)

            Of course, unless you've created your own demo platform (all the way from mining your own minerals... Oh, and making your own pick to mine the minerals.. And ...), you're just using what others have done for you already.

            You have to set a limit somewhere. You just seem gruff because you've arbitrary set the limit a different place than the competition holders. Most of the old DOS demos used BIOS routines, after all.

            The compo rules for win 64kb :

            Windows:
            * The compo machine will be installed with Windows 7 64bit, however all entries have to be supplied in 32bit exe format and be able to run in a 32bit environment!

            * We will provide the then-latest DirectX distributables.

            * The "Media" and "Music samples" directories will be deleted from the compo machine.

            * .net Entries : We will install the then-current version and patches of the latest .net runtime.

            * And in case someone might still have this mad idea : We will not install any drivers or virtual machines to provide or improve DOS compatibility.

            64k intro:

            * Maximum file size is 65536 bytes for the executable. All other files in the archive will be deleted before showing the entry in the competition.

            * Maximum running time: 8 minutes (including loading/precalc).

            * We will not install any additional Runtimes, SDKs, Codecs, Drivers etc on the compo machine. This means that, among others, msvcr70.dll, msvcr71.dll and msvcr80.dll will not be available.

            * You may not use the contents of the Windows "Media" or "Music Samples" directories. These directories will be deleted on the compo machine.

            * Java entries are not allowed

            * .net entries are allowed when they follow the rules listed above.

            Pretty reasonable for a windows d

      • Or do they use OS services like DirectX11, etc? When they say 64k, is it a 64k executable using up another dozen meg of OS DLLs?

        That was exactly my question. If it's not 64K running on bare metal, it's cheating.

        What a clown.

      • by sqldr ( 838964 )

        we crammed a LOT of code into 64k. when it decompresses, it explodes into about 800 megs of calculations before it starts, but you have a point, and I'd like to see you prove it by releasing a 64k demo that beats one of ours..

    • There's not 64k of assembly pumping bytes into a framebuffer and twiddling the PC speaker port to synthesize digital audio.

      Of course. But all the creative work is squeezed into 64K.

      One thing I couldn't find in there (and I've been out of the scene for a LONG time, so I don't know how this works on new-fangled fancy computers...) -- do these write directly to the video hardware? Or do they use OS services like DirectX11, etc?

      They use DirectX, because that is the only way to support a reasonable range of hardware. (Also, you can't hit the hardware without installing a new driver or exploiting a kernel bug. Neither of which is very friendly.)

      But are people still getting down and counting clock cycles?

      Cycle counts aren't even documented today. Now it's all about avoiding cache misses and cache invalidation.

    • Yeah yeah old man (Score:4, Insightful)

      by SmallFurryCreature ( 593017 ) on Tuesday April 10, 2012 @09:52AM (#39630255) Journal

      But in your days it was easy, you could count the clock cycles on the fingers of one hand and if you wanted a bit flipped you just climbed inside the computer with a hammer!

      Anyway, you weren't all that impressive, you relied on a blacksmith for a hammer and a miner for the coal to fire your machine. You were just the slave master benefiting from the slave labor of others.

    • by AmiMoJo ( 196126 )

      The rule is that the executable must be 64k and not use an data files. DLLs are allowed, however, and all of these demos use Direct X for video and sound.

      The objects and textures are procedurally generated with a bunch of pixel shaders thrown in. Often they take minutes to load even on a high end machine as they do all the generation. No-one counts clock cycles because the target hardware is abstracted anyway.

      A long way from the way things used to be, hitting the bare metal. In fact the original limit was 4

      • They may have moved to 64k because that was the maximum size of an executable .COM file on CP/M and MS-DOS.

    • by sqldr ( 838964 )

      do these write directly to the video hardware?

      I'm meaty. I coded the synth in gaia mahina. We link against opengl, but we had to do some real dirty shit to throw out stdlib and don't get me started on the manifest. There were oldskool demos at the party on A500s and C64s, but don't get us wrong.. we had to do some crazy shit to get it down to 64kb. It was exactly 65536 bytes after some work. Try getting something like that down to 64k and you will see.

      PS. have 15k of muisc: http://spacepigs.com/meaty-al [spacepigs.com]

  • The summary says 64kb (kilobits), or 64,000 bits. That's 7.8125 KiB (kibibytes), or 8,000 bytes. The competition is actually for 65,536 bytes, or 64 KiB.
  • they have been doing it for two decades ... you should forward this story to my mom, she might be astounded by it

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...