home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!destroyer!gumby!kzoo!k044477
- From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
- Subject: Re: HELP: Color mapping and copybits
- Message-ID: <1992Aug13.140905.7600@hobbes.kzoo.edu>
- Organization: Kalamazoo College
- References: <m0mITTz-0006ChC@gluttony.reed.edu>
- Date: Thu, 13 Aug 1992 14:09:05 GMT
- Lines: 26
-
- gluttony@reed.edu!gluttony.reed.edu!pcalahan (Patrick John Calahan) writes:
- >I have two offscreen pixmaps, one 4bits deep and one 8bits deep.
- >Each has its own color table of 16 and 256 colors respectively. I want to
- >be able to copy one to the other with copybits and have the colors
- >be mapped using the color tables (im using apple standard colors for
- >both tables). The problem is, as I understand it, copybits uses the
- >current gDevice's color table for the destPixmap. What do I do?
-
- Make sure the current GDevice is set up the way you want it. :-) That
- will usually mean making your own; but if you get lucky and one of the
- screens is set up right, then no one will stop you from mooching off it.
-
- TN120's listing 3 is great source code for making your own.
-
- (BTW, it's more appropriate to say "CopyBits uses the current GDevice's
- color environment" than "...color table." For example, I don't think
- CopyBits will even look at the GDevice's color table beyond checking
- ctSeeds to see if it can do a fast copy. If the fast-copy is ruled out,
- CopyBits uses the _inverse_ table to decide where to map all the colors.
- Or the destination might even use direct color, in which case there
- isn't any "GDevice's color table." :-) Sorry about all that, I just
- felt like picking a nit... :-)
- --
- Jamie McCarthy Internet: k044477@kzoo.edu AppleLink: j.mccarthy
- The essence of OOP: "After some hacking, I finally got the program to
- work, but I'm still not sure why." - David Marcovitz (marcovitz@uiuc.edu)
-