For simulating mouse movement on windows would it be better performance-wise to move the cursor to absolute coordinates or to move it relative to it's previous location?
Obviously if moving to an absolute location each pixel in between must also be reached.
It would make more sense if you move it relative. Why would you want to move it absolute?
Well I'm mapping from my xbox 360 controller to mouse movement, and I'm not satisfied yet. I've already done it using relative.
The xbox 360 controller thumbstick coordinate system is a pretty standard 4 axis.
32767
| Quadrant One
|
-32768 ---- 32767
|
|
-32768
The strategy I'm considering is retrieving the X and Y values from the controller, and then mapping it to a different coordinate system based on the sensitivity. This coordinate system value will be used to move the cursor--I don't know how yet, could be a number of pixels at a time or by moving 1 pixel at a time in a loop with a high resolution timer. I was considering moving more than one pixel at a time.
Y max
| Quadrant One
|
-X max ---- X max
|
|
-Y max
The basic problem (for me) when simulating mouse movement is determining the measure of mouse movement wrt to time. I have considered Pixels Per Second as the proper unit of measure, but that may mean I need a high resolution timer (moving 1 pixel will boil down to me "sleeping" the loop for less than a millisecond) but it now seems that the count of pixels moved in one millisecond would avoid needing the high resolution timer. I also need to know the expected range of PPS settings, which I don't know.
Another consideration is how the PPS value is to affect the sensitivity, in a previous implementation I used the graph of (X^2)/SENSITIVITY to provide a nonlinear sensitivity feel. The graph of X^2 / SENSITIVITY has a special property that when viewed in a SENSITIVITY by SENSITIVITY viewing window the parabola touches the upper right corner of the viewing window giving the maximum value available at it's highest point.
ok stuff like this might be a little test and trial. But how about saving three states, previous mouse position, post mouse position, and time interval of movement. This way you can derive the rate at which the user locks the stick in a position. Then use that information to transform it into mouse speed.
When your mapping it into the screen, are you using windows for manipulating the mouse or are you using other libraries? How about having a matrix that transforms logical position into pixel position( ex. (0,0) map to pixel (x0,y0) and (1,1) map to pixel(x1,y1) ) but you need to take into account the viewing perspective to differentiate the length between the amount of pixel from x = 0 to x = 1( assuming x is horizontal axis). This is what essentially opengl does.
And there might be libraries out there that takes care of this for you already so check that out as well.
ok stuff like this might be a little test and trial. But how about saving three states, previous mouse position, post mouse position, and time interval of movement. This way you can derive the rate at which the user locks the stick in a position. Then use that information to transform it into mouse speed.
When your mapping it into the screen, are you using windows for manipulating the mouse or are you using other libraries? How about having a matrix that transforms logical position into pixel position( ex. (0,0) map to pixel (x0,y0) and (1,1) map to pixel(x1,y1) ) but you need to take into account the viewing perspective to differentiate the length between the amount of pixel from x = 0 to x = 1( assuming x is horizontal axis). This is what essentially opengl does.
And there might be libraries out there that takes care of this for you already so check that out as well.
Does that mean my sensitivity settings are a length of time?
>Definitely using Windows SendInput
I'll consider this, because ultimately the implementation doesn't matter as long as the user likes using and it is customizable.
Well yea. If the user moves the stick from initial position to end position in a fast time, then you would expect the mouse to move in a fast time as well, right? Its like the mac, touch pad; touch the pad at one position, and quickly move it to a destination , then the mouse would have to quickly move to the destination as well right? And if the user slowly moves the the stick then the mouse should move slow as well right?
Well yea. If the user moves the stick from initial position to end position in a fast time, then you would expect the mouse to move in a fast time as well, right? Its like the mac, touch pad; touch the pad at one position, and quickly move it to a destination , then the mouse would have to quickly move to the destination as well right? And if the user slowly moves the the stick then the mouse should move slow as well right?
Yes you are correct, that was a consideration I had forgotten, as well as the aspect ratio correction. Originally I didn't think the quickness of the thumbstick movement would matter.
If you have an xbox 360 controller connected to your PC you can try my previous implementation to get a feel for what it currently is like. http://sourceforge.net/projects/xinmapper/
Unfortunately, I don't have one. Good luck with your project, sounds interesting.
Oh I almost forgot, I would like some opinions on how to write a design for implementing this.
So far I have a few classes in mind, but I don't think it's adequate.
1.
struct MouseMoveInfo
-data members:
unsigned ppsX, ppsY, pixelTimeX, pixelTimeY;
-member function:
void CorrectAcceleration(MouseMoveInfo &previous)
2.
class XInputMouseTranslator
-Prepares a MouseMoveInfo containing a translation of X and Y values to their Pixel-Per-Second values taking into account the aspect ratio of the screen. Also used for relevant time per pixel details.
3.
XInputMouseMapper
-Responsible for acting upon information in a MouseMoveInfo structure, stores the previous MouseMoveInfo and can be set to correct for acceleration.
They will work in the following manner:
[XInputMouseTranslator] -[MouseMoveInfo]-> [XInputMouseMapper]
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.