From: johnsd2@vccsouth21.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: NON-QUICKDRAW GAMES
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Fri, 11 Sep 1992 01:57:12 GMT

In article <18one7INNm74@agate.berkeley.edu>, deadman@garnet.berkeley.edu (Ben Haller) writes:
|> 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...

My apps wouldn't, but that's beside the point.

This is not the case I was talking about. Let me try again.

Lets say we have two apps that use clut switching, instead of
palette wrecking or just taking their punishment like a good
little app. :)

Call them "Mongo Colors" and "Freds Neato Picture Program". Just to
waste bandwidth. :)

Start 'em both. Say mongo-colors is in front, and so far all is well.
Now bring Freds Picture Prog to the front. NOW, if Mong-Colors
gets a suspend and THEN fred's gets a resume, all is well.

If freds gets a resume, THEN mongo gets a suspend, things are not well.
Because fred will resume and save the "old" color environment, and
institute its own. the environment it is saving however is really
mongos! Then mongo replaces "its" environment with ITS saved version.
But its really replaces freds, which will mess fred up of course. AND
it will throw sand in the wheels of the mechanism that restores
freds palette, since its restoring the wrong thing. Mongo remains
blissfully ignorant tho.

However, is the order is guarantted to be suspend then resume,
all is well. Is it? [alternaately, maybe I have no clue.]

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

This can be done for your by the palette manager. Convert the default
clut you want to a palette, set all of its tolerances to something
reasonable, set the usage to pmTolerant. It will do nothing
in the case that the system palette IS there, and will fix the
palette in case it isn't.

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

This is NOT at all what happens on my mac anyway. Gray scale
still means gray ramp. the finder icons still draw right. They
draw they way they would if resedit had reversed the palette on them-
a bit slower. Because they need to compare RGB values and all that.
They do NOT revert to b&w! [however, u'd think it could use the 8 bit
icons in 4 bit mode when in grayscale, and it does not do this]

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

Funny, I find it easier not to use the palette, despite the fact
that I cannot assume that I will have exactly the colors I expect.
I have to use device-independant methods to do everything- the moreso
the better. MakeRGBPat, fer instance. icon families. That sorta thing.

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

This may be why the palette manager will never let you change black
or white. [is that what u mean? if u change black or white the
finder is mucked up beyond repair?]

I dont know of any way to use the Palette MAnager to muck up the finder
beyond repair. 

[a little deletia]
|> >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.

Perhaps so.

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

Rrrrgh! Dont remind me.. I had to shelve a good project (it played
sounds in the background) cuz I could not get the sound manager to
behave.

I DO consider this a bug.

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

But it doesn't do it on mine. Then again, I set the palette not the CLUT,
so maybe that clues it in. Or maybe not. It still has never happened to
me, and I have tried to use dialogs with the entire palette allocated.

[deletia- code to refresh whole screen. go read it yerself. :) ]

Thanks!

[deletia- about getting the palette manager not to touch certain depths]

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

[deletia- about not touching b&w]

|>   Amusing fact: you, and so many others, dread going as low-level as
|> SetEntries.

Oh, thats a little strong. I prefer not to go so low.. makes my life
more difficult that it has to be.. but I am not exactly cowering in the
closet afraid my Mac will come and get me if I dare to violate the
CLUT. :)

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

Well, this probably would send me scrabling for my closet. :)
 
|>  So, pretty much the end of this thread, I think...

That may be. Im not placing any bets yet.
-- 
copying			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.