alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) (05/02/88)
I've written an XCMD for HyperCard that does diagonal screen wipes. Although
I am not quite happy with it yet, I'd like to ask at this point if the following
is kosher under HyperCard:
Drawing into the current Grafport.
I do save the penState. Is this ok? I've only tried it on a II, and it works
fine, even under color.
Will this code break? Since there currently is no way to add in your own
visual effects, and the only way I have figured to get a bitmap of the
destination card ('go to next card' type thing) is to use the clipboard, and
lockScreen. Any suggestions?
Also, while I am at it, are there any requests for styles of visual effects
that I might try? I am planning to offer all four diagonal wipe directions,
and can easily add more.
My interface is as follows:
myWiper 1, "ffffffffffffffff"
The first arg is the number of ticks to use as a delay during the wipe,
effectively offering different speeds. The second arg is the pattern to
use for the wipe. A third arg will probably be inserted between these,
offering a numeric selector for wipe style (i.e. directions aren't yet
implemented...)
Is there a nicer way? Can I do the following:
myWiper slowly, "ffffffffffffffff"
Will that be better? Offering say, 0 through 5 for tick delays?
Any ideas/comments are appreciated.
-------------------------------------------------------------------------------
- Alexander M. Rosenberg - INTERNET: alibaba@ucscb.ucsc.edu - Yoyodyne -
- Crown College, UCSC - UUCP:...!ucbvax!ucscc!ucscb!alibaba- Propulsion -
- Santa Cruz, CA 95064 - BITNET:alibaba%ucscb@ucscc.BITNET - Systems -
- (408) 426-8869 - Disclaimer: Nobody is my employer - :-) -
- - so nobody cares what I say. - -bayes@hpfcdc.HP.COM (Scott Bayes) (05/04/88)
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. It may be better in colour than in mono, as the mono will probably tend to produce "blots" until the resolution increases to near the feature size of the picture on the card. Larry Fenske invented something like this to incrementally focus on a Mandelbrot display, in a program we wrote some years ago. It was quicker than a scan-line-oriented painting algorithm for quickly deciding whether the current computation/viewing rectangle contained any features of interest, as you could "kind of" see the whole rectangle, instead of waiting for the scan-line painting to move down the screen. Scott Bayes hpfclw!bayes
steele@unc.cs.unc.edu (Oliver Steele) (05/07/88)
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.