Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!ihnp4!houxm!mhuxl!eagle!allegra!jdd
From: jdd@allegra.UUCP
Newsgroups: net.cog-eng
Subject: Re: mice, pens, and graphics - (nf)
Message-ID: <2095@allegra.UUCP>
Date: Wed, 14-Dec-83 10:35:33 EST
Article-I.D.: allegra.2095
Posted: Wed Dec 14 10:35:33 1983
Date-Received: Fri, 16-Dec-83 01:45:05 EST
References: <1070@ucbcad.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 28

My experience with multi-speed mice:

The last time I had to build a mouse-tracker from scratch, I made the
tracking nonlinear.  My software polled the mouse periodically, obtaining a
delta-x and a delta-y (call them dx and dy).  It then computed the effective
dx as (I seem to recall) dx*(dx+1)/2, and dy similarly.

The important properties of that transformation were that 0->0 (so the mouse
didn't move by itself) and that 1->1 (so you could still make small, careful
changes), but that medium-sized values mapped into larger values, so you
could move faster.  It was also nice that it could be computed fairly fast.
Other transformations would also work, of course; dx*(dx+2)/3 would also
provide 2->2, and higher-order polynomials would allow for a sharper rise.

When people first started using this software, they would tend to overshoot
distant targets for the first ten minutes, but very quickly became used to
it.

There did not seem to be much trouble with the fact that the x and the y
transformations were computed separately, even though this meant that the
direction of the mouse movement was not preserved.  In fact, this might have
been an advantage, since the transformations would tend to make the
direction line up more exactly with the x-axis or y-axis, which is often
what you want.

Cheers,
John ("And This Is Called The `DeTreville' Mouse Transformation") DeTreville
Bell Labs, Murray Hill