Re: [AD] mouse bug

[ 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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/