Really well done. It's a bummer that source code are rarely released for demos.<p>For me one of the best of all times is Second Life [1], by Future Crew. Developed in 1993 nonetheless, it was a big breakthrough at the time, with almost 10 minutes of animation, and in early x86 hardware. Source code available [2].<p>[1] <a href="https://www.youtube.com/watch?v=rFv7mHTf0nA" rel="nofollow">https://www.youtube.com/watch?v=rFv7mHTf0nA</a><p>[2] <a href="http://fabiensanglard.net/second_reality/index.php" rel="nofollow">http://fabiensanglard.net/second_reality/index.php</a>
A note on the architecture from the demo:<p>The vast majority of ancient buildings follows quite simple procedural methods that only very recently got reverse engineered:<p><a href="https://www.researchgate.net/profile/Francisco_Javier_Roldan-Medina/publication/283490185_Unraveling_the_Classic_Proportions_Through_the_Anthropometric_Analysis_of_the_Architectural_Heritage_The_Case_of_the_Pantheon/links/563a4dd908ae405111a5841f/Unraveling-the-Classic-Proportions-Through-the-Anthropometric-Analysis-of-the-Architectural-Heritage-The-Case-of-the-Pantheon.pdf" rel="nofollow">https://www.researchgate.net/profile/Francisco_Javier_Roldan...</a><p>(I suspect this method also permits approximating the plastic number [ <a href="https://en.wikipedia.org/wiki/Plastic_number" rel="nofollow">https://en.wikipedia.org/wiki/Plastic_number</a> ], but so far it seems nobody has figured out a way to do so yet. I mention this due to the architectural relevance of the plastic number.)<p>I speculate that leveraging this fact could likely permit even more complex architecture in demos. (And, to mention an off topic point, it likely has some relevance for automating UI layouting.)
I used to do a lot of demoscene stuff as well [1]. I've been trying to get back into it but I've found that all of the software engineering I've done in the meantime has kind of driven the "just get it working" mindset away somewhat.<p>I used to just write code that "happened" to work, more or less. Nowadays I would want to get unit tests in place, make it cross-platform if at all possible and get a nice GUI going for easy tweaking. It's made it impossible for me to get anything done in the limited free time I have :) ideally I'd write it in Rust, but there, too, I am waiting for tooling to catch up. I get the feeling that I'm not so much waiting for the tooling, but I'm using the waiting as a sneaky way of procrastinating and fooling myself...<p>[1] <a href="http://www.pouet.net/groups.php?which=65" rel="nofollow">http://www.pouet.net/groups.php?which=65</a>
A previous discussion of the source code of a 4K demo, 'Elevated', by Rgba, with a link to a really good dive into it by Iñigo Quilez, who worked on it:<p><a href="https://news.ycombinator.com/item?id=11848097" rel="nofollow">https://news.ycombinator.com/item?id=11848097</a>
This is the kind of stuff I grew up on, so when I’m critical of the software and the implementations here, the bloat, the unnecessary dependencies, the slowness... this is the standard I judge them against. The mentality and the techniques in the article are applicable to any kind of software. When applied correctly, they make any software small and fast.
Another great writeup of making of a 64k: <a href="http://www.lofibucket.com/articles/64k_intro.html" rel="nofollow">http://www.lofibucket.com/articles/64k_intro.html</a>
Well the first optimization would be to roll my own libc (not that hard at all :) ) where i would load api calls by ordinal and only those that i really need (ok, for the sake of compatibility, i would dig them from IAT table based on 16bit hash (folding fnv32) of API name + dll name). Same for all other libraries, everything compiled with agressive optimization (at least /O2). Next step would be to take compiler that is minimizing the bloat, tinyc (<a href="https://bellard.org/tcc/" rel="nofollow">https://bellard.org/tcc/</a>), compiling 32 bit binaries just to save some space. Maybe even go for .com to avoid PE header bloat. At the end compress everything with something like upx, but probably i would roll my own PE compressor. Instead of using functions, the macros would be used, absolutely no classes, #pragma pack(1) all structures (i never tryed what tinyc does :D). Also merging PE sections will save some bytes.<p>Size optimizing is fun and you can learn a lot but it is dying art, probably 99.9999% of todays developers dont understand what I have written in first part (today, you are learning the programming, but very indequately what the OS does, actually typical today programer understands the programing but is clueless what his code does on low level) ... but +1 for anyone that goes into that direction, my boss at my first job was saying that good software fits to one 1.44 floppy but this is today violated by HHLL. Well business wise no need for that unless you are making malware, but still cool.
I’ve always been impressed by the demo scene but never tried my hand at one because of the insane programming chops needed.<p>What are your top 3 favorite intros that you would recommend watching?
If someone is interested in small demoes, I recommend "A Mind is Born", a 256 Byte Demo. It runs for about 3 minutes (IIRC).<p>[ <a href="https://linusakesson.net/scene/a-mind-is-born/" rel="nofollow">https://linusakesson.net/scene/a-mind-is-born/</a> ]
I still play <a href="https://www.youtube.com/watch?v=sWblpsLZ-O8" rel="nofollow">https://www.youtube.com/watch?v=sWblpsLZ-O8</a> over and over, just for the song, not only because it is 256 bytes, but because it is a compelling song too.