9
« on: 01:10 PM - 04/07/12 »
Regarding your questions, mouse movements did not feel at all laggy while inside the black dot zone. It's once you're outside the zone that the mouse felt laggy as one would have screen movement for a long length of time after the user stopped moving the mouse.
I implemented the control loop the way you described it, by having a black dot buffer, and removing from it until the max mouse speed wasn't exceeded. This made it feel 1:1 in the angle domain, but very unpredictable in the velocity domain. Overshooting and then correcting took too long, making it impossible to quickly turn around and aim at a target behind you. After this, I also tried removing the feedback when the user is attempting to correct from overshooting: I simply made the app ignore the buffer if the user suddenly changes directions, which allowed one to turn around in one quick motion, and then cancel out of it to regain control over the aiming system. What I noticed was that even then, turning around didn't feel at all natural, still feeling laggy as the system responds to past-time input, and the cancelling feature was easily triggered by accident, removing any apparent advantage.
By the way, the SDK sends raw mouse, keyboard, and joystick data to the XIM. This is then interpreted as if a physical device was sending the data directly to the XIM. All user settings, including smart translator settings, are used to process the input. The XIM requires an extra processing cycle for the SDK, so it halves the processing frequency from 125 Hz to 62.5 Hz. Input is still fast enough for most games.
Let me know if you have any other questions!
Show Posts
