From: "Campbell, Rolf [SKY:1U32:EXCH]" <moscoop AT americasm01 DOT nt DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Very fast allegro blitting
Date: Fri, 14 Jan 2000 09:47:13 -0500
Organization: Nortel Networks
Lines: 33
Message-ID: <387F36F1.9DA97E3@americasm01.nt.com>
References: <386A9193 DOT 124D022D AT ozemail DOT com DOT au> <84q027$mg2$1 AT the-fly DOT zip DOT com DOT au> <3871A7BC DOT F317063F AT wxs DOT nl>
NNTP-Posting-Host: wmerh0tk.ca.nortel.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.71 [en] (X11; I; HP-UX B.10.20 9000/785)
X-Accept-Language: en
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"A. Jans-Beken" wrote:

>
> A second idea that I once proposed in this:
>
> When doing animations with sprites or bitmaps:
> 1 Create a BITMAP
> 2 Draw the OLD situation in this bitmap
> 3 Create a second BITMAP
> 4 Draw the NEW situation in this bitmap
> 5 Create a third BITMAP = OLD - NEW
> 6 Masked-blit this bitmap to the screen
>
> The trick is in the OLD-NEW operator. It blanks all pixels that are the same
> color in both the NEW and OLD situation. Only pixels where really new
> content appears will be blitted.
> The OLD-NEW operator should be written in assembler (to difficult for me).
> Maybe it is even possible to use MMX or hardware accelerated functionality.
> However I tested this algo in plain C some time ago and it really works very
> smooth.

This would be smooth, but slower than a normal blit.  Only new data may be
blitted, but it will be more than 3 times as slow because the old-new operator
will take twice as long as a simple blit (it has to read twice the memory and
write just as much).  Also a masked-blit of a region is slower than a standard
blit (even if very few pixels are actually copied) because all pixels need to
be checked to see if they need copying.

--
(\/) Rolf Campbell (\/)