pouët.net

Using hardware-incompatible trickery

category: general [glöplog]
 
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.
added on the 2017-04-28 10:38:50 by Sdw Sdw
"NVIDIA-only"
added on the 2017-04-28 10:39:39 by Gargaj Gargaj
Also, so much for the myth that "my C64 is exactly the same as my neighbor's C64" :)
added on the 2017-04-28 10:40:23 by Gargaj Gargaj
Quote:
"NVIDIA-only"
pc is not considered a fixed hardware platform that much
added on the 2017-04-28 10:55:09 by the_Ye-Ti the_Ye-Ti
Quote:
Also, so much for the myth that "my C64 is exactly the same as my neighbor's C64" :)

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).
Quote:
"NVIDIA-only"

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. ;)

Quote:
That kind off went out the window with new vs. old SID

Better examples: Drive-related issues that break fast IRQ loaders, KERNAL differences, VICII revisions, illegal/undocumented/unstable opcodes.
added on the 2017-04-28 12:35:18 by tomaes tomaes
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 :')
added on the 2017-04-28 14:55:05 by ___ ___
Quote:
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.

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.

Quote:
"NVIDIA-only"

Not the same thing.
added on the 2017-04-29 15:49:57 by Photon Photon
Ultimately, demoscene is about doing whatever the hell you want. So do that.
added on the 2017-04-29 20:21:38 by xeron xeron
@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 :/
added on the 2017-04-30 00:12:37 by oerg866 oerg866
But on the other hand, if 85% do, then clearly that's the intended behavior. So I dunno how to judge that. :S
added on the 2017-04-30 00:14:17 by oerg866 oerg866
Quote:
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?


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.*
added on the 2017-04-30 01:05:05 by jmph jmph
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 :)
added on the 2017-04-30 02:56:21 by groepaz groepaz
Quote:
Hell, sometimes demos would just refuse to run twice in a row on the same machine.

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

Quote:
getting one of the really impressive ones to run perfectly was an *event.*

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.
added on the 2017-04-30 07:20:58 by tomaes tomaes
Quote:
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


hahahahaha, that's why my DOS stuff often crashes or just refuses to run! :D
added on the 2017-04-30 17:18:04 by wbcbz7 wbcbz7
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.
added on the 2017-05-02 08:42:54 by trixter trixter
Quote:
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.
added on the 2017-05-02 08:49:55 by britelite britelite
Quote:
Also, so much for the myth that "my C64 is exactly the same as my neighbor's C64" :)


that myth dont exists to begin with.
added on the 2017-05-02 10:03:04 by Oswald Oswald
lol :)
added on the 2017-05-02 10:10:57 by havoc havoc
*ahem*
added on the 2017-05-02 16:41:48 by Gargaj Gargaj
Quote:
Personally, I am in favor of demos that break emulators, because come on, that's fucking awesome.


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.)
added on the 2017-05-02 21:51:52 by jmph jmph

login