🚀 go-pugleaf

I have written several commercial games on a variety of systems, and I really
have rarely  found it desireable to maintain a 3rd "clean" bitmap around for
starting with a clean background.  What you propose requires moving a clean
bitmap with no oibjects in it, into one of the displayable raster maps,
then simply drawing the objects on that clean background, then doing
all over again for the other bitmap after you switch views.  
This requires more overhead in almost all instances than saving the
recangular background behind raster objects, the restoring it and redrawing.

I recall on old apple //e stuff, the 3 screen approach was sometimes used,
and I did use it for a while, double buffereing the display but
keeping a "clean" background around for wiping the slate clean
between frames.  On a system like the amiga, this makes no sense, 
since hardware sprites can be reused and you get 128 pixels of 
sprite per scanline, and you DO NOT need to save the background
since they are not drawn into the raster in any case.

In other systems, the bitmaps are not too irregular (except maybe for
320X200X16 color EGA) and the processor can generally access rectangular
portions of the screen easily, so there is no need to copy the entire
background in each frame, the overhead to do this is generally MUCH
higher than it is to save/redraw many objects, whether they are large/medium
or small.  But if the screen bitmap is arranged wierd enough (like the
old apple // or IBM EGA) it is may become worthwhile to just bus in a new
screen each time.

-Roger

UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.com