es2q+@andrew.cmu.edu (Erik Warren Selberg) (07/05/90)
I'm writing a simple program that involves some animation, and I'm wondering
what the best way to do it. Basically, I want to use Think C and have the
animation done by replaceing pictures (have 4 frames and run through them,
so animation is simulated -- like crystal quest).
Is there some neat way to do this that I'm not thinking of, or am I just
bein a blockhead? BTW: I need the ability for all the animated objects to
check for certain conditions & change appropriately, if that's any help.
Thanks much!
...they call me fluppie...
\ ARPA: es2q@andrew.cmu.edu Fido: 129/107 BBS: Mac @ Night (412) 268-5534 /
\ GEnie: E.SELBERG Delphi: LORDERIK CIS: 71470,2127 MacList: 6009/1 /trotter@ENUXHA.EAS.ASU.EDU (Russell T. Trotter) (02/03/91)
What is the best way to do animation if I am relying on the main event loop for the updates for the motion? I have tried various combinations of CopyBits(), PutIcon, DrawPicture(),...etc, but they all seem to be too flickery. Am I just doing something fundamentally wrong? Thanks to all who reply!
lippin@spam.berkeley.edu (The Apathist) (02/03/91)
Recently trotter@enuxha.eas.asu.edu (Russell T. Trotter) wrote: >What is the best way to do animation if I am relying on >the main event loop for the updates for the motion? > >I have tried various combinations of CopyBits(), >PutIcon, DrawPicture(),...etc, but they all >seem to be too flickery. Am I just doing >something fundamentally wrong? The most common cause of flicker is trying to animate by erasing and redrawing an object -- you can get away with this on a very small scale, but on a larger scale the viewer will see some background through the object in between the steps. Sometimes you can do a little better by drawing the new image before erasing the old; the eye tricks itself into ignoring the ghosts sometimes. But a better way is to get the stuff on the screen right the first time. Combine your background and foreground off screen, and copy both the old and new areas onto the screen at the same time. A second problem that can arise is that moving objects may get torn in half -- the bottom half may seem to be a frame ahead of the top. This can happen when the vertical scan of the monitor passes the place where you're drawing. This problem can be solved by starting the on-screen part of the drawing as the tick count changes, or, on a II, synchronize with the appropriate slot VBL interrupt. The only problems caused by doing the animation in your main event loop are ones of speed. If the animation seems jerky, you're not getting enough time. Try it with fewer applications running, or fewer INITs, or fewer Think C debuggers. If the speed is uneven, you should slow down and use the tick count to pace it. (You should pace the motion in any case, so that it doesn't vary from one machine to another.) --Tom Lippincott lippin@math.berkeley.edu "The poetry of motion! The *real* way to travel! The *only* way to travel! Here today -- in next week tomorrow! Villages skipped, towns and cities jumped -- always somebody else's horizons!" --Kenneth Grahame _The Wind in the Willows_
Chris.Parson@f54.n382.z1.FIDONET.ORG (Chris Parson) (02/05/91)
You need to synch your drawing with the hardware level screen refresh to lose the flicker. Check the VBLtask sections of Inside Mac. /s -- Chris Parson via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!382!54!Chris.Parson INET: Chris.Parson@f54.n382.z1.FIDONET.ORG
mab@ecmwf.co.uk (Baudoin Raoult) (02/07/91)
In article <9102030634.AA09598@enuxha.eas.asu.edu>, trotter@ENUXHA.EAS.ASU.EDU (Russell T. Trotter) writes: > What is the best way to do animation if I am relying on > the main event loop for the updates for the motion? > > I have tried various combinations of CopyBits(), > PutIcon, DrawPicture(),...etc, but they all > seem to be too flickery. Am I just doing > something fundamentally wrong? > Thanks to all who reply! To avoid flickery animation, you must synchronise your CopyBits with the video spot. The simplest way is to use TickCount, as the tick counter is updated every 60th of second, each time the video spot starts to update new screen. So just write: tmp := TickCount; while tmp=Tickcount do { nothing } ; CopyBits(.....)
dweisman@umiami.ir.miami.edu (Ordinary Man) (02/08/91)
In article <1991Feb7.093610.12594@ecmwf.co.uk>, mab@ecmwf.co.uk (Baudoin Raoult) writes: > In article <9102030634.AA09598@enuxha.eas.asu.edu>, trotter@ENUXHA.EAS.ASU.EDU (Russell T. Trotter) writes: >> What is the best way to do animation if I am relying on >> the main event loop for the updates for the motion? >> >> I have tried various combinations of CopyBits(), >> PutIcon, DrawPicture(),...etc, but they all >> seem to be too flickery. Am I just doing >> something fundamentally wrong? >> Thanks to all who reply! > > To avoid flickery animation, you must synchronise your CopyBits with the video spot. > The simplest way is to use TickCount, as the tick counter is updated every 60th of > second, each time the video spot starts to update new screen. So just write: > > tmp := TickCount; > while tmp=Tickcount do { nothing } ; > > CopyBits(.....) This is fine except for a minor detail. As it says in IM Vol. I... "...don't rely on the tick count being incremented to a certain value, such as testing whether it has become equal to its old value plus 1; check for 'greater than or equal to' (since an interrupt task may keep control for more than one tick)." So instead say: tmp:=TickCount; repeat until TickCount>=(tmp+1); CopyBits..... ==Dan -- /-------------------------------------------------------------------------\ | Dan Weisman - University of Miami - Florida | || || || || | |--------------------------------------------------| || || ||\ /|| | | INTERNET -----> dweisman@umiami.IR.Miami.edu | || || || | || | | BITNET -----> dweisman@umiami | ||||||| || | || | |-------------------------------------------------------------------------| | "...bows it's head and prays to the mother of all machines." | \_________________________________________________________________________/
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (02/09/91)
Baudoin Raoult writes in a message to All
BR> The simplest way is to use TickCount, as the tick counter is
BR> updated every 60th of second, each time the video spot starts
BR> to update new screen. So just write:
BR> tmp := TickCount; while tmp=Tickcount do { nothing } ; CopyBits(.....)
To make sure that you get the most accurate reading (and the longest time in
which to do your drawing) use GetTrapAddress to bypass the Trap Dispatcher and
jump directly to TickCount. Otherwise, you have 100+ CPU cycles of overhead
that you are wasting. This might not be much, but it could change the flicker
if your drawing is small enough.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgdjvelleman@amherst.bitnet (02/09/91)
In article <1991Feb7.233344.7781@umiami.ir.miami.edu>, dweisman@umiami.ir.miami.edu (Ordinary Man) writes: > In article <1991Feb7.093610.12594@ecmwf.co.uk>, mab@ecmwf.co.uk (Baudoin Raoult) writes: [stuff deleted] >> To avoid flickery animation, you must synchronise your CopyBits with the video spot. >> The simplest way is to use TickCount, as the tick counter is updated every 60th of >> second, each time the video spot starts to update new screen. So just write: >> >> tmp := TickCount; >> while tmp=Tickcount do { nothing } ; >> >> CopyBits(.....) > > This is fine except for a minor detail. As it says in IM Vol. I... > > "...don't rely on the tick count being incremented to a certain value, such > as testing whether it has become equal to its old value plus 1; check for > 'greater than or equal to' (since an interrupt task may keep control for > more than one tick)." > > So instead say: > > tmp:=TickCount; > repeat until TickCount>=(tmp+1); > > CopyBits..... > > ==Dan Sorry Dan, but you've missed the point of the warning in IM. IM says not to rely on the tick count being INCREMENTED TO a certain value, because it might skip over values if an interrupt task keeps control for more than one tick. But the proposed code doesn't rely on TickCount being incremented to the value stored in tmp. TickCount already has that value, and the code relies on it eventually being incremented to a different value, which is just fine. Your code is OK too. What IM was warning against was something like this: tmp:=TickCount; repeat until TickCount=tmp+1; CopyBits... This could turn into an infinite loop if TickCount goes right from tmp to tmp+2. By the way, the THINK Pascal procedure Synch will take care of this for you. -Dan Velleman
CXT105@psuvm.psu.edu (Christopher Tate) (02/09/91)
[ discussion on using TickCount to synchronize CopyBits to the vertical ]
[ retrace interval, to avoid flicker. ]
Unfortunately, TickCount is only hardwired to the vertical retrace interval
on Mac Plus/SE - type machines (possibly the Classic; I don't know). On a
Mac II series machine, the problem of multiple monitors rears its ugly
little head -- which monitor's vertical retrace are you synching to?
In fact, on a Mac II series machine, TickCount is anchored to an internal
60.15 Hz (is that right?) clock which has absolutely nothing to do with
the actual vertical retrace interval of any monitor. In order to genuinely
synchronize your CopyBits (or whatever) to a monitor's vertical flyback,
you need to play some games with slot-based VBL tasks.
The Usenet Mac Programmers' Guide (UMPG) has a good article, with code, on
how to do just this. As I recall the code is in C, but even if you're not
comfortable with C it's probably a good place to start.
And remember, you only have to monkey with slot VBL routines for this
stuff if you've determined that you're running on a Mac II-series machine.
-------
Christopher Tate | "Mr. Churchill, you're drunk!"
|
cxt105@psuvm.psu.edu | "Yes madam, and you are ugly. In the
{...}!psuvax1!psuvm.bitnet!cxt105 | morning, however, I shall be sober."
cxt105@psuvm.bitnet |grendel@aix01.aix.rpi.edu (Thomas E DeWeese) (02/09/91)
Hello I have two quick questions. First what is The Usenet Mac Programmers' Guide (UMPG) and how can I get a copy of it. Second I own an 8.24GC Card. It has performed wonderfully, but I am interested in programming it. As yet I have not seen any documentation on how one might program it. Also I do not as yet know of any compiler that will generate code for it. If anyone could me with these two things I would appreciate it greatly. Also is there a way to shut off the Accelerator in software that is available to us meer mortals. Or is it to be held in reserve by the Control panel, like screen depth? Thomas DeWeese TD Designs.
cfejm@ux1.cts.eiu.edu (John Miller) (02/09/91)
In article <91039.125723CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >[ discussion on using TickCount to synchronize CopyBits to the vertical ] >[ retrace interval, to avoid flicker. ] > >Unfortunately, TickCount is only hardwired to the vertical retrace interval >on Mac Plus/SE - type machines (possibly the Classic; I don't know). On a >Mac II series machine, the problem of multiple monitors rears its ugly >little head -- which monitor's vertical retrace are you synching to? > >In fact, on a Mac II series machine, TickCount is anchored to an internal >60.15 Hz (is that right?) clock which has absolutely nothing to do with >the actual vertical retrace interval of any monitor. In order to genuinely >synchronize your CopyBits (or whatever) to a monitor's vertical flyback, >you need to play some games with slot-based VBL tasks. > >The Usenet Mac Programmers' Guide (UMPG) has a good article, with code, on >how to do just this. As I recall the code is in C, but even if you're not >comfortable with C it's probably a good place to start. > Where can one find this UMPG?? Thanks, John Miller Music Theory Eastern Illinois University CFEJM@UX1.CTS.EIU.EDU
mdavis@pro-sol.cts.com (Morgan Davis) (02/10/91)
In-Reply-To: message from dweisman@umiami.ir.miami.edu } > tmp := TickCount; } > while tmp=Tickcount do { nothing } ; } > } > CopyBits(.....) } } This is fine except for a minor detail. As it says in IM Vol. I... } } [quote removed] } } So instead say: } } tmp:=TickCount; } repeat until TickCount>=(tmp+1); } } CopyBits..... } } ==Dan Your method, derived from what you understood about TickCount from Inside Mac, is almost as safe as the first one, but certainly not any better. While the first example would loop until Ticks changed, your example would loop until Ticks increased by some amount. In reality, they're identical in function, only your method would not work if Ticks had somehow managed to decrease in value. In either case, I think it is important to realize that both methods are equally acceptable for this situation. Where I think you misinterpreted Inside Mac is when you have a scenario such as this: tmp := TickCount; repeat until TickCount = (tmp + N); The problem here is that you're waiting for TickCount to equal a certain constant value *OTHER THAN ITS OLD VALUE*. This isn't safe. It is important to understand the difference. UUCP: crash!pro-sol!mdavis AOL, BIX: mdavis ARPA: crash!pro-sol!mdavis@nosc.mil GEnie: m.davis42 INET: mdavis@pro-sol.cts.com ProLine: mdavis@pro-sol
costin@cogsci.ucsd.edu (Dan Costin) (02/12/91)
In article <1961.27B4BFB4@stjhmc.fidonet.org>, Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: |>Baudoin Raoult writes in a message to All |> |>BR> The simplest way is to use TickCount, as the tick counter is |>BR> updated every 60th of second, each time the video spot starts |>BR> to update new screen. So just write: |>BR> tmp := TickCount; while tmp=Tickcount do { nothing } ; CopyBits(.....) |> |>To make sure that you get the most accurate reading (and the longest time in |>which to do your drawing) use GetTrapAddress to bypass the Trap Dispatcher and |>jump directly to TickCount. Otherwise, you have 100+ CPU cycles of overhead |>that you are wasting. This might not be much, but it could change the flicker |>if your drawing is small enough. |> |> |>Lawson |> Y'all, of course, realize that this hack only works for Mac Classics and such. Mac II screen refresh rates are not necessarily related to the tick count (buy a monitor that refreshes at 72Hz, for example, and the flicker will return) You have to synchronize to the refresh, not the tick, as they are no longer the same. To do this, use a VBL task. (see one of the later Inside Macs) -dan
jimc@isc-br.ISC-BR.COM (Jim Cathey) (02/14/91)
In article <1991Feb7.233344.7781@umiami.ir.miami.edu> dweisman@umiami.ir.miami.edu (Ordinary Man) writes: >[From IM page mumble]: >"...don't rely on the tick count being incremented to a certain value, such >as testing whether it has become equal to its old value plus 1; check for >'greater than or equal to' (since an interrupt task may keep control for >more than one tick)." > >So instead say: > > tmp:=TickCount; > repeat until TickCount>=(tmp+1); > > CopyBits..... Of course even this isn't completely correct (foolproof). Eventually (2 years or so isn't it?) TickCount will overflow and you could get into a place where you would wait forever. (Yes I know the chances are small, but it's nice to learn the right way too isn't it?) The most correct way to hang until TickCount changes is: > tmp:=TickCount; > repeat until TickCount <> tmp; > > CopyBits..... This also should generate less code and will always work. After all, you don't give a hoot about _which_ value it's moving to, you just want to wait until it changes. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
schorsch@oxy.edu (Brent William Schorsch) (02/17/91)
Baudoin Raoult writes in a message to All > tmp := TickCount; while tmp=Tickcount do { nothing } ; CopyBits(.....) Lawson English says: >To make sure that you get the most accurate reading (and the longest time i which to do your drawing) use GetTrapAddress to bypass the Trap Dispatcher a jump directly to TickCount. Otherwise, you have 100+ CPU cycles of overhead if you're going to go against guideline, why not use the global variable Ticks. (unless you're running under A/UX)... This seems safer to me.. (not to metion faster) -Brent
rmh@apple.com (Rick Holzgrafe) (02/19/91)
In article <145515@tiger.oxy.edu> schorsch@oxy.edu (Brent William Schorsch) writes: > Baudoin Raoult writes in a message to All > > tmp := TickCount; while tmp=Tickcount do { nothing } ; CopyBits(.....) > > Lawson English says: > >To make sure that you get the most accurate reading (and the longest time i > which to do your drawing) use GetTrapAddress to bypass the Trap Dispatcher a > jump directly to TickCount. Otherwise, you have 100+ CPU cycles of overhead > > if you're going to go against guideline, why not use the global variable > Ticks. (unless you're running under A/UX)... > This seems safer to me.. (not to metion faster) > -Brent It's not safer - and you yourself just gave one reason why: it won't run under A/UX. This is a portent of the future: not that A/UX will take over, but that low-memory globals will not be supported forever. GetTrapAddress may not work forever either (we are recommending against its use, as Brent implies) but directly accessing some low-memory globals is already broken in some environments, while GetTrapAddress at least still works. If you *must* bypass the trap mechanism, GetTrapAddress is safer than accessing Ticks directly. (BTW - in most environments, it's also nearly as fast. TickCount is a very short, fast routine, if you avoid the trap overhead.) ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 3-PK | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (02/20/91)
Rick Holzgrafe writes in a message to All
RH> GetTrapAddress may not work forever either (we are recommending
RH> against its use, as Brent implies) but directly accessing some
RH> low-memory globals is already broken in some environments, while
RH> GetTrapAddress at least still works. If you *must* bypass the
RH> trap mechanism, GetTrapAddress is safer than accessing Ticks
RH> directly
I can understand that given protected memory, the supervisor mode, etc, that
GetTrapAddress may someday be inadvisable for patching, but why is its use for
finding the trap table entry and jumping directly there a future no-no? Our
ROM-use-profiler broke after System 4.2, and would be totally useless in a MultiFinder
environment anyway, but we found out stuff about ROM/trap use that probably
will never change using the 68xxx, and I can guaruntee that some programs will
show significan speedups by using NGetTrapAddress, no matter how fast the CPU
(especially using a fast CPU?).
As long as traps are used, wouldn't it be advisable to have NGetTrapAddress
available?
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orglippin@ragu.berkeley.edu (The Apathist) (02/23/91)
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: > I can understand that given protected memory, the supervisor mode, > etc, that GetTrapAddress may someday be inadvisable for patching, but > why is its use for finding the trap table entry and jumping directly > there a future no-no? I can think of one reason: if the change is made to have applications run in user mode (a sensible change, which Apple has threatened in the past) many parts of the operating system will still require supervisor mode. A trap instruction switches to supervisor mode; a simple JSR doesn't. --Tom Lippincott lippin@math.berkeley.edu "Hell is like a supermarket in other ways, too -- There's an express lane for ten sins or less, and they won't let you take the carts out to the parking lot." --Mr. Boffo
chaffee@reed.UUCP (Alex Chaffee) (02/26/91)
> Baudoin Raoult tells us how to sync to the vertical retrace on small-screen Mac's: tmp := TickCount; while tmp=Tickcount do { nothing } ; CopyBits(.....) > Lawson English says: [use GetTrapAddress] > Brent Schorsch says: [use the global variable Ticks] > Rick Holzgrafe replies: [it's not safe - Be Compatible!] I jumped into the middle of this thread, so this might have been addressed earlier, but if you're going to try to be compatible, why not go whole hog and be able to work on Mac II's? Using SlotVInstall, you can set up a VBL task which is synched to the monitor, regardless of phase or refresh rate. Then this VBL task will increment a global - call it vCount - every single screen refresh. Then you can use vCount just like you use Ticks was in the original code fragment. If you like, I can send (or post) source code that does just this. By the way, I don't always align my right margins; it just seemed to work out that way this time. /* beginning of program */ SlotVInstall(...) ... /* middle */ tmp = vCount; while(tmp==vCount) ; CopyBits(...) ... /* end of program */ SlotVRemove(...) -- Alex Chaffee chaffee@reed.{UUCP,BITNET} Reed College, Portland OR 97202 ____________________
chaffee@reed.UUCP (Alex Chaffee) (03/02/91)
In <91058.111052CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >[Alex Chaffee talks about using VBL tasks to get true vertical retrace sync > on Mac II-series machines, instead of watching the tick count.] >The only problem is that not all Macs have slots. For those that don't, >the best you can do is to watch the tick count by one of those methods >already debated here. Is that true? I was under the impression that on slotless Macs, SlotVInstall et al. just mimiced VInstall (et al.). Assuming a recent enough version of system software. If that is so, then the techniques I described (and provide source for in a concurrent post) should work exactly like TickCount. Of course, if I'm wrong, you're right. :-) I guess the best thing to do is look to see if SlotVInstall is an implemented trap before braching to the slot-using code. - Alex -- Alex Chaffee chaffee@reed.{UUCP,BITNET} Reed College, Portland OR 97202 ____________________
tarr@cs.yale.edu (03/05/91)
There really seem to be three cases concerning installing VBL tasks: 1. small macs (plus, SE, SE/30, classic) 2. slotted macs (II, IIx, IIcx, IIfx) 3. on board video (IIci, LC, IIsi) I think I have categories 1 and 2 down pat. Just check machine type and then use VInstall or SlotVInstall, but on the cat 3 machines, I try to use a SlotVInstall which I am doubtful is getting the actual tickcount. For instance, on a IIsi w/ apple color monitor, the rate is reported at 1/62 second per tick, just like the cat 1 machines. Is this correct? I would be very interested in seeing a listing of the actual refresh rates of all of these machines and in the case of the cat 2 machines, the refresh rates with standard apple cards and monitors -- is there anyone at apple that can post this info. In addition, I have received several suggestions on how to get the tickcount for each machine and then sync copybits to this, but most if not all schemes seem to fail under some circumstances. Couldn't apple just give us a toolbox or system call for supplying the moment of refresh? Also, is the tickcount value still 60.15 ticks per second and is it used for determing the value of the event.when field in events? Mike Tarr tarr@cs.yale.edu
jmunkki@hila.hut.fi (Juri Munkki) (03/05/91)
In article <16178@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >Of course, if I'm wrong, you're right. :-) I guess the best thing to do is >look to see if SlotVInstall is an implemented trap before braching to the >slot-using code. All color quickdraw machines have SlotVInstall, so I just check for color quickdraw with SysEnvirons and then use the hasColorQD field to determine which routine I should use. Far all those who are interested in a real working example of synchronized animation with offscreen buffers and quickdraw, take a look at the sega glasses demo software (comes with source code) in vega.hut.fi. The files are in the pub/mac/finnish/sega3d directory and you don't need the glasses to run the software (it doesn't look nice without the glasses, but you can easily modify it to apply to any kind of animation). The source code is in Think C and contains a routine that installs a VBL task on any existing machine. It also allows you to play with drawing directly onto the screen or using quickdraw, so it's a good way to see the speed difference between quickdraw and optimized hand-written code. ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
d88-jwa@byse.nada.kth.se (Jon W{tte) (03/05/91)
In article <29222@cs.yale.edu> tarr@cs.yale.edu writes: >1. small macs (plus, SE, SE/30, classic) ^^^^^ The SE/30 is a slotted mac (it has one, processor-direct slot). >I think I have categories 1 and 2 down pat. Just check machine type and then >use VInstall or SlotVInstall, but on the cat 3 machines, I try to use a Never test for a machine type ! How many times has Apple said that ? Check for avaiability of the slot mgr calls, and then check through the slots to find video is a better strategy... >SlotVInstall which I am doubtful is getting the actual tickcount. For >instance, on a IIsi w/ apple color monitor, the rate is reported at 1/62 >second per tick, just like the cat 1 machines. Is this correct? I would >be very interested in seeing a listing of the actual refresh rates of all >of these machines and in the case of the cat 2 machines, the refresh rates >some circumstances. Couldn't apple just give us a toolbox or system call for >supplying the moment of refresh? Also, is the tickcount value still 60.15 >ticks per second and is it used for determing the value of the event.when >field in events? Surprise ! Inside macintosh volume V says (paraphrased) that: the global variable Ticks (which is not available unde A/UX) and TickCount() remain as updated-60-times-a-second variables. To synch to the vertical retrace of a video card, a new routine (SlotVInstall...) is provided. It's all in Inside mac. I don't have it here, but read volume V yourself and you should be on your way. h+ "The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do." -- Juri Munkki in comp.sys.mac.programmer