The 64kB is a category in the demoscene where the total executable size must be less than 65,536 bytes, and at that size, storing vertexes, edges, and normal maps is a waste of space. [Ctrl-Alt-Test] is a French Demoscene group that has been doing incredible animations for the last 13 years. They’ve written an excellent guide on how they’ve been procedurally generating the meshes in their demos.
It all starts with cubes. By stacking them, overlaying them, reusing them, and tiling them you can get better compression than raw vertexes. Revolution was the next trick, as it uses just a few points, plotting it via Catmul-Rom splines, and revolving around an axis. The numbers are pairs of 32-bit floats and before compression, a detailed pawn on a chess board can weigh in at just 40 bytes. Just these few techniques can take you surprisingly far (as seen in the picture above).
They later worked on deforming cubes and placing them into a semi-randomized column, which happened to look a lot like plants. This isn’t the first generated vegetation we’ve seen, and the demoscene technique focused more on getting the shape and setting the mood rather than being accurate.
Signed distance fields are another useful trick that allows you to generate a mesh by implementing a signed distance function and then running a marching cubes algorithm on it. In a nutshell, a signed distance function just returns the distance to the closest point on a surface from a given point. This means you can describe shapes with just a single mathematical equation. As you can imagine, this is a popular technique in the demoscene world because it is so space efficient in terms of code and data. [Ctrl-Alt-Test] even has a deep dive into one of their projects, Immersion, with a breakdown of where the space is allocated.
There are plenty of other tips and tricks here, such as generating textures and developing a C++ hot reload system for faster iteration. It’s just incredible that the executable that plays the whole video is smaller than just a JPEG screenshot of the video. It’s a reminder that the demoscene is still fascinating with new tricks and experiences even as the hardware stays the same.
Farbrausch is another long time demo group that’s done some 64K and other size constrained demos. Unfortunately some of their older ones don’t render correctly or even run at all on newer versions of Windows.
177k for that one for example:
https://www.pouet.net/prod.php?which=30244
Their first demo was released in 2000, and they’ve released well over 100 demos and other things since. fr-030: candytron (party and release versions) is one that doesn’t play nicely with later DirectX versions. Would be nice if they’d do a revisit on their old demos from the Win9x-XP era that have glitches or don’t work at all on Windows Vista and later.
How unfortunate. The good news is that they seem to run just fine on Linux with WINE.
As I was scrolling down and the picture started to appear, my immediate thought was “that looks like it was computer-generated”. Yet when I study it I can’t quite pinpoint the cues that alerted me to the fact. It feels like an ‘uncanny valley’ effect; when I see that in videos I can usually describe why it feels uncanny, but here I can’t. There’s a dream-like quality in the picture, but I don’t know why.
Usually by being too perfect.
Simple smooth shapes. Graphical textures but not physical texture. And simple lighting. Yeah it reminds me of pre-rendered cutscenes from 90s video games
A cutscene from the mid-90s, with the size of a program from the early 80s
With SDF there arent any meshes. Johann Korndörfer of Mercury has some nice content for SDF’s
https://www.youtube.com/watch?v=s8nFqwOho-s
And if you want to turn SDF into a mesh (e.g., for an opengl rendering if it is too complex for ray marching), there is always Marching Cubes.
The point of the SDF is that you can easily raymarch (or better spheretrace) seemingly very complex geometry. A grid of 1k x 1k x 1k spheres is hard as a mesh but very simple as a sphere traced SDF. or look https://www.shadertoy.com/view/3dGSWR
With SDF you don’t ever generate meshes. Johann Korndörfer of Mercury has some nice intro on how to use SDF to create content:
https://www.youtube.com/watch?v=s8nFqwOho-s
Sort of the best of both worlds of voxels and 3D meshes? AFAIK nobody ever figured out how to hardware accelerate voxel rendering. With as many voxel graphics games as there was some years ago, I was surprised 3Dfx, ATi, nVidia, or S3, none of them came up with hardware voxel rendering and acceleration. Not even any of the smaller players in the video chip game like Rendition, Cirrus Logic, or Trident bothered with having a look at it.
It’s an amazing demo! I’m flabbergasted that they could create such a long and detailed video and sound in just 64k bytes.
But what does the “64k bytes” limit mean? Is it the size of the C source, or the compiled C program? For what CPU and video system? Is it using external libraries, or code in the OS or system ROMs?
64K for the compiled program. Ideally 100% of the compiled code should be used to create the demo graphics and sound. Some demos have a text scroll at the end to pad out the compiled size. That’s typically used for ‘greetz’ to other groups, promotion of the demo group, and explanations of some of the techniques used in the demo. Farbrausch’s fr-08: .the.product has a scroll at the end that tells the total generated sizes of the sound, geometry, and textures from the 64K executable. IIRC it’s over a gigabyte of data generated and streamed on the fly.
The demoscene has parties, usually somewhere in Europe, where people start from scratch coding their demo at the party. They have a time limit to produce the compiled binary. Often the groups will refine their demo (especially if they won or placed high in the competition) so they have a party version and a release version.
If you want to try your hand at creating state of the circa 2012 art demos, Farbrausch released werkzeug4, their own tool they wrote for making some of their demos. https://www.pouet.net/prod.php?which=91144 They have source code available on github for this and all their tools prior to it.
They even did a 3D first person shooter, packed into a 96K executable. Look for .kkrieger
From the link:
“64kB intros, 64k for short, are like demos but with an added arbitrary limitation on the size: they must fit entirely within a single binary file of no more than 65536 bytes. No extra assets, no network, no extra libraries: the usual rule is that it should run on a freshly installed Windows PC with up to date drivers.”
HAHAHAHA. Amateurs. You must not be aware of the team that recreated most of the first level of Descent, procedurally, in real-time 3D, IN -FOUR- F##KING KILOBYTES OF CODE. WITH MUSIC. Behold, Omniscent.. https://www.youtube.com/watch?v=G1Q9LtnnE4w
You know,there used to be some computers(myself remembering my c64) with only 64kb ram,they used to have great demos/intros or games,obviously under 64kb(subtract some basic rom/kernal and other stuff to leave maybe 32kb free ram)
On x86 platform, 64KB also equal the size of a *.COM file/a segment.
Pah, Kilobytes is for losers!!!!!!! 256 bytes is King. One 256 Byte demo has been featured here before: https://hackaday.com/2020/04/21/a-jaw-dropping-demo-in-only-256-bytes/. Which means the size of the demo’s executable is the same as this post!!!!!!!!!
Great, now do the same on Windows 3.x or OS/2. That’d be a challenge.
It would merely require more space and computational power. The foundational point of a size limited demo is maximally use what is available.
I aggree, though those platforms don’t provide ready-made functions for every occasion. They’d require much more trickery, thus. Basic audio i/o and 2D graphics acceleration is already available, though.