elevated by Rgba & TBC | 4k intro (FullHD 1080p demoscene demo)

Those who don't see anything unusual or wasteful about an 8KB+ executable whose only action is to exit and return a value are recommended to watch this demo generated in realtime by a 4KB executable: [this video] There's more here: [link] The demoscene is basically the exact opposite of mainstream software culture, and although it's focused on multimedia shows, I think some of their techniques and underlying motivation could be applied more generally... I wonder if /bin/true and /bin/false in their most simplest forms even meet the minimum "requirement for creativity" to be copyrightable, and if the reason why it has bloated significantly is so that it could be.

The maths isn't hard, but you do need a decent grasp of vectors and (optionally) 3D transformation matrices, and it's pretty opaque until you figure out the terminology. I haven't done GPU raymarching myself but I've used the same techniques on the CPU side in order to develop a whole-planet procedural renderer (in Ada, of course); the raymarching was relatively straightforward but I got horribly bogged down trying to make a volumetric atmosphere work. One resource I found really useful was Iñigo Quilez' website; in particular, his article on basic terrain raymarching explains most of the concepts: [link] (Also known as iq, he's responsible for a number of amazing demos, including the 4kB demo _Elevated_: [this video] He also appears to have written ShaderToy. Search for iq to see his stuff omfg ShaderToy lets you write shaders to produce _music_ now? [link] )

The size comparisons are also very useful, if anything to show that even the simple "non-Modern" C++ program already has quite a bit of bloat. Compilation takes 0.064 seconds, produces 8480 byte executable I am experienced with Asm so I can come up with an instinctive order-of-magnitude estimate, but even those who aren't should try to roughly estimate how many machine instructions are required to implement that code, and come to the conclusion that over 8000 bytes for three nested loops with not much in them, a comparison, some arithmetic, and a handful of library function calls seems rather excessive. Even 800 would be on the high side --- somewhere around 100-200 bytes is my estimate. Also, watch this 4k demo (everything you see and hear is generated in realtime by a 4096-byte executable): [this video]

This is a great example of the point the guy is making: [link] That's 128 bytes. You could encode that as a 43 pixel RGB888 image. That's less than 7x7 pixel icon! Now as Jare mentioned in another comment, this video [this video] contains less bytes than a basic 32-bit 32x32 pixel icon. Some of the whole essence of this demoscene stuff is to work within these constraints(256 bytes, 1024 bytes, 4096 bytes, 64 kbytes, ...) to produce this kind of art . Custom virtual machines, on-fly decompression algorithms and methods, carefully crafted data and ingenious ways of data re-use are the key. It's like black magic.

Switching out of the "staticy" background for a plain gray reduced the payload size to ~20M, a savings of ~30Mb. I know this might sound somewhat obvious in retrospect, but you could've retained something similar to the original background and reduced the size significantly by generating it at runtime --- the code to create a random-looking background may only be not more than a few dozen bytes, and can be the same for multiple resolutions. For more examples of this technique, see demoscene productions --- the following video was generated by a binary of less than 4096 bytes : [this video] Source code: [link] Explanation: [link]

I am reminded of this 4 kilobyte demo: [this video] (Source code and discussion at [link] ; explanation at [link] ) although the flight sim is a little more interesting from a technical perspective, since it's interactive and also not using the GPU to do most of the computation. Also, despite the source code being obfuscated, observe that that "external symbols" which are still visible, e.g. XDrawLine, XSetForeground, etc. already give a pretty good overview of how it does what it does --- and in general, when reverse-engineering or analysing software, inspecting where the "black box" interacts with the rest of the world is an important part of understanding it.