NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/mac/programm/15333

Internet Message Format | 1992-09-10 | 3.6 KB

Path: sparky!uunet!decwrl!waikato.ac.nz!ldo
From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The Pallette manager
Message-ID: <[e-mail]>
Date: 11 Sep 92 18:18:06 +1200
References: <[e-mail]>
Distribution: comp.sys.mac.programmer
Organization: University of Waikato, Hamilton, New Zealand
Lines: 66

In article <[e-mail]>, [e-mail] (Matthew Hall) writes:
>
> I am drawing a 256 color plot in an offscreen pixmap.  I set the
> offscreen pmtable to whatever clut I wish to choose.  Then, from that
> I creat a palette optimized for the current color level (or none for
> direct devices).  So, if I'm in 16 colors, I would take one of every
> 16 colors in the 256 color clut that I loaded in (with black and white
> appropriately placed) and place them in the palette. Then I set the
> app's default palette to this new palette.

An easier way might be to use the pmInhibit flags. That way you can specify
for each palette entry which screen depths to use it at, and you don't have
to check the screen depth before setting up your palette.

>  This way, I can
> draw directly into the offscreen map since the positions of the colors
> in the clut don't change, and I don't have to use
> pmtolerant+pmexplicit, or setentries, and I can draw in an ideal color
> environment and let PM take care of tolerance and updates.

Hang on--you don't need a palette for an offscreen port. The main point of
palettes is for use with on-screen windows. The only point with attaching
a palette to an offscreen port would be so you can use PmForeColor and
PmBackColor to quickly specify colours from the palette. Tolerant and
animated entries don't mean anything in an offscreen palette.

[problems with on-screen display omitted]

>  Now when I draw direct (plug index values in the data) into the
> pixmap, and copybits to the screen
> everything is fine. $FF turns to black, etc.  So the problem seems to
> be that fillrect is placing the (teh) wrong index into the pixmap.  Is
> this because my offscreen port is using the current gdevice, and
> thinks black is somewhere else in my clut than it actually is? If so,
> do I have to create a new gdevice for the pixmap?
> Actually, is my method compatible? Is it stupid?  and why the strange
> problems.

What exactly *is* your method? If you're directly poking colour table
entries, are you remembering to call CTabChanged so QuickDraw knows what
you've been up to? If you want a custom colour table for your pixmap, then
*YES*, you *DO* have to create a custom GDevice. This is because the mapping
from the colours you ask for to actual pixel values is done using an inverse
colour table, and you find those in the GDevice structure, not in the PixMap.

Are you using the GWorld routines? If not, I highly recommend them. Here's how
you create a GWorld:

    Err := NewGWorld
      (
        MyGWorld, (* ptr to returned GWorld *)
        PixelDepth, (* number of bits per pixel *)
        BoundsRect, (* bounds of GWorld's PortRect *)
        CTable, (* custom colour table or NIL for default *)
        NIL, (* don't want to use an existing GDevice *)
        Flags (* specifying useTempMem puts pixmap into temporary memory *)
      )

You can read the rest in IM6. The GWorld routines really are easy to use.
Compatible, too.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
                       Signature tow-away zone. You have been wa