Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!sdcsvax!sdcc6!sdcc7!ee162faq
From: ee162faq@sdcc7.ucsd.EDU (JOHN SCHULTZ)
Newsgroups: comp.sys.amiga
Subject: Re: Blitter
Message-ID: <831@sdcc7.ucsd.EDU>
Date: Thu, 4-Dec-86 05:23:17 EST
Article-I.D.: sdcc7.831
Posted: Thu Dec  4 05:23:17 1986
Date-Received: Thu, 4-Dec-86 20:03:25 EST
References: <8612040134.AA15904@cory.Berkeley.EDU>
Reply-To: ee162faq@sdcc7.ucsd.edu.UUCP (JOHN SCHULTZ)
Organization: U.C. San Diego, Academic Computer Center
Lines: 50

'not changing either image' defined as not changing the colors of
the top image from the original definition, transparent areas of top
image not affecting background image. Anyway, doing multiple blits
will definitely slow things down.  I want to have the fastest
frame-frame generation as possible.  Therefore I am using a
double-buffered display and SetRasting the whole screen to 0 each
frame.  The simulation has multiple particle explosions (AreaXXXX
commands), particle beams (Move/Draw/SetDrPt), various onscreen
information (Text,RectFill), and of course shapes defining the
simulation (BltBitMap).

The only time the colors change is when a jet is drawn on top of a
carrier.  The change is noticeable, but I do not think it would be
worth the extra blits to make this one instance look correct.
I have written all of my own routines/data structures for displaying
and manipulating shapes and currently do not know if the
"backup-copy-replace backup" method would run faster than simply
blitting the entire screen.  I feel that the neccessary code
overhead and 68000 execution time could not surpass the single
blitter operation (SetRast).  Please correct me if I am wrong.

I had one scheme set up with two viewports: the upper was lores x 2
bitplanes, (8 pixels high), and the lower lores x 4 bitplanes and
double buffered.  I had hoped that this method would run faster (use the
top viewport for information, no need to remake each frame) and the
bottom for animation.  This scheme was quite a bit slower than a
single db viewport.  Why?  (more work for the copper?)

As for *any* new 1.2 routines, I'll have to wait until January when
TDI releases their 1.2 update.  And no, I would not want to rewrite
the entire program in Aztec.  Currently with 2 drives and 1024k I am
just barely able to compile and link all of the modules neccessary
to define this simulation in ram.

I should have a release version of this simulation before Christmas,
which takes advantage of all the above routines, all 4 audio
channels, the narrator device, uses both game ports, one or two
players.

Ah yes, one last, pressing, legal question:  What are the laws
pertaining to using music / cuts from copyrighted sources (compact
disk, etc) in video games (digitized from the source)?

If illegal, I could always say the sound you just heard was 
generated using random number samples and I kept running the program
until I heard a cut I liked...

Thank you for your support.

John