From:	"James Slaughter" <James_Slaughter AT CompuServe DOT COM>
References:	<34a9da82 DOT 0 AT news DOT usinternet DOT com>
Subject:	Re: DJGPP Mouse Routines
Date:	Sat, 3 Jan 1998 20:04:14 -0000
Lines:	35
Message-ID:	<OlSDNrIG9GA.318@nih2naab.prod2.compuserve.com>
Newsgroups:	comp.os.msdos.djgpp,rec.games.programmer
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Matthew Reiferson wrote in message <34a9da82 DOT 0 AT news DOT usinternet DOT com>...
>I wrote some mouse routines in C with DJGPP.  The problem I came across is
>that I must divide the x value returned into REGS from a call to the
>position of the mouse (to determine the x,y location of the cursor), but
not
>the y value.

The mouse interrupt functions (0x33) return the position measured in their
own virtual coordinates, which often have absoloutly no relation with the
onscreen graphics modes. It just happens that the virtual resoloution for
Mode 0x13 is 640x200, which means that you need to divide the X by two, just
not Y; this isn't a fault with your program.

The problem is complicated by higher resoloution graphic modes, where the
virtual resoloution is less than that of the screen, and you have to fiddle
it all to work properly. In my Dim-Distant-DOS-Days(TM) I ended up writting
my own COM port interrupt handler and interpretting the packets directly.
I'll send you a copy if you want, but I wouldn't recommend that you followed
this archaic way to do things.

A (perhaps) better way to handle the mouse in High Res modes is to take the
delta between the current position and the previous for both X & Y, and
increment the variables that your program uses by this, resetting the mouse
position to the center when it approaches an edge. If you do this, allow the
option of a scale factor if the mouse exceeds a certain threshold, lest you
end up with a mouse cursor as slow as in some of the early EA Sport games.

Hope this helps,
James.

- Raw text -