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.
Instead, as you guessed, these demos generate assets on the fly and stream to the respective devices. You cite inefficiencies. I tell they run at more than 60 FPS on these constrained systems. Remember, these are early 2000s systems. They are not that powerful by today’s standards, yet these small binaries use these systems efficiently and generate real time rendered CG on the fly.
Nothing about them is inefficient or poor. Instead they are marvels.
That’s not what I said. I said you’re trading memory footprint for CPU footprint.
This is the correct way to design a demo but absolutely the wrong way to design a desktop application.
They are marvels, I agree. But, and as I said before, there’s no such things as a free lunch. at risk of stating the obvious; If there wasn’t a trade off to be made then all software would be written that way already.