pouët.net

In the SW dev industry it is common to have code reviews on all commits, followed by static analysis, precommit tests, nightly tests, weekendly and release tests of the full codebase. The test scope may include several years worth of products and platforms.

Working on demo prods, how do you keep your prods together and avoid breaking your old releases?

(most boring pouet topic ever, but I'm curious still!)

why?


i don't think somebody cares. demoscene is kinda in release-for-forever way

I almost wrote something but then I saw that the authority on the topic has already posted, so...

heh, same here

without wanting to derail this thread, a good question might be..
How do you keep your scrolltexts working?

In some cases you make your demo and then Stingray creates a whdload patch to clean up your mess 10 years later * cough * * cough *

When I download an old demo these days.. I've found that this is my confidence that it will run:

C64 : Successful demo run rate 100%
Amiga500 : it will run in UAE somehow. Run success 95%
AmigaAGA : Might require weird library. Also try all combinations of disable/enable caches and whdload patches.. Success 75%
MSDOS : It works in DOSBOX. Might get weird screenmode, out of memory or no sound because personal incompetence at autoexec.bat and config.sys.
Older windows demo : ?%
Mac demo : 0%... backwards compatibility buried together with Steve Jobs and tombstone signed by Jony Ive

This analysis backed by a lot of data.. I promise

Amiga PPC demos are the real dig, a good 100bit approach.

Out of all Amiga PPC Demos, the one I would love to run in an emulator to watch at full framerate would be Planet Potion! The intro that introduced the hard hitting demoscene communication method of announcing greetings with electro voice! Probably one of the most spine chilling communication style

Your post is somewhat contradictory to the thread title. Do you want to recompile your stuff over and over again against shifting interfaces?
Ask yourself what needs to be done that your work can be enjoyed in 10, 50, 500 years from now, preferrably without applying curatorial rocket science. Choose your canvas and paints accordingly.
Obsolete hardware that in a certain configuration has sold in the hundered thousands is a stable interface to work against.

You say "keep" demos working, but from your examples it sounds like you want them to start working on platforms they never worked on to begin with. Those old Mac demos run fine without backwards compatibility on old Macs. Minor platform changes can be handled with patches, like in your Whdload example, but beyond that, emulation is your best bet.

imagine keeping old bbstros running on modern pc after 30 years.

i think != it's true. if you think trolling is more viable way than helping, continue.

Answer to the question: it's a pointless thing to do, so I don't. Problem solved.

I make demos for oldschool platforms, so they defacto need no maintenance.

True. They crash on the exact oldschool system they were designed for.
Sorry, couldn't resist...

If that happens to you, I recommend the following best practises:

1. Keep hardware properly functioning. It's part of your job if you want to become part of the cultural heritance of your platform.

2. Test your stuff on real hardware. Use mechanical components, such as a disk drives, as an entropy source. Because if you code against emulators, they are too deterministic, and inaccuracies in emulation amplify into states that have little resemblance to reality: Works all the time although it shouldn't - doesnt't work although it should. When working with real hardware, you're practically immune.

3. Designate a computer for nothing but testing. As close to the original state as possible, no modifications.

@Bifat, it was paranoids way of telling me some of my code doesnt run on his hardware :)

- publish the sourcecode so someone can patch it if they really want to
- provide a reference video capture so people know how it looked on initial release

The rest is not the job of the artist, but of the art conservators, I guess?

Yeah, I think publishing source code is the only successful long term solution. That way, others can fix things after you've lost interest and moved on to shinier things...

When it comes to the choice between patching a binary and compiling the source, I almost always found the former easier :)

With fixing the source and recompiling later you just move the compatibility problem from the demo to the compiler and other tools, which may or may not be easier to run. :)

Porting a demo to a different compiler and toolchain will inevitably taint (if not destroy) the original artwork, so only binaries are interesting for artistic authenticity.
I found a more than thirty years old C source of a Workbench game of mine. The source looked rather clean, only the assembler inclusions and some binary blobs would give me some headaches. But if I don't set up the ancient compiler and headers, the game probably wouldn't run on Kickstart 1.3 anymore, and be faster due to higher levels of compiler optimization.

Porting to a different toolchain wouldn't be enough though. It doesn't matter what Kickstart it requires if you don't have an Amiga:

Creators and curators need the machine. Emulators are in their infancy and are currently only suitable for consuming. If we now neglect the real machines, they might become ultra-rare in working condition in 500 years, and in the meantime we have a large number of demos produced against emulators.