Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!usenet
From: deadman@garnet.berkeley.edu (Ben Haller)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Double-Buffering in QuickDraw
Message-ID: <1990Sep28.171750.17381@agate.berkeley.edu>
Date: 28 Sep 90 17:17:50 GMT
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: Stick Software
Lines: 58

In message <1990Sep28.073335.30984@cunixf.cc.columbia.edu>,
jtt@cunixd.cc.columbia.edu (James T. Tanis) asks:
> I'm trying to speed up some animation I'm doing, and thought it would be a
> really neat idea to swap in from an offscreen buffer. Too bad the tech
> notes say that this does not speed things up. Ah, the joys of a graphics
> machine... :-)
Since when is the Mac a graphics machine?  Just because it has graphics,
doesn't make it a *graphics machine*...  Myself, I see a graphics machine
as a machine with a graphics coprocessor at the very least.

> So, then I tried to set the bits in thePort->portBits directly, resulting
> in improved performance and a spectacular crash...
> Does anybody have a good solution to this sort of thing?
Hmm.  Well, Solarian II sets the video buffer directly, and after several
new versions (1.01 for the IIci, 1.03 for 24-bit boards) I seem to have
gotten it right.  It's rather tricky.  You should think seriously about
it first, since it limits you do a single bit depth unless you special-
case for different depths, and it won't be much faster (if at all) than
CopyBits unless you write it all in assembler (all of the display routines,
not all of your program...)
  But assuming you really want to do this, the steps to take are:
    1. Search for a monitor in the bit depth you need
    1b. If not found, exit gracefully
    2. Figure out the coordinate system of that monitor, i.e. rowBytes,
       physical width and height, base address.
    3. Figure out if you need to switch the processor into 32-bit mode to
       write to the monitor (you can do this using 32-bit QuickDraw calls.
       If 32-BCQD isn't present you know you can stay in 24-bit mode).
    4. Calculate the address of the start of the block you want to write
    5. Switch into 32-bit mode if necessary
    6. Start writing, being careful not to draw off the screen boundaries
    7. Switch back to 24-bit mode
  This really isn't that simple, but it's not impossible, as Solarian II
shows.  It just takes a lot of trial and error.  Things to make it faster:
    1. Write as much data as you can at one time
    2. Have one routine that clips to screen boundaries that you only use
       for sprites that may need clipping, and another routine that does
       no checking at all for most of your sprites, which will be onscreen
       all the time.
    3. Write as big a chunk as you can at once.  In other words, write out
       long words, not bytes.  This depends on what processors to want to
       run on, since earlier ones are dependant on word and longword writes
       falling on word boundaries
    4. Fall on word boundaries anyway, it's much faster.
    5. Obviously do a color translation beforehand if necessary, don't
       do it on the fly.
There are lots more optimizations you can make, but they aren't all really
necessary.  Solarian II could probably be more optimized than it is...
keep in mind the limits of the machine, though.  A IIcx can't blit a
full-screen image from an offscreen buffer to on-screen in less than 2-3
60ths of a second (in 8-bit mode), so moving-backdrop games in 8-bit color
are simply not currently possible.  And keep in mind that on machines with
one of Apple's QuickDraw accelerators, the *most* optimized blit you can
write may be considerably slower than CopyBits would be.
  Hmm.  I hope that was all clear.  If enough people are very interested I
could probably spout more on this subject. :->

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