🚀 go-pugleaf

> I've just started writing an arcade-style game in Lightspeed C and
> there are a few problems which I'd like to clear up before moving on.
> 
> 1) How do you make sure the memory for the alternate screen buffer isn't
> used for something other than a display?
BufPtr points to the top of available memory.  You have to re-launch
yourself to get the alternate screen setup.  So: at first launch, check
that BufPtr points *above* the alternate screen.  At re-launch, check
that it points *below* the alternate screen.  This should guarantee that
the screen was available and is now yours.

> 3) How do you make the video display hardware display the alternate
> screen buffer? How can you make it do this during a vertical blank?
Twiddle some hardware bits to switch screens; see the Hardware chapter
of the Addison-Wesley Inside Mac.  To hit the vertical blanking interval,
just wait for the Ticks counter to change.

> 4) Is there a global variable I can access that holds the address of
> the alternate screen buffer so that the program will run on the Mac
> 128, 512, and Mac Plus?
I'm not positive, but I think that the screen pointer global will point
to the alternate screen if you launch yourself with the alternate screen
configuration.  For the existing Macs, it's sufficient to use fixed
screen addresses assuming 4Meg of memory.  Wrap-around takes care of
smaller memory sizes.  This technique will drop dead as soon as Apple
comes out with a Mac with a different-sized screen.

> I realize that screen flipping is not a 100% Apple-approved animation
> technique (and it won't run on the Lisa), but it does provide the
> highest quality animation possible.
Apple suggests: draw into an off-screen bitmap, wait for the clock to
tick, then _BlockMove the changes onto the screen.  If your changes are
organized from top to bottom, you don't have to finish during the vertical
retrace, you just have to keep ahead of the current scan line.