Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uwm.edu!bionet!agate!garnet.berkeley.edu!deadman
From: deadman@garnet.berkeley.edu (Ben Haller)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Graphics/Animation Problems (long)
Keywords: video, game, color
Message-ID: <1991Apr20.200229.805@agate.berkeley.edu>
Date: 20 Apr 91 20:02:29 GMT
References: <9822@etsu.CMI.COM> <1991Apr14.011556.23504@santra.uucp>
Sender: root@agate.berkeley.edu (Charlie Root)
Organization: Stick Software
Lines: 51

In article <1991Apr14.011556.23504@santra.uucp> jmunkki@hila.hut.fi (Juri Munkki) writes:
>In article <9822@etsu.CMI.COM> davet@cmi.com (David Temkin) writes:
>> I'm using 24-bit addressing, but even if I 
>>use 32-bit addressing (with SwapMMUMode) the result is the same. 
>
>You should be using 32-bit addressing no matter what machine you are
>using. It never hurts and if you fail to use it in the right place,
>you'll just a crash or something even worse.

Wrong.  Switching processor modes is slow, because the SwapMMUMode routine
is slow.  So you only want to call it if you have to.  People with 24-bit
boards tend to be people with fast machines, so they can afford the call,
whereas people with vanilla Mac IIs (or an LC, even worse) haven't got much
processor to spare, and probably don't have 24-bit boards.

>>have any experience with this? I assume that the 2-bit screen is mapped 
>>essentially like the black and white screen, except that each pixel takes 
>>two bits. Is this not universally true?
>
>As I said above, this is not true. Never assume anything. Dig it out from
>Inside Macintosh. Inside Macintosh says that each row is rowBytes wide, so
>that's how you have to write software.

Um, he was asking about 2-bit graphics, not about rowBytes.  In answer,
yes, in two-bit mode each pixels takes two consecutive bits, and is
otherwise mapped the same as in 1-bit mode.  This may not be true in
the future, but it's true now.

>>This works fine, but sometimes when the program exits, the text 
>>in underlying windows is drawn improperly (white on black -- it seems that 
>>something happens to the QuickDraw background/foreground colors).
>
>I assume that you are using SetEntries to restore the screen contents.
>A Develop magazine issue specifically warns about this (it was an article
>about the palette manager). I haven't had any problems with a pair of
>SaveEntries and RestoreEntries. Just remember that the color count is
>not the actual count but the count-1 (I was bitten by that feature).

Interesting.  Could you give a more specific reference?  Is there a TN on
this, or is this Develop article the only reference?  I've been having a
fair bit of trouble with QuickDraw's color matching scheme lately, and
I'm pretty sure I've found some outright bugs, so I'd like to see this
article.

-Ben Haller (deadman@garnet.berkeley.edu)

"Wave after wave, each mightier than the last
 'Til last, a ninth one, gathering half the deep
 And full of voices, slowly rose and plunged
 Roaring, and all the wave was in a flame"
   -Tennyson, "The Coming of Arthur"