info-mac@uw-beaver (12/07/84)
From: INTMET@BBNA.ARPA
Dear INFO-MAC readers,
Some time ago I wrote a program to move sprites about on the
Macintosh's screen. It didn't work. I'm hoping that somebody out there
can tell me were I went wrong.
To make a sprite move I set up this loop:
for(i=0;i<100;i++){tickSync();removeSprite(s);moveSprite(s);drawSprite(s);}
RemoveSprite doesn't do anything in the minimalist
version, causing it to leave a trail of litter on the screen as it moves.
In the full version it overwrites the Sprite on the screen with the saved
background. drawSprite uses PlotIcon in the minimalist version, in
the full version it saves the background, and then copybits a mask
followed by an image.
To sync with the vertical retrace interval the program spins on
the value returned by TickCount. This assumes that TickCount is
reading a low core global which is bumped by a task on the vertical
retrace task list. It also assumes that the retrace interupt is
generated at the beginning of the retrace, not the end. I can
see reasons why you might decide it should occur at either time.
Does anybody know when the vertical retrace interupt is generated,
my version of Inside lacks VRMG documentation.
All this mechinism doesn't work. The sprite is background in the
upper part of the screen and correct in the lower part of the screen.
That implies that the TickSync() returns at the end of the vertical
retrace. This might because the tasks in the default VRT task list
consume all of retrace time. Cursor updating is the only one that
I can think of that might take time. Anyway I can tell that MacPaint
manages to copybits the entire Paint window in the retrace time,
but I don't know if it took over cursor management too.
I'd like to avoid solving this problem by generate and test. Can
anybody offer some suggestions based on experiance. I have not
discussed here all kinds of stuff like raw memory access vs.
graphPorts, or caching the trap entry points, etc that I presume are
necessary if I want lots of sprites. Ben Hyde, Cambridge
-------info-mac@uw-beaver (12/08/84)
From: winkler@harvard.ARPA (Dan Winkler) > Anyway I can tell that MacPaint > manages to copybits the entire Paint window in the retrace time, I don't think that's true. As I recall from what Bill said, he uses both video buffers and only manages to switch between them in the retrace time. He also keeps yet another (third) copy of the screen to allow undo. So the MacPaint code is squeezed into even less memory than you might think.