Your third example seems to generate 2G of data at runtime, so misleadingly minimalistic

All of them generates tons (up to tens of gigabytes or more) of data during runtime, but they all output it, and don't store them on disk or RAM.

They are highly dynamic programs, and not very different from game engines on that regard.

> misleadingly minimalistic.

That's the magic of these programs or demoscene in general. No misleading. That's the goal.

	▲	hnlmorg 42 minutes ago \| parent [-]
		I’m on my phone so cannot run it, but you cannot generate data and not store it somewhere. It’s going to consume either system resources (RAM/storage) or video resources (VRAM). If your point is that it uses gigabytes of VRAM instead of system memory, then I think that is an extremely weak argument for how modern software doesn’t need much memory because all you’re doing is shifting that cost from one stack of silicon to a a different stack silicon. But the cost is still the same. The only way around that is to dynamically generate those assets on the fly and streaming them to the video card. But then you’re sacrificing CPU efficiency for memory efficiency. So the cost is still there. And I’ve already discussed how data compresses better as vectors than as bitmaps and PCM but is significantly harder to work with than bitmaps and waveforms. using vectors / trackers are another big trick for demos that aren’t really practical for a lot of day to day development because they take a little more effort and the savings in file sizes are negligible for people with multi-GB (not even TB!!!) disks. As the saying goes: there’s no such thing as a free lunch.