From: deadman@garnet.berkeley.edu (Ben Haller)
Newsgroups: comp.sys.mac.games,comp.sys.mac.programmer
Subject: Re: NON-QUICKDRAW GAMES
Date: 10 Sep 1992 23:57:59 GMT
Organization: Stick Software
NNTP-Posting-Host: garnet.berkeley.edu

In article <ah5ywvd@rpi.edu> johnsd2@rpi.edu writes:
>[huge amounts deleted...]
>Doesn't this depend on the order in which these events happen? Is
>it garaounteed that suspends come before resumes? If not, then
>you could wind up "saving" the wrong CLUT.
>
>Also, what if you dont want all the colors?
  I don't think you can get two suspends or two resumes in a row.  If
you did, I bet a lot more than the CLUT would break, in a lot of
apps...

>Also, NO app can count on having the "default palette" in Color QD. The
>palette manager isn't the only way to mess it up. Some fool user must
>still be using a 4-bit display. Or 2 bit. Or 1 bit. In any of these cases,
>the palette is quite different from the 8 bit. Further, in 4 and 2 bit
>color modes, the palete depends on the current hilight color.
>[with truely nasty effects too. Try steting your hilite color to light blue,
>switching to 4 bit color and using the fidner. light blue icons! :)]
>
>Apps that dont use the palette manager (or something like that)
>have to be able to deal with this sort of thing, as well as having
>the color environment switched around on them. The finder is one: it
>reverts to 4-bit or b&w icons as needed if the palette gets too warped.
Well really this is a part of my problem with their scheme.  If all
you want is the system palette, you can either use the palette manager
to install that palette (gets the colors in the wrong order, slows down
CopyBits), use SetEntries (compatability problems, etc.), or go through
all of these labyrinthine tests to determine whether the clut is within
a sufficient tolerance of the system CLUT.  The Finder (as far as I know
it is still this, 7.0 was...) doesn't actually do a CLUT compare, it
compares the ctSeed value!  Which means if you set the CLUT with SetEntries
and the ctSeed changes (which it always does) the Finder will barf, even
if the CLUT you set is the system CLUT!  No, wait I'm misremembering this.
It checks the ctSeed to see if it *needs* to check the CLUTs.  But if
you're in grayscale, and you set the CLUT to the standard grayscale CLUT
(gray ramp), the ctSeed changes, the Finder does a compare of all the
colors in the current CLUT - but against the *color* CLUT for the bit
depth you're in.  And so of course the compare fails, the color and
grayscale CLUTs being different.  And so all your icons are then 1-bit,
until you tweak the monitor or reboot.  And now I remember, they did
"fix" this problem - they changed the grayscale CLUT to be the same as
the color CLUT, instead of a grayscale ramp!  Love those bug fixes.
  Anyhow, the point is, it should be *easy* to write an app that likes
the default palette.  But as it is, writing such an app is actually
*harder* than writing an app that installs a custom palette (thus causing
flashes, slowness, etc.)  This is not the way things should be.

>Incidentally, the Finder IS a palette-using app! It has palettes on its
>windows (including the desktop, but not including the control panels)
>for the LABEL COLORS. But NOT the 34 std-icon-colors. Thats probably
>because the finder CAN draw wo/ the color icons- it uses teh black
>and white versions, but it CANT draw properly wo/ the label colors.
>After all, u can't make an icon "light blue" if theres no light blue in
>the palette. This arrangement does little damange to any cool-looking
>custom-palette windows int the background, yet gives u a working finder
>too.
  It is also fairly easy to get the finder to permanantly draw the
window backgrounds in beige rather than white (even white is in
entry 0 of the CLUT), and to draw text white-on-black (again, with
a normal CLUT).  Temporarily setting white and black to other colors will
tweak it beyond repair, and then even if you put the system CLUT
back in it will be confused.

>|> In many cases the Palette Wrecker does save time & effort, and if it's
>|> a little buggy and annoying (a LITTLE?) well, maybe Apple will fix it
>I know of no bugs in it myself (yet) but I dont find it annoying
>very often. But I do have one complaint about it:
I think many of the things that you might just consider annoying,
I consider bugs.  A design flaw is a bug.
  I think you also have more patience with Apple than I do...
  But then, how many years is it *supposed* to take until you can
play sounds without crashing, hanging, or silencing the speaker?
It's been 8...

>|> I recall that when I tried to use the Palette Wrecker (so long ago) to
>|> do stuff, it did not, in fact, like being used to take over very much
>|> of the CLUT.  Everything would be fine until a dialog or something
>|> came up, and then my nice green would suddenly be replaced by an icky
>|> brown (which the dialog didn't even use!)  Of course, this happens with
>|> CLUT setting too, but hey, the Palette Wrecker is supposed to fix such
>|> problems.
>I have never seen this, but it soudns like a bug. I have only
>written 1 prog that takes over the whole palette (less black and white),
>and it has a dialog box (and about box) and it does not have this
>problem.
  I'm quite certain of this.  Just set the CLUT to, say, a ramp from
white to black, and then bring up some dialogs and stuff.  This is
System 6 & 7.  It will shove nasty colors in there and not take them
out.  Very annoying.  At least, it does it on my machine :->

>|> >Anyway, if u r gonna save and restore the clut, how do u force all other
>|> >apps and such to redraw [in teh case where u r not taking over the
>|> >whole screen], and of course also force teh desktop to redraw?
>
>|> Well, forcing a full refresh is easy, I could post the code if you
>|> really want it.  A few lines.  But only updating the windows that
>|> want a color refresh is not easy, and I conceded that point to you above.
>
>Well, if its short go ahead, as I have no clue how to do this and
>if you covert me to CLUT-manipulation I will need to know. But
>does it also updated the desktop?
Here's the code:

void InvalScreen()
{
	DrawMenuBar();
	PaintOne(0L,GrayRgn);
	PaintBehind(WindowList,GrayRgn);
}

I believe this is the only code I have ever posted that is copied
directly from Solarian II, so all you people who have been slavering
over the (imagined) prospect of getting Sol source out of my tight
little fists, rejoice!
  It does redraw the desktop.  It also seems to work in MultiFinder,
for reasons that I free admit to not understanding.  I wish they
would document what the window manager *means* in MultiFinder...

>|> those monitors.  Which the Palette Wrecker won't do.  A loop that sets
>|> all CLUT-driven 8-bit active screen devices to your CLUT is what you
>|> really want in this case, so the PaletteWrecker does you little good.
>
>Just inhibit all 4-bit devices. No problemo.
>Well, also inhibit all 2 bit devices. Unless u are nuts.
>
>The drawing in white part has nothing to do with the palette
>manager OR clut-fooling.
So the Palette Manager lets you say "this is the palette I want for this
window, but only touch windows that are 8-bit"?  I had no idea.  That's
nice.

>I now agree that SetEntries is better if u r taking over the whole
>screen. It is also the ONLY way to get teh whole palette to yourself.
>The Palette Manager will NOT touch white or black, EVER.
One of the more obscure areas of knowledge is "which parts of
QuickDraw continue to work when black and white are not in their
accustomed places?"  Due to a stupid design flaw in Solarian II,
I'm pretty familiar with this issue...

  Amusing fact: you, and so many others, dread going as low-level as
SetEntries.  Me, I've had to resort to calling the video driver
directly, because I considered SetEntries too slow...  And recently
I've been wondering if there isn't a way to get even lower-level -
some of those video drivers are pretty badly written, if you want to
get 60-75 CLUT switches a second...

  So, pretty much the end of this thread, I think...

-Ben Haller (deadman@garnet.berkeley.edu)
Xref: sparky comp.sys.mac.games:9034 comp.sys.mac.programmer:15262