[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> If you need to position the mouse exactly this is really bad. Imagine
> you move the mouse 100 pixels wide (1/8th of a screen) then mouse code
> kicks in -> the mouse is moved 400 pixels wide (1/2 of the screen).
The problem is, you can't speak of moving the mouse by x pixels because this
would end up having a physical mouse range depending on the screen
resolution. Obviously you don't want to have a mouse pad for each screen
resolution :-)
So there must be a function mapping raw mouse mickeys (as returned by
DirectInput) to screen pixels.
> Anyway, if you need to speed it up, the speed increment should
> be the same all the time (say multiplying all values with some factor)
That's not a very good solution because:
- how do you choose the factor ? DirectInput returns raw mickeys, that is
hardware-dependent datas,
- you lose accuracy: for example, in 1600x1200 the mouse will be roughly 5
times less accurate than in 320x200, so that you can't point every pixel.
> Imagine the crosshair of your sniper would jump 132 pixels instead of 33
> just because you moved it a bit too far.
Too fast. If you want precision, you must move the mouse slowly enough.
> A quick turn which would normally result in a 90 degree turn would result
> in a 360 degree turn.
Yes, that's acceleration.
> You must see that this cannot be the solution for the "mouse is too slow"
> bug.
Acceleration is indeed the right solution, but we can discuss the
acceleration function. We can choose it more regular (with a continuous
derivative function) than the current one.
--
Eric Botcazou
ebotcazou@xxxxxxxxxx