[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ggi-develop
Subject:    RE: [ggi-develop] [dxinput] pointer movement issue (bug?)
From:       "Peter Ekberg" <peda () axentia ! se>
Date:       2004-10-05 11:40:45
Message-ID: 90459864DAD67D43BDD3D517DEFC2F7D71C7 () axon ! Axentia ! local
[Download RAW message or body]

Albert Graef wrote:
> Peter Ekberg wrote:
>> Improved pointer acceleration, yikes, more stuff to rework. And you
>> never know when it's going to change. Emulating this stuff seems
>> awfully fragile. I wonder if there is a win32 function that converts
>> raw mouse deltas (mickies) into the actual movements seen in the
>> GUI... 
> 
> There must be, somwhere in this pile of awfully designed
> interfaces they
> call the DirectX API... What about the absolute mouse
> positions reported
> by Windows? Oh, I see, these are probably confined to the
> screen boundaries.

I did some digging in MSDN, and I think it is impossible
to have the relative mouse movements reported by DirectX
match the cursor movements seen on screen. Here's the
reason: In Win2k there are two ways to control the mouse
movements (and three in WinXP it seems):

1. Acceleration, applied (approx) as
	mouse_delta > threshold ? 2 * mouse_delta : mouse_delta
2. Sensitivity (or speed), applied as
	mouse_delta * scale_factor / 10

Now, Win2k applies acceleration then sensitivity to the
cursor. The problem is that the mouse deltas reported by
DirectX have the sensitivity applied, but not the accel-
eration. Trying to undo the sensitivity in order to
apply acceleration and then redo the sensitivity is not
possible, as a scale_factor less than 10 destroys
information (integer math). The real raw mouse movement
is thus not possible to get to, and it is therefore not
possible to redo what Win32 does with the cursor using
the mouse deltas gathered from DirectX.

So, I will rip out the acceleration code from input-directx
as it can't be made to work 100% like the cursor. This
snippet from the DirectX docs is also "revealing":

"The data returned for the x-axis and y-axis of a mouse
 indicates the movement of the mouse itself, not the
 cursor. The units of measurement are based on the values
 returned by the mouse hardware and have nothing to do
 with pixels or any other form of screen measurement.
 Because Microsoft DirectInput communicates directly with
 the mouse driver, the values for mouse speed and
 acceleration set by the user in Control Panel do not
 affect this data."

But this is not entirely true, the value for mouse speed
in the Control Panel *is* used (see above). So, what else
is new? :-/

>> BTW, I just looked for a way to determine the number of mouse
>> buttons, and found GetSystemMetrics(SM_CMOUSEBUTTONS). Expect
>> that to appear in cvs soonish...
> 
> Ok, I'm looking forward to this. I'm currently in the release process
> for a new Q version; the Windows msi will include the latest GGI from
> CVS. I'll put that on hold until you update the driver.

It's been in cvs for a while in case you didn't notice.

Cheers,
Peter


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
ggi-develop mailing list
ggi-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ggi-develop

[prev in list] [next in list] [prev in thread] [next in thread]