grants@usage.csd.unsw.oz (Grant Sayer) (01/23/89)
I am trying to draw two images one on an offscreen pixelmap and then quickly swap the images, testing if a subject can detect the colour changes. The problem is that with the vertical retrace the subject will see part of the scan line which interrupts the picture. Does the method of placing the code which swaps the images, basically a copybits operation, into the VBL task queue seem a viable solution. If this is the casethen is it true that Turbo Pascal failsto allow procedures to be passed using the @ operator on the procedure name thereby preventing installation of the drawing procedure into VBInstall Any comments or suggestions would be appreciated Thanks in advance Grant Sayer (grants%usage.csd.unsw.oz@munnari.oz)
vincent@ditsyda.oz (David A. Vincent) (01/24/89)
in article <243@usage.csd.unsw.oz>, grants@usage.csd.unsw.oz (Grant Sayer) says: > Xref: ditsyda aus.mac:414 comp.sys.mac.programmer:2784 comp.sys.mac:18246 > > > I am trying to draw two images one on an offscreen pixelmap and then [...] >code which swaps the images, basically a copybits operation, into the VBL >task queue seem a viable solution. If this is the casethen is it true This seems viable provided that the copybits can be completed during the VBL period. >that Turbo Pascal failsto allow procedures to be passed using the @ >operator on the procedure name thereby preventing installation of the >drawing procedure into VBInstall TP allows you to apply @ to proc. or func. and pass the resulting pointer to an assembly-language routine (which I think is all you need to do). TP does not allow you to use such a pointer except to pass it around as a parameter. > > Any comments or suggestions would be appreciated > > Thanks in advance You're welcome. > Grant Sayer (grants%usage.csd.unsw.oz@munnari.oz) David A. Vincent vacation student, CSIRO Division of IT ACSnet: vincent@ditsyda.oz Post: GPO Box 1710-T Phone (w): +61 2 887 9383 Hobart TAS 7001 FidoNet: 3:670/700 Australia ---------------------------------------------------------------- Common sense is not all that common. -- Bertrand Russell.
jackiw@cs.swarthmore.edu (Nick Jackiw) (01/24/89)
In article <1453@ditsyda.oz> vincent@ditsyda.oz (David A. Vincent) writes: > in article <243@usage.csd.unsw.oz>, grants@usage.csd.unsw.oz (Grant Sayer) says: > > I am trying to draw two images one on an offscreen pixelmap and then > [...] > >code which swaps the images, basically a copybits operation, into the VBL > >task queue seem a viable solution. If this is the casethen is it true > > This seems viable provided that the copybits can be completed during > the VBL period. > Much easier is just to coordinate your copyBits with the VBL interval. You can do this in Pascal by waiting for the system timer to tick, something which happens as a system-VBL task. var x:longint; Delay(1,X); {Wait for next VBL interval} Copybits(...); {Here we go, do it fast!} Follow-ups to comp.sys.mac.programmer ONLY. Eradicate cross-posts! -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ PER ASPERA AD ASTRA
buffington@radar.UUCP (Jon Buffington) (01/25/89)
From article <2350@ilium.cs.swarthmore.edu>, by jackiw@cs.swarthmore.edu (Nick Jackiw): > In article <1453@ditsyda.oz> vincent@ditsyda.oz (David A. Vincent) writes: >> in article <243@usage.csd.unsw.oz>, grants@usage.csd.unsw.oz (Grant Sayer) says: >> > I am trying to draw two images one on an offscreen pixelmap and then >> [...] >> >code which swaps the images, basically a copybits operation, into the VBL >> >task queue seem a viable solution. If this is the casethen is it true >> >> This seems viable provided that the copybits can be completed during >> the VBL period. >> > > Much easier is just to coordinate your copyBits with the VBL interval. > You can do this in Pascal by waiting for the system timer to tick, something > which happens as a system-VBL task. > > var x:longint; > > Delay(1,X); {Wait for next VBL interval} > Copybits(...); {Here we go, do it fast!} > > Follow-ups to comp.sys.mac.programmer ONLY. Eradicate cross-posts! Your above advice (using tickcount to synch the raster) is sound only if your monitor is running at 60Hz. Since the person was inteerested in pixmaps, I would think they are using Apple's MAc II monitors which runn near 67Hz. In this case you have to use SlotVInstall() and assoc. routines to create a goAhead Boolean which you should check before CopyBits() in the main code. ex: pushScreen(bMapPtr, src, dest) BitMap *bMapPtr; Rect *src, *dest; { extern Boolean goAhead; /* this is modified in the VTask routine */ goAhead = FALSE; while (!goAhead) ; /* wait for task to signal retrace interupt */ CopyBits(...); } Helpful? Hope so... ------------------- jcb Q Q P eexxex: pushImage2Scree
lsr@Apple.COM (Larry Rosenstein) (01/26/89)
In article <243@usage.csd.unsw.oz> grants@usage.csd.unsw.oz (Grant Sayer) writes: > >scan line which interrupts the picture. Does the method of placing the >code which swaps the images, basically a copybits operation, into the VBL >task queue seem a viable solution. If this is the casethen is it true You can't actually do the CopyBits in the VBL task, because VBL tasks are restricted in what they can do. You can use the VBL task to indicate to your main application when vertical blanking occurs. The main application would poll the flag and do the copybits when vertical blanking happens. On a Mac II, things work a bit differently. Since the video is handled by each video card, the standard VBL stuff doesn't directly correspond to vertical retraces. Instead you have to use SlotVInstall to install the vbl task in the queue associated with the desired screen. You should look at the Vertical Retrace Manager of Inside Mac volume 5 for more info. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
billkatt@sol.engin.umich.edu (Steve Bollinger) (01/26/89)
In article <2350@ilium.cs.swarthmore.edu> jackiw@ilium.UUCP (Nick Jackiw) writes: >In article <1453@ditsyda.oz> vincent@ditsyda.oz (David A. Vincent) writes: >> in article <243@usage.csd.unsw.oz>, grants@usage.csd.unsw.oz (Grant Sayer) says: >> > I am trying to draw two images one on an offscreen pixelmap and then >> [...] >> >code which swaps the images, basically a copybits operation, into the VBL >> >task queue seem a viable solution. If this is the casethen is it true >> >> This seems viable provided that the copybits can be completed during >> the VBL period. >> > >Much easier is just to coordinate your copyBits with the VBL interval. >You can do this in Pascal by waiting for the system timer to tick, something >which happens as a system-VBL task. > > var x:longint; > > Delay(1,X); {Wait for next VBL interval} > Copybits(...); {Here we go, do it fast!} Except... He said that he was using a pixelmap (pixMap), and those are under color quickdraw. The VBL is fake on the Mac II and won't help reduce flicker. You need to look in inside Mac V 5 at chapter 29 for the correct way to sync to the REAL VBL on a Mac II. And also you don't need to complete the operation before the verticla blanking interval is over, you just need to keep ahead of the scan line. +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+
carr@Apple.COM (Randy Carr) (01/27/89)
In article <2350@ilium.cs.swarthmore.edu> jackiw@ilium.UUCP (Nick Jackiw) writes: >In article <1453@ditsyda.oz> vincent@ditsyda.oz (David A. Vincent) writes: >> in article <243@usage.csd.unsw.oz>, grants@usage.csd.unsw.oz (Grant Sayer) says: >> > I am trying to draw two images one on an offscreen pixelmap and then >> >code which swaps the images, basically a copybits operation, into the VBL >> >task queue seem a viable solution. If this is the casethen is it true >> >> This seems viable provided that the copybits can be completed during >> the VBL period. >> >Much easier is just to coordinate your copyBits with the VBL interval. >You can do this in Pascal by waiting for the system timer to tick, something >which happens as a system-VBL task. > > Delay(1,X); {Wait for next VBL interval} > Copybits(...); {Here we go, do it fast!} > >Follow-ups to comp.sys.mac.programmer ONLY. Eradicate cross-posts! > Well... Mac II's and other machines that use NuBus video have different vbl times depending on the monitor used. _Delay, on the other hand, is always in 1/60 sec intervals. So... in order to have true vbl drawing, you must use _SlotVInstall tasks (see the Apple Technote #221). >+-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ >| nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | >+-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ Randy Carr Network Systems Development Domain: carr@apple.com Apple Computer, Inc. UUCP: {nsc,dual,sun,voder}!apple!carr 20525 Mariani Ave. M/S 27-O AppleLink: CARR2 Cupertino, CA 95014 Opinions & Responses are my own and do NOT represent my employer...
jcl@hpausla.HP.COM (Jeff Laing) (01/27/89)
Another question about this 'CopyBits' inside VBL tasks. Is there a potential problem if the CopyBits decides to move memory around for you because it needs the space to draw a particularly difficult bitmap? Or is this one of those places the Quickdraw cheats and uses memory between heap and stack that it thinks is fair game?
bob@accuvax.nwu.edu (Bob Hablutzel) (01/29/89)
> Another question about this 'CopyBits' inside VBL tasks. > Is there a potential problem if the CopyBits decides to move memory > around for you because it needs the space to draw a particularly difficult > bitmap? Or is this one of those places the Quickdraw cheats and uses > memory between heap and stack that it thinks is fair game? You cannot use CopyBits from a VBL task. CopyBits is on the list of traps which might move or purge memory. Bob Hablutzel Wildwood Software BOB@NUACC.ACNS.NWU.EDU
jkjl@munnari.oz (John Lim) (01/31/89)
In article <10050074@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) writes: >You cannot use CopyBits from a VBL task. CopyBits is on the list of traps >which might move or purge memory. > David Dunham in MacTutor quoted Steve Brecher as saying that CopyBits only moves memory when you are saving a Picture. That was many months ago, so i dont know how valid this comment would be today. john lim
lsr@Apple.COM (Larry Rosenstein) (02/02/89)
In article <2661@munnari.oz> jkjl@munnari.oz (John Lim) writes: > >You cannot use CopyBits from a VBL task. CopyBits is on the list of traps > >which might move or purge memory. > > > David Dunham in MacTutor quoted Steve Brecher as saying that CopyBits > only moves memory when you are saving a Picture. That was many months > ago, so i dont know how valid this comment would be today. Probably right, except that CopyBits (as do all Quickdraw drawing calls) use the current port's clipping and visible region. At interrupt level, you can't be sure that the region handles will be consistent. They could be in the process of being moved by the Memory Manager. I suppose one could lock down the clipRgn and visRgn, but under Color Quickdraw, there might be other handles that would need to be locked as well (eg, the pixmap handle). Larry Rosenstein lsr@Apple.COM or {sun, nsc}!apple!lsr AppleLink: Rosenstein1
jcl@hpausla.HP.COM (Jeff Laing) (02/06/89)
Has anyone had a look though the article in the February issue of MacTutor which seems to be doing PlotIcon from within a VBL task? Has the discussion here been missing something, or will the article's program have real problems?
lsr@Apple.COM (Larry Rosenstein) (02/07/89)
In article <2580015@hpausla.HP.COM> jcl@hpausla.HP.COM (Jeff Laing) writes: >Has anyone had a look though the article in the February issue of MacTutor >which seems to be doing PlotIcon from within a VBL task? > >Has the discussion here been missing something, or will the article's program >have real problems? You are right, the article has problems. I found 3 problems (in increasing order of seriousness): (1) In the VBL task, the program sets up A5 based on the low memory value CurrentA5. This won't work under MultiFinder, if the VBL task is installed in the System Heap (which means it would be running when the application was in the background). The current recommendation is that a VBL task get the proper A5 from a value associated with the queue element. The application should set this value before starting the VBL task. (2) The program pushes the old value of A5 on the stack and pops it off at the end. Tech Note 208 warns against doing this because some compilers (eg, MPW C 3.0) will leave things on the stack and pop them off all at once. The technique of pushing A5 on the stack will mess this up. It is better to save A5 in a local variable of the VBL task and restore it from that variable. The Tech Note gives the code to do this. (3) As you mentioned, the VBL task calls PlotIcon and GetIcon, both of which are listed as moving memory, which means they can't be called from a VBL task. The third problem is generally fatal, although you could make it work most of the time if the icons were marked preload and locked in the resource file. In a small program like this, there wouldn't be much heap compaction going on, and you probably can get away with it. The first 2 points are not fatal, but are not good programming style. Unfortunately, the style that works in this simple case may not work in other cases. Someone who uses this article as a guide but makes his/her VBL task run in the background will find it won't work under MultiFinder. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr