home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.programmer
- Path: sparky!uunet!portal!danb
- From: danb@shell.portal.com (Dan E Babcock)
- Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
- Message-ID: <C01MuB.G1J@unix.portal.com>
- Sender: news@unix.portal.com
- Nntp-Posting-Host: jobe
- Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
- References: <1992Dec29.010853.12840@mpifr-bonn.mpg.de> <C00nKw.Lx7@unix.portal.com> <1992Dec29.114206.2227@mpifr-bonn.mpg.de>
- Date: Tue, 29 Dec 1992 23:06:11 GMT
- Lines: 26
-
- In article <1992Dec29.114206.2227@mpifr-bonn.mpg.de> mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst) writes:
- >In <C00nKw.Lx7@unix.portal.com> danb@shell.portal.com (Dan E Babcock) writes:
- >>mask, dest, and dest) per word transferred. On a TI graphics chip it requires
- >>only 2 accesses, source and dest, because it can avoid disturbing the destination
- >>byte if the source byte is 0 (transparent). It's inherently twice as fast.
- >
- >>Dan
- >
- >You meant, the TI chip performs the operation twice as fast as our blitter.
- >True (besides that it is even faster because of a higher clock).
- >
- >With planes you could read a word of each plane (at that time OR them together
- >in a register) read the destination if the generated mask is nonzero and
- >different from all-one (AND it at that time with the mask) and write it back
- >(just if the mask was nonzero).
-
- That's a huge amount of additional hardware (maybe that's why it isn't
- implemented in the Amiga blitter, eh?). And it gets worse when you add buffers
- to take advantage of page mode, which must be duplicated for each bitplane.
- Ok, here's another thing to chew on: VRAMs have a pixel-expand feature which
- can effectively quadruple the data rate for monochrome fills (for example
- text drawing or polygon drawing). Bitplanes need not apply.
-
- Dan
-
-
-