Xref: utzoo rec.games.programmer:2177 comp.sys.amiga.tech:14362 Path: utzoo!utgpu!watserv1!watmath!att!pacbell!indetech!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: rec.games.programmer,comp.sys.amiga.tech Subject: Re: Animation Speed & Redraw Message-ID: <1990Sep8.081905.18030@zorch.SF-Bay.ORG> Date: 8 Sep 90 08:19:05 GMT References: <4347@dogie.macc.wisc.edu> Organization: SF Bay Public-Access Unix Lines: 48 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. [My experience with them is limited to AmigaBASIC, though; the less said about that, the better.] >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. I guess I don't understand that. But anyway, fascinating discussion. I have a question, though. In the case (not Amiga specific), where a "pristine" background screen is being kept and the animation overlaid with rectangles from that to restore the background, and then redrawn in the new position, is it really so difficult to synchronize with the vertical trace that double buffering is needed, so you end up with THREE copies of the screen? That seems like a lot of overhead, if avoidable. You've cut the data you have to move by a third this way (overlay old animation with pristine background, draw new animation, versus overlay saved background rectangle, save new background rectangle, draw animation in new rectangle's space), doesn't that give you time to evade the scan line? 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? Kent, the man from xanth.