Thread View: rec.games.programmer
2 messages
2 total messages
Started by Neil Gilmore
Sat, 08 Sep 1990 03:47
Re: Animation Speed & Redraw
Author: Neil Gilmore
Date: Sat, 08 Sep 1990 03:47
Date: Sat, 08 Sep 1990 03:47
18 lines
1707 bytes
1707 bytes
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) | +-----------------------------------------------------------------------+
Re: Animation Speed & Redraw
Author: Kent Paul Dolan
Date: Sat, 08 Sep 1990 08:19
Date: Sat, 08 Sep 1990 08:19
48 lines
2682 bytes
2682 bytes
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. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads