That is a fine way to create an exponential curve, if you can afford the time and memory it takes to do floating point calculations. For a real-time application, such as modifying joystick response, that may not be the best choice. Same for things like polynomial curve fitting - computation intensive and overkill as well unless you want to precisely fit a curve who's characteristics you already know. Again, for joystick response, the thing we want is to get the right "feel" and that's something we're going to have to find out by trial and error. In the stuff I posted, the four curves are generated by:
(1) taking the analog value and squaring it (using long as the number can get pretty big)
(2) making different linear combinations of the straight analog value and the squared value:
a - original
b - (2 * original + 1* squared)/3
c - (original + squared)/2
d - (original + 2*squared)/3
e - squared
The results of these integer manipulations are quite close (better than 1% at all points) to the curves shown in the graph for the exponents shown in the graph legend. As I can't move a joystick with anywhere near that precision, I figure that this is more than good enough, and if one of these five curves doesn't give me the right feel I can always try another combination of original and squared (or cubed if need be, but I highly doubt that). Running on a pair of CAN-bus nodes, these integer calculations (not just curving for the 2 axes, but deadband, speedpot range setting and different scaling for forward and reverse as well) are still using substantially more time than the CAN messaging, or the rest of loop () for that matter. The more time that is taken for calculating things, the more the joystick will have a rubber-band feel to it, and I don't want that.
Ciao,
Lenny