5 ms·

How a 64k intro is made (2017)

218 points by aragonite 2y ago

banish-m4 2y ago
Here I thought it was going to be a 64k Amiga or .COM DOS demo. This seems to be a very expensive and elaborate demo that is out of general reach.
aragonite 2y ago
Past HN discussions: - https://news.ycombinator.com/item?id=14392305 https://news.ycombinator.com/item?id=14392305 (2017 - 60 comments) - https://news.ycombinator.com/item?id=16842576 https://news.ycombinator.com/item?id=16842576 (2018 - 60 comments)
velo_aprx 2y ago
Here is a another great place to get started if you want to get into 64k size coding: https://64k-scene.github.io/ https://64k-scene.github.io/
- laurentlb 2y ago
  I came here to say that :) In particular, we have a list of making-ofs like this one: https://64k-scene.github.io/resources.html#making-ofs https://64k-scene.github.io/resources.html#making-ofs
royjacobs 2y ago
It's probably good to know that the focus in the demoscene has shifted away from 64k more towards 4k/1k intros and 'regular' demos. The amount of work required to do a high quality 64k is so huge that, especially now that the demoscene is not as big as it used to be, a lot of people don't think it warrants the time investment anymore. (Btw, the best way to prove me wrong is to write a 64k intro about it)
- whizzter 2y ago
  Actually a bunch of people that do still like them... it's just that we don't have the infinite time we had at our disposal in our teens that makes us not ever be finished :P
  - jsheard 2y ago
    Isn't that the same issue really? The demoscene seems to be in decline because there's hardly any new blood coming in, the teens who would have time to commit to a big production today just aren't interested.
    - llmblockchain 2y ago
      Teens have been so accustomed to immediate gratification and short form content they don't possess the willpower to focus on something truly difficult. You can't watch a few shorts and bust out a 4k demo over the weekend the same way you can "make minecraft in 24 hours".
      - jsheard 2y ago
        Maybe that's part of it, but I think not having any personal experience with the constraints of early computing is also a factor. The demoscene does try to keep that spirit going on modern platforms with artificial constraints like "Windows exe limited to 64kb" but I think it's harder for someone coming in fresh to appreciate the appeal of that handicap. They definitely won't appreciate the actual retro computer targets like the C64 and Amiga, why would they, those systems came out before they were born and unlike early game consoles they have almost no lasting appeal outside of nostalgia (sorry Amiga fans).
      - whizzter 2y ago
        Teens addicted to only instant gratification were never the ones to produce really good stuff in the demoscene anyhow, they will put countless hours into other arenas. Also back in the mid 1990s maybe the demoscene _was_ instant gratification to get started? You could start doing graphics with "mov eax,13h / int 10 / mov ax,a0000h / mov es,ax / mov di,0 / (loop with stosb).. ". To get started today with graphics you either setup openGL/d3d with their weird API's with decades of legacy, use something third party (and learn linking/libraries) or write a 3000 LoC hello-vulkan (Or use Unity,etc but then up until 5 years ago you'd get shouted out of the scene due to elitistic attitudes).
- laurentlb 2y ago
  It's also worth noting that the expectations around 64k got higher. We can do so much more in 64k than it was possible in the past. Compression tools have improved. If you take the famous fr-08 intro from Farbrausch and recompress it with modern packers, you would get back many kilobytes. So I think the time investment needed to make a top 64k has increased. The source code of all my 64k intros has been shared (the last one was added two weeks ago): https://github.com/ctrl-alt-test/demo-archive/ https://github.com/ctrl-alt-test/demo-archive/ and my plan is to share more code to help people get started. Creating demos using procedural generation is incredibly fun.
tomxor 2y ago
I've toyed with doing writeups of some of my demos, but one aspect I've struggled with is how the explanation of how it works is often severely departed from the process of creating it. The writeup here appears to be fairly natural, and maybe this is the true process for something as large as 64k, but I mostly do 192 byte demos, the largest I've ever done is 512 and 1024 byte. I think there is a difference at this size where the size very much takes charge of the creative process - and that can be quite interesting because you end up doing a lot of experimentation and accidentation and discover things you wouldn't normally be pushed to and can pivot the entire demo. However when deconstructing the result in order to explain it, this juts gets lost and I've struggled to figure out how to convey this duality. To only post a "how it works" would omit the part where all magic happens, yet that's hard to explain on it's own, and hard to combine with the "how it works".
- codetrotter 2y ago
  Would be cool to see a full video of the process from start to finish, if you’re up for it. That way people can get a better impression of it.
  - tomxor 2y ago
    I've actually tried that on Twitch, it was fun for another reason: viewer involvement. But as a format I found it didn't really work well because for my most impressive demos 90% of the time I'm just staring intensely at tiny fragments of code and trying to rearrange and run it in my brain - this is not interesting to watch believe me, I suppose one could condense the video to only show the ends of those segments and just talk out-loud about the concrete thought that has coalesced at the end of it and the actions that are now being taken.
    - codetrotter 2y ago
      > I suppose one could condense the video to only show the ends of those segments and just talk out-loud about the concrete thought that has coalesced at the end of it and the actions that are now being taken. I like that idea.
meta-level 2y ago
I'm wondering if there are similar demos featuring graphics and sound with strong constraints but written in Python?
- jsheard 2y ago
  Not really, the only way it makes sense for a high level language to be used in a constrained competition is if the rules are specifically set up so that the runtime doesn't count towards the size limit. There are such competitions for Javascript, where you get 64kb of HTML to play with and the size of the browser itself is "free", or for Lua via the PICO-8 runtime, but I don't think anyone has done it for Python.
  - leptons 2y ago
    There's also https://dwitter.net https://dwitter.net which has a limit of 140 characters of javascript, and the site is fairly active.
  - immibis 2y ago
    Write a Linux demo. You're allowed to use all the tools that come with the distribution (check the rules for the competition you want to enter, to see which distribution). I remember one with a Python shebang that launched SimpleHTTPServer to deliver a brotli-compressed payload to a browser.
nsxwolf 2y ago
Is it 64K period, or 64K plus access to gigabytes of external libraries?
- laurentlb 2y ago
  64kB is the size of the binary file. You can rely on an operating system (Windows, Linux...) with its graphics drivers. Basically, you can use the GPU and you can use most of the 64kB to generate procedural content.
- deleted 2y ago
  [deleted]
- amiga386 2y ago
  It's an exe <= 65536 bytes. A modern OS does have gigabytes of external libraries, but the functions in them are more "support every graphics and sound chip out there" than "draw cool spaceship" and "play a funky beat". They're not allowed to obtain anything from the internet, nor anything else beside what comes as standard with the OS. Everyone gets the same base OS and compete against _each other_, so nobody gets a special advantage. If someone finds a clever way to use the base OS for more bytes (such as reusing the standard Windows fonts or MIDI soundfont or CAB compressor), then so does everyone else, and they use the saved space for even more cool and impressive stuff next release. Here's some tricks used for 4kb demos (some of which are applicable to 64kb demos too): https://in4k.github.io/wiki/aulds-4kb-introduction https://in4k.github.io/wiki/aulds-4kb-introduction https://in4k.github.io/wiki/aulds-4k-synth https://in4k.github.io/wiki/aulds-4k-synth https://in4k.github.io/wiki/exe-packers-tweakers-and-linkers https://in4k.github.io/wiki/exe-packers-tweakers-and-linkers
- GuB-42 2y ago
  The executable has to be 64k or less and has to run by itself on a clean install of your OS of choice. There may be "gigabytes of external libraries" included in the OS, but these are necessary for using current-gen hardware. Libraries and assets that are not just for interfacing with the hardware and basic stuff like opening a window are rarely taken advantage of, except sometimes for text rendering. System decompressors used to be used, but nowadays, productions come with their own specialized unpackers (ex: kkrunchy) that are much more powerful yet smaller than anything that comes with the OS. EDIT: I see MIDI being mentioned, and it is indeed still used. But for 64k, there are softsynths that sound way better than system MIDI and only take a small part of the size budget, sometimes going as far as physically modelling instruments. 64k is crazy. These 64k intros could be made run on the bare metal with not much difference in size if there was hardware for it. But the way modern hardware is designed, it is impossible. If you really insist on going "bare metal", try an Amiga ;)
rgomez 2y ago
Coming from the "old ages" when a PC didn't even feature a (3D capable) GPU and all was about getting all the possible juice of the CPU... shaders now allow incredible things in a very small size, as long as you stick to procedural content. shadertoy.com features an insane amount of great samples.

218 points by aragonite 2y ago

Here I thought it was going to be a 64k Amiga or .COM DOS demo. This seems to be a very expensive and elaborate demo that is out of general reach.

aragonite 2y ago

Past HN discussions: - https://news.ycombinator.com/item?id=14392305 https://news.ycombinator.com/item?id=14392305 (2017 - 60 comments) - https://news.ycombinator.com/item?id=16842576 https://news.ycombinator.com/item?id=16842576 (2018 - 60 comments)

velo_aprx 2y ago

Here is a another great place to get started if you want to get into 64k size coding: https://64k-scene.github.io/ https://64k-scene.github.io/

laurentlb 2y ago
I came here to say that :) In particular, we have a list of making-ofs like this one: https://64k-scene.github.io/resources.html#making-ofs https://64k-scene.github.io/resources.html#making-ofs

royjacobs 2y ago

It's probably good to know that the focus in the demoscene has shifted away from 64k more towards 4k/1k intros and 'regular' demos. The amount of work required to do a high quality 64k is so huge that, especially now that the demoscene is not as big as it used to be, a lot of people don't think it warrants the time investment anymore. (Btw, the best way to prove me wrong is to write a 64k intro about it)

whizzter 2y ago
Actually a bunch of people that do still like them... it's just that we don't have the infinite time we had at our disposal in our teens that makes us not ever be finished :P
- jsheard 2y ago
  Isn't that the same issue really? The demoscene seems to be in decline because there's hardly any new blood coming in, the teens who would have time to commit to a big production today just aren't interested.
  - llmblockchain 2y ago
    Teens have been so accustomed to immediate gratification and short form content they don't possess the willpower to focus on something truly difficult. You can't watch a few shorts and bust out a 4k demo over the weekend the same way you can "make minecraft in 24 hours".
    - jsheard 2y ago
      Maybe that's part of it, but I think not having any personal experience with the constraints of early computing is also a factor. The demoscene does try to keep that spirit going on modern platforms with artificial constraints like "Windows exe limited to 64kb" but I think it's harder for someone coming in fresh to appreciate the appeal of that handicap. They definitely won't appreciate the actual retro computer targets like the C64 and Amiga, why would they, those systems came out before they were born and unlike early game consoles they have almost no lasting appeal outside of nostalgia (sorry Amiga fans).
    - whizzter 2y ago
      Teens addicted to only instant gratification were never the ones to produce really good stuff in the demoscene anyhow, they will put countless hours into other arenas. Also back in the mid 1990s maybe the demoscene _was_ instant gratification to get started? You could start doing graphics with "mov eax,13h / int 10 / mov ax,a0000h / mov es,ax / mov di,0 / (loop with stosb).. ". To get started today with graphics you either setup openGL/d3d with their weird API's with decades of legacy, use something third party (and learn linking/libraries) or write a 3000 LoC hello-vulkan (Or use Unity,etc but then up until 5 years ago you'd get shouted out of the scene due to elitistic attitudes).
laurentlb 2y ago
It's also worth noting that the expectations around 64k got higher. We can do so much more in 64k than it was possible in the past. Compression tools have improved. If you take the famous fr-08 intro from Farbrausch and recompress it with modern packers, you would get back many kilobytes. So I think the time investment needed to make a top 64k has increased. The source code of all my 64k intros has been shared (the last one was added two weeks ago): https://github.com/ctrl-alt-test/demo-archive/ https://github.com/ctrl-alt-test/demo-archive/ and my plan is to share more code to help people get started. Creating demos using procedural generation is incredibly fun.

tomxor 2y ago

I've toyed with doing writeups of some of my demos, but one aspect I've struggled with is how the explanation of how it works is often severely departed from the process of creating it. The writeup here appears to be fairly natural, and maybe this is the true process for something as large as 64k, but I mostly do 192 byte demos, the largest I've ever done is 512 and 1024 byte. I think there is a difference at this size where the size very much takes charge of the creative process - and that can be quite interesting because you end up doing a lot of experimentation and accidentation and discover things you wouldn't normally be pushed to and can pivot the entire demo. However when deconstructing the result in order to explain it, this juts gets lost and I've struggled to figure out how to convey this duality. To only post a "how it works" would omit the part where all magic happens, yet that's hard to explain on it's own, and hard to combine with the "how it works".

codetrotter 2y ago
Would be cool to see a full video of the process from start to finish, if you’re up for it. That way people can get a better impression of it.
- tomxor 2y ago
  I've actually tried that on Twitch, it was fun for another reason: viewer involvement. But as a format I found it didn't really work well because for my most impressive demos 90% of the time I'm just staring intensely at tiny fragments of code and trying to rearrange and run it in my brain - this is not interesting to watch believe me, I suppose one could condense the video to only show the ends of those segments and just talk out-loud about the concrete thought that has coalesced at the end of it and the actions that are now being taken.
  - codetrotter 2y ago
    > I suppose one could condense the video to only show the ends of those segments and just talk out-loud about the concrete thought that has coalesced at the end of it and the actions that are now being taken. I like that idea.

meta-level 2y ago

I'm wondering if there are similar demos featuring graphics and sound with strong constraints but written in Python?

jsheard 2y ago
Not really, the only way it makes sense for a high level language to be used in a constrained competition is if the rules are specifically set up so that the runtime doesn't count towards the size limit. There are such competitions for Javascript, where you get 64kb of HTML to play with and the size of the browser itself is "free", or for Lua via the PICO-8 runtime, but I don't think anyone has done it for Python.
- leptons 2y ago
  There's also https://dwitter.net https://dwitter.net which has a limit of 140 characters of javascript, and the site is fairly active.
- immibis 2y ago
  Write a Linux demo. You're allowed to use all the tools that come with the distribution (check the rules for the competition you want to enter, to see which distribution). I remember one with a Python shebang that launched SimpleHTTPServer to deliver a brotli-compressed payload to a browser.

nsxwolf 2y ago

Is it 64K period, or 64K plus access to gigabytes of external libraries?

laurentlb 2y ago
64kB is the size of the binary file. You can rely on an operating system (Windows, Linux...) with its graphics drivers. Basically, you can use the GPU and you can use most of the 64kB to generate procedural content.
deleted 2y ago
[deleted]
amiga386 2y ago
It's an exe <= 65536 bytes. A modern OS does have gigabytes of external libraries, but the functions in them are more "support every graphics and sound chip out there" than "draw cool spaceship" and "play a funky beat". They're not allowed to obtain anything from the internet, nor anything else beside what comes as standard with the OS. Everyone gets the same base OS and compete against _each other_, so nobody gets a special advantage. If someone finds a clever way to use the base OS for more bytes (such as reusing the standard Windows fonts or MIDI soundfont or CAB compressor), then so does everyone else, and they use the saved space for even more cool and impressive stuff next release. Here's some tricks used for 4kb demos (some of which are applicable to 64kb demos too): https://in4k.github.io/wiki/aulds-4kb-introduction https://in4k.github.io/wiki/aulds-4kb-introduction https://in4k.github.io/wiki/aulds-4k-synth https://in4k.github.io/wiki/aulds-4k-synth https://in4k.github.io/wiki/exe-packers-tweakers-and-linkers https://in4k.github.io/wiki/exe-packers-tweakers-and-linkers
GuB-42 2y ago
The executable has to be 64k or less and has to run by itself on a clean install of your OS of choice. There may be "gigabytes of external libraries" included in the OS, but these are necessary for using current-gen hardware. Libraries and assets that are not just for interfacing with the hardware and basic stuff like opening a window are rarely taken advantage of, except sometimes for text rendering. System decompressors used to be used, but nowadays, productions come with their own specialized unpackers (ex: kkrunchy) that are much more powerful yet smaller than anything that comes with the OS. EDIT: I see MIDI being mentioned, and it is indeed still used. But for 64k, there are softsynths that sound way better than system MIDI and only take a small part of the size budget, sometimes going as far as physically modelling instruments. 64k is crazy. These 64k intros could be made run on the bare metal with not much difference in size if there was hardware for it. But the way modern hardware is designed, it is impossible. If you really insist on going "bare metal", try an Amiga ;)

rgomez 2y ago

Coming from the "old ages" when a PC didn't even feature a (3D capable) GPU and all was about getting all the possible juice of the CPU... shaders now allow incredible things in a very small size, as long as you stick to procedural content. shadertoy.com features an insane amount of great samples.