Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!eagle.wesleyan.edu!rcook
From: rcook@eagle.wesleyan.edu (ME:MINT.INIT)
Newsgroups: comp.sys.mac.programmer
Subject: Who cares about sync? (was Re: Animation)
Message-ID: <1991Feb11.142307.38779@eagle.wesleyan.edu>
Date: 11 Feb 91 19:23:06 GMT
References: <1961.27B4BFB4@stjhmc.fidonet.org>
Organization: Wesleyan University
Lines: 47

In article <1961.27B4BFB4@stjhmc.fidonet.org>, Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes:
> Baudoin Raoult writes in a message to All
> 
> BR> The simplest way is to use TickCount, as the tick counter is 
> BR> updated every 60th of second, each time the video spot starts 
> BR> to update new screen. So just write: 
> BR>  tmp := TickCount;  while tmp=Tickcount do { nothing } ;  CopyBits(.....)
> 
> To make sure that you get the most accurate reading (and the longest time in
> which to do your drawing) use GetTrapAddress to bypass the Trap Dispatcher and
> jump directly to TickCount. Otherwise, you have 100+ CPU cycles of overhead
> that you are wasting. This might not be much, but it could change the flicker
> if your drawing is small enough.

um, couldn't you just read the global variable ticks (or whatever it is
called)?  If you did it inline, it might take 12 or 16 CPU cycles or so.

BUT, what does all this talk of synchronization to the screen refresh mean if
CopyBits takes more than one video frame to put the image on the screen?  And
even if it takes less than one video frame, what happens if the "video spot"
passes over the point in the screen buffer CopyBits it currently writing to? 
This could easily occur if your object is to be drawn near the top of the
screen.

In addition, how would your program deal with the unpredicatble VBL tasks which
eat up time potentially every video frame?  For example, suppose you are
playing a sound on a Mac with no sound chip, so the 68000 must send the sound
bytes to the speaker.  This can take up lots of CPU time; so much so that it
could seriously impinge on any graphics you might be doing concurrently.

I realize that I'm raising a lot of questions and giving no answers, but I hope
I have made the point that good animation comes as a result of a very efficient
erase/redraw algorithm and not from fancy synchronization schemes.  Perhaps the
best way is to do what games programmers were doing on Apple ][s 12 years ago*:
page flipping, where you have two screen buffers and you alternate between
them.

*I'm sure page flipping has been around a lot longer than the Apple ][, I just
want to keep everything in the same company :-)

If only the Mac had sprites like a Nintendo...


------------------------
Randall Cook
rcook@eagle.wesleyan.edu
------------------------