Xref: utzoo rec.games.programmer:2176 comp.sys.amiga.tech:14360
Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu
From: gilmore@vms.macc.wisc.edu (Neil Gilmore)
Newsgroups: rec.games.programmer,comp.sys.amiga.tech
Subject: Re: Animation Speed & Redraw
Message-ID: <4347@dogie.macc.wisc.edu>
Date: 8 Sep 90 03:47:24 GMT
Sender: news@dogie.macc.wisc.edu
Followup-To: rec.games.programmer
Organization: University of Wisconsin Academic Computing Center
Lines: 18

Most games which I have programmed (on systems which had them) did not 
tend to use hardware sprites, as there was always too many objects 
moving around at once. Even using vsprites probably wouldn't work here. 
I never found scrolling to be a problem. The technique which I would use 
would scroll the buffered screen and redraw the animated portions with 
the knowledge that the scroll had taken place. Thus, all I had to do was 
scroll the screen, draw in those portions of the playfield which had 
become visible, and renew the animated objects. You can even use the 
same list of objects for each screen, as the positions, animation frame, 
etc. still differ by only 1 from the current list (after scroll), even 
though the positions differ by two from the position on the current 
drawing screen.

+-----------------------------------------------------------------------+
| Kitakaze Tatsu Raito	Neil Gilmore     internet:gilmore@macc.wisc.edu | 
| Jararvellir,          MACC, UW-Madison bitnet: gilmore@wiscmac3       |  
| Middle Kingdom        Madison, Wi      DoD #00000064 (no ints here)   |
+-----------------------------------------------------------------------+