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
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 (\/)

- Raw text -