Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!rena!lkbreth!trebor
From: trebor@lkbreth.foretune.co.jp (Robert J Woodhead)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Optimizing animation processing speed
Message-ID: <9355@lkbreth.foretune.co.jp>
Date: 21 May 91 03:01:51 GMT
References: <1776@babcock.cerc.wvu.wvnet.edu> <8996@ucdavis.ucdavis.edu> <1991May18.231302.16630@nntp-server.caltech.edu> <1991May20.202641.5094@visix.com>
Organization: Foretune Co., Ltd.  Tokyo Japan
Lines: 64

ed@nsx.Berkeley.EDU (Ed Devinney) writes:
>Which is all very nice, but not for animation.  Like the commercial says, sometimes you
>gotta break the rules, and smooth, consistent animation requires taking control of the
>drawing.  (Kind of hard to guarantee a frame rate in a purely user-event-driven 
>environment).

Well said!  I've been doing a little hacking with a colorspace II board
recently and worked out a couple of simple techniques that can be
useful.

My problem was to be able to do an instantaneous (eg: during the VBL
time) change from 1 image to another.  Unfortunately, a Mac II can't
repaint all 250k odd pixels in <1/60th of a second!

	(BTW, if anyone has any tricks to speed up block
	transfers to NuBus device memory, I'd be interested!)

Since I often needed to change most of the pixels on the screen, but
DIDN'T need to do this each and every VBL interrupt, the following
technique was useful.

The idea is to reduce the number of simultaneous colors you can have
on the screen and trade this for having multiple images in the screen
buffer.  You then simply change the color table in order to make the
desired image appear.

A simple example:  Lets say you only need 8 colors per image (3
bits per "pixel".  You reserve a block of color table entries that
start on an 64 entry boundary.  You need 64 of them (6 bits) do
be able to put 2 8 color images into the buffer at the same time.

These colors will all be in the format of, say, 01AAABBB, where AAA
is one set of 3 pixels and BBB is another set.  Next, paint image
#1 into the AAA pixels and image #2 into the BBB pixels.

Now set up 2 color tables for the graphics device.  In one, the AAA
bits are "don't care", so that the color setting for any value in
the table depends only on the value of BBB.  The second is the inverse,
where the AAA bits are don't care bits.  In each table, each color
is repeated 8 times.

Now, by flipping from color table to color table in a slotVBL routine,
the images will appear alternately.

If the object you are animating is small enough, you have enough time
to repaint the invisible object before the next VBL time, and thus
do totally seamless animation (albeit in reduced colors).  Note that
you can change the invisible object at any time, because changes to
those bits don't affect the visible image on the screen.

In my own application (a video titler) I only needed 4 colors, so I
have 3 different objects on the screen, and a pixel format of
01AABBCC.  Thus my program has 1 image visible, one waiting to be
displayed, and one being created.  You can also, by use of multiple
color tables, do fades and dissolves between images.

Not a general technique, but for some things it is incredibly useful.


-- 
+--------------------------------------------------------------------------+
| Robert J. Woodhead, Biar Games / AnimEigo, Incs.   trebor@foretune.co.jp |
| "The Force. It surrounds us; It enfolds us; It gets us dates on Saturday |
| Nights." -- Obi Wan Kenobi, Famous Jedi Knight and Party Animal.         |