page@humu.NOSC.Mil (Ward C. Page) (04/04/91)
I have been trying to do some simple animation on the Mac for a while now without success. All I want to do is move a line around the screen without flicker. The Mac can't do real double-buffering (although inside Mac claims otherwise) and it can't transfer bitmaps from on offscreen bitmap during the vertical retrace. This pretty much exhausts the options as far as I can tell. There may be more approaches but the Mac documentation is too poor to provide any clues. Does anyone have any suggestions or should I turn this machine into a boat anchor and get some real use out of it. Ward Page Naval Ocean Systems Center Kaneohe, Hawaii
rdd@cactus.org (Robert Dorsett) (04/04/91)
In article <551@humu.NOSC.Mil>, page@humu.NOSC.Mil (Ward C. Page) writes: > I have been trying to do some simple animation on the Mac for a while > now without success. All I want to do is move a line around the screen > without flicker. The Mac can't do real double-buffering (although > inside Mac claims otherwise) and it can't transfer bitmaps from on > offscreen bitmap during the vertical retrace. This pretty much exhausts > the options as far as I can tell. There may be more approaches but the > Mac documentation is too poor to provide any clues. Does anyone have > any suggestions or should I turn this machine into a boat anchor and > get some real use out of it. I have to second the guy, a couple of weeks ago, who observed that one does NOT need to do animation during the vertical retrace. (a) it's highly unlikely that the *support* logic of any animation can work faster than 60 times a second; (b) it's *unnecessary* to plan for 60 times a second. Movies work at less than 25 Hz; most children's cartoons work at less than 8 Hz. Flight Simulator on the PC works at less than 20 (on a 25MHz 386). The highest-quality professional flight simulators work at 30-60 Hz. A lot of you seem to be losing the forest for the trees: use offscreen bitmaps (1-10 smallish objects on a largely static background work best). It'd be great to animate 60 times a second, but it's just not going to happen on any mass-market personal computer. Animation has always been done with smoke and mirrors, and it probably always will. Brute force doesn't cut it. --- Robert Dorsett Internet: rdd@peyote.cactus.org UUCP: ...cs.utexas.edu!peyote.cactus.org!rdd
page@cod.NOSC.MIL (Ward C. Page) (04/04/91)
In article <6205@cactus.org> rdd@cactus.org (Robert Dorsett) writes: >In article <551@humu.NOSC.Mil>, page@humu.NOSC.Mil (Ward C. Page) writes: >> I have been trying to do some simple animation on the Mac for a while >> now without success. All I want to do is move a line around the screen >> without flicker. Does anyone have >> any suggestions or should I turn this machine into a boat anchor and >> get some real use out of it. > >I have to second the guy, a couple of weeks ago, who observed that one does >NOT need to do animation during the vertical retrace. (a) it's highly >unlikely that the *support* logic of any animation can work faster than 60 >times a second; I'm getting about 100Hz update on the simple symbology that I'm moving around the screen. The problem is not with the update rate but with the flicker caused by rewriting the screen a couple times per frame. If you can't draw during the retrace then your not really doing animation. Your just flailing away at the screen. Control of the update rate is important in animation, and it's done by syncing with the screen refresh somehow. Normally, this is done with a double buffered system. >work at less than 25 Hz; most children's cartoons work at less than 8 Hz. >Flight Simulator on the PC works at less than 20 (on a 25MHz 386). The >highest-quality professional flight simulators work at 30-60 Hz. Movies have the advantage of motion blur which reduces the need for faster updates (movies run at 24 fps and video at 30 fps). Flight simulator on the PC is really to slow to get any real feel for flying. This is why the high dollar flight simulators run at at least 50 Hz for regular flying tasks, and upawrds of 100-120 Hz for any handling qualities work. >A lot of you seem to be losing the forest for the trees: use offscreen bitmaps >(1-10 smallish objects on a largely static background work best). It'd be >great to animate 60 times a second, but it's just not going to happen on >any mass-market personal computer. Animation has always been done with smoke >and mirrors, and it probably always will. Brute force doesn't cut it. > This is true, but the hardware is thre for getting impressive performance out of the machine i fonly the utilities had been a little better thought out. For the 10,000 bucks we spent on this Mac II fx we could have bought a couple of SGI Iris 3D's. I guess I was expecting too much of Apple. >Robert Dorsett Ward Page Naval Ocean Systems Center (formerly General Dynamics Flight Simulation Lab)
gort@cup.portal.com (george d harrington) (04/04/91)
. . . >This is true, but the hardware is thre for getting impressive performance >out of the machine i fonly the utilities had been a little better thought >out. For the 10,000 bucks we spent on this Mac II fx we could have bought >a couple of SGI Iris 3D's. I guess I was expecting too much of Apple. > > >>Robert Dorsett >> > >Ward Page >Naval Ocean Systems Center >>(formerly General Dynamics Flight Simulation Lab) $5000 for a sgi 3d!? I thought they started around $15000, with monitor and frame buffer.
al@crucible.UUCP (Al Evans) (04/05/91)
In article <2966@cod.NOSC.MIL> page@cod.NOSC.MIL (Ward C. Page) writes: >I'm getting about 100Hz update on the simple symbology that I'm moving >around the screen. The problem is not with the update rate but with the >flicker caused by rewriting the screen a couple times per frame. If you >can't draw during the retrace then your not really doing animation. Your >just flailing away at the screen. Control of the update rate is >important in animation, and it's done by syncing with the screen refresh >somehow. Normally, this is done with a double buffered system. Sorry, Ward, but you're simply looking at it wrong. Vertical blanking is completely irrelevant to Mac animation when it's done properly. In this context, "properly" means "using offscreen bitmaps." The process is fairly simple: 1) construct the relevent area of background in an offscreen bitmap, including the part that lies under the current screen image; 2) draw the new image into this bitmap; 3) Copybits the bitmap to the screen at a time of your choosing, erasing the old image and drawing the new one simultaneously. No flicker. Naturally, the procedure gets a bit more elaborate if animated images can overlap, but the approach remains the same. --Al Evans-- -- Al Evans Reality is like this: al@crucible.uucp We are born knowing uunet!execu!sequoia!crucible!al the world isn't what we think.
pete@csc-sun.mckinsey.com (Peter Gaston) (04/05/91)
In article <2966@cod.NOSC.MIL> page@cod.NOSC.MIL (Ward C. Page) writes: >>flicker caused by rewriting the screen a couple times per frame. If you >>can't draw during the retrace then your not really doing animation. Your >>just flailing away at the screen. Control of the update rate is In article <6205@cactus.org> <2966@cod.NOSC.MIL> al@crucible.UUCP (Al Evans) >Sorry, Ward, but you're simply looking at it wrong. Vertical blanking is >completely irrelevant to Mac animation when it's done properly. In this >context, "properly" means "using offscreen bitmaps." The process is fairly >simple: 1) construct the relevent area of background in an offscreen >bitmap, including the part that lies under the current screen image; >2) draw the new image into this bitmap; 3) Copybits the bitmap to the >screen at a time of your choosing, erasing the old image and drawing the >new one simultaneously. No flicker. Naturally, the procedure gets a bit >more elaborate if animated images can overlap, but the approach remains >the same. I beg to differ. I, for example have two video games that you can buy at Toys-r-us if you really want. In that world, video sync is king. Yes, you can decouple game logic from display logic, but you still have to worry about keeping a consistent update rate. For the record, both of the games I worked on updated the screen every other refresh, i.e., 30x/sec. I've experimented on getting good animation on the Mac, but from looking at the games out there, I'm certainly no expert. I do have code that I developed that can display a double-buffered bitmap: - of size - 352 across - 350 down - B&W or 4 color (This is pushing the limits, memory bandwidth wise, as far as my experimentation could determine.) - on 'both' machine families, no slot, slotted (I haven't designed in for the video card with the QD processor yet.) - allowing vertical scrolling - displaying the cursor on top of the bitmap - with no flicker Tricks: - ignore copybits - as you might have guessed - understand video drawing, i.e., when to draw what Unfortunately, there's not enough time in this world to finish my game idea (multi-player, real-time football). oh well... peter gaston
page@humu.NOSC.Mil (Ward C. Page) (04/06/91)
In article <314@crucible.UUCP> al@crucible.UUCP (Al Evans) writes: > >Sorry, Ward, but you're simply looking at it wrong. Vertical blanking is >completely irrelevant to Mac animation when it's done properly. In this >context, "properly" means "using offscreen bitmaps." The process is fairly >simple: 1) construct the relevent area of background in an offscreen >bitmap, including the part that lies under the current screen image; >2) draw the new image into this bitmap; 3) Copybits the bitmap to the >screen at a time of your choosing, erasing the old image and drawing the >new one simultaneously. No flicker. Naturally, the procedure gets a bit ^^^^^^^^^^ This isn't quite correct. You will reduce flicker but not eliminate it. 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. >Al Evans Reality is like this: >al@crucible.uucp We are born knowing >uunet!execu!sequoia!crucible!al the world isn't what we think. Ward Page Naval Ocean Systems Center Kaneohe, Hawaii
chaffee@reed.UUCP (Alex Chaffee) (04/08/91)
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: void DrawWithoutFlicker() { Wait(); Draw(); } void Wait() { if (Running_On_An_Old_Mac()) { now = TickCount(); while (TickCount() == now) ; } else { WaitForSync(); } } (Where WaitForSync() is in a file I posted a few weeks ago, sync.c. If you'd like a copy of sync.c, let me know. It ties a VBL task to the refresh queue of the main screen.) Pretty simple, huh? 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. > The Mac can't do real double-buffering (although inside Mac claims > otherwise) and it can't transfer bitmaps from on offscreen bitmap during the > vertical retrace. Both wrong, although true double-buffering is not supported on all machines, thus you shouldn't rely on it. References: Usenet Mac Programmers Guide Tech Note # ? (Of Time and Space and Copybits) >Ward Page >Naval Ocean Systems Center >Kaneohe, Hawaii - Alex -- Alex Chaffee chaffee@reed.bitnet Reed College, Portland OR 97202 ____________________
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (04/08/91)
Al Evans writes in a message to All
AE> Naturally, the procedure gets a bit more elaborate if animated
AE> images can overlap, but the approach remains the same. --Al
AE> Evans-
Hi. I'm trying to scroll using the TCL's whilest doing something like the
above
(I'm dragging using a region outline instead of a bitmapped image, but the
principle
seems to be the same). My problem is that when I scroll, the image gets messed
up... Should I abandon the PaintRgn call and just use CopyBits, or is there
a fundamental problem that I haven't addressed? (I'm basing my dragging method
on the example given in Macintosh Programming Primer II but dragging ICON
outlines
instead of Rects). The method works when I use the example but if I "buffer"
the Regions before drawing, the scrolling part looks disasterous (bits of the
region never get erased when the Panorama scrolls). I'd really like to use the
buffering technique as the flicker-free dragging looks real professional...
Thanks...
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgDouglas.Hill@f438.n109.z1.Fidonet.Org (Douglas Hill) (04/08/91)
Just a quick comment here. For a really nice example of the animation - Doug * Origin: Europa BBS (301) 718-4690 HST/DS (1:109/438)
galetti@uservx.afwl.af.mil (04/10/91)
In article <6205@cactus.org>, rdd@cactus.org (Robert Dorsett) writes: > In article <551@humu.NOSC.Mil>, page@humu.NOSC.Mil (Ward C. Page) writes: >> I have been trying to do some simple animation on the Mac for a while >> now without success. All I want to do is move a line around the screen >> without flicker. The Mac can't do real double-buffering (although >> inside Mac claims otherwise) and it can't transfer bitmaps from on >> offscreen bitmap during the vertical retrace. This pretty much exhausts >> the options as far as I can tell. There may be more approaches but the >> Mac documentation is too poor to provide any clues. Does anyone have >> any suggestions or should I turn this machine into a boat anchor and >> get some real use out of it. > > I have to second the guy, a couple of weeks ago, who observed that one does > NOT need to do animation during the vertical retrace. (a) it's highly You update the screen during the vertical retrace so there is no flicker in your animation. It doesn't matter how slowly you update the screen, if you update it while it's being redrawn, part of the screen will change as you update it, and the other part won't change until the next retrace, resulting in a flicker. > unlikely that the *support* logic of any animation can work faster than 60 > times a second; (b) it's *unnecessary* to plan for 60 times a second. Movies > work at less than 25 Hz; most children's cartoons work at less than 8 Hz. > Flight Simulator on the PC works at less than 20 (on a 25MHz 386). The > highest-quality professional flight simulators work at 30-60 Hz. > A lot of you seem to be losing the forest for the trees: use offscreen bitmaps > (1-10 smallish objects on a largely static background work best). It'd be > great to animate 60 times a second, but it's just not going to happen on > any mass-market personal computer. Animation has always been done with smoke > and mirrors, and it probably always will. Brute force doesn't cut it. > Well, you can't really say ANY mass-market personal computer. After all, the Commodore Amiga easily animates at 60 Hz. Of course, there could be some argument as to whether the Amiga is a mass-market computer! :-) > --- > Robert Dorsett > Internet: rdd@peyote.cactus.org > UUCP: ...cs.utexas.edu!peyote.cactus.org!rdd ___________________________________________________________________________ / Ralph Galetti Internet: galetti@uservx.afwl.af.mil \ | PL/LITT Interests: computers, music, computers | | Kirtland AFB, NM 87117-6008 and music, golf, sleep. | \__"No, they couldn't actually prove that it was HIS vomit" - Nigel Tufnel__/
chaffee@reed.UUCP (Alex Chaffee) (04/10/91)
Okay, I've gotten enough requests -- here's a repost of Sync.c. Be careful -
I haven't tested this on small Macs. It's likely that it only works if Color
Quickdraw is installed.
Alex Chaffee
chaffee@reed.bitnet
Reed College, Portland OR 97202
____________________
/*
Sync.h
*/
/* Exported Variables */
extern long vCounter; /* just like Ticks - incremented every refresh */
/* Macros/Prototypes */
void InstallSync(void);
void RemoveSync(void);
void WaitForSync (void);
static long vblJunk;
#define WaitForSync() vblJunk = vCounter; do {} while (vblJunk == vCounter);
/*
Sync.c
Implements a VBL counter (like Ticks) on a Mac II
Usage:
#include "sync.h"
InstallSync();
...
WaitForSync();
CopyBits(...);
...
RemoveSync();
*/
#include "Sync.h"
/* Types */
typedef struct {
long goodA5;
VBLTask task;
} MYVBLTASK;
/* Globals */
long vCounter;
static MYVBLTASK mytask;
static DefVideoRec video;
/* Prototypes */
static pascal void Task(void);
/* Task */
static pascal void Task(void)
{
long oldA5;
MYVBLTASK vbltask;
asm {
move.l A5,oldA5 ; save off the old value of A5
move.l -4(A0), A5 ; A0 points to our VBL task record, and earlier we
; saved CurrentA5 near it
}
vCounter++;
mytask.task.vblCount = 1; /* we want to run again real soon */
asm {
move.l oldA5,A5
}
}
/* InstallSync */
void InstallSync(void)
{
GetVideoDefault(&video);
mytask.goodA5 = (long)CurrentA5;
vCounter = 0;
mytask.task.qType = vType;
mytask.task.vblAddr = (ProcPtr) Task;
mytask.task.vblCount = 1;
mytask.task.vblPhase = 0;
SlotVInstall(&mytask.task, video.sdSlot);
}
void RemoveSync(void)
{
SlotVRemove(&mytask.task, video.sdSlot);
}
/* If you don't want to use the macro, uncomment this function */
/*
void WaitForSync (void)
{
long vJunk = vCounter;
do {} while ( vCounter == vJunk );
}
*/
--
Alex Chaffee
chaffee@reed.bitnet
Reed College, Portland OR 97202
____________________deadman@garnet.berkeley.edu (Ben Haller) (04/11/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)
YUNSANJ@YaleVM.YCC.Yale.Edu (04/12/91)
Although reluctant to divulge tthe processes, it is possible to do mediocre arcade animation on a Mac. I've been able to get full background scrolling with several sprites moving around fine on either a Plus or SE in B/W or a Mac II in color. Of course, you're going to need to get down and dirty with assembly (yes, I know all you wimps out there are afraid of writing directly to the screen in fear of incompatibility). Actually, the incompatibility risks aren't very high, generally juts with graphics accelerators (then why do you need to write directly?) Offer a choice for users to switch between custom and standard routines and everything should work out fine.
Mark.Fong@f444.n161.z1.FIDONET.ORG (Mark Fong) (04/19/91)
You must be the author of Solarian. Great work! How come you didn't go
commercial with it? It was certainly worthy of it. I'm sure you're asked
this time and time again.
Also, I noticed you're on Garnet at U.C. Berkeley, are you a grad student?
Anyways, I wrote "The Big One!" (renamed "Operation: Tsunami"), and I
basically rewrote CopyMask() (application-specific, however), used
double-offscreen buffers, and kept track of "update" zones. I still get
caught by the gun on the slower machines though. Do you know of a way to
time it just right (VBL task maybe) to beat the gun and avoid tearing?
Thanks,
Mark Fong
--
Mark Fong - via FidoNet node 1:125/777
UUCP: ...!uunet!hoptoad!fidogate!161!444!Mark.Fong
INTERNET: Mark.Fong@f444.n161.z1.FIDONET.ORGdeadman@garnet.berkeley.edu (Ben Haller) (04/21/91)
God I'm posting a lot today. In article <91101.195933YUNSANJ@YaleVM.YCC.Yale.Edu> YUNSANJ@YaleVM.YCC.Yale.Edu writes: > > Although reluctant to divulge tthe processes, it is possible to do mediocre >arcade animation on a Mac. I've been able to get full background scrolling >with several sprites moving around fine on either a Plus or SE in B/W or a Mac >II in color. Of course, you're going to need to get down and dirty with >assembly (yes, I know all you wimps out there are afraid of writing directly >to the screen in fear of incompatibility). Actually, the incompatibility risks >aren't very high, generally juts with graphics accelerators (then why do you >need to write directly?) Offer a choice for users to switch between custom and >standard routines and everything should work out fine. I find this extremely annoying. The poster says "I know how to do this, and it's really nifty, and I'm going to make you drool in anticipation of this neat technology, but I'm not actually going to tell you how to do it." Very immature. I can understand not being willing to publish source code (I don't publish some of my source, either) but restricting the free flow of knowledge just because you're "reluctant" is a bit much. I've done a lot of direct to screen code, and my firmly held opinion is that there is no way, with brute-force change-every-pixel-value code, to scroll the full screen in 8-bit mode on a Mac II in less than about 3/60 of a second, too long for good animation. As I've mentioned before, there are tricks, like color table animation, page flipping on some monitors, using diff algorithms instead of redisplaying the whole screen, etc., but the brute force method simply doesn't work. The poster seems to directly contradict my above assertion. I challenge him: either present proof that your assertion is true, or don't waste our time. I'd present my proof, except that I think I deleted it a long time ago; however, anyone can write a routine that just stuffs values into video memory, and clock it. Unless I made some stupid mistake when I did this, I believe my assertions are correct. -Ben Haller (deadman@garnet.berkeley.edu) "You take what you get and get what you please It's better to die on your feet than live on your knees" -Midnight Oil, "Power And The Passion"