Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!sdsu!crash!pro-gsplus.cts.com!rhood
From: rhood@pro-gsplus.cts.com (Robert Hood)
Newsgroups: comp.sys.apple2
Subject: Re: C compiler, question on Apple II graphics
Message-ID: <2008@crash.cts.com>
Date: 29 Mar 90 16:17:12 GMT
Sender: root@crash.cts.com
Lines: 31

In-Reply-To: message from ross@apollo.HP.COM

1.  I'd like to see an ANSI C compiler for the Apple 8-bits!  I'm tired of
hearing how great C is and not being able to use it!

2.  One way of doing animation on an Apple is by using shape tables and
DRAW/XDRAW to erase a shape from one place and redraw it elsewhere.  This
normally results in a lot of flickering - not to mention crude shapes. 
Another way is to use bitmapped shapes.  These are shapes formatted in such a
form that they can be stored directly on the Apple screen (as opposed to
vector shapes, where the shapes are drawn by following the vectors).  Finally,
there's a method that grew out of bitmapped shapes: overlays.  These overlays
differ from bitmapped shapes only in that they aren't "shapes" as much as they
are picture fragments.

A way to see the difference is to imagine a stick figure raising its arm. 
With typical shapes, you could have a shape of the whole figure defined in all
the intermediate phases.  You erase the old shape and draw the next in the
sequence until you get to the end.  Very bad flicker.  The next best way would
be to define just the moving part as a shape and operate as before.  Better,
but still leaves a lot to be desired.  Thirdly, you could take an area of the
screen and see what it would look like in each intermediate phase.  You
"capture" that area into a "shape" and just put it on top of the old image. 
That's even better.  Of course, it's slow if the area is large.  Hence, you
want to diminish the area of the animation as far as possible.

Maybe that helps, I don't know much more.

Robert Hood - programmer

ProLine address: pro-gsplus!rhood