pouët.net

How do you keep your demos working?

category: general [glöplog]
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!)
added on the 2022-07-03 01:30:51 by rloaderro rloaderro
Quote:
how do you keep your prods together

why?

Quote:
and avoid breaking your old releases?

i don't think somebody cares. demoscene is kinda in release-for-forever way
added on the 2022-07-03 01:37:53 by 100bit 100bit
I almost wrote something but then I saw that the authority on the topic has already posted, so...
added on the 2022-07-03 02:18:50 by Gargaj Gargaj
heh, same here
added on the 2022-07-03 02:20:10 by gentleman gentleman
without wanting to derail this thread, a good question might be..
How do you keep your scrolltexts working?
added on the 2022-07-03 02:28:50 by gentleman gentleman
In some cases you make your demo and then Stingray creates a whdload patch to clean up your mess 10 years later * cough * * cough *
added on the 2022-07-03 02:59:16 by rloaderro rloaderro
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
added on the 2022-07-03 03:27:51 by rloaderro rloaderro
This analysis backed by a lot of data.. I promise
added on the 2022-07-03 03:29:14 by rloaderro rloaderro
Amiga PPC demos are the real dig, a good 100bit approach.
added on the 2022-07-03 03:39:19 by gentleman gentleman
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
added on the 2022-07-03 10:50:32 by rloaderro rloaderro
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.
added on the 2022-07-03 11:39:19 by bifat bifat
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.
added on the 2022-07-03 12:49:49 by absence absence
Quote:
I saw that the authority on the topic has already posted

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.
added on the 2022-07-03 15:39:34 by 100bit 100bit
Answer to the question: it's a pointless thing to do, so I don't. Problem solved.
added on the 2022-07-03 16:42:24 by yzi yzi
I make demos for oldschool platforms, so they defacto need no maintenance.
added on the 2022-07-03 17:24:32 by spkr spkr
Quote:
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...
added on the 2022-07-03 18:25:15 by Paranoid Paranoid
Quote:
True. They crash on the exact oldschool system they were designed for.


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.
added on the 2022-07-03 18:51:40 by bifat bifat
@Bifat, it was paranoids way of telling me some of my code doesnt run on his hardware :)
added on the 2022-07-03 20:26:53 by spkr spkr
- 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...
added on the 2022-07-03 23:59:14 by kusma kusma
When it comes to the choice between patching a binary and compiling the source, I almost always found the former easier :)
added on the 2022-07-04 00:22:47 by Gargaj Gargaj
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. :)
added on the 2022-07-04 00:59:50 by neon neon
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.
added on the 2022-07-04 01:17:02 by bifat bifat
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:
Quote:
Ask yourself what needs to be done that your work can be enjoyed in 10, 50, 500 years from now
added on the 2022-07-04 11:19:58 by absence absence
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.
added on the 2022-07-04 11:59:47 by bifat bifat

login