From: frankv@cit.ac.nz (Tutor)
To: glove-list@karazm.math.uh.edu
Date: Mon, 21 Oct 91 17:41:11 NZT
Message-Id:  <9110211741.aa05523@cit1.cit.ac.nz>
> Hey, thanks for the 320x400x256 code fragment!  I had already figured out how
> get that resolution, and how to get 2 pictures, but I couln't figure out how
> to write the pictures without leaving the mode. (A bit misleading, calling
> SC#4 bit 3 "odd/even"!)  A bit expensive in time, constantly changing the plane
> write register, though.  Guess I'll have to figure out another damn 4-pass
> write algorithm. (B-{)

You don't think I actually write stuff using that display_pixel()
routine, do you ;-) That was just an example showing how to calculate
addresses, etc. The following fragment reads a file (produced by a
ray-tracer followed by quantising) which contains the four "planes" in
order. Note that setting the mask variable to F00, E00, C00, 800 writes
the first "plane" to all 4 planes in the VGA, the 2nd to planes 2-4,
etc. That fills the screen with a chunky image, then progressively
neatens it up. Alternatively you could initialise mask to 100, which
gives a vertical stripe effect.

void display_320x400()
{
int plane, mask;
char far *base;

	setvgapalette(&palette, colours);
        base = (char far *)0xa0000000L;

        mask = 0xf00;
	for (plane = 0; plane < 4; plane++, mask <<= 1) {
		outport(SC_INDEX, (mask & 0xf00) | MAP_MASK);
		fread(base, 400 * (320/4), 1, fp);
	}
}

> I think that VR applications would be better served by using 4 pages of
> 200 lines, as that cuts down the rendering time and allows double buffering.

I'm coming to the same conclusion: 320*200 gives a single-plane memory
map with corresponding benefits. Also, the size of the image is less
than 64K, giving benefits in address calculations.. I'm not sure whether
double-buffering of both images is needed -- update the right-eye view
while displaying the left-eye view may work.

> Any comments on using 16-color modes for even faster rendering?  Is there
> ANY way that so few colors is sufficient for filled-poly VR work?

I think that 16-colour (sorry to correct you spelling here :-) would
be worse, since each pixel (as far as I can tell) is represented by 1
bit in each of 4 bytes (remember the planes). Lots of bit-shuffling and
ANDing and ORing required too. Unless you're just flipping entire frames
up, 1 byte/pixel has to be better.

I can't comment on how many colours are needed for "filled-poly VR" --
I'm not familiar with that area. However, MS Flight Simulator does a
respectable job of displaying 3D material using only 16 colours.

> Which brings up the topic of reprogramming VGA cards to achieve new
> resolutions and timings.  Cheap LCD displays are going to need this to
> work properly. I did some work last summer on getting NTSC timings to
> run Sharp LCD panels, but I had to add a new clock source via the VGA
> feature connector. Any idea how cards from different manufacturers
> handle radical reprogramming of the registers?  Is the timing (i.e.
> blanking period) and "screwy" video modes reliable across all cards?

I don't know much about LCDs and VGAs. "My" 320x400 routine was simply
translated from assembler written by Michael Abrash in Programmers
Journal. He commented there that 320x400 should work on all VGA cards.

Frank.