[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 30 Mar 2010, at 16:09 , Milan Mimica wrote:
> I say we should aim to raw values. When you use the mouse to drive the camera
> you don't want the screen resolution to affect input precision.
When I'm not using it to do anything of the sort I probably do want screen resolution to affect mouse speed.
So in that case, maybe we do want the option of returning both. However, I feel that we should ONLY do this if we can guarantee the same behaviour across platforms.
Which means someone (not me) gets the job of looking up how to do it on OS X and how to make it play well with the event API. I'm reasonably sure you can do it, but it looks quite complicated and I don't know how well it plays with the event system, ie, I don't think you get a movement event when the mouse is at the edge of the screen/outside the tracking rectangle. Since all of the mouse code (in OS X) depends on getting notified (by the OS) of mouse events, I don't see an easy way to make that work.
I also don't see this as a reason to hold back the 5.0 release, which means I don't see this as a reason to delay the feature-freeze before that. That probably means it needs to be implemented in the next week or two, or it gets pushed back (at least) to 5.0.1 (assuming it doesn't break ABI compatibility in the process).
An alternative, which may be quite neat if we can implement this properly, is to be able to register the mouse as a "generic input device" rather than a mouse. The rationale being that if you're using the mouse to control a camera (to stick with that example), then you're really using it as a generic input device more than a mouse.
Evert