pouët.net

The usage of hardware tricks in Overdrive 2 that has problems on certain VDP-chip revisions got me thinking about other instances of this phenomenon.

We have for example the VSP/AGSP tricks on C64 which have been used by many productions even since the 80ies, and produce lockups on quite many machines.
On the CPC we have demos using tricks that only work on certain CRTC revisions.

One one hand, using undocumented features that give the best result is what the demoscene is all about, on the other hand it is kind of annoying to not know if a machine actually can run demos or not.
My first C64 never was able to run VSP stuff, I later bought a second one that couldn't either, then finally on the third try I got a machine that is VSP stable.
When I bought my CPC I had to convince the seller to open it up and check the CRTC revision to make sure I got one of the "good" CRTC versions.

"NVIDIA-only"

Also, so much for the myth that "my C64 is exactly the same as my neighbor's C64" :)

pc is not considered a fixed hardware platform that much

That kind off went out the window with new vs. old SID. (Or old & new luminance levels)

Or PAL and NTSC (ok, that's only if you have neighbo(u)rs quite far away).

More like: runs on vendor card X and driver revision Y, but with Y.2 everything looks funny. Or if we go that route, "GUS-only" would be the one to mention first. ;)


Better examples: Drive-related issues that break fast IRQ loaders, KERNAL differences, VICII revisions, illegal/undocumented/unstable opcodes.

let's not forget that even when using the safe VSP routines discovered not too long ago, some machines will still crash.

I don't recall any of my c64 to really suffer the VSP bug but I might not have tested extensively, since not *EVERY* instance of VSP crashes on every VSP-crash sensitive machine either.

It's a clusterfuck :')

Speaking just for myself, the demoscene isn't about that for me. It IS how it just ended up from pushing the boundaries sometimes, I think. But coders must have found out about VSP etc as soon as they started competing at parties?

Now we have more info on what tricks/tries at outsmarting the hardware that work, and some may reveal flaws (perhaps! be very careful!), and f.ex. VSP tricks still don't work on all machines. Should you use them then?

Well, if it's as high as 5-10% of the machines, maybe not?

If it's lower AND you can point out a hardware manufacturing error, I guess it's ok.

It's not clear cut, though. In some cases it's a pain, in other cases it might be from not bothering to read signal train schematics for floppy drives, for example. In still other cases there may be a new or old interface that performs badly. In that case you should take care to support as many as possible, and not just the fastest one made in 2016.

We can't really be culling computers for not being "demoscene-compatible". So, the answer is that the demo should run 100% as intended on all machines that meet the specs in NFO. If the specs are high and narrow, maybe the hardware setup is the achievement and not the code?

100% is an ideal and will never be reached, but we should definitely keep reporting demos that don't work. This will sort the software side effects from the hardware side effects, and besides, some are party versions that may get a patch/final.


Not the same thing.

Ultimately, demoscene is about doing whatever the hell you want. So do that.

@Photon: Looks like you'll have to report ours then. I think a good estimate would be that about 15% of MDs will not run our demo :/

But on the other hand, if 85% do, then clearly that's the intended behavior. So I dunno how to judge that. :S

Most of us who were on DOS during the '90s are laughing at this. You could build a 100% identical clone of any compo or dev's PC and it would still be a crapshoot whether a given demo would run. Hell, sometimes demos would just refuse to run twice in a row on the same machine. It was definitely part of the experience back then; getting one of the really impressive ones to run perfectly was an *event.*

yeah indeed =) back in the days you were lucky to be able if you could run other peoples pc stuff at all =D

regarding VSP - dont forget back then parties weren't the major outlet for demos. the vast majority of demos were released outside parties. and it wasnt uncommon to get random crashes in demos either - just run it again :)

Honestly, most of those DOS issues came from the fact that the code was hella crap, coming from inexperienced 16 year olds (who lacked documentation too). :D


I think it was an event because "advanced" graphics was not the norm yet. Monochrome pixelated text-only environments with beeper sounds were the norm and hence the contrast to those demos (and some games) felt so big. Today we go from one hi-res, fully animated 1080p+ desktop to another 1080p+ graphical presentation, which is not such a big break in context and presentation.

hahahahaha, that's why my DOS stuff often crashes or just refuses to run! :D

Now you know what we were up against with 8088 MPH. We thought the first PC and its first graphics standard would be a stable target, only to discover that there were no less than 4 hardware revisions of CGA, one of which had very different colors on the composite output, all completely undocumented of course. Bonus fun: Because various chips run on different dividers of a master clock, the system could be in one of 4 different states/alignments after a cold power-on, which made it nearly impossible to cycle-count some effects and/or get everything in lockstep.

Personally, I am in favor of demos that break emulators, because come on, that's fucking awesome.

And it's also useful for improving emulators.

that myth dont exists to begin with.

lol :)

lololol http://www.pouet.net/topic.php?which=11055&page=3#c530199

*ahem*

Don't Mess With Texas ran perfectly on two of the most popular emulators for our platform right from release - because the devs for those emulators were also coding the demo. :P

(Just to be clear, they improved their emulators to support all the trickery we were already using rather than putting compatibility hacks into the demo.)