Xref: utzoo rec.games.programmer:2160 comp.sys.amiga.tech:14299
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!psuvax1!psuvm!psuecl!d6b
From: d6b@psuecl.bitnet
Newsgroups: rec.games.programmer,comp.sys.amiga.tech
Subject: Re: Animation Speed & Redraw
Message-ID: <20554.26e51403@psuecl.bitnet>
Date: 5 Sep 90 19:04:33 GMT
References: <1401@metaphor.Metaphor.COM>
Organization: Engineering Computer Lab, Pennsylvania State University
Lines: 27

In article <1401@metaphor.Metaphor.COM>, djh@neuromancer.metaphor.com (Dallas J. Hodgson) writes:
> You know, I've never seen this mentioned anywhere but the question is always
> in the back of my mind. If you're working on a real-time game that commonly
> has high numbers of animated objects moving around at all times (using a
> double-buffered screen) is it faster to clear out the undisplayed screen
> completely and redraw all the objects vs. restoring the background behind
> each object and then redrawing?
>
> There's a lot of overhead associated with clipping & storing the background
> behind every object just so it can be restored later. However, even with
> blitter assist clearing out 32-40K worth of video memory each frame is
> real-time significant. Not that I'm working on any games currently, but I've
> always wondered about this. How do you approach bitmap animation when speed
> is a prime consideration?

That is actually a very astute question. It isn't just a matter for game
designers, either. If you're going to re-write the entire background each
time, hardware scrolling becomes superfluous. In fact, although Menace,
the first game from DMA Design, used hardware scrolling and saved/restored
the spaces where the BOBs were to go, they switched to a software scroll
in their next game (Blood Money). Sprites, of course, are a different matter...

> Games like Datastorm are technological wonders in my book.

I agree. In fact, Datastorm happens to be my favorite Amiga shoot-em-up
game.

-- Dan Babcock