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

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"...) :->

>|>   If you use it, in the best of all possible worlds, when your application
>|> get context-switched in your palette will be swapped back in, using the
>|> best possible slots in the CLUT taking into consideration the colors
>|> everybody else is using, etc. etc.  This is hogwash - it never happens.
>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.  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.  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?)

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

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

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

>|>  It just isn't worth it, folks.  Nobody else uses the Palette
>|> Wrecker, and so all of the much-touted benefits simply aren't there (lack
>|> of entry conflicts with other apps, etc.)
>Well, the-no-entry-conflicts thing works for apps that dont use ANY
>clut or palette mucking.. they are forced to redraw, and do so with
>the new colors. This is of course only in my experience, u have
>already said yours differs. It also works for other programs
>that use the palette manager, and it does no harm for those that
>don't, right?
See the discussion above, I believe it *does* harm apps that don't fiddle
with the color environment in any way.

>|>  And it has a lot of drawbacks,
>|> not the least being that's it's slow,
>granted.

>|> it increases your code size,
>how does it do this? U can have a palette in a pltt resources
>and not add ANY code, if u r using GetNewCWindow. You
>can grab palettes from resources with very little
>code. Even if you are assembling one on-the-fly, it doesn't seem
>to me like it takes nearly as much code to allocate, fill in,
>assign and activate a palette as it would to write code to make
>clut-manipulation work on multiple monitors,  on direct devices,
>on b&w machines, 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.

>By the way, Im talking about the more general case of
>drawing-w/-quickdraw-in-a-window, not just the direct screen drawing
>stuff and the take-over-teh-screen stuff, since you appear to be saying
>"never use teh Palette Wrecker, ever ever ever". I can see (now) why you
>would not want to do this if you are not using windows, quickdraw, etc.
>It would be most pointless, but slow anyway. :)
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.

>|> it
>|> looks worse, and it's (in my opinion) meither as aesthetically pleasing
>|> nor as compatable as just saving & setting the CLUT (or part of the CLUT)
>|> on resume events and restoring the parts you changed on suspend events.
>Why do you say this? The palette manager should be able to completely
>change the clut to anything u want, 'cept u have to have black and white
>in the clut. Is that such a big difference?
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.
  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?

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

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

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

>|>  Just because Apple says to use the Palette Wrecker doesn't
>|> mean you have to.  There is nothing wrong with SetEntries - at least
>|> nothing that the Wrecker fixes.  So why bother.
>Well, the Palette Manager takes care of a bunch of details for you,
>which I have mentioned, and lets you share palette entries with other
>apps if you like (although this doens't work very well, in my option.
>Its that annoying restriction on the values tolerances can take.. you
>cant have small, non-zero tolerances. bleah) It also (in my experience,
>perhaps yours differs again) can allocate "unused" palette entries- IF
>other apps are using the palette manager. If they aren't, no harm (that
>I know of) done.
All discussed above.  You have a point, as I conceded, and I reduce my
claim somewhat.

>|>   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.
  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)
Newsgroups: comp.sys.mac.games