
How a 64k intro is made - kowdermeister
http://www.lofibucket.com/articles/64k_intro.html
======
kodfodrasz
There is a nice documentary on the history of the demoscene, with some
introspection to the creative process behind a demo/intro. It was made by a
Hungarian team, who has other interesting documentaries on underground
culture.

It is also available in English, at:
[https://www.youtube.com/watch?v=iRkZcTg1JWU](https://www.youtube.com/watch?v=iRkZcTg1JWU)

~~~
will_pseudonym
FYI, there's a lot of interviews in that video that are not in English.

~~~
kodfodrasz
I'm sorry to hear that. There should be CC available, but to be honest I have
only watched the Hungarian version in full length, and only knew about the
existence of the English version.

I hope you still find it interesting.

~~~
flanbiscuit
there are English subtitles available, you just need to turn CC on in Youtube
and click the gear next to to make sure it's set to English.

------
forinti
In the other sciences, you strive to take the complexity of the world and to
reduce it to underlying principles. In Computer Science, you start with very
simple rules and strive to build as much complexity as possible. This is what
I really like about demos: they represent what I think makes programming
interesting.

~~~
westoncb
It seems like we do go in the other direction, too, though. When computer
scientists encounter some new problem domain—e.g. rendering photorealistic
scenes at 60 frames per second—people analyze the domain into various
'primitives' or underlying principles. We don't have the same notion of
'truth' in selecting a set of underlying principles like you get in the
sciences, though, which means multiple sets can survive and be used in
different contexts (e.g. using raymarching and distance functions, versus
using triangle meshes and Phong shading)—there doesn't only have to be one.

Then at some point, other engineers _use_ those 'underlying
principles'/primitives in order you build up particular complex instances of
whatever domain was analyzed in the previous stage—but it does start with the
science-like analyzing and 'theory building' (not literally—it just has an
analogous structure/role).

------
mostlyskeptical
For wanting interested in this stuff, check out pouet.net
([http://www.pouet.net/prodlist.php](http://www.pouet.net/prodlist.php)). They
have demos as small as 32b. Most of them have YouTube mirrors and usually they
have the executables if you'd like to verify yourself.

~~~
haberman
At first I thought you wrote "32kb" and I was going to correct you.

Note to others: that's 32 BYTES! :)

~~~
nom
here's an 8 byte demo :>
[http://www.pouet.net/prod.php?which=63126](http://www.pouet.net/prod.php?which=63126)

asm file is included

------
fnord123
If you like this stuff then you may also be interested in an excellent
streamer (ferrisstreamsstuff - mentioned in the extra stuff section) who often
makes demos:

[https://www.youtube.com/watch?v=V8JXraZPkh8&list=PL-
sXmdrqqY...](https://www.youtube.com/watch?v=V8JXraZPkh8&list=PL-
sXmdrqqYYeyUpx7BvKXpcw8EbFQLR70)

~~~
kowdermeister
OMG, thank you for this. I love looking behind the scenes in video stream
format.

------
teemwerk
These are always so wonderful. The size limitation is the icing, they are
always so gorgeous on their own. The advantage is always in seeing what cool
tricks they do to make awesome stuff that is defined by such little
information.

------
mattnewport
Great article, the demo scene was what got me into programming as a teenager
back in the 90s and is still inspirational today!

~~~
sofaofthedamned
Yup, same here!

------
ensiferum
God it's a beautiful intro. Really like that science fiction like feeling to
it!

------
cr0sh
After quickly skimming this article, I got sucked down the rabbit hole of "ray
marching" \- in concept, and implementation (mainly as a shader). The idea and
how it works was fascinating, if a little above my head mathematically. I got
the general gist of the idea, though; it's kinda a combination of ray casting
and ray tracing, where you send out the rays and step along them, but in ray
marching you don't cast secondary or tertiary (or more rays) like you do in
ray tracing (thus limiting the processing, but also the level of realism) and
instead continue to "step" (ie - "march") along the ray past the intersection,
to gather more information (and thus you can do volumetric stuff with
transparency - smoke, water, clouds, marble, skin, etc).

Stepping is done using something called "sphere tracing" \- where for each
step along the ray, you compute a sphere, and where it intersects the scene,
and only step that far; as you get closer to surfaces, the spheres become
smaller (and so do the steps and more computations) - this keeps you from
sampling along the ray where there is no scene, and stepping along the ray in
larger "jumps" to keep the computational reqs down (it has limitations,
particularly along edges of objects, and complex scenes).

For 4k comps (and in general, I think) objects of the scene are described
algorithmically (ie - you don't create a model of a sphere or torus or cube,
but rather the mathematical representation of it) - so intersects with the ray
become a bit trivial. At the same time, complex scenes can become tedious to
lay out, so you typically see tessellations and repetitions of scene objects,
or other mathematical constructs are used (fractals and the like) that can
generate complexity from simple representations (thus, procedural rendering
and representational concepts come into play of course).

There was a ton more involved (found interesting shadertoy demos from known
authors, going over the concepts of how raymarching and related techniques are
used - especially in the context of GPU shader rendering, where it is
frequently used in 4k compos - the idea of "two triangle demos", doing
everything in the shaders) - and I probably got a lot of this wrong or over-
simplified (as I said, I felt a lot went over my head in the math arena).

But I think I got the gist. Regardless, it was a fascinating exploration, and
taught me some new things I didn't know about until then; I haven't kept up
much with the demoscene since I stopped playing around with my Amigas a long
time ago (aside from the occasional amazing demo or whatnot here and there -
especially those authors who like to push their Craft - hint-hint - using
microcontrollers). So it was nice to see what "state of the art" was. Although
- milkytracker is still being used as well - which is nice to see.

~~~
westoncb
I think that's a pretty nice overview you have. One thing I would clarify is
about how the objects in the scene are represented mathematically: it's done
using 'signed distance functions' so every object you have in the scene is
actually created through one of these functions which takes a point in 3D
space and returns the distance to the nearest point on the object's surface to
that point—which does, as you say, make the object/ray intersection testing
trivial (the return value of this function is the radius of the sphere used to
step along the ray).

The other basic components when creating scenes to be raymarched are distance
functions which combine other distance functions together. The simplest cases
are just union and intersection, but it's easy to get more interesting things
like smoothly blending objects together. This page is a nice reference of
these 'combining' functions as well as distance functions for geometric
primitives: [http://mercury.sexy/hg_sdf/](http://mercury.sexy/hg_sdf/) I think
that combining power is one of the main reasons to use raymarching/distance
functions: building procedural content this way is faaar easier than trying to
knit triangle meshes together.

Additionally, if anyone wants to go a little further on the subject of
building up sophisticated content by raymarching distance functions, this is
an excellent talk on the subject:
[https://www.youtube.com/watch?v=s8nFqwOho-s](https://www.youtube.com/watch?v=s8nFqwOho-s)

~~~
userbinator
Here is another page on distance functions...

[http://www.iquilezles.org/www/articles/distfunctions/distfun...](http://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm)

...written by one of the authors of this amazing 4k ( _four kilobytes!_ )
demo:

[https://www.youtube.com/watch?v=jB0vBmiTr6o](https://www.youtube.com/watch?v=jB0vBmiTr6o)

------
Tepix
At first I was surprised they didn't use any assembly language. However, GLSL
is their replacement...

~~~
ygra
I wonder how common GLSL is for demos, though; as far as I know you have to
have the actual source text and send that to the driver at runtime for
compilation. In contrast, shaders for DirectX are AOT-compiled, greatly
minimising their size. An executable packer might mitigate that for the most
part, although it probably depends.

In this particular case they noted that they weren't size-constrained anyway.

~~~
laurentlb
Both GLSL and HLSL are very popular, for both 64kB intros and 4kB intros. Even
Elevated is storing the actual text in the binary
([http://www.pouet.net/prod.php?which=52938](http://www.pouet.net/prod.php?which=52938)).
Compressed text can be quite small.

I wrote a minifier specifically for these use-cases and it has been used in
many demoscene productions:
[https://github.com/laurentlb/Shader_Minifier](https://github.com/laurentlb/Shader_Minifier)
On a 64kB intro like Guberniya, it can save a few kilobytes (but size was not
an issue for them) - after compression.

------
kenowi
Amazing. Brings me back to the 90 and my days with the FUEL coders when
putting asm as first line of your demo was the thing to do.

------
nsxwolf
64k + gigabytes of system libraries and GPU drivers.

~~~
taway_1212
They mostly provide hardware abstractions; I suspect that the intros, if coded
in 100% bare metal (Amiga style), wouldn't be that much larger.

~~~
royjacobs
Indeed. PC 64k intros in the 90s were just as popular. Initially running on
MS-DOS but later moving to Windows. Unless you have some memory-mapped
interface to the underlying hardware (like the C64/Amiga) you'll always have
device drivers, I don't see how that's "less impressive" at all.

It's not like a device driver has an undocumented "MakeAwesome()" call that
modern 64k intros are abusing.

------
EGreg
I thought this was going to be about how to introduce people to investors who
put in $64k :)

~~~
EGreg
Why is this being downvoted so heavily? Given the forum it seems like a very
reasonable expectation.

~~~
Neliquat
Simply put, it does not add to the discussion. It is mildly amusing a personal
quip, that invites no further insight. It is also not relevant to the link,
which is not always startup funding related. HN is picky about the commens it
promotes, and most of us feel thats a good thing.

