pouët.net

The point is that the source code carries the original intent, in it's rawest technical form. Sure, it might be difficult to dig out the build tools needed for ancient productions, but these days we have tools to ensure reproducable builds etc, so it's not entirely out of reach either.

We're entering a really difficult territory as folks who are used to think in mainly technical terms. I think that a piece of art needs at some point be frozen in time and be excluded from changes and alterations. That's why I disagree about the sources - you can delete them after your work has been released, which means it has been committed to the public space of common cultural heritage. Only if we understand this we can truly advance demos and make them a sustainable artform. May the peasants tinker around with our work, as we are in digital space, but there has been a starting point which is entirely determined by the creator. There's an original version and there are fixes, patches, derivatives. Which are meaningless.

You're free to think that way about your own demos. I will still keep the source around, and try to keep the demo working. Even if that means you think I've tainted my own work, I'm pretty sure that's something I get to decide for myself.

For instance, I've recently ported a Windows demo I released in 2003 to work on modern Linux machines, which happens to be what I use these days. I'm pretty happy that I could do that with relative ease. And while I did that, I also fixed a bug that lead to a small rendering issue on any non-NVIDIA GPUs.

If you really want to freeze it in time, there's always the option of a video capture…

And Lua - this is also a stable interface you can trust.
Videos are very important, if they are live footage from the release party. Like for example the Gubbdata stream, which captured the surroundings and audience. This is done properly. Otherwise, well.. some synthetic forgery of which you don't know if it's authentic.

The problem with videos is that they cancel one of the demos potential specificity and unique feature: randomness.

wat

(and the change to the parser that disallows things like `x=0y=0` that are used all the time in TIC-80 sizecoding wasn't even considered notable enough to mention, apparently)

Lua makes no promise about source level compatibility between versions and even revisions. Bugfixes go into subrevisions which are safe on source level. This is a very unfortunate and maybe uneducated decision by the TIC-80 makers. Lua is a long-term promise: I am on Lua 5.1 since 2006 with all my tools and prototypings, and I can be sure that my stuff runs in 100 years on whatever platform, because the core Lua is just ANSI-C or now perpaps some subset of C99 - haven't checked in a while.

To date, I have yet to see any code written pre-1970, in any language, to run unchanged for fifty years on a modern platform. Given this, it seems optimistic that something as large as the Lua interpreter would last for a hundred. At least it would seem more stable to avoid the dependency altogether :-)

Purely subjective, but I don't find that big by today's standards.

To clarify - TIC-80 hasn't upgraded to Lua 5.4 (and this is a big reason why they probably won't).

If what you really mean is "Lua is a stable interface as long as you always build against the exact same minor release of it", then I'm not sure what particular relevance Lua has to this conversation. Isn't the same thing going to be true of any library written in some sort of standard-compliant C?

For demomaking - in the same way as people make demos on Pico8 and TIC-80, I prototype effects in Lua (with own runtime), used the Lua runtime compiled into PS2 demos and Amiga tools, etc. Lua provides a small and transparent HLL interface at utmost portability, therein lies its strength for long-term considerations. The things learned from visual prototyping can be used in effects for different platforms, and doing your own brand of Pico8 or TIC-80 is very easy.

Since one does not know what will be in 10 years or in even more I think binaries being preserved is most important and sources are a fantastic extra (may it recompiling after fixing or for learning purposes). Videos are nice but where do you draw the line of overkill in terms of quality? Not to mention the space they eat up compared to executables (well mostly, but also those 500mb demos have also their place ^^).

That's for the current discussion because I fail to understand the initial question of this thread. but that is ok :)

I don't know enough about the materials and processes used to make chips, but I suspect that no matter how well they are cared for, working Amigas will be very rare indeed 500 years from now. I doubt anyone will be interested in Amiga demos even 100 years from now, but assuming they are, emulation seems like a safer bet.


What it doesn't carry is the workings of the machine the code is for. Accurately porting e.g. an Amiga demo to Windows is a challenge even for an original author who is still alive and knows how an Amiga works, but without that knowledge or working machines, source code is of limited use. I still agree that it's potentially very useful in the short term for "soft" ports like the Windows-to-Linux one you mention, and possibly valuable as a historical document.

We in our group find a handful of emulator bugs each time we are making a demo. Simply because I'm not using one. The best service you can do to emulators is to produce stuff on real hardware.

If someone thinks my demo is worth preserving, they'll do it somehow. If nobody thinks my demo is worth preserving, it probably isn't.

Absence: Sure, I agree that it doesn't solve all compatibility-issues. I think we're on the same page here.

bifat: Yeah, emulators are great to ensure compatibility for many platforms, and often essential to getting binaries running for a specific old platform. But as Loaderror pointed out here initially, several decades of Amiga emulator development still hasn't solved compatibility for the Amiga platform, because there's also issues of software incompatibility within the platforms. Source code can help in these cases, because coders who know or care more about how to write system-friendly code (maybe even the original coder, just a few decades wiser) can come around and solve some issue after-the-fact.

Clearly, what we need is a port of Docker to AmigaOS.

Ah, the "solve one problem by adding ten more" technique. :D