AndyKorth's picture

Mac OpenTK.Input.Mouse provides coordinates that drift badly.

Project:The Open Toolkit library
Version:all versions
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:confirmed
Description

HIDInput.cs, ~line 230. Mouse values seem to be coming from the hardware as deltas, which are then added to the current state to give you the current mouse position. Unfortunately, these values seem to immediately become wildly off, and then the (0,0) point of the cursor continues to move across the screen as you click.

So, http://www.opentk.com/doc/input hints that the Input class might be inappropriate for games where you need a mouse position.. but if the coordinates are so inaccurate, perhaps position should be removed from the API. Not 100% sure what the plan is on this, or how it performs on other platforms.

Solution for now is to avoid these input methods and instead use GameWindow.Mouse or one of the other mouse input methods that go through the CarbonGLNative.ProcessMouseEvent or other Carbon methods.

The MouseState.X and Y should be pulling their info from elsewhere. I don't really know what to do about this one, so I'll leave this issue open until someone more knowledgable comes by.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Status:open» confirmed

I *believe* that this is caused by not applying the scaling factor reported by the HID device.