From: KC5TJA <kc5tja@topaz.axisinternet.com>
  To  : ggi-develop@eskimo.com
  Date: Sun, 5 Jul 1998 19:09:37 -0700 (PDT)

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

> 	They aren't foreign to *VGA*, at least not anymore - all modern
> SVGA cards do chunky pixels.  Both memory layout have advantages and

Yes, I know; however, they've been doing planar graphics for much longer
than they've been doing chunky (in the EGA).

> 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

Planar display systems tend to use less hardware as well, so they cost
less.  Furthermore, bitplanes also use less memory than chunky modes, for
the same reasons you mention above: you can exclude information you don't
need.

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

I find this to be questionable, actually.  For a given resolution with a
given depth, both chunky and planar modes must exchange exactly the same
amount of information.  One of the reasons that Mode X is so popular is
because you can break it up into planes.  By setting the VGA to use planar
chunky mode, a single 32-bit memory access can set all of 16 pixels
concurrently!

Also, your comparison of the Amiga's "slow" video performance stems
directly from the use of a 3.579545MHz clock to the blitter.  With three
sources and one destination, the blitter can conceivably achieve, at most,
approximately 1 million pixels per second per blit.  Keep in mind that
this is best case; the blitter does most of its work ONLY during vertical
and horizontal retrace periods, leaving the bus open to the pixel
serializers during normal display time.  Sure, you can set the blitter to
hog CPU cycles, but with a color depth required for DOOM and Quake, even
the blitter doesn't have a chance with the barrage of AGNUS/ALICE bus
access cycles.

In short, the Amiga is slower because it's outdated bus architecture
prevents it from achieving its full potential.  Even the AGA chipset must
live with this hinderance.

If you want fast graphics on the Amiga, like the PC, you must now resort
to using the CPU itself to perform the necessary blits.  There even was a
program in the Fred Fish disks (forgot the name) that replaced the
graphics.library's Blitter-related functions with soft-blitter equivalents
(falling back to the hardware only when the "software" blitter was busy).

> 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

Also keep in mind that, to use the blitter, you need to figure out the
source addresses for up to three sources, first and last word masks, shift
counts, and other register settings.  The software for DOOM didn't do
this, because it already knew exactly what to do and when.  Again, direct
CPU intervention is the answer... :)

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

It is exactly this type of MMU that was to be placed into the Amiga's AA
chipset (the successor to the AGA) before Commodore filed chapter 11.  The
new Amiga's coming out sometime in November(??) will most likely have this
type of MMU as well, especially with claims of 1280x1024, truecolor, 3-D
rendering in real-time.

Only time will tell.  But alas, this is starting to get a bit off-topic,
so if you'd like, let's take this to private e-mail... :)

==========================================================================
      KC5TJA/6     |                  -| TEAM DOLPHIN |-
        DM13       |                  Samuel A. Falvo II
    QRP-L #1447    |          http://www.dolphin.openprojects.net