1. dos_interrupt(#33,rl) --please read
Ok--in NEILMSE, I use the #33 dos interrupt with
REG_AX=3. That works all well and good except one
little thing...it only gives x and y values in factors
of 8 (0,8,16,24,etc.). How do I get it to
increase/decrease in factors of 1 (0,1,2,3,4,etc.)?
Its not that it makes NEILMSE bad or anything, just
that if the x and y went by ones, then you could get
more precise as to where the mouse is.
Thanks to all,
Mike Hurley
===
EMail (Yahoo): mikehurley2 at yahoo.com
EMail (AOL): mhssoft at aol.com
Web: www.geocities.com/SiliconValley/Circuit/6268/
Quote from Jeff Foxworthy: "If your dad walks you to school everyday because
you're in the same grade, you might be a redneck."
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
2. Re: dos_interrupt(#33,rl) --please read
That 8 pixel movement is so mouse is compatiable in text mode.
If your using graphics mode try using
int 33 with the following:
[REGS_AX] = #000F
[REGS_CX] = number of mickeys per 8 pixels horizonially ( default is 8 )
[REGS_DX] = number of mickeys per 8 pixels vertically ( default is 16 )
I havent look at mouse.e so I don't know if this will help
but you can try it.
3. Re: dos_interrupt(#33,rl) --please read
Bernie-
I tried your [AX]=#000F with interrupt #33, and when I called it I set [cx]
and [dx] to 1. That didn't make it go by ones, but it did make the mouse
move faster (which is not what I want). If I'm giving wrong values to [cx]
and [dx], please let me know, or if I'm using the wrong format.
Wait, here's an idea--I looked in Pete Eberlein's MIGHTY.E library and to get
the x and y values, he sets [AX] to #B, I tried that and I get numbers like
65536 and such. Would that be a better way to do what I'm trying to do, and
just use [AX]=3 just to get button events?
Thanks,
Mike Hurley
4. Re: dos_interrupt(#33,rl) --please read
Since all the mouse co-ordinates are multiples of 8, i suggest what you do
is set the area that the mouse is confined to to 8 times the actual screen
size IE: 640x480, confine the mouse to 5120x3840. And then any co-ordinates
you get for the mouse should be divided by 8.
The only problem with this is the mouse will be slowed down, since it has to
move 8x as far as normal, so you can probably use that dos_interrupt to
speed up the mouse a bit.
-Mark.
On Sun, 30 May 1999 17:05:37 EDT, Mike Hurley <MHsSoft at AOL.COM> wrote:
>Bernie-
>I tried your [AX]=#000F with interrupt #33, and when I called it I set [cx]
>and [dx] to 1. That didn't make it go by ones, but it did make the mouse
>move faster (which is not what I want). If I'm giving wrong values to [cx]
>and [dx], please let me know, or if I'm using the wrong format.
>
>Wait, here's an idea--I looked in Pete Eberlein's MIGHTY.E library and to
get
>the x and y values, he sets [AX] to #B, I tried that and I get numbers like
>65536 and such. Would that be a better way to do what I'm trying to do,
and
>just use [AX]=3 just to get button events?
>
>Thanks,
>Mike Hurley
5. Re: dos_interrupt(#33,rl) --please read
Mike,
Dos interrupt #33 service function #03 is the correct way to get the mous=
e
cursor position. It sounds like the problem is with your mouse driver,
which maybe thinks that it is in text mode. Try doing a mouse reset
(interrupt #33 service #00) after you are in the proper graphics mode. =
Maybe that will help.
Colin Taylor
6. Re: dos_interrupt(#33,rl) --please read
function #000B gets the mouse motion
cx is number of mickeys moved horz.
dx is number of mickeys moved vert.
By the way a mickey is equivalent to 1/200 of an inch .
this function returns the number of mickeys moved since the last call
to this function. I don't know what neilmse is unless you mean mighty.e
Have you looked at RAT.E in the supervga demo in the archives by J. Barbor ?
7. Re: dos_interrupt(#33,rl) --please read
One other thing I forgot to mention is that the microsoft mouse drivers
keep track of the mouse position on a vertual screen and then when you
request the mouse's location from int 33 The vertual position is translated
into physical screen position for the video mode you are in. Some modes may
be jumpy than others because of this mapping.
Bernie
the physical screen position
