Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!news.funet.fi!funic!santra!hila.hut.fi!jmunkki
From: jmunkki@hila.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Graphics/Animation Problems (long)
Summary: Let's flame!
Keywords: video, game, color
Message-ID: <1991Apr21.073551.14802@santra.uucp>
Date: 21 Apr 91 07:35:51 GMT
References: <9822@etsu.CMI.COM> <1991Apr14.011556.23504@santra.uucp> <1991Apr20.200229.805@agate.berkeley.edu>
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@hila.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, FINLAND
Lines: 71

In article <1991Apr20.200229.805@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes:
>In article <1991Apr14.011556.23504@santra.uucp> jmunkki@hila.hut.fi (Juri Munkki) 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.

Assuming that you group all your drawing between two calls to SwapMMUMode,
the overhead is not noticeable. Of course, I was just giving my opinion
and you are quite free to disagree. I just dropped into TMON to look at
the ROM code from SwapMMUMode and it's 27 assembly instructions long. Of
course there's the overhead from the trap dispatcher that you might be
worried about.

If you would like to be useful, how about showing us how to find out which
cards need the call to SwapMMUMode? I have no idea how this could be done
unless one has full documentation for 32 bit QD.

Usually when people try to find out about machine features that they really
do not need to know about, they end up shooting themselves in the foot. Just
think of all those programs that checked for a Mac II and failed to work if
they were run on a IIx. I spent a few hours fixing their code with TMON to
prove my clients that a Mac IIx really was compatible with the software.

>>In article <9822@etsu.CMI.COM> davet@cmi.com (David Temkin) writes:
>>>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.

Actually what I said fixed the problem. David contacted me with E-mail
to thank for solving the problems he had problems with. He really did
assume that with a 640 pixel wide screen the rowBytes value would be
something like 160. If you read the symptoms that he wrote about, you'll
see why I answered the way I did. [The above quote from David isn't
complete and as such is slightly misleading.]

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

Develop, volume 2, issue 1, Palette Manager Animation, by Rich Collyer.

   ____________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~