Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!harvard!bunny!mlr0
From: mlr0@bunny.UUCP (Martin Resnick)
Newsgroups: net.micro.mac
Subject: Re: Animation Query
Message-ID: <495@bunny.UUCP>
Date: Wed, 2-Jul-86 02:31:19 EDT
Article-I.D.: bunny.495
Posted: Wed Jul  2 02:31:19 1986
Date-Received: Thu, 3-Jul-86 01:16:21 EDT
References: <798@unirot.UUCP>
Organization: GTE Laboratories, Waltham, MA.
Lines: 82

> 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?
> 2) How do you tell Quickdraw to start drawing on the alternate screen
> buffer? How do you switch back to the main buffer?
> 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?
> 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 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.
> 
> On a separate matter, has anybody found Quickdraw to be too slow for
> putting down simple rectangular bit images in animation? In particular,
> has anyone tried preshifted shapes (this is the old Apple II technique
> where each shape is stored seven times - eight for the Mac - so
> that no "bit shifting" is done when the image is put on the screen -
> instead, each shape is always available in all possible bit
> alignments)? Is the speed gain worth writing the assembly code it
> needs?
> 

From a friend of a friend:

David --

I spent some time recently working on an animation program which dealt with
a lot of the issues you asked about.  (It's "Vanlandingham", the Mac parody
of Amiga's "boing" -- available on some nets and through the Boston Computer
Society).  A lot of the answers to your questions are covered in an article
in the June '86 MacTutor on "Screen-switching animation".  Some more details,
not quite in order of your questions:

(1) In theory, the Launch trap allows your invoker (eg, the Finder) to ask
for you to get the second screen.  So, you can wake up, see if you have the
screen allocated, and re-Launch yourself if you don't.  Unfortunately,
things like RAM disks, debuggers, and the damned Mac Plus RAM cache seem to
reside in this area, but don't prevent the Launch code from promising you
the second screen.  Apparently the global variable BufPtr can give you a
clue about whether this area is actually in use.  I'm not sure how to do this,
so Vanlandingham crashes in some cases.  Sorry.
(4) In all existing Macs, the alternate buffer is 32K bytes below the main
screen.  Of course, if a Mac with a larger screen comes out, they'll have to
be farther apart.
(2) It's possible to switch screens by using two grafPorts, but I use just
one and switch the bitmaps with SetPortBits.  The standard screen is described
by the bitmap screenBits, so you can say something like (pardon my Pascal):
    var altBits: bitmap;
       ...
    altBits := screenBits;  /* alternate screen's bitmap is almost same... */
    altBits.baseaddr := screenbits.baseaddr - 32768; /* ...but lower */
      ...
    SetPortBits (altBits);  /* do all drawing in the alternate screen */
      ...
    SetPortBits (screenBits); /* do all drawing on the main screen */
I suspect SetPortBits is faster than SetPort, but I don't know.
(3) You control the screen hardware through the VIA; the article covers this.

Yes, Quickdraw is very slow.  Vanlandingham has 16 or 32 (I can never
remember) preshifted shapes.  Even if you keep using Quickdraw, keeping
the stuff aligned will save some time.  Remember that when you clean up
a screen (copy from a pure background to erase an old image), you can round
the copy out to the next word (or longword) boundary on either side, and
your erase code can run much faster -- although it's copying a little more
data, it doesn't have to worry about left and right boundaries.

Yes, assembly language is worth it.  Vanlandingham does a good imitation of
the Amiga's bouncing ball, including drawing the ball to scale on the screen.
Using Quickdraw, the ball would have been about the size of a quarter, or
else the animation would have had to be much slower than 60Hz.  I found it
easy to prototype with Quickdraw, but needed assembler in the end.  Have fun!

The best way to reach me is via US Snail at:

Mike Morton / Lotus / 161 First Street / Cambridge, MA 02142

-- Mike Morton