hawk@pnet01.cts.com (John Anderson) (05/07/91)
>DMouse's only gotcha had to do with mouse blanking. I went direct to >the copper list on earlier versions of DMouse and this broke under 2.0 >(admittedly, I was doing something entirely illegal). By the time 2.0 >had come out I had already stuck a check in the code to not attempt to >blank the mouse if the copper list was not as expected. After some >discussion somebody came up with the bright idea, and I kick myself for >not thinking of it, of simply turning off sprite DMA to blank the >mouse. Entirely compatible and documented. Works great! And if it >ever breaks in the future you simply turn off that particular feature. Turning off sprite DMA to blank the mouse pointer may be good for some things but the people who wrote the few pointer blankers for 2.0 also turned off the cursor for JRComm (which is a sprite). So when the mouse pinter blanks so does the darn cursor!!!
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/07/91)
In article <9107@crash.cts.com> hawk@pnet01.cts.com (John Anderson) writes: >not thinking of it, of simply turning off sprite DMA to blank the >mouse. Entirely compatible and documented. Works great! And if it >ever breaks in the future you simply turn off that particular feature. Turning off sprite DMA to blank the mouse pointer may be good for some things but the people who wrote the few pointer blankers for 2.0 also turned off the cursor for JRComm (which is a sprite). So when the mouse pinter blanks so does the darn cursor!!! As one of those authors, I can tell you it's not avoidable. Turning off sprite DMA (the safe way to turn it off) turns off all the sprites. That's the way the hardware works. Since MouseOff is a commodity, use Exchange to disable it when you're running JRComm (or anything else that needs sprites). Now, if you want to suggest another way to turn off the cursor that's 2.0 safe (doesn't even need to work in 1.3), I'll gladly consider it. Matt, what does DMouse do to prevent the sprite dma from being turned off while a sprite is being displayed? I'm still trying to find a good solution to that. <mike -- Love and affection, Mike Meyer Of the corporate kind. mwm@pa.dec.com It's just belly to belly, decwrl!mwm Never eye to eye.
DXB132@psuvm.psu.edu (05/08/91)
In article <MWM.91May7113724@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) says: >Matt, what does DMouse do to prevent the sprite dma from being turned >off while a sprite is being displayed? I'm still trying to find a good >solution to that. I'm not Matt, but... The complicated solution is to syncronize with the video beam. The simple solution is to poke zero (which means transparent - not visible) into the "sprite data" register for sprite 0. One line of assembly. :-) You can also avoid this problem by using SetPrefs to blank instead of turning off sprite DMA. Turning off sprite DMA is a pretty drastic measure, after all. -- Dan Babcock
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/08/91)
In article <9107@crash.cts.com> hawk@pnet01.cts.com (John Anderson) writes: >>DMouse's only gotcha had to do with mouse blanking. I went direct to >>the copper list on earlier versions of DMouse and this broke under 2.0 >>(admittedly, I was doing something entirely illegal). By the time 2.0 >>had come out I had already stuck a check in the code to not attempt to >>blank the mouse if the copper list was not as expected. After some >>discussion somebody came up with the bright idea, and I kick myself for >>not thinking of it, of simply turning off sprite DMA to blank the >>mouse. Entirely compatible and documented. Works great! And if it >>ever breaks in the future you simply turn off that particular feature. > >Turning off sprite DMA to blank the mouse pointer may be good for some >things but the people who wrote the few pointer blankers for 2.0 >also turned off the cursor for JRComm (which is a sprite). So when >the mouse pinter blanks so does the darn cursor!!! Yes, I know. Too bad. There is no other way to do it. You can always turn the feature off (without effecting other features). Call it a design decision if you will, but the majority of people who use DMouse these days use it for the mouse blanking. The mouse acceleration also generally used on 1.3 systems, but not as much under 2.0. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) (05/08/91)
Hi, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >As one of those authors, I can tell you it's not avoidable. Turning >off sprite DMA (the safe way to turn it off) turns off all the >sprites. That's the way the hardware works. Since MouseOff is a >commodity, use Exchange to disable it when you're running JRComm (or >anything else that needs sprites). I still wonder if switching off sprite DMA by directly addressing the custom chips is a 'legal' way, according to Commodore's programmer guidelines ? I've got the same problem in these days, and other ways like SetPointer() from intuition.library or ChangeSprite() from graphics.library just don't do exactly what I want - turn off ALL sprites, no matter if they are already occupied or not.. >Now, if you want to suggest another way to turn off the cursor that's >2.0 safe (doesn't even need to work in 1.3), I'll gladly consider it. I'll be glad to hear such suggestions, too.. >Matt, what does DMouse do to prevent the sprite dma from being turned >off while a sprite is being displayed? I'm still trying to find a good >solution to that. Although I'm not Matt ;^), I had a short look into dmouse-handler.c: > * 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.. :} So long, Frank -- + Frank Neumann, Hauptstr. 107, 2900 Oldenburg, FRG The Amiga is it. + + InterNet: Frank.Neumann@arbi.informatik.uni-oldenburg.de + + UUCP: neumann@uniol.uucp \\// InHouse:amigo@faramir + + Zerberus: neumann@uniol.zer BitNet:295391@DOLUNI1.BITNET IRC: Franky + + Alan Turing's letzte Worte: 'Mein Gott - es ist voller Blanks..' (ME) +
itch@cbnews.cb.att.com (richard.m.brack) (05/08/91)
In article <MWM.91May7113724@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <9107@crash.cts.com> hawk@pnet01.cts.com (John Anderson) writes: > >not thinking of it, of simply turning off sprite DMA to blank the > >mouse. Entirely compatible and documented. Works great! And if it > >ever breaks in the future you simply turn off that particular feature. > > Turning off sprite DMA to blank the mouse pointer may be good for some > things but the people who wrote the few pointer blankers for 2.0 > also turned off the cursor for JRComm (which is a sprite). So when > the mouse pinter blanks so does the darn cursor!!! > > As one of those authors, I can tell you it's not avoidable. Turning > off sprite DMA (the safe way to turn it off) turns off all the > sprites. That's the way the hardware works. Since MouseOff is a > commodity, use Exchange to disable it when you're running JRComm (or > anything else that needs sprites). > > Now, if you want to suggest another way to turn off the cursor that's > 2.0 safe (doesn't even need to work in 1.3), I'll gladly consider it. Well, I haven't done any programming on my Amiga so I may say something stupid, but one idea did come to mind just now. I have seen applications that change the sprite pointer so I assume it is a safe thing to do. So why not change the sprite to something that has no bits set so the background shows through. Sort of like, not turning the sprite off, but making it invisible. Just a thought.... RichBrack -- { the itchman cometh /-/ _ i don't want to be your angel } { itch@cbnews.att.com /-/ _|_|_ i want to be your witch! } { att!cbnews!itch \-\/-/ ( * )tch -yello } { \/\/ /^\ }
mjl@alison.at (Martin J. Laubach) (05/09/91)
In article <MWM.91May7113724@raven.pa.dec.com>, Mike (My Watch Has Windows writes: | Matt, what does DMouse do to prevent the sprite dma from being turned | off while a sprite is being displayed? I'm still trying to find a good | solution to that. The mouse blanker in APyro turns off the DMA, then stuffs zeroes in the sprite DMA data registers. mjl
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/09/91)
In article <MWM.91May7113724@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > >Matt, what does DMouse do to prevent the sprite dma from being turned >off while a sprite is being displayed? I'm still trying to find a good >solution to that. > > <mike >-- >Love and affection, Mike Meyer >Of the corporate kind. mwm@pa.dec.com >It's just belly to belly, decwrl!mwm >Never eye to eye. Oh, that's an easy one! Somebody on bix suggested it to me ... problem: if sprite DMA is turned off while the sprite is being displayed, the sprite DMA registers will contain non-zero data causing a vertical bar. solution: After turning off sprite DMA, write a 0 to the DMA data registers for the sprite(s). OFF_SPRITE; custom.spr[0].dataa=0; /* sprite0 DMA */ custom.spr[0].datab=0; /* data register */ Though I just realized that I should go through all the other sprite's DMA data registers too instead of just sprite 0. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/09/91)
In article <91127.171511DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >In article <MWM.91May7113724@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch >Has Windows) Meyer) says: > >You can also avoid this problem by using SetPrefs to blank instead of >turning off sprite DMA. Turning off sprite DMA is a pretty drastic >measure, after all. > >-- Dan Babcock Nope, doesn't work. A couple of problems with SetPrefs(): (1) Takes an incredible amount of CPU. Not something you want to do very often. (2) Buggy under 1.3 (not reliable, could crash the machine), effects many subsystems, including the printer I believe, as well as alerts programs requesting the appropriate class, which you don't want either. (3) Obsolete under 2.0, though probably still works for pointer data. (4) Only effects pointer when under workbench's control, does not effect application custom pointers. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/09/91)
In article <amigo.673697667@faramir> Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: I'll be glad to hear such suggestions, too.. Well, someone mentioned the Prefs method. I used to use that; it created more problems than it solved under 1.3 - you had to kill it to save prefernces. It should work better under 2.0, but I don't use many things that need the extra sprites. >Matt, what does DMouse do to prevent the sprite dma from being turned >off while a sprite is being displayed? I'm still trying to find a good >solution to that. Although I'm not Matt ;^), I had a short look into dmouse-handler.c: 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.. :} Yeah, I used to do the WaitTOF(). Not only do you have to worry about the scheduler getting the task, but all the interrupts & such get to run before you do. I beat that by having the mouse get turned off by code in the VBLANK interrupt chain. I _still_ get hit by the dma going off at the wrong time every so often. Maybe I should turn off overscan and quit using a crosshair mouse, as they both contribute to it. BTW, my mouse blanker is the only one I know of that uses a keystroke count instead of a timeout. I've come to prefer that. <mike -- All around my hat, I will wear the green willow. Mike Meyer And all around my hat, for a twelve-month and a day. mwm@pa.dec.com And if anyone should ask me, the reason why I'm wearing it, decwrl!mwm It's all for my true love, who's far far away.
jsmoller@jsmami.UUCP (Jesper Steen Moller) (05/09/91)
In article <91127.171511DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: [voilent ways of blanking mouse] > You can also avoid this problem by using SetPrefs to blank instead of > turning off sprite DMA. Turning off sprite DMA is a pretty drastic > measure, after all. Good idea, but not good enough for those who use their own pointers. My suggestion is to use the intuition SetPointer() call, and then, when unblanking, check if the blanked window is still there (traverse the Intuition list while LockIBase()'d) - if yes, put back the old value... > -- Dan Babcock -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmami!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/09/91)
In article <dillon.7443@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes:
solution: After turning off sprite DMA, write a 0 to the DMA
data registers for the sprite(s).
OFF_SPRITE;
custom.spr[0].dataa=0; /* sprite0 DMA */
custom.spr[0].datab=0; /* data register */
Though I just realized that I should go through all the other sprite's
DMA data registers too instead of just sprite 0.
This seems to be backwards - you've left a window where the dma could
be turned off with non-zero sprite data. Shouldn't you zero the
sprite data, _THEN_ turn off sprite DMA?
Thanx,
<mike
--
Cheeseburger in paradise Mike Meyer
Making the best of every virtue and vice mwm@pa.dec.com
Worth every damn bit of sacrifice decwrl!mwm
To get a cheeseburger in paradisebombadil@diku.dk (Kristian Nielsen) (05/09/91)
Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: >>Matt, what does DMouse do to prevent the sprite dma from being turned >>off while a sprite is being displayed? I'm still trying to find a good >>solution to that. >Although I'm not Matt ;^), I had a short look into dmouse-handler.c: >> * 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.
peter@cbmvax.commodore.com (Peter Cherna) (05/09/91)
In article <dillon.7445@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > Nope, doesn't work. A couple of problems with SetPrefs(): > > (1) Takes an incredible amount of CPU. Not something you want > to do very often. And it's slower under 2.0, because its job is much harder. > (3) Obsolete under 2.0, though probably still works for pointer data. Under 2.0, Preferences has been broken into multiple subsystems, which are sometimes equivalent to but often leagues beyond what could be set through SetPrefs(). SetPrefs() still works where the old-style information is known to be meaningful. Where the old style information could wipe out new information it couldn't know about, it's ignored. Here are a few examples: * Printer. No new Preferences items were added. SetPrefs() is fully equivalent. * Colors. Preferences contains 7 colors (four for the WB, three for the pointer). These take effect as before, even though the new Preferences allows you to set all the colors of the WB, even if that means 16. * FontHeight. Under 1.3, this could be 8 or 9. Under 2.0, you get to specify font names and size. Thus FontHeight is ignored, since it'll always contain 8 or 9, and you don't want to lose your nice Helvetica 15 just because someone did a SetPrefs(). * Pointer. 2.0 pointers can be taller. If you do a GetPrefs(), you'll receive the first 16 lines in the structure you get back. If you did a SetPrefs() and Intuition listened to it, it'd chop off your pointer. Here the rule is: the pointer part of SetPrefs() is followed until the first new-style pointer is seen, and ignored thereafter. So the answer is: when reasonable and possible, SetPrefs() is still heeded. Those pieces of SetPrefs() that would interfere with new 2.0-style preferences are ignored. > Matthew Dillon dillon@Overload.Berkeley.CA.US Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/10/91)
In article <amigo.673697667@faramir> Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: >Hi, >> 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, Actually, it's the custom.spr[0] ... stuff that does it. WaitTOF() doesn't guarentee anything but exists to reduce 'glitches'. >So long, >Frank -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/10/91)
In article <MWM.91May8165946@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <amigo.673697667@faramir> Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: > >BTW, my mouse blanker is the only one I know of that uses a keystroke >count instead of a timeout. I've come to prefer that. > > <mike Yuck! :-) I prefer a timeout. -Matt >-- >All around my hat, I will wear the green willow. Mike Meyer >And all around my hat, for a twelve-month and a day. mwm@pa.dec.com >And if anyone should ask me, the reason why I'm wearing it, decwrl!mwm >It's all for my true love, who's far far away. -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/10/91)
In article <amigo.673697667@faramir> Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: >>Matt, what does DMouse do to prevent the sprite dma from being turned >>off while a sprite is being displayed? I'm still trying to find a good >>solution to that. >Although I'm not Matt ;^), I had a short look into dmouse-handler.c: > >> * 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.. :} > By bumping your task priority to 127 before the WaitTOF(), you have a much better chance of another task not getting the CPU. By the way: custom.spr[0].dataa, etc. sure looks like going to the metal to me :) -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/10/91)
In article <dillon.7417@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <9107@crash.cts.com> hawk@pnet01.cts.com (John Anderson) writes: >>>DMouse's only gotcha had to do with mouse blanking. I went direct to >>>the copper list on earlier versions of DMouse and this broke under 2.0 >>>(admittedly, I was doing something entirely illegal). By the time 2.0 >>>had come out I had already stuck a check in the code to not attempt to >>>blank the mouse if the copper list was not as expected. After some >>>discussion somebody came up with the bright idea, and I kick myself for >>>not thinking of it, of simply turning off sprite DMA to blank the >>>mouse. Entirely compatible and documented. Works great! And if it >>>ever breaks in the future you simply turn off that particular feature. >> >>Turning off sprite DMA to blank the mouse pointer may be good for some >>things but the people who wrote the few pointer blankers for 2.0 >>also turned off the cursor for JRComm (which is a sprite). So when >>the mouse pinter blanks so does the darn cursor!!! > > Yes, I know. Too bad. There is no other way to do it. You can always > turn the feature off (without effecting other features). Call it a > design decision if you will, but the majority of people who use DMouse > these days use it for the mouse blanking. The mouse acceleration also > generally used on 1.3 systems, but not as much under 2.0. > > -Matt > Why not check to see if you are running under 2.0 and work as a commodity? >-- > > Matthew Dillon dillon@Overload.Berkeley.CA.US > 891 Regal Rd. uunet.uu.net!overload!dillon > Berkeley, Ca. 94708 > USA -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/11/91)
In article <mykes.2444@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > Yes, I know. Too bad. There is no other way to do it. You can always > turn the feature off (without effecting other features). Call it a > design decision if you will, but the majority of people who use DMouse > these days use it for the mouse blanking. The mouse acceleration also > generally used on 1.3 systems, but not as much under 2.0. > > -Matt > Why not check to see if you are running under 2.0 and work as a commodity? Because the commodity system doesn't provide any way to turn the mouse off. The commodity system provides programmers and users with an easier way of controlling things on the input food chain, and dealing with events from same. It doesn't provide applications specific utilities like turning off the mouse, or blanking the screen, or window shuffling. It's up to the application to do that. My blanker was upgraded to commodity status under 2.0. It still uses the same technic to turn off the mouse. It's nice to be able to disable it without just killing the thing, though. <mike -- I know the world is flat. Mike Meyer Don't try tell me that it's round. mwm@pa.dec.com I know the world stands still. decwrl!mwm Don't try to make it turn around.
jsmoller@jsmami.UUCP (Jesper Steen Moller) (05/11/91)
Isn't the best way of blanking the mouse to use SetPointer with
a transparent image on the active window, just for the sake of
compatibility? One day, the mouse-pointer may not be a sprite...
Roughly something like (pseudo-c ;)
void BlankMouse() /* function called when blanking and staying blanked */
{
struct Window *window;
window=IntuitionBase->ActiveWindow; /* assume LockIBase()'d */
if(window!=blankwin)
{
UnBlankMouse();
blankwin=window;
save=all.the.lot.of.values.stashed.in.blankwin.to.describe.the.pointer;
SetPointer(blankwin,&zerochips[0],0,0,0,0,0,0);
}
}
void UnBlankMouse() /* to clean up the mess */
{
if(blankwin) return;
if(CheckIfWindowReallyExistsByTraversingWindowList(blankwin))
SetPointer(save);
blankwin=0;
}
Am I right?
-- __
Jesper Steen Moller /// VOICE: +45 31 62 46 45
Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmami!jsmoller
DK-2920 Charl \\\/// FIDONET: 2:231/84.45
Denmark \XX/mjl@alison.at (Martin J. Laubach) (05/12/91)
In article <jsmoller.5147@jsmami.UUCP>, Jesper Steen Moller writes: | Isn't the best way of blanking the mouse to use SetPointer with | a transparent image on the active window, just for the sake of | compatibility? One day, the mouse-pointer may not be a sprite... Nope, it won't work. Suppose I'm in an editor, writing text. The mouse is blanked as it should be. Now the editor opens a new window ("Do you really want to save?"), and -poof- the pointer reappears. mjl
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/12/91)
In article <mykes.2444@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <dillon.7417@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> Yes, I know. Too bad. There is no other way to do it. You can always >> turn the feature off (without effecting other features). Call it a >> design decision if you will, but the majority of people who use DMouse >> these days use it for the mouse blanking. The mouse acceleration also >> generally used on 1.3 systems, but not as much under 2.0. >> >> -Matt >> > >Why not check to see if you are running under 2.0 and work as a commodity? Because I wrote DMouse years ago and have no intention of upgrading it any time soon (that is, I don't have the time :-)). My opinion of *Mouse type programs is that they come a dime a dozen.. I originally wrote DMouse because I didn't like Mach at the time, and encourage other people who don't like current *mouse enhancers to write their own! re: clearing the DMA registers before turning off sprite DMA. This will not work because sprite DMA may write to the registers after I clear them but before I turn off DMA. re: using WaitTOF()/Forbid(). It isn't a good idea to depend on this for mouse blanking, even in an interrupt (i.e. using VBLANK), because it makes too many assumptions on how and when system sprite DMA occurs, as well as adds a needless Forbid()/Permit() call and the overhead associated with the interrupt processing. Of course, it could also be argued that the overhead of processing input events is already so great that everything else is in the noise :-) -Matt >>-- >> >> Matthew Dillon dillon@Overload.Berkeley.CA.US >> 891 Regal Rd. uunet.uu.net!overload!dillon >> Berkeley, Ca. 94708 >> USA > >-- >**************************************************** >* I want games that look like Shadow of the Beast * >* but play like Leisure Suit Larry. * >**************************************************** -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
peter@cutmcvax.cs.curtin.edu.au (Peter Wemm) (05/12/91)
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!
peter@cbmvax.commodore.com (Peter Cherna) (05/13/91)
In article <jsmoller.5147@jsmami.UUCP> jsmoller@jsmami.UUCP (Jesper Steen Moller) writes: >Isn't the best way of blanking the mouse to use SetPointer with >a transparent image on the active window, just for the sake of >compatibility? One day, the mouse-pointer may not be a sprite... !!! ONLY !!! if _you_ own the active window. It's not a very friendly or safe thing to "attack" a window you don't own. >Jesper Steen Moller /// VOICE: +45 31 62 46 45 Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/16/91)
In article <21502@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <jsmoller.5147@jsmami.UUCP> jsmoller@jsmami.UUCP (Jesper Steen Moller) writes: >>Isn't the best way of blanking the mouse to use SetPointer with >>a transparent image on the active window, just for the sake of >>compatibility? One day, the mouse-pointer may not be a sprite... > >!!! ONLY !!! if _you_ own the active window. It's not a very friendly >or safe thing to "attack" a window you don't own. > >>Jesper Steen Moller /// VOICE: +45 31 62 46 45 > > Peter >-- >Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. >{uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com >My opinions do not necessarily represent the opinions of my employer. >"If all you have is a hammer, everything looks like a nail." OK, I think I can settle this once and for all (how to blank the screen). All you need to do is to strobe the copper with your own copper list that disables all the bitplane and sprite DMA. When your input event handler sees a mouse or key event, you can restore the display by doing a WorkbenchToFront() or by looking at GfxBase->copinit and strobing the copper with that. You should do a Disable()/Enable() pair around your code that diddles the copper and you should wait for VBL to do it. This method won't mess with anybody else's property. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
bombadil@diku.dk (Kristian Nielsen) (05/16/91)
About all these problems with mouse blanking: How about just sending the pointer to a corner of the display? this way it won't clutter up the main screen, and even better, you needn't start guessing where the h**l it will re-appear when you want to use it again. And this solves all problems with going to the hardware, since it can be done by creating the proper input event. One could even move the mouse back to the previous position upon recieving the first mouse event to comfort people who feel uncomfortable with having the pointer movve around without user control. I think this is the way I would prefer a mouse blanker to work (I don't like current blankers, I currently just put the mouse to a rest in a corner manually anyway). - Kristian.
Charlie_Gibbs@mindlink.bc.ca (Charlie Gibbs) (05/16/91)
In article <1991May16.123017.23498@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes: > About all these problems with mouse blanking: How about just sending the >pointer to a corner of the display? You could always run Leo Schwab's "Robotroff" - then a little robot will come along and drag it off for you. Of course, it might be a bit of a nuisance having a robot chasing you when you're actually trying to _use_ the mouse... :-) Charlie_Gibbs@mindlink.bc.ca "Sure they're Pink - but their money is green." -- "Bob"
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (05/17/91)
In article <1991May16.123017.23498@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes: > About all these problems with mouse blanking: How about just sending the >pointer to a corner of the display? That's an idea, but I would vote against it. Please don't touch my mouse! I put it someone where intentionally, and I'd like it to stay there, thank you very much. >One could even move the mouse back to the previous position upon >recieving the first mouse event to comfort people who feel uncomfortable >with having the pointer movve around without user control. So when the user leaves the computer for 10 minutes and comes back, he/she sees the mouse pointer sitting in the corner. How is the user supposed to know if the pointer is REALLY in the corner, or just there because of the mouse-blanking? You can't tell. I still vote against the idea -- I prefer true blanking. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
jleonard@pica.army.mil (05/17/91)
In article <1991May16.123017.23498@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes: > About all these problems with mouse blanking: How about just sending the >pointer to a corner of the display? This is not an option if you use a Sun type mouse, since it would very likely deselect the window every time the mouse blanks. ___________________________________________________________________________ |Jeff Leonard Usenet: jleonard@pica.army.mil | | My strength is as the strength of ten because my code is pure. | ---------------------------------------------------------------------------
ewilts@janus.mtroyal.ab.ca (Ed Wilts) (05/17/91)
In article <8392@jhunix.HCF.JHU.EDU>, barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > In article <1991May16.123017.23498@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes: >> About all these problems with mouse blanking: How about just sending the >>pointer to a corner of the display? > > That's an idea, but I would vote against it. Please don't touch my > mouse! I put it someone where intentionally, and I'd like it to stay there, > thank you very much. > > //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > | Dan Barrett, Department of Computer Science Johns Hopkins University | > | INTERNET: barrett@cs.jhu.edu | | > | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////// One feature quite common on Intergraph Unix workstations is the default mouse positioning when a requestor pops up. For example, many programs have a (stupid) requestor saying "Do you really want to quit?". At this stage, the program can move the pointer to over the OK gadget, at which point the user can do a single click to finish up. Saves a lot of mouse movements if you have a lot of requestors pop up. I rather liked them, although I haven't worked on an Intergraph station in about a year or so. -- .../Ed Preferrred: Ed.Wilts@BSC.Galaxy.BCSystems.Gov.BC.CA Ed Wilts Alternate: EdWilts@BCSC02.BITNET (604) 389-3430 B.C. Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8