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

Text File | 1992-09-11 | 3.9 KB | 87 lines

Newsgroups: comp.sys.mac.programmer
Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!caen!sol.ctr.columbia.edu!sol.ctr.columbia.edu!mhall
From: [e-mail] (Matthew Hall)
Subject: Re: The Pallette manager
Organization: Oberlin College Computer Science
In-Reply-To: [e-mail]'s message of 11 Sep 92 18:18:06 +1200
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
Distribution: comp.sys.mac.programmer
Sender: [e-mail]
Date: Fri, 11 Sep 1992 21:28:09 GMT
X-Posted-From: occs.cs.oberlin.edu
X-Posted-Through: sol.ctr.columbia.edu
Lines: 71

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>
>   >  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.
>
I should have been clearer.  I load a 256 color pallette from a
resource file with GetCTable.  Then I set
Offscreen^.portpixmap^^.pmtable equal to that clut.  Then, I create a
palette for the current screen depth, and fill it with values from the
clut.  The palette is only for the window that the plot will
eventually be displayed in.  I draw in the offscreen pixmap by
directly setting the bytes.  If I loaded a gray scale, then the level
of gray is from 0-255.  I just place that byte in the pixmap data.
When I am done, I call copybits from the port to the screen.



>   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?

No I haven't.  I didn't even know I was supposed to.  Thanks.

>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:

The problem is that I want this to be compatible with as many
computers as it can.  GWorlds are only in sys 7 and 32 bit quickdraw
equipped Macs.  Inhibited colors are only in systems 6.0.5 and later.
I may be able to assume that anyone running color should be running
6.0.5, so maybe I will use inhibited colors, and just create one
palette, but I don't want to assume system 7, or 32-bit QD.
Of course, my compatibility concerns are worthless if my method
crashes most computers or graphics cards.  It works on an LC tho'

I guess I will have to create a gDevice for the offscreen port then.
The only quickdraw call I make, besides copybits, is fillrect though.
Otherwise I just poke in numbers.  it seems kind of a waste of memory
to create a GDevice just for FillRect when otherwise things seem to be
working well.  I can't see any problems with accelerator cards since I
don't modify screen data directly.

Thanks for the help
-matt hall

--


-------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco