6 ms·
How a 64k intro is made
- Tepix 9y agoAt first I was surprised they didn't use any assembly language. However, GLSL is their replacement...
- cpdt 9y agoEspecially in 64ks, assembly isn't particularly necessary - limited use of the standard API and a good exe packer will almost always get you under the limit (especially when a lot of your code is GLSL, as text compresses well). Smaller intros like 4ks, on the other hand, will often use assembly (although completely shader-based ones are becoming more common).
- pjmlp 9y agoActually a better comparison for shader languages is doing DMA with the Blitters on the Amiga. https://en.wikipedia.org/wiki/MOS_Technology_Agnus https://en.wikipedia.org/wiki/MOS_Technology_Agnus
- walkingolof 9y agoActually the interesting part in Angus is the Copper, a small "co-processor" (which can trace its roots to the Atari XL/XE series and its ANTIC processor) that could execute instructions triggered by the beam passing specific coordinates on screen. The obvious advantage of this is that you do not need to interrupt the 68k CPU, which in the era of single digit Mhz speeds, was very nice. The blitter (and other things) could be controlled by the Copper..
- pjmlp 9y agoYes, that is what I had in mind, but could not remember any more the details how it used to be.
- Flow 9y agoYes, the Copper is a very cool thing. I've done insane copper lists with up to 52 splits per rasterline(each split is 8 pixels wide), and then a unique new set of colors for each rasterline. The result is very mesmerizing. It can look like this: https://youtu.be/d1axngYxuuo?t=3m19s https://youtu.be/d1axngYxuuo?t=3m19s and this: https://www.youtube.com/watch?v=fFeHd5hoRyM https://www.youtube.com/watch?v=fFeHd5hoRyM The Copper can also wait for the Blitter to be ready, and the Copper can give the Blitter new instructions and start a new blit. The circle would be complete if the Blitter could blit into the hardware registers for the Copper and other chips, but it cannot. :-( I think the Atari STe Blitter can do that though. But you can use the Blitter to modify the Copper list, so perhaps they together are Turing complete?
- ygra 9y agoI 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.
- majewsky 9y agoThe article mentioned that the final executable was packed again, so the GLSL source code is also stored compressed.
- hrydgard 9y agoZipped GLSL (if you're using short variable names) is usually smaller than the corresponding DX byte code, so it turns out to actually be an advantage.
- laurentlb 9y agoBoth 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.
- kodfodrasz 9y agoThere 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
- z303 9y agoPrevious discussion https://news.ycombinator.com/item?id=3840830 https://news.ycombinator.com/item?id=3840830
- will_pseudonym 9y agoFYI, there's a lot of interviews in that video that are not in English.
- kodfodrasz 9y agoI'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.
- will_pseudonym 9y agoIt was interesting. I wish I knew Hungarian. :)
- flanbiscuit 9y agothere 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.
- Audiophilip 9y agoMake sure to turn on the subtitles.
- mbrookes 9y ago
- nsxwolf 9y ago64k + gigabytes of system libraries and GPU drivers.
- mrestko 9y agoIt wouldn't be HN without an immediate dismissive comment!
- nsxwolf 9y agoDidn't intend to be dismissive. I think they're awesome. It just seems incorrect to conflate one of these 64k demos with one that runs on, say, a Commodore 64. Context is needed. There's a lot more code actually running.
- skrebbel 9y agoThat's a straw man. Nobody's conflating anything. This is a PC intro, not a C64 intro and it's advertised as such.
- camperman 9y agoQuite true. I personally don't have a problem that PC 64k intros today will leverage the GPU as much as possible, with all the help from the driver code that that implies. It's how they stay current and awesome. Of course anyone writing a 64k intro with no help at all from the GPU except perhaps context creation and teardown is just giving themselves more creative limitations that I would respect.
- nialv7 9y agoThere're 64k demos that use software rendering only.
- raverbashing 9y agoDo you know if that's specific category?
- ensiferum 9y agoGod it's a beautiful intro. Really like that science fiction like feeling to it!
- mostlyskeptical 9y agoFor 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.
- unixhero 9y agoYes most have what we refer to as "renders", so you don't have to load up your favourite hardware to run it natively.
- haberman 9y agoAt first I thought you wrote "32kb" and I was going to correct you. Note to others: that's 32 BYTES! :)
- nom 9y agohere'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
- mattnewport 9y agoGreat article, the demo scene was what got me into programming as a teenager back in the 90s and is still inspirational today!
- sofaofthedamned 9y agoYup, same here!
- teemwerk 9y agoThese 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.
- EGreg 9y agoI thought this was going to be about how to introduce people to investors who put in $64k :)
- EGreg 9y agoWhy is this being downvoted so heavily? Given the forum it seems like a very reasonable expectation.
- Neliquat 9y agoSimply 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.
- cr0sh 9y agoAfter 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.
- forinti 9y agoIn 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 9y agoIt 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).
- kenowi 9y agoAmazing. 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.
- fnord123 9y agoIf 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-sXmdrqqYYeyUpx7BvKXpcw8EbFQLR70 https://www.youtube.com/watch?v=V8JXraZPkh8&list=PL-sXmdrqqY...
- kowdermeister 9y agoOMG, thank you for this. I love looking behind the scenes in video stream format.