Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!agate!garnet.berkeley.edu!deadman From: deadman@garnet.berkeley.edu (Ben Haller) Newsgroups: comp.sys.mac.programmer Subject: Re: Can the Mac actually do animation? Message-ID: <1991Apr11.081141.11669@agate.berkeley.edu> Date: 11 Apr 91 08:11:41 GMT References: <314@crucible.UUCP> <552@humu.NOSC.Mil> <16301@reed.UUCP> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: Stick Software Lines: 91 In article <16301@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >In <552@humu.NOSC.Mil> page@humu.NOSC.Mil (Ward C. Page) writes: >>There are two causes of flicker: the flicker caused by seeing the erase >>of the old symbology before the redraw, and the flicker caused when the >>gun starts drawing the CopyBits half way through the scan, thus taking >>two scan fields (frames) to get the copybits to the screen. Without >>syncing to the retrace interval you can't guarantee that you won't see >>this. The faster the updates the more you will notice this. Double- >>buffering was designed to address both these problems. Without it, you >>have to handle it by yourself. > >How To Handle It By Yourself: > [code omitted] > >The only case where this will fail (that is, flicker) is if the Draw() >routine takes more than 1/60 sec. to work. But as long as you're copybitsing >from an offscreen bitmap of the same pixel depth as the screen, and you're >not trying to copy an image larger than, say, half the screen, this won't >happen. This is patently not true. First of all, it will fail (flicker) if the monitor's retrace catches up with and passes the location you're drawing at. This (especially if you're drawing near the top of the screen) could be well under 1/60 of a second. It takes 1/60 of a second for the gun to get from point X all the way around to point X again. That's not the important fact here, and so 1/60 isn't the important number here. Second, the vertical retrace rate is not guaranteed on anything but the most primitive Macs. On a Mac II the retrace can be any speed at all; I've used monitors that retrace over 70 times a second, and I believe (without evidence) that there are monitors that retrace at 90Hz and up. Third, perhaps the half-screen estimate would be true for a 1-bit image to a 1-bit screen on a reasonably fast machine. But I've done timing tests on a IIcx, which was unable to update a full (640x480) 8-bit screen in less that about 3 ticks. In 32 bit, of course, it would be four times as slow. And of course larger monitors do exist, and if you want to fill them (which you might) you have to take into account that a "half screen" could be more than 512x400 on a two-page display. And of course there are slower machines than a IIcx (the LC springs easily to mind). Another problem (there are a lot, aren't there?) is that CopyBits optimization is *not* as simple as "have the offscreen in the same depth as the onscreen". There's a fairly long and involved TechNote about optimizing CopyBits, and even it doesn't cover all the issues (as it itself admits). So whats the solution? There isn't one, except for specific cases. If you can afford to go to black between images (i.e. the speed of appearance and disappearance is the issue, not really animation) then you can use color table animation - display the picture while the color table is black, then set the color table to the correct table when you want to display, set it to black when you want to hide. If, on the other hand, you're willing to sacrifice colors, then you can do actual animation with color table fiddling. See the game "Spectre" for an example of this. In the optimal case, you have sqrt(# of colors) to use, so in 4-color mode you can flip from one 1-bit image to another with a color table switch, in 16-color mode you have 4 colors per frame, and in 8-bit mode you have 16 colors per frame. This method cannot be used in 16 or 32-bit mode, since they don't have cluts, although perhaps a gamma table method could be devised (I haven't thought about it, but I don't see why not, actually, except that I don't see a way that you could get more than 16 colors per frame, making it pointless - but then I haven't ever done gamma stuff, so I don't really know what I'm talking about here). If neither of these methods is acceptable, then you can either write your own blindingly fast CopyBits replacement (not a simple task, especially if you want to be screen size and bit depth independant), limit yourself to sufficiently small blits that you can prevent ripping by watching the vertical retrace, write code that gets uploaded to an on-graphics-board processor (like the 8/24 GC) (this is pretty much a joke, although QuickDraw supposedly does it for certain things), or resign yourself to ripping. One final solution, when you can do it, is: know what you're copying from and to. If you know that most of your image is black, and that most of the destination is already black, only draw the parts that are changing. In theory this is very nice. In practice it's difficult, but many games (Spectre and Oids seem likely candidates) keep track of this sort of thing. In Spectre, for example, a frame change generally covers the whole screen, but probably well under 5% of the pixels on the screen are actually changing value. This is a prime area for optimization. It's things like this that make the Mac such a pain in the ass. I'd like to see all Macs be equipped with a blit chip that could do alignment correction and color table translation. Now that would be hot technology. Of course, just a faster NuBus would be nice. Even a IIfx can't redraw a 640x480 screen in under a tick, and I think (without any particular basis) that this is a NuBus limited things - 10MHz just isn't fast enough. Perhaps the Tower, with its rumored 20Mhz NuBus, will be able to do this kind of thing. Probably not. And besides, you can't really write Tower-specific code (can you?) If anyone has other ideas about how to speed up graphics, I'd be extrememly interested. -Ben Haller (deadman@garnet.berkeley.edu) "You can't not be on a boat." "I've often not been on boats!" "No, what you've been is not on boats." - Rosencranz And Guildenstern Are Dead (hope I spelled "Rosencranz" right)