Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!bloom-beacon!bloom-picayune.mit.edu!athena.mit.edu!captkidd
From: captkidd@athena.mit.edu (Ivan Cavero Belaunde)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Color offscreen pixmap woes...
Message-ID: <1991Apr12.172631.5033@athena.mit.edu>
Date: 12 Apr 91 17:26:31 GMT
References: <SMARGARI.91Apr8222848@emmy.nmsu.edu>
Sender: news@athena.mit.edu (News system)
Distribution: comp.sys.mac.programmer
Organization: Massachusetts Institute of Technology
Lines: 37

In article <SMARGARI.91Apr8222848@emmy.nmsu.edu> smargari@nmsu.edu (Susan Margarit) writes:
>I am using color offscreen bitmaps for the first time and, of course, 
>I am having problems. I am writing a card game, actually, updating
>one I wrote to color now that I have a color system. I have a
>256 color picture as a backdrop stored in one offscreen bitmap. I use
>a second offscreen bitmap to redraw the hand after each card play.
>I blast the background to the hand bitmap and then draw the cards
>over that and then blast the whole thing on to the screen so that
>the player doesnt have to watch the cards blank and redraw. Sometimes
>I draw the cards directly on the screen in color.  The problem is
>that the cards drawn directly to the screen come out perfectly in 
>color but the hand that comes from the offscreen map come out in 
>monochrome on a color background. The color backdrop stays in color
>in the transfer from its offscreen map to the hand offscreen map to
>the screen but the cards are mono.  All of the offscreen maps are
>created with the same routine ( taken from MacTutor/TN #120). The 
>only difference between drawing the cards to the screen and the
>offscreen bitmap is a SetPort call ( ie SetPort(handPort) or
>SetPort(OnscreenPort)). Any Ideas??

I should have thought of this before, but it just came to me. One possible
reason is that the gdevice for the handPort is not properly set up. What
could happen there is that when you do CopyBits, and both source and
destination have the same clut, it don't think it requires an inverse table
from the GDevice. So if the backdrop and the handPort have the same clut,
the CopyBits would work fine. If the cards have a different clut than the
handPort, however, CopyBits would need an inverse table installed in the
gDevice that is attached to the handPort. I'd check the code that sets up
the graphics device when creating the grafport. It really does sound like
an inverse table problem, tho'.

Hope this helps,

-Ivan Cavero Belaunde
Visualist
Digital Video Applications Corp. (DiVA)
Internet: captkidd@ATHENA.MIT.EDU