Checking mouse-position: isn't working. (ASM, MASM)

[na_th_an]

Yeah, int 33h is lazy . I found out some years ago when I first used a mouse handler in QB. I realized that the coordinates were multiplied by two in screen modes with 320 pixels wide, and by 8 in text mode.

Sterling wrote this:

When taking X coords from the driver in mode 13 you have to divide by 2, when giving X coords to the driver you have to multiply by 2

Meaning that if you read the X position of your mouse you have to divide it by two to get the real screen position in a 320 pixels wide mode, and if you want to write a new value to the mouse's X position you have to multiply the real screen position in a 320 pixels wide mode by two. There was just a bit of misunderstanding

As in the SVGA resolutions, libraries usually do two things:

1.- They are lazy and use the mickeys to move the mouse (a mickey is some kind of measure that tells "how much" the mouse has moved in the horizontal and vertical axis.

2.- They are cool and use the mickeys to create a pseudo-virtual mouse resolution that ranges in the screen mode size.

[Sterling Christensen]

Thanks na_th_an.

It seems like whenever I explain something, Zack misunderstands, but when you do, he gets it. I guess I need to work on my communication skills.

Zack: na_th_an's right, I was talking about (int 33), not the video bios. I don't see what it is about my previous posts that suggests otherwise...

[Zack]

Lazy piece of &&*#, that int 33h is.
Sterling, sorry, I confused myself. I thought later on that I had been talking about int 10h rather than 33h. Not your fault at all.

[relsoft]

Thanks na_th_an.

It seems like whenever I explain something, Zack misunderstands, but when you do, he gets it. I guess I need to work on my communication skills.

Zack: na_th_an's right, I was talking about (int 33), not the video bios. I don't see what it is about my previous posts that suggests otherwise...

LOL