Xref: utzoo rec.games.programmer:2168 comp.sys.amiga.tech:14326
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!metaphor!neuromancer!djh
From: djh@neuromancer.metaphor.com (Dallas J. Hodgson)
Newsgroups: rec.games.programmer,comp.sys.amiga.tech
Subject: Re: Animation Speed & Redraw
Message-ID: <1410@metaphor.Metaphor.COM>
Date: 6 Sep 90 18:18:44 GMT
References: <4265@crash.cts.com>
Sender: news@metaphor.Metaphor.COM
Reply-To: djh@neuromancer.metaphor.com (Dallas J. Hodgson)
Organization: Metaphor Computer Systems, Mountain View, CA
Lines: 52

In article <4265@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes:
>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.
>

No need. What I was talking about in an earlier letter was displaying
screen A, while clearing out screen B, rendering objects in B, then swapping.
Games w/large backgrounds could replace the "clearing out" step with a "copy
the background" step from a third (background) bitmap. No "clean" bitmap
copies necessary.

>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.

I think most developers have realized that hardware sprites are a headache.
A decent 16-color x 32 pixel wide sprite image requires 4 sprites which
can't be reused until the line after the bottom of the image.

<other stuff about EGA/Apple-II deleted>

So, let's hear it: you can blitter-zap a 320x200x4 screen
7,160,000 / (# words in screen * 4 cycles/word) = 111.875 times a second.
If a blitter-copy is performed instead, you have 59.93 frames/second
refresh.

Theoretical maximums, but still plenty quick. There's high overhead in
blitter register setup, and performing many cookie-cut background
save/restore operations for each animated object sounds is much higher
overhead than just blasting the bitmap. Of course, if there's only a few
small objects, then it may not make much difference...

So, let's hear from folks that have commercial products with high-speed
refresh. How did you do it?
+----------------------------------------------------------------------------+
| Dallas J. Hodgson               |     "This here's the wattle,             |
| Metaphor Computer Systems       |      It's the emblem of our land.        |
| Mountain View, Ca.              |      You can put it in a bottle,         |
| USENET : djh@metaphor.com       |      You can hold it in your hand."      |
+============================================================================+
| "The views I express are my own, and not necessarily those of my employer" |
+----------------------------------------------------------------------------+