How a 64k intro is made (2017)

https://www.lofibucket.com/articles/64k_intro.html

by aragonite • 2 years ago

218 46 2 years ago

lofibucket.com

aragonite• 2 years ago

Past HN discussions:

- https://news.ycombinator.com/item?id=14392305 (2017 - 60 comments)

- https://news.ycombinator.com/item?id=16842576 (2018 - 60 comments)

velo_aprx• 2 years ago

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

laurentlb3• 2 years 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

royjacobs2• 2 years 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)

whizzter5• 2 years 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

jsheard3• 2 years 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.

royjacobs2• 2 years ago

My point exactly :)

laurentlb3• 2 years 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/ and my plan is to share more code to help people get started. Creating demos using procedural generation is incredibly fun.

tomxor6• 2 years 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".

codetrotter2• 2 years 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.

tomxor6• 2 years 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.

theeandthy• 2 years ago

This is the same for any creative process. Any painter could describe how they’re reasoning about a composition and what-not. But ultimately each individual needs to digest technique and make it their own.

Writeups like this are great though because it can at least share the tools used and give folks some place to start.

mysterydip• 2 years ago

Maybe a "why it works" post would be useful, as in "this part of the demo does x because I was trying to do y but ran into this issue, which caused me to experiment with z and then a side effect inspired me to switch abc to def", etc. Personally I think explaining the creative process is more interesting than explaining the end result.

tomxor6• 2 years ago

Personally I think explaining the creative process is more interesting than explaining the end result.

Thanks, I think this is right, to focus on the process instead (and commenters indigochill and lawn) which I think are describing the same type of writeup.

Perhaps my error was starting with "how it works", whereas I probably should focus on the story of the process and add the "how it works" where it makes sense in the story. I also don't really try to record the process at the moment, it's just from memory.

lawn• 2 years ago

I know nothing about the subject but an idea is to use a "let's make a demo" story to, as you say, capture the important journey instead of the end result.

It takes more effort than a simple "how it works" explanation but if done correctly I think it should explain how the demo works while also capturing the magic of the creation process.

kaoD• 2 years ago

How long does it take you to make a demo? Might be cool to do a live streaming, or just record the process even if not live.

tomxor6• 2 years ago

Sometimes I do it in one sitting, sometimes that's quite long, like 12 hours or more! Other times I will revisit it over days or months - You'd be surprised how much thought and transformation can go into 192 characters. It depends how much potential room for improvement it "feels" like there is left, you get a sense for it, sometimes you just know it's done, others you're never quite sure when to stop trying to push harder.

I've commented in a sibling my experience live streaming which was interesting. Another Demoscener who has given this far more concerted effort on Twitch is KilledByAPixel, I think they are recorded somewhere maybe on youtube. My two attempts are lost to time.

As an example (yes shameless plug) I wrote this one recently over a couple of long evenings, I'd estimate 8 hours maybe:

https://www.dwitter.net/d/31805 (runs fastest in Firefox)

But there are some familiar micro-raymarching techniques I've already developed and reused in this. The bit that took most of the time in this one was figuring out how to fit binary search marching that was required to support large differences in marching distances and textures without producing excessive moire effects.

indigochill• 2 years ago

Although a different context, I always find the writeups of cybersecurity CTFs that go through the "What I was thinking, what surprises I encountered, how I pivoted" process both more enjoyable and more enlightening than writeups that simply explain the solution as if it was known from the beginning.

At the same time there might be some editing since there might have been approaches tried that didn't go anywhere, and whether that's interesting/relevant to the reader is probably a judgement call from someone who knows the domain and whether those dead ends might have been natural things to try in that specific context.

divbzero• 2 years ago

the explanation of how it works is often severely departed from the process of creating it

This description rings true for a whole swath of creative endeavors, including ones like demos that appear technical on the surface: optimizing an algorithm, conducting scientific research, building an engine, constructing a mathematical proof, and so on.

GuB-422• 2 years ago

High-quality 64k intros usually need a film-like production process nowadays, except it is harder because you have to fit it into 64k later, it typically means procedurally generating everything as well as using the appropriate tools (runtime packers, compiler options, etc...). It is, I think, the most demanding demoscene category.

There is much less commitment in a tiny intro. You don't have days of preparation, storytelling, art direction, etc... to stick to. If, when optimizing your intro, you stumble on something better, you are better off throwing everything away and build on that instead, "everything" is just 192 bytes after all. I didn't know 192b was a thing BTW, I am more accustomed to powers of two, like 256b.

tomxor6• 2 years ago

It's 194 bytes I keep getting it wrong :D yeah it's a strange size, the short version is SMS (140 bytes) => twitter => dwitter => unicode packing of ascii with JS decoder (which could not be undone because the limit was defined as unicode points) yields 194 bytes.

If, when optimizing your intro, you stumble on something better, you are better off throwing everything away and build on that instead,

Exactly this, but because of the extreme size limitations you often end up forced to iterate out of frustration trying to fit something, and then something else weird but interesting will often pop out of that process that you wouldn't have directly thought of.

DrewADesign• 2 years ago

I straddle the tech/art gap as a tech artist in 3D VFX & Animation. I've done work as visual as branding and identity, and as technical as network performance and a back-end web development. I'm also a technical writer for a commercial rendering engine, which is pretty different, but I've some experience reading and writing about these things.

Technical folks often approach process write-ups as they would an incident report, or a tutorial. Rarely a pleasant read! A little prep before you start yields major improvement: First, decide exactly what you're saying, and to whom. For a big one, having a "story" part, a prosaic technical write-up, and a reference section can fit multiple people's needs. Then, consider exactly what your audience wants and needs to know about your message: try not to be overly broad. Make that into a simple narrative and story arc, and expand it into an outline. It sounds like boilerplate, but it's more like scaffolding. Correctly applied, it steers you towards a concise, compelling piece without endless dickering and waffling about what to say next. Start with the broadest, least specialized audience-- adding details is easier than editing them out.

lupire• 2 years ago

If you write your demo in a recording editor, then when you're done, you can go back and watch the playback of all your edits and add commentary.

tomxor6• 2 years ago

Interesting idea, thanks!

meta-level• 2 years ago

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

jsheard3• 2 years 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• 2 years ago

There's also https://dwitter.net which has a limit of 140 characters of javascript, and the site is fairly active.

immibis5• 2 years 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• 2 years ago

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

laurentlb3• 2 years 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.

amiga386• 2 years 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-4k-synth

https://in4k.github.io/wiki/exe-packers-tweakers-and-linkers

GuB-422• 2 years 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 ;)

Silphendio• 2 years ago

You can still make stuff that runs from the boot sector. You just won't have access to fancy graphics drivers.

I found this: https://github.com/nanochess/RayTracer

banish-m4• 2 years 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.

rgomez• 2 years 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.

How a 64k intro is made (2017)

Related Stories