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

In article <BuCK18.FE9@iat.holonet.net> bwilliam@iat.holonet.net (Bill Williams) writes:
>...I feel he is missing the point of what
>Ben Haller was trying to really express. HE HATES the inept way Apple
>implemented the Pallette Wrecker and it offends him...
Thank you, you expressed this very nicely.

>But on the other hand Ben Haller loses my respect as a person who has
>released products such as Solarian II which (from what I recall) take over
>the screen in a VERY UN-MAC manner. I have written graphics routines
>intended for inclusion in a flight simulator I might finish one day and
>all my routines (lines, ovals, rects, circles, simple polygons, filled and
>hollow of the aforementioned) were ALWAYS faster than quickdraw at every
>depth, but I designed them to work on movable windows. I do not see ANY
>speed advantages in a fixed non-window solution.
  Oh, no, no speed advantages.  That isn't why I designed Solarian II
the way I did.  I have written *many* graphics routines that are
origin independant, do region clipping, etc.  That isn't the problem.
  The reason Solarian II has no Mac interface is that it is supposed to
look like an arcade game.  As far as I'm concerned, things like
menubar, windows from other applications, etc. are pure distraction
when you're trying to play a video game, and they also ruin the mood
of the game.  Video games should look like the games you play in
a real video arcade, if possible.  I only regret that the Mac doesn't
ship with a joystick...
  I think this point of view is quite defensible...imagine if you're
trying to play a game using the mouse, and you accidentally click outside
of it's correctly-Mac-interfacey window, do a context, and your enemies
kick your ass while you're fumbling around trying to get back to the
game (you could say "pause the game", but it's still annoying, and what
about networked games?  You could say "hide the menubar during play"
and stuff, but then isn't this exactly what Solarian II does?)
  I think it's even more defensible from an aesthetic view...

>I want DAs, menubars, and windows in everything I run, including games.
  Well, I think you're in a minority.  And in any case, I make
aesthetic decisions based on *my* aesthetics, which makes the point moot -
I consider the choice I made to be correct, public opinion be damned.

>And my games have to use the mouse a proportional positioning device, like
>my hand, rather than a left right toggle switch, or I don't like to play them.
  A "left right toggle switch" being the way Solarian II works?
Actually, Solarian's mouse control is more subtle than this, and it was
very carefully designed.  You would hate life if Solarian II used the mouse
as a "proportional positioning device", you wouldn't be able to move
continuously...
  Well, wait.  Do you absolute positioning or relative positioning?  Really,
there are so many way to use the mouse, different ways suit different games
or applications, and I think it's dumb to say "I hate all games that don't
use the mouse *my* way."  The way Crystal Quest uses the mouse feels
very difficult to control initially, but after you get good at it it gives
you the perfect kind of control for the game.  I think that the mouse
control is probably my favorite thing about that game.

>Yes I know that there are right ways to program but people should
>recognize that the Pallete Wrecker is currently pretty obnoxious, but we
>still should use it.
  Why bother?  When they fix it, they'll probably put a whole new API
on, that seems to be what they do with things as broken as it is...
  Oh, but we've argued this to death, don't let's reopen it...

>Not only is the current pallete manager worthless, but Apple had someone
>type in the indices to the colors as shipped for the current System 7.0
>and the person made a TYPO on one of the crucial grays!!! The color is
>ruined and will never be fixed, its value escapes me now but its effect
>didn't. It made it IMPOSSIBLE to get TWO DAMN NEUTRAL GRAYS off the system
>at times. All I wanted were two grays equal in intensity to the light and
>dark grays used in NeXT and OSF Motif.
Here you are on drugs, I believe (metaphorically, at least).  The
System 7 CLUT is just fine.  I feel pretty sure of this.  Want to
specify which color you think is bad?  The grayscale ramp at the end
of the CLUT isn't *supposed* to be a smooth ramp, you know.  The
missing grays are to be found elsewhere in the CLUT.  And you know,
I'd be incredibly surprised if they had someone *type in* the CLUT
values, since it can be (much more easily) generated with a few lines
of code, being a simple algorithmically-generable color set...

>Also why all this talk about animating palletes now and then? isn't it (1)
>impossible on direct mapped 24 bit devices and (2) only possible at the
>end of a device VBL (governing it not only to 60 per second, but IDLING
>THE CPU during the wait? (not sure if it waits in the trap or not though))
>resulting in an effect leaving 0% free CPU.?
  It is impossible on 24-bit devices, although on these you can do
gamma animation instead (although the Palette Manager doesn't support this)
 Some video drivers wait on the VBL, some don't.  Which is very annoying.
But all you have to do (all you have to do - it's easy!) is do all of your
other processing at interrupt time, and then you'll be fine, the delay loop
in the video driver won't bother you at all...
  It should also be possible to use a combination of a slotVBL and a
Time Manager task (and a Deferred Task too, I suppose) to get rid
of the delay loop...

-Ben Haller (deadman@garnet.berkeley.edu)