From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Sun, 5 Jul 1998 16:47:07 -0700 (PDT)

Re: kgicon difficulties |-< (and new tarballs |->)

On Sun, 5 Jul 1998, KC5TJA wrote:

> > which is like the code in lib/libggi/default/linear-4/*, whereas VGA 4
> > bit mode is a weird thing called "ModeX" and needs code like the stuff
> > in kgi/lib/libggi/IBM/*.
> 
> Bitplane mode is not in any way "weird".  Bitplane techniques have been in
> use for far longer than packed pixel modes.  If anything, it's the packed
> pixel modes that are foreign to the VGA architecture.

	They aren't foreign to *VGA*, at least not anymore - all modern
SVGA cards do chunky pixels.  Both memory layout have advantages and
disadvantages.  Planar layouts lend themselves well to things like
hardware scissors, alpha channels, multiple independent overlapping
playfields, and in general any situation where each pixel contains more
information than just its color.  This lets you modify only the info you
want, without having to touch the other stuff.  However, one of the main
drawbacks of planar layouts is that they are considerably slower when it
comes to rapid software pixel-setting of the whole framebuffer.

	Doom is the classic example - the chunky pixel layout of
320x200x8bpp VGA allowed for setting more than one pixel (four w/32-bit
longwords?) with each write to the framebuffer.  That is why Doom was so
fast on those old 386s with dumb linear framebuffers over a slow 16-bit
ISA bus, while similar 3d engines on the Amiga with its DMA and blitting
capabilities took a lot more work to get decent speed out of.  AFAIK, all
that high-end SGI video hardware uses bitplanes, but they do OpenGL in
hardware which lets them optimize their rendering algorithms or the memory
layout.  This is possible to do in software too of course, otherwise those
Amiga Doom-like engines would not have been possible at all.  But it make
things quite a bit harder.

	The basic issue is that on most memory architectures, memory is
mapped linearly regardless of how the video hardware sees it.  The DAC may
have no speed problem with linear vs. chunky layout - it has to read all
the data from the framebuffer each frame anyway.  However, the programs
running on the CPU do _not_ need to completely rewrite the framebuffer
every frame, and so the issue of accessing only the data you need to
modify in the form requiring the fewest write operations becomes the
sticky point.  Ideally, your MMU would be able to let you map the
framebuffer however was most convenient for the algorithm at hand - planar
everything, chunky RGB and planar alpha, planar-chunky RGB (plane1 =
R8R8R8, plane2 = G8G8G8, etc), etc.  This MMU would probably be quite
expensive, however |->. 

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed