Xref: utzoo rec.games.programmer:2178 comp.sys.amiga.tech:14364
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.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: <4350@dogie.macc.wisc.edu>
Date: 9 Sep 90 04:09:41 GMT
Sender: news@dogie.macc.wisc.edu
Followup-To: rec.games.programmer
Organization: University of Wisconsin Academic Computing Center
Lines: 58

In article <1990Sep8.081905.18030@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes...

>gilmore@vms.macc.wisc.edu (Neil Gilmore) writes:
>>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.

>Hmmm.  Any reason not to use sprites for some stuff (bullets,
>missiles, power bolts, etc.) and blitter objects for others?
>From what I understand of sprites, doing as much as possible
>with them seems to be A Good Thing.

Yes, too many things moving around. There are only so many hardware 
sprites, and even if you multiplex them, there will be situations where 
you just can't put all them on the screen. >IF< your design can 
accomodate sprites, then yes, it is usually better to use them. But I 
won't sacrifice my design just to be able to use them.

>>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.
(my scrolling example deleted)
Think of it this way. There is an object currently displayed at 10,10 on 
the first screen. This object moves right at a speed of 2, while the 
screen scrolls downward with a speed of 1. Say that previous to this the 
position of the screen and object were static, so that both screens have 
the object at 10,10. Now, while the first screen is displayed, the 
second screen is scrolled down 1. When the object is displayed, the 
background is restored to 10,11 because of the scroll, then the object 
is drawn at 12,11 because of the movement. Now the screens are swapped 
so that the object is displayed at 13,11 using the second screen. The 
first screen is scrolled >2< down to be consistant, and the background 
restored to 10,12 because 2 frames have passed since this screen was 
drawn into. The object is drawn at 14,12, then the screens are swapped, 
etc.

>More generally, do you find yourself always becoming
>performance bound before you become memory bound, so that
>this "triple buffering" is a good tradeoff of memory for
>speed?
It depends on the design of the game. For the sort of thigs I write, 
memory is always tight, because in strategy games there is so much 
information I'd like to store and use, and in animated games keeping 
several frames for each type of object is costly. But for animation, 
performance must be considered, becuase clunky games are no fun.


+-----------------------------------------------------------------------+
| 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)   |
+-----------------------------------------------------------------------+