From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
Subject: Palette Manager vs. Color Manager (was Re: NON-QUICKDRAW GAMES)
Summary: OK, Ben, but only for your very-special-purpose games
Organization: Kalamazoo College
Date: Thu, 10 Sep 1992 18:21:47 GMT

(Sorry to the csmp folks who are tiring of this thread;  I think this
article is relevant enough to be of interest to some programmers.)

deadman@garnet.berkeley.edu (Ben Haller) writes:
>
>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*)

With all deference to your experience--I love the two games of yours
that I've seen--I think your bad impressions are due to not using the PM
for a long time, and to badly-behaved applications (such as yours :-).

I'm right now flipping back and forth between my app and GIFConverter
(which uses the P.M.).  The clut changes exactly once, and each app
redraws its window for the new color environment exactly once.  (Well,
mine does it twice, but that's debugging code I haven't taken out yet.)
With lots of windows, it takes a few seconds, but so do all
mass-updates; what do you expect?

>the other applications
>in the system are often permanantly fucked up and don't redraw correctly
>from then on.

You may be thinking specifically of the Finder, which is courteous to
the point of obsequiosity.  If its icon colors aren't immediately
available, it doesn't even try to get them;  it just reverts to black
and white.

Applications that use the P.M. properly will get the colors they
request.  Those that don't, won't.

>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.)
>[later...]
>what proportion of commercial apps do you suppose use
>the Palette Manager?

I'd guess 90% of them, at least.  Those that don't cause conflicts.  For
example, our staff artist uses Studio/8, which uses the Color Manager.
It doesn't happen very often, but every once in a while, you'll notice
that after quitting, the inverse table is out of sync--the Finder's
icons are screwed up, some text prints in funny colors, and so on.  Only
restarting fixes it.  And if you hate color flashes on context switches,
try flipping in and out of Studio/8 a few times.

Same for those apps of mine that use the C.M.  It's totally unpredictable,
and affects any system or machine.  I still have no idea what I did wrong.

Solarian II and Lunatic Fringe take over the whole screen.  Try putting
them in a window, and doing context switches like a good little app.
Not during game play, of course--just so I can start and keep track of a
download between games, without having to quit.  Suddenly the C.M. isn't
so useful, is it?  Unless your users like everything behind your window
appear in truly bizarre colors.

Then, keep in mind what you have to do to prevent background apps from
coming forward.  Sure, you just don't react to clicks on the desktop.
But remember those FKEYs that call OpenDeskAcc()?  OK, you have to set
that byte at ScrnDmpEnable--er, or do you clear it?  Now no one can
cmd-shift-3 a snapshot of the game in action, and the boss wants a .GIF
to put on the box ten minutes ago...

It's just not worth it.

>And it has a lot of drawbacks,
>not the least being that's it's slow, it increases your code size,

It's as slow as it takes apps to redraw for a new color environment.
Code size does not increase appreciably (though 'pltt' resources take up
twice as much room as 'clut's, caveat ResEditer).

>it looks worse,

Oh come on!  Colors are colors.

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

And in my opinion it's a thousand times easier and more compatible.

>  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

How many games do you know that really, really _need_ 256 colors--not
254 or 255 but 256?  If you're clut-flipping to simulate page-flipping,
OK;  if you're writing for a 2-bit-deep screen, I can see that.  Most
games get along fine with 254 colors.

Paint programs...well, Studio/8 uses the Color Manager and it _still_
doesn't let you edit black and white.

>[in a later article...]
>*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).

Wait a minute.  If your app wants the system palette, attach a clone of
the system palette to its windows.  If you don't care what colors you
have, what's the problem?

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

You were supposed to rip that chapter out when you got IM VI.  :-)  That
phrase is nowhere to be found now, having been replaced by "By creating
a palette of colors for your application, you ensure that appropriate
colors are available when its window becomes frontmost."

By "many simple applications" is meant "applications that only want
black and white, and don't really care too much whether they get their
other colors or not."

>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;  but at least the Color Picker chapter no longer promises "it will
not alter the clut."  That's another chapter you should have ripped out
of IM V.  :-/

>There is nothing wrong with SetEntries - at least
>nothing that the Wrecker fixes.  So why bother.

Except color arbitration with the large majority of apps that _do_ use
the Palette Manager.  Except having to worry about ctSeeds and iTabSeeds;
when to re-make the inverse table (do you have to after SetEntries?
RestoreEntries? will Color2Index do it for you?);  sequence vs. index
mode in SetEntries;  how to use your source-level debugger when you've
set colors 0 and 255 to black...  Hey, three years ago I thought the
Color Manager looked easier, and I wrote three games with it.  We
still get about one tech call a week, "why does my text draw in aqua
after I quit your game?"

The Palette Manager is the right choice for 99% of the apps out there--
the 1% being those games which take over an entire screen, don't have a
menubar, _and_ which truly need _every_ color in the table.  At present,
I know of exactly one game which fulfills all three conditions.  (Storm,
because it uses clut flipping.)


If you followup, please edit the Followup-To line appropriately.  Thanks.
-- 
 Jamie McCarthy      Internet: k044477@kzoo.edu      AppleLink: j.mccarthy
 "Don't listen to Jamie, he averages several lies per message, especially when
  they are directed towards me or are talking about me, this BBS, 'Holocaust
  Deniers', etc.  I'm ignoring him now."   - Dan "Maynard" Gannon, 23 Aug 1992
Newsgroups: comp.sys.mac.games