Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!uvaarpa!mcnc!thorin!unc!steele
From: steele@unc.cs.unc.edu (Oliver Steele)
Newsgroups: comp.sys.mac.programmer
Subject: Re: writing XCMDs
Message-ID: <2605@thorin.cs.unc.edu>
Date: 6 May 88 19:43:56 GMT
References: <3127@saturn.ucsc.edu> <11550003@hpfcdc.HP.COM>
Sender: news@thorin.cs.unc.edu
Reply-To: steele@unc.UUCP (Oliver Steele)
Organization: University Of North Carolina, Chapel Hill
Lines: 62
Summary: nice, but needs work

bayes@hpfcdc.HP.COM (Scott Bayes) writes:
>An interesting wipe might be one I've seen ESPN and some other broadcasters
>use in sports telecasts, usually with title announcements superimposed:
>
>Average the to-be-displayed card over some large rectangular or square
>tiling (eg over 64x64 tiles) for the whole screen and display all tiles.
>Then cut the rectangles in half in both x and y, giving 4 times as many
>tiles, and average over those.  Iterate until you have the 1 pixel
>resolution of the final display.  It's a neat effect, almost like
>focussing a lens on the the display, gradually getting the focus better
>and better.

I just tried this, and it is pretty neat, but needs some more work (which
I'm not going to do).  First of all, I just tried the 1bit/pixel case,
differing future work until CopyBits dithers and picks best colors in
the case when sourceRect != destRect (please?).  I allocated two
offscreen bitmaps, sourceBits and midBits, each of them the size of my
picture.  Draw the picture in sourceBits, and let bounds be
(**picture).picBounds offset by it's -topLeft(), and destPort and destRect
be the part of the screen you're writing to.

The first try was as Mr. Bayes suggested, starting with large squares and
cutting them in half each time, with something like
    for (i = first power of 2 greater than max(bounds.right,bounds.bottom);
	    i; i>>=1) {
	Rect	midRect;
	long	last;

	last = Ticks;
	SetRect(&midRect,0,0,i,i);
	CopyBits(&sourceBits,&midBits,&bounds,&midRect,srcCopy,0);
	CopyBits(&midBits,&destBits,&midRect,&destRect,srcCopy,0);
	while (last == Ticks)
		;
	}
, although you really need to adjust things a bit to get a better effect
for non-equal width and height, and of course clip it to the dest window
in the second CopyBits.

The problem with this is that it starts out as a nice smooth fade and
finishes far to fast.  It's over by the time you're starting to perceive
the effect.  I don't watch TV, so I don't know how this problem is
obviated (if it is) there, but it's definitely not as smooth appearing as
the other HyperCard wipes.

The next thing I tried was varying i linearly and setting the middle
rectangle based on its reciprocal, which was even worse, and varying i
linearly, which was interesting but a little lumpy and took too long
to finish (the opposite problem of the first two, predictably enough).
Varying it quadratically, with
    SetRect(&midRect,0,0,bounds.right-i*i,bounds.bottom-i*i);
(adjusted for right!=bottom) got good results, but was two slow even
on my II.

A potentially nice fade, but I can't put any more time into it.  Anyone
want to take it from there?

 ---------------------------------------------------------------------------
 Oliver Steele					  ...!decnet!mcnc!unc!steele
 UNC-CH							   steele@cs.unc.edu

 Disclaimer:  any factual errors are Larry Speakes's.