Just keeping it real, part 4.6

I’d like to correct something from the first part of this series. I mentioned some examples of very fast polygon routines on early PC hardware.

Namely Triton’s Crystal Dream:

And the game F29 Retaliator:

At the time I suspected that they were using an optimized polyon filler in VGA’s ‘mode X’. However, once I started getting into EGA, I realized that EGA has even more potential for polygon fillers than VGA, because you can do up to 32 pixels with a single dword write, as I mentioned in part 2. VGA is limited to ‘only’ 16 pixels.

Another thing about EGA is that it has a true planar memory layout. This makes it relatively easy to make translucency effects (known as ‘glenz’ in the demoscene). Namely, if you render polygons of colour A to bitplane 0, and polygons of colour B to bitplane 1, then the overlapping parts will automatically index into colour index 3 of the palette. So if you make it so that colour 3 looks like the result of colours 1 and 2 combined, you get ‘free’ translucency.

With VGA (even in unchained mode) you’d have to perform a logical OR-operation on the pixels, which requires reading back each pixel with the CPU, then performing the OR and writing it again. There is a way to use the graphics controller for the logical OR. But that makes use of the latches that each bitplane has. These are only 1 byte in size. So at best you can read 1 byte, then write 1 byte, which results in the bytes of all 4 planes being updated. It will not work with a word or dword at a time, because the latches would only hold the last byte read. I have made a simple test-case for that scenario (I have not bothered to modify the palette so that the translucency would look correct, but it is clear that a logical OR is performed on every pixel of the triangle on top of the cube):

So it works, and is reasonably efficient, but still it reduces your fillrate from 16 pixels per write to 4 pixels per write, and requires an additional read to initialize the latches with the proper pixels.

In EGA mode however, you can simply use the plane write enable register to control which planes you write your polygons to. So there is no read-modify-write cycle required. The EGA graphics controller will simply ignore the bitplanes that are not write-enabled. This would mean that your translucent objects would still render at 32 pixels per write.

Combine that with the fact that you can use the VGA palette in EGA modes, as I mentioned in part 4.5, and you can set up a really fast 16-colour mode that can look quite good for shading and translucency. And then it hit me: Crystal Dream ‘looks’ VGA, because of the nice choice of colours. However, they have a sequence with some glenz objects, which doesn’t seem to slow down at all. Perhaps an even better example of that is in Crystal Dream II, at the beginning of the second part, around 0:58:

And upon closer inspection, Crystal Dream I and II don’t use that many colours on screen at a time. You could do this with 16 colours and the VGA palette. A subtle hint was in the endscroller of Crystal Dream, where a reference is made to The Space Pigs for the information about the ‘undocumented VGA mode’. And as you might know, The Space Pigs are mainly famous for their ‘Megademo for EGA’:
http://www.demoscene.tv/mediaplayer.swf?id=4186_6650_14

So now I wondered: Are these demos using this same trick with EGA mode? I decided to investigate. I ran dosbox in a debugger, and put a breakpoint on the INT10_SetVideoMode() function. This way I could easily determine which videomodes were used.

Imagine my surprise when I indeed saw mode 0x0D popping up in the debugger! Yes, that’s the 16-colour 320×200 EGA mode! Not the 256-colour 320×200 mode, which is 0x13. Both Crystal Dream I and II run in this mode for various parts of the demo, including the fast vector/glenz sequences. I then reconfigured dosbox to EGA, and tried to run the demos again. Luckily they didn’t try to detect VGA, so they ran as usual. And indeed, many parts just ran in EGA, the graphics were rendered correctly. Only the colours were wrong. I guess I am on to something here.

I then looked through The Space Pigs’ productions to see if they had used this mode before. And indeed, their demo Vicky uses this same mode:

That might be the first time this mode was used in a demo. I decided to also check the game F29 Retaliator. After all, for a VGA game it did not seem to use that many colours, and there was dithering visible. Then again, this was common back in those days, since graphics were often ported from other systems such as the Amiga and Atari ST, and as such weren’t made for the 256-colour VGA mode anyway. And yes, once again I found mode 0x0D instead of mode 0x13!

So there we have it: those superfast polygon renderers that I mentioned are in fact not the work of mode X, but rather of good old EGA with some VGA colours on top. Speed-wise that is even better! Which is rather funny to me, as my recollection was that games generally ran much slower in EGA mode than in VGA whenever I tried (such as Test Drive III, which I could play in VGA quite well on my 386SX-16, but in EGA it just crawled).

Advertisements
This entry was posted in Oldskool/retro programming, Software development and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

One Response to Just keeping it real, part 4.6

  1. Pingback: Just keeping it real, part 5 | Scali's blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s