Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!uniwa!cc.curtin.edu.au!cutmcvax!peter From: peter@cutmcvax.cs.curtin.edu.au (Peter Wemm) Newsgroups: comp.sys.amiga.programmer Subject: Re: Mouse blanking Message-ID: Date: 12 May 91 10:57:45 GMT References: <9107@crash.cts.com> <1991May9.132214.19206@odin.diku.dk> Sender: news@cutmcvax.cs.curtin.edu.au (Usenet News System) Organization: Curtin University of Technology, Computing Science Lines: 64 Nntp-Posting-Host: cutmcvax.cs.curtin.edu.au bombadil@diku.dk (Kristian Nielsen) writes: >Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: >>> * note, sometimes the sprite gets turned on again, so >>> * we re-off it every mouse-ptr-timeout >>> */ >>> if (doipcmsg(0x81) == 0) { >>> WaitTOF(); >>> OFF_SPRITE; >>> custom.spr[0].dataa=0; /* sprite0 DMA */ >>> custom.spr[0].datab=0; /* data register */ >>> sproff = 1; >>> } >>So - before switching off sprite DMA, he waits for the top of the frame - >>in this time there is for sure NO sprite DMA, so it is a safe way - however, >>one might think about what would happen if just after the WaitTOF() the >>scheduler would do his work to give the CPU to another task...but this should >>happen so rarely.. :} > The obvious answer to this should be to flank the WaitTOF()/OFF_SPRITE >pair with Forbid()/Permit(). Since an input handler is usually (not always, I >guess :-)) at the highest priority, this should prevent other tasks from >messing up the timing. Remember, a Wait() is supposed to break a Forbid() >until the task is woken up again. Now Where did I hear someone muttering >about the graphics.library using busy-wait? (I think it was for the blitter, >though) > - Kristian. Note that the WaitTOF() is ENTIRELY UNNECESSARY! I used dmouse 1.24 which caused the sprites to streak! - so, I took out the WaitTOF() and put in the pokes to the sprite dma data registers. I sent my changes to matt, though I dont know if he used mine or not. It no longer matters if the dma is turned off while the sprite is being displayed, as the sprite "streak" becomes transparent! Also, if you brutally turn off dma, you should also make sure the rest of the sprites are off... (ever seen how audiomaster3's sprites almost always "streak"?) Also, I had to rewrite the WhichMouseLayer() routine, because the version of 2.0 that I was using at the time had SCALED the intuitionbase mousex and mousey variables. If you moved the mouse to the bottom right corner of my 662x268 (pal overscan on medium res screen) workbench screen, the ibase mouse address was something like x=662, y=440. Since it was not interlaced, the y value was halved within dmouse to get a y value of 220. So... it activated the window that was 48 pixels AWAY from the mouse pointer! It was a REAL problem! My replacement routine uses an entirely different and officially supported way of getting which layer the mouse pointer is over. I never sent it to matt though.... I dont know if the scaling is still in the more recent beta 2.0's - it doesn't matter to my version of dmouse anymore. Also, that problem would only have appeared on PAL systems with their extra vertical scan lines. -- Peter Wemm ------------------------------------------------------------------------------ peter@cs.curtin.edu.au (Home) +61-9-450-5243 Curtin University of Technology, Perth, Western Australia. Nuke the Simpsons!