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

<I am crossposting this question, which arose in comp.sys.mac.games,
 to comp.sys.mac.programmer since it seems appropriate.  I don't
 read comp.sys.mac.programmer, so followups that I might want to
 see / reply to, please keep in comp.sys.mac.games as well...>

In article <josteisv.2@dhhalden.no> josteisv@dhhalden.no
  (JOSTEIN SVENDSEN) writes:
>In article <17loj6INN7mb@agate.berkeley.edu> deadman@garnet.berkeley.edu
>  (Ben Haller) (me) writes:

>>  The posting you saw was probably mine.  This is correct, many (most?)
>>fast-action games for the Mac do not use QuickDraw.  Certainly I would
>>never even attempt to write a fast-action game using QuickDraw.  The
>>"other method" that is used is to write directly to the memory that
>>represents the screen, with custom assembly code that results in faster
>>drawing than QuickDraw is able to achieve.

>   Can you please give me some hints/tips on how to learn the skills 
>neccessary to program fast-action games for the Mac?
>- e.g. books, sources, programming languages etc.

  Well.  This topic has been covered many times on comp.sys.mac.programmer,
and a (partial, at least) answer is in UMPG, the UseNet Macintosh
Programmer's Guide, the ordering details of which can be found in the
c.s.m.p. FAQ file.  But, since I'm in a good mood, I'll go over it briefly.
 Books: UMPG has stuff, as mentioned above.  Inside Macintosh has all the
actual technical details you need (if you include the tech notes, the 32
Bit QuickDraw documentation, etc.), although putting the pieces together
can be difficult, as usual with IM.  The latest (is it still the latest?)
d e v e l o p magazine (available from Apple or APDA somehow, I believe)
has quite a good article on direct to screen video, that's a very good
source.  It has been mentioned in many other places, in varying levels of
detail, but these three sources seem easy to find and relatively helpful.
  Sources.  The only source code I know of that uses direct to screen video
in a significant way is Juri Munki's (sp?) VectorKit code, which is now
publicly available from some FTP site which he just told me, but which I
forgot to save.  Someone else can surely produce the FTP site if there is
demand.  There may be source available for other things that I am not aware
of.  Source to my games (Solarian II, Lunatic Fringe) is not available no
matter how much you beg, so please don't try.
  Programming languages.  Think C is usually best for small projects,
games, trivial things.  MPW C or C++ is better for projects being worked on
by several people.  You may want to still use Think C, but use MPW to
project your source files for version control, etc.
  The actual code is really not very hard.  You get the base address of the
monitor from the GDevice record of the monitor (see IM 5, GDevices), or by
calling GetPixBaseAddr (but beware, old versions of that trap returned 0 in
at least some cases).  You synch to the monitor by installing a VBL task
with SlotVInstall (VInstall only synchs you to the monitor on the
non-color-QuickDraw machines), getting the slot number from the AuxDevRec
or some darn thing, which you get indirectly from the GDevice record (this
is vague, I know, I could dig up details if needed).  You change pixels by
simply writing to the memory off of the base address of the screen (beware,
you may be in 24-bit mode and you may need to be in 32-bit mode, call
SwapMMUMode to switch modes).  You may or may not want to notify the system
that you have changed the pixels (PixMapChanged, or PixelsChanged, or some
such trap - basically makes the GC card slightly less crash-prone than it
otherwise is...)  Don't write outside of the actual screen space, leave the
machine in the memory mode is was in when you're done, etc. and you'll be
fine.  Did I forget anything?
  I'd be glad to help anybody who needs it through e-mail, but remember,
if your question is general at all, others would probably appreciate
seeing the question and answer on the net, so you may want to keep
discussion there.  Please respect the request about continuing the
crossposting to both groups (c.s.m.p. and c.s.m.g.) since I do think it
is relevant to both groups...

-Ben Haller (deadman@garnet.berkeley.edu)
Newsgroups: comp.sys.mac.games