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: <C00nKw.Lx7@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: <1992Dec28.000531.26783@mpifr-bonn.mpg.de> <doiron.0k4a@starpt.UUCP> <1992Dec29.010853.12840@mpifr-bonn.mpg.de>
- Date: Tue, 29 Dec 1992 10:24:32 GMT
- Lines: 19
-
- In article <1992Dec29.010853.12840@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
- >In <doiron.0k4a@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
- >
- >Chunky wins slightly in most operations IF you use a 256 color image.
- >It looses with a depth != 8. BTW, 32x32 blit is tiny, what about 50x50
- >or 156x200 ? And since we were talking about 'image processing'. Most tools
- >have some sort of GUI which eats some of the 256 colors. The easiest
- >way is to go down to 128 colors. Bitplanes will then be faster for 12.5%.
-
- Huh? That doesn't follow, except for trivial operations like clearing the whole
- screen. Another big advantage for chunky/8-bit displays is fast "cookie-cut"
- blitting. On the Amiga a cookie-cut blit requires 4 memory accesses (source,
- 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
-
-
-