haitex@pnet01.cts.com (Wade Bickel) (12/08/87)
I am using non-intuition screens to achieve a static double buffer
effect. Basically, I create two View/ViewPort/RasInfo/BitMaps, and
then switch between them. The switching is handled by a copper
generated interrupt. The views are Loaded individually before the
interrupt switching is installed, so I know that each view is properly
created.
Sometimes the program works properly, but sometimes the screen goes
totally black (no mouse pointer). Regaurdless, when the program
terminates, the screen is returned to the system and continues to
function properly. The interrupts are definitly occurring, even when
the screen goes black (I have checked via other output).
Any idea what is going on? I have tried all kinds of disable/enable
mechanisms to avoid conflicts, without success.
How does LoadView work?
Thanks in advance,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (12/09/87)
In article <2108@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > I am using non-intuition screens to achieve a static double buffer > effect. Basically, I create two View/ViewPort/RasInfo/BitMaps, and > then switch between them. The switching is handled by a copper > generated interrupt. [ ... ] You're trying to do 3D, aren't ya? I happen to know that you're in quasi-competition with us, so I'm not at liberty to disclose any information I may have. :-) :-) > How does LoadView work? > It updates GfxBase, then stuffs some registers in the chips. > Any idea what is going on? [ ... ] Yes. :-) HINT: Use VBLANK instead; it's easier to work with. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jimm@amiga.UUCP (Jim Mackraz) (12/11/87)
[forgive that this is not a true rn followup] Wade asks what LoadView does ... Leo says: "It updates GfxBase, then stuffs some registers in the chips." This isn't too educational. The main content of a view is/are ready-to-go Copper List(s), which result from MgrCop. LoadView() primarily puts the address of these Copper Lists into the fields in GfxBase from which GfxBase will initialize the Copper during vertical blank. That's right, even though the hardware seems to have the capability to restart the coppers itself, it is in fact done through software--the graphics Vblank interrupt handler. LoadView() was augmented in 1.2 to set the top margin color to the background color of the TOP screen, instead of leaving it the background color of the bottommost visible screen (remember that ugly?). This latter is done by looking down the View's viewport list, but isn't a big performance hit. SO: you cannot get away with stuffing the hardware copper registers without also inhibiting gfx vblank from putting back the copper lists stored in GfxBase. Better way to go, however is to use LoadView to install your new copper lists. The effect of displaying the new view will then occur after the very next vertical blank. This is a cleaner change than when one tries ScrollVPort() (which is a copper list Poke). You do not need the copper generated interrupt to do the voodoo, but such an interrupt is invaluable in notifying your program (send a signal to your- self from the copper interrupt handler) that BOTTOM of frame has occured, so it is now safe to render in the buffer which you have just set up to be "offscreen". I think the optimal way to behave is this .... ... Draw in offscreen view's raster (call it rasterA, so rasterB is now onscreen) LoadView (rasterA will be displayed onscreen after next vblank) Tell your copper int handler to send you a signal next Bottom of Frame. (set a global, perhaps) Perform any calculations needed for the next view (while the beam finishes tracing rasterB) Wait for the signal (if BOF has occured already, your signal will be pending, and your task won't even be switched out) Draw in rasterB .... repeat Note that this wastes minimal time in a couple ways. 1) You perform calculations in the "dead time" while the beam finishes scanning rasterB. If you have minimal calculation (such as with an ANIM playback), you might want to bag this, and try a beam synchronization scheme. 2) You don't wait for Top of Frame before rendering in rasterB, so you get to use that most valuable vblank period when the processor and blitter don't get compromised by the display dma. plus 3) You don't spin wait for the bottom of frame (which WaitBOF() does in 1.2) which really only effects multi-tasking, I think. This way, all you need to do to go wild is crank your priority up, not take over the machine or Forbid(). Since I've been posting this scheme for several months, but never actually coded it up, maybe someone can send me an example or tell me how wonderful it really is in practice. jimm -- Jim Mackraz, I and I Computing amiga!jimm BIX:jmackraz Opinions are my own. Comments regarding the Amiga operating system, and all others, are NOT to be taken as Commodore official policy.