Reaction to "Scene Standards" by Paranoid

Written by T$

Content:
-Comment on "Scene Standards" article
-Let's create a survey
-What could be done already

Paranoid demanded in his article "Scene Standards" that a basic system config should be established for eliminating the problem with demos not running on many machines. It's true, having downloaded something and realizing that you' ve just wasted your (online-)time coz it doesn't run is not funny at all.

In Paranoid's article we could read:

"Coders should form some kind of coders guild, and likewise for GFXers and trackers."

Hmmm... are GFX and MODs hardware-dependent? There are viewers and players for every system, so where's the problem?

Considering coders, creating a "kind of guild" is problematic. If it's small, it won't be accepted by everyone and some innovative ideas may be excluded. If it is large, it'll never be productive. And a strict standard is useless, the biggest advantage of a PC is its modularity. Either it is too low so that most productions demanding more power will still remain incompatible. Or it is too high, and only a few people will have the corresponding hardware. (Remember the idea of a DemoOS?)

The problem should be solved from the other end: The demos should be designed for the PC, not the PCs for the demos!

Maybe we should take a look at the commercial game and multimedia producers (don't moan): They direct the mass market and therefore they determine what hardware and APIs are bought most and which will still be supported in the future. Let's take a look back: The SoundBlaster was supported by nearly everyone. But many demos were GUSonly ("da only standard"). And today, even the cheapest noisecard is supporting at least the SBPro standard. But none supports GUS. In some years, the mainboards won't even have ISA slots to stick a GUS in.

Every proprietary "standards" and all the undocumented features are sentenced to death - and with them, the programs using them. How long will Glide stay alive?

The industry standards are not an alternative: Even the PC97/98/99 standards did not reach their aims - the market defines the standard, not the ideas of some wannabe leaders. And not to mention who made them...

Idea worth thinking about:

A big survey should be done (yearly?) among everyone involved somewhere in the scene so that we can see what the average config our code will run on is.

It should look like this:
-OS(es) used
-processor used (clock rate, supported extensions)
-amount of RAM available (at all and <640k)
-GFXcard and supported APIs (Vesa2, D3D, OpenGL), maximum resolution
-the same with the soundcard

It should be available through the web and as a standard text sheet.

If anyone is interested in this idea feel free to mail me. It would be nice if it'd become reality.

But now let's take a look at what can be done now.

First possibility: You are a coder.

If you are working on a DOS program make sure SB support works, including the old SB and SBPro. Also face the fact that all possible IRQs and DMAs may be used, but hardware detecting them should be avoided as it can crash the system. Check if the soundplayer works with PCI soundcards, too. DOS programs which do not run under Win95/98 won't be watched by many people (about <10%, I think), especially if they demand plain DOS with a lot of free conventional memory. In addition, if you are using weird VGA modes, make sure that it is possible to fall back to Mode 13h or the standard 640*480 Vesa.

Note: Vesa TrueColor modes can be 24Bit or 32Bit. Make sure both are supported (eats about a line in most blitting routines). Watcom users: If dos4gw is needed include it in your production.

When you are using Win32, one can expect the latest DirectX drivers installed coz they are available everythere. Hardware acceleration via D3D is also available on all cards, at least in software. OpenGL is not a standard yet, 3Dfx should IMHO be avoided.

Wave output and MIDI is usually available, too.

Under Linux, only SVGAlib, a window server and an audio device should be counted on. OpenGL(=Mesa) hardware acceleration is not supported by most cards. Similar things apply for BeOS.

OK, that was the stuff directly related with hardware. But the different software setups cause problems as well. Check your code on as many computers as possible in order to detect GFX and SFX problems. Check what happens if it runs on a P75 as well as on the fastest PC reachable by you. Try it out on different configs (especially in DOS: HIMEM, EMS, Win95, DOSemu). Start other programs running in the background eating RAM and CPU time, try to get your program out of sync and watch how it behaves. Formatting disks, producing network transfer and -if two soundcards are available- playing music in parallel to your code is a hardcore test for its stability. Testing consumes a lot of time, but it's worth it. (Imagine what happens if you are presenting untested code in public and it crashes... maybe you succeed at least in increasing the overall fun level.)

Second possibility: You just want to watch the demos.

Check this: -If you have an old or very cheap card (vesa 1.2, but also some 2.0): install UniVBE or buy a new (maybe used) one. -Get the latest drivers for your SFX and GFX (including OpenGL) card, as well as the current DirectX version. -Get a 100% original SB16, 32 or 64 (ISA) and set it to DMA1 & 5, IRQ 5, Port 220h (or a GUS). -Be aware that slower CPUs than about 166 MHz as well as less than 32MB RAM are often causing problems today. -Include options for plain DOS with and without EMS and HIMEM into config.sys. -Some demos do not run from write-protected media and some require being started from drive C:. -Make sure you have about 500 - 600kb free DOS memory. -If a dos4gw is needed, copy it into the demo's directory. Unfortunately, there are several versions (check the date). -Some PCs are too fast (uh-oh, TP programs crash if they contain DELAY, hehe).

All in all, this is more realistic than trying to establish a kind of standard. If we all work together, incompatible demos will become history. (Well, not all: Heh, this bloody Amiga/C64/... stuff does not work on my PC.)

Waiting for response:

T$