From: johnsd2@lib106.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: NON-QUICKDRAW GAMES
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Wed, 9 Sep 1992 21:15:31 GMT

[note that I inserted blank lines all over the place, so I could
 read this stuff]

In article <18lbbfINNsdp@agate.berkeley.edu>, deadman@garnet.berkeley.edu (Ben Haller) writes:
|> In article <#m4y9kn@rpi.edu> johnsd2@rpi.edu writes:
|> >In article <18ja83INNk53@agate.berkeley.edu>,
|> >  deadman@garnet.berkeley.edu (Ben Haller) writes:
|> >|>   As several people have already indicated, the two basic methods
|> >|> are either using the Palette Wrecker (oh, did I say wrecker?  I meant
|> >|> manager) or using SetEntries.  The thing I want to address is this,
|> >|> in my mind unwarranted, bias towards the Palette Wrecker (there, I
|> >|> mistyped it again!)

|> >Dang.. ya gotta watch them typos, ya know :)

|> I just keep doing it, I don't know why...but then you seem to mistype
|> "you" as "u" (not to mention "the" as "teh"...) :->

Hmm... must be line noise. That's it, yeah... :)

[deletia- Palette Manager gives u best o' all possible worlds. Not. ]
|> >Granted. The Palette Manager does not care about which slots it
|> >uses. I don't see why you do.. is there some benefit to particular
|> >slots that I am not aware of? Id think that CLUT slot is pretty
|> >much like annother, unless u r XORing things... Of course, u could use
|> >pmExplicit colors to get specific indicies.

|> No, the whole point of using the Palette Manager, as far as I can tell
|> from Inside Mac, is that you will be compatable with other people, to
|> reduce the amount of CLUT-flashing and such that goes on to a minimum.
|> Well, not the whole point.  But most of the point.

Well, I would say it has a more important function- to be compatible
with all sorts of wierd hardware, new system versions, etc. SetEntries
and all that can be made compatible, of course, but that sounds
like doing things the hard way.

|>  When you ask for
|> a certain shade of green, it is supposed to either say "oh, here's a
|> green that's good enough, use it" or say "well, there's no green close
|> enough, here's one that I just allocated into the CLUT using a slot nobody
|> else's palette was using."  The first case works, but then you could've
|> called Color2Index to find that out.

Sure. But why bother? [actually, thats a bit of a silly
question. That's what your artile was about. :)]

|>  The second case does not work
|> unless everybody else running is also using the Palette Manager (not
|> bloody likely - what proportion of commercial apps do you suppose use
|> the Palette Manager?)

Id make that "anybody" not "everybody"; if we have 3 apps, A B and C [such
nice names], and A and B use the palette manager and C does not, then
A and B will avoid each others palettes (allegedly. You claim this
does not work; I have never tested it); Neither will avoid the
colors C is using (if any), but you are still deriving some benefit.
Ill get more into what happens to C later, since C is probably
the Finder. :)

|> >|> In my experience using the palette manager means the screen does CLUT
|> >|> flashes that are even more distracting than they would usually be (i.e.
|> >|> it will often flash *several times*),

|> >I have never seen this myself. Can you give an example?
|> >[ie how can I make it happen?]

|> No, I can't.  I haven't used the Palette Manager in years.  Anybody want
|> to give an example, or alternatively tell me I'm full of it?  I may
|> be full of it, but this was my impression.
|>   A point in your favor.

Yay! A Point! That's one! :)
I am also eagerly awaiting instructions on how to muck up the
Palette Manager this way. So if u email it to Ben Haller,
please email it to me too. Thanx.

|> >Also, I presume the technique you propound somehow gets the screen
|> >to redraw, with the new colors. Otherwise, you'd wind up with the
|> >usual my-background-is-in-briliant-yellow-and-turquoise-and-my-finder-
|> >icons-are-indecyperable syndrome. This bothers me much more than the
|> >"flash" the palette manager produces. And things only get weirder, since
|> >thigns that are redraw/exposed get draw right, but everything else
|> >is still mauve or something. yeck. :)

|> Mmm, you can force a refresh, but you would be quite right to point out
|> that the Palette Manager can do a selective refresh on only the windows
|> that requested color update refreshes, which is preferable.  A point in
|> your favor.

Thats 2 points! Im on a roll! Anyway,

Well, maybe *you* can force a refresh. I dont know how. And I have
seen a few comercial apps that dont know how either. Also, it seems
to me that most of the time wasted by the Palette Manager is spent
redrawing teh screen.. in this case do you not invoke a similar penalty
(although probably smaller... I think the PM is wasting more time than
just this)

|> >|> you end up with a pretty crappy CLUT
|> >|> that in no way avoids frequently-used colors, and the other applications
|> >|> in the system are often permanantly fucked up and don't redraw correctly
|> >|> from then on.

|> >Can you give examples of when this happens too? It does not
|> >happen to the programs I have written that use palettes. Also,
|> >why dont they have the same prob with direct-clut-changes?

|> OK, here I think I'm on firm ground.  Applications that are written
|> correctly using SetEntries install their CLUT on resume events and
|> replace the CLUT that they overwrote on suspend events, and therefore
|> applications that depend on having the system CLUT get the system CLUT.

I talk about the question of apps-w/-no-clut-or-palette below. A Lot.
Just one other thing:

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?

|>   Application that use the Palette Manager basically get ActivatePalette
|> called for them when their window comes to front.  *But* - when another
|> application that doesn't use the Palette Manager *or* SetEntries get
|> brought to front, the environment is not restored.  The other applications
|> palette stays in place, and the app that wanted the system palette is
|> fucked (pardon the expression).

Yes, it is.

|>   Now you could say "oh, well that application should have put in a palette
|> that had the full system palette in it, and then everything would have
|> worked."

Yuck. This is not a good idea, the palette will be loaded backwards or
something.. not in the "standard" order. This slows down copybits!

|>  But IMV-152 says "If the front window is an old-style window,
|> or if it has no assigned palette, the Palette Manager establishes the color
|> environment using a default palette.  For many simple application the
|> default palette will suffice."  To me this implies that you are supposed
|> to be more or less guaranteed the system palette unless you request
|> something else.  It doesn't seem to work this way.

I disagree- the palette manager is trying to let apps SHARE the
palette, so that if apps only allocate (say) 30 colors each,
they can BOTH get their palettes. CLUT manipulation does not do
this in any way I can see. If the system palette was restored whenever
a non-PM app came forward, there would be a lot of flashing and this
palette sharing would be disturbed.

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.

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.

|>   Any comments?  As I said, I haven't written an app using the Palette
|> Wrecker (oops) in a long time, maybe Apple has fixed this sort of thing.

No, they haven't.

|> But I seem to recall ResEdit still premanantly fucks up the color
|> environment (it sort of flips the clut across the line y=x, for
|> no apparent reason, which confuses the hell out of the Finder), and
|> presumably it uses the Palette Wrecker.
|>   Until further notice, I'll count a point for me...

Go right ahead. It still does that. Like I said, the Palette
Manager doesn't care what slots the colors go in- so it sez
"hey lets slow down copybits by putting the palette in BACKWARDS!"
or something. Quite lame. This only applies to the default palettes,
tho. [other palettes slow down copybits either way]

ResEdit is a little crazy with its palettes- it has the default palette
assigned to a lot of its windows. This makes for loads o flashing,
as is unecessary (as the resedit rarely makes large changes to the
palette, the colored icons would look decent anyway. If they didn't
it would revert to b&w, so its not a big deal.)

[deletia- entirely redundant stuff, see above and below about
	  apps that dont have their own palettes :)]

[deletia- its slow, yep it is]
[deletia- it inreases yer code size, no it doesn't, yes it does, etc]
|> OK, perhaps you are right on this.  Point for you.  I was thinking
|> more of the type of CLUT code I tend to write (take over the screen),
|> whereas you're talking more about QD-in-a-window.

Yay, annother point! That's 3 now, isn't it?

[deletia- I am talking about qd-in-a-window, not just direct-to-screen]
|> Yes, I think I stated my case a little more broadly than I should have.
|> 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
|> someday.

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:

if you close a window w/ a palette, or remove the palette from it,
nothing happens to the color environment. If I am explicitly
getting RID of a palette, it ought to revert to the default
IMHO. Right now it assumes if you have a palette, u want those
colors until you tell it you want some OTHER colors.

Yech.

[deletia- PM looks worse, why?]
|> 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.

Can you give me more specifics?

|>   BTW, anybody noticed the charming System 7 bug that when the Color Picker
|> comes up, after you dismiss it it leaves the CLUT fucked up?  Charming.
|> They haven't fixed that one yet, have they?

Nope, they haven't. RRRRGH.

But, if yer window has a palette that palette gets activated, and
u have your colors back anyway. If you dont, I dunno maybe u r just
messed up. Sounds like a bug, to me. I hope they fix it, its a pain.

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

|> >Also, why is the Palette Manager less compatible than CLUT stuff?
|> The apps-that-use-the-system-palette problem described above.

How's that a compatibility prob? They still work. They dont
have the system palette, but they they already had to deal with
that.

|> >|>   Also, if you're using direct-to-screen as almost everyone does - in a
|> >|> pixel-oriented paint program or in a video game - then you'll want the
|> >|> whole CLUT to yourself, in which case the Palette Wrecker (even if it
|> >|> worked) provides no benefits and all the drawbacks.

|> >Well, the Palette Manager takes care of multiple-monitor setups for you,
|> >and direct devices. I thot u'd have to special-case for that if
|> >u r using SetEntries. This doesn't matter if you are taking over the
|> >screen, but that drawing program ought to run in a window.

|> Yes, but...suppose it's an 8-bit paint program, in my opinion it would
|> be dumb to try to display on a 4-bit or less display, you just want to
|> leave those monitor's CLUTs alone and paint your window with white on
|> 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.

|>   Direct devices, etc. I tend to feel the same way - either they have
|> enough colors that you can show the 8-bit image on them just doing
|> matching with Color2Index (why is PmForeColor any better?) or you can't,
|> in which case you're just going to fill with white.

I suspect they have enough colors. :)

PmForeColor is not usefull for direct writing, and it is
a little shorter and more compatible (Apple's stamp-o-approval. :)
for QD drawing.

[deletia- stuff about which I have a point, according to Ben H.]
|> >|>   OK, I'm ready for the flames... :->

|> >I tried to be reasonable, and not flame. Mostly because
|> >I have the feeling that Im way, way out of my depth
|> >arguing with you. But what the hey. Now pardon me why
|> >I go dig up my asbestos underwear. I have a feeling
|> >my ignorance is about to be rudely exposed. :)

|>   You were very kind not to flame, given the unwise generality of my
|> original declaration.  I hope this reply didn't seem too hot either, I
|> think if it's a matter of one or the other of use being right I'd
|> give the prize to you.  However, I still feel SetEntries is better when
|> you're either taking over a monitor entirely, or when you want the whole
|> CLUT to yourself guaranteed.

Awwwww twernt nothing.

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.

|>   Sorry to waste bandwidth on stupid arguments, folks.  I was in a bad
|> mood yesterday, and didn't phrase my argument as rationally as I might
|> have...
|> 
|> -Ben Haller (deadman@garnet.berkeley.edu)

I suspect this little thread is about to die, since
we agree so much. :)
But if you decide to drop it, please email me that code to
refreshes the whole screen on ya. Id like to know how ya do that,
for everything (including menubar+desktop)

PS my apologies to everyone NOT concered with this for chewing up
all this bandwidth. :) I tried not to be redundant, repetetive or
even repeat myself, really I did. Honestly. But well...

Oh well, here goes nothing. Now where's that send button.. ah..
ther...
-- 
			- 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.