Newsgroups: comp.sys.amiga.graphics
From: dnavas@oracle.uucp (David Navas)
Subject: Re: Bitplanes vs. chunky pixels?
Organization: Oracle Corporation, Redwood Shores CA
Date: Fri, 16 Oct 1992 15:56:16 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <Bw6nuB.Cx5@rice.edu> kopnicky@owlnet.rice.edu (Lyle Warren Kopnicky) writes:
>[Why chunky?]

I'll take a swack at this one -- pardon me if I miss.

The issue, again, is speed.
Bitplanes do give you the option of having lots of different animations
going on in the different bitplanes, without having to affect each other -- and
this can cut down on rendering time.  However, if you need to move an image
that spans multiple bitplanes, you start having a very high overhead on things
like Blitter setup times (once per bitplane....).

Let's say, for example, that you wanted to mask an 8bitplane image onto the
screen.  So, you read the first bitplane, along with the mask, and write to
the dest.  Then you read the second bitplane, along with the mask AGAIN, and
write to the dest.  Repeat another six times.  You read a full-screen mask
in seven times more than you'd need to.  Uncool.

Now take the case of moving small images (like, say, fonts ;) ).  The blitter
has a very high setup time, and it's frequently faster to move small images
with the CPU than with the blitter.  Now when you increase the bit-depth
to something reasonable (8 or 24), the amount of data that you're moving
goes up.  On a chunky mode display you have fewer edges that you have to
read partial values of and combine them to correctly form the image, because
you only have one set of edges, and they tend to be on byte boundaries anyway.
On a bitplaned architecture, you'd have eight or twenty-four (gag) sets of
partial values with a much greater chance of not being aligned, so you end
up having to do more masking, in addition to more setup (get those twenty-four
bitplane pointers setup, one after 'ta other).

And as for having to be aligned, chunky modes allow you to have better
alignment properties for things like burst-mode 128bit datalines ( ;) ),
because all the data is available in one spot (I think I'm not eshplainin'
this very well), whereas with bitplanes you run a much bigger risk of not being
aligned.  Which, coincidentally, I've been led to believe explains (at least
partially ) why DblXXXX modes on the AGA don't have the overscan that
ECS did.  See, the display chip has this 64bit alignment requirement for all
of its bitplanes, which limits the overscan.  In chunky, every additional
"bit/color" improves the alignment (well, evenpower-of-two bits/color,
anyway ;) ).

Plus, it's apparantly easier to do chunky with VRAM, which is an affordable
dual-ported RAM look-alike (roughly, very roughly).  That's because VRAM has
this serial-out where when you ask for the first bit, it becomes easier
to ask for the one just after that -- which is great for chunky because
everything is one right after the other.  With bitplanes, it's one word
here, one word there, one word someplace else, and back we go....

Perhaps somebody else will explain it better, hope I've cleared things up
rather than confused them more.... ;}

David C. Navas						dnavas@oracle.com
Working for, but not speaking on behalf of, Oracle Corp.
Newsgroups: comp.sys.amiga.graphics,comp.sys.amiga.multimedia,comp.sys.amiga.hardware,comp.sys.amiga.applications,comp.sys.mac.advocacy