Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!sri-spam!ames!amdahl!dlb!dana!rap
From: rap@dana.UUCP (Rob Peck)
Newsgroups: comp.sys.amiga
Subject: Re: BltMaskBitMapRastPort
Message-ID: <210@dana.UUCP>
Date: Thu, 13-Aug-87 13:25:33 EDT
Article-I.D.: dana.210
Posted: Thu Aug 13 13:25:33 1987
Date-Received: Sat, 15-Aug-87 12:01:09 EDT
References: <1702@amiga.amiga.UUCP> <6978@steinmetz.steinmetz.UUCP>
Organization: Dana Computer, Inc., Sunnyvale, CA
Lines: 83
Summary: Offscreen may help the flash situation (a little long, but...)

In article <6978@steinmetz.steinmetz.UUCP>, jesup@steinmetz.steinmetz.UUCP (Randell Jesup) writes:
> I've been doing some 4-bitplane, 640x200 graphics work and wondered why, every
> time I updated a portion of the screen with the new 1.2 BltMaskBitMapRastPort,
> there was a white flash in the area before the update.  In that resolution,
> things are slow enough that it was VERY annoying.
> ....
> 	And the inspiration struck!  The BltMaskBitMapRastPort was implemented
> as Rob Pecks ClipBlitTransparent was, by blasting a hole in the destination,
> then blitting in the new version (2 blits on every plane)!

To avoid the flash, I'd suggest doing the merge using BltMask... in an
offscreen rastport/bitmap combination, then use ClipBlit() itself to
simply replace the onscreen with the offscreen stuff in a single rectangular
blit, of a size equal to that which would cover the outermost boundaries
of the old-version vs the new version of the object that has morphed.
(In other words, actually update the screen with only as much of the
screen as is now different.)  I created ClipBlitTransparent before the
BltMask... routine existed - I guess you're right about how BltMask
does things, I never looked at its insides.  There will be a couple more
blits needed overall, but only one would happen onscreen and you'd
be less likely to see the flash in that case.

(I suggested using BltMask... instead of trying to use ClipBlitTransparent
because I was told that BltMask was designed to be much more efficient
than what I created, supposedly fewer setups and fewer blits.  Probably.)

Second suggestion would be to use the GEL system to do your update work.
The Bob's use the blitter also, and in a more direct manner than all of
the overhead I had to use in ClipBlitTransparent (Bobs use QBlit or QBSBlit
as I recall).   If an object is to move against a background I believe
that the Bobs system may be the most efficient available in the system
at the moment.  If an object is to change while moving, there are a
couple of things you can try - for a limited number of views of an
object, create a Bob structure for each, then

   RemBob( ... old bob ...)  (restore background; erase during next DrawGList)	
   AddBob( ... next view ...)
   DrawGList(.... )            (no book here, forgot parameters)

to get the new view of the object drawn while also restoring the background
behind where the old object was located.

As suggested, by using the blitter directly, one would not go through
the layers library in the process.  So it would probably be best to
come up with something that the system already has.  It took Dale a
while to make sure that everything worked right with layers ... reinventing
the wheel is a bummer.

There is something else interesting that Randell pointed out:  the
BltMaskBitMapRastPort is limited to two possible minterms.  Notice
that the system ClipBlit routine is limited to FOUR rather than two.
(It lets you specify the B and C terms, basically, minterm values
as $x0 where x can be in the range of 0-F).  That's what let me
blast the hole in the destination area using the mask for ClipBlitTransparent,
then reverse the process saying blit in only where the mask was
a 1 bit.   The A term is left out of the ClipBlit equation since
the routine uses it internally (I forget exactly how ... maybe
Dale .. or Kodiak if he is listening ... can expand on this.)

Maybe someday a system routine can be created (for 1.3?) that would
be maybe ClipBlitAll(...) that would be the same as the current 
ClipBlit but allow all of the possible combinations of minterms,
perhaps taking a mask parameter as well (as ClipBlitTransparent does).
Would be nice. 

As a final remark, at 640 by 200, the display DMA is taking up all of the
time during the display part of the screen.  The blitter can only do its
work during non-display time (because both are accessing CHIP RAM), so
this is really asking an awful lot of the system.  One more suggestion,
then... if there is FAST memory available, make sure that everything
that can be in FAST memory is located there so the 68000 can do the
setup work for the blitter while the display DMA is on the independent
CHIP mem bus, then the "only" contention you'll have is between the blitter
and the display DMA, not asking the processor to try to get its job 
done on that same bus as well.


Please let me know via EMAIL what you finally come up with to solve
your problem - I may have a few other things to suggest as well.

Good luck in the meantime.

Rob Peck			...ihnp4!hplabs!dana!rap