🚀 go-pugleaf

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

Dallas J. Hodgson writes:
> 
> 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?

  If you are talking about having a background behind the
animated objects, then you going to have to dump the
background onto the entire area of the screen after clearing
it.  Hence if the sum of the areas of the foreground objects
is less than the area of the screen, storing and restoring
the background behind each object is probably going to be
faster.  You will have a little bit of overhead calculating
the position of the areas to save, but this can be minimized
by clever programming. 
  One way to get faster animation is to devide the screen
into a grid of identical squares, and then quickly dump
shapes into those squares.  This gives blindingly fast
animation, but of course to animate across squares you need
lots of pre-shifted shape tables.  There are other
considerations as well, but I won't bother you with the
details (suffice to say it's the fastest technique I've come
across so far).

</\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\>
<  Philip J. Stephens                ><   "Many views yield the truth."        >
<  Hons. student, Computer Science   ><   "Therefore, be not alone."           >
<  La Trobe University, Melbourne    ><   - Prime Song of the viggies, from    >
<  AUSTRALIA                         ><   THE ENGIMA SCORE by Sheri S Tepper   >
<\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>

I can tell you from my experience that it is definately faster to erase
each object than to erase the whole screen; blitter or not.  The method
I use has three screen buffers.  Two for double buffering, and the
third I call the "pristene screen".  The pristene screen contains the
background without any objects and is never written to.  When I prepare
the object to be blitted, I save some of the information (that
pertaining to the rectangle that encompasses the object) in a structure
for erasing (actually, 2 structures because of double buffering).  Then
when I erase, I simply copy the reactangle from the pristene screen to
the rendering buffer.  When I was given the task of speeding up Dark
Castle/Atari, it was just this kind of change that brought it from 2
frames/sec to 15f/s, and that was using the CPU.  It's a tradeoff of
memory for speed.  If you can afford the third buffer, this is the way
to go.

Jay

Disclaimer: so, if I didn't have a disclaimer here, would anybody
seriously think I was speaking for my company???  yeah, right!