I'm sure I will get flack from some disingenuous people and the Wiimote brigade but here it is. Some of these suggestions come from experimenting with the Wiimote and the Steam Controller.
- Make vmulti support work again for Windows users
This one is my fault. I had been using a customized version of vmulti and I had been building antimicro using that VID+PID combination. Because of this, I was the only person who was ever able to use vmulti support. It is a great driver and it can be used to work around many problems that the SendInput implementation has; I had come across the driver while playing with Touchmote. Some of the benefits are being able to work with games that use HackShield or equivalent anti-cheat software without worrying about getting banned (seen as a real KB+M), working through UAC prompts, and not having to worry about running antimicro as the administrator for some games. Performance seems to be a little bit better as well but that could just be my perception. The main downside is that some multimedia keys are not mapped in the vanilla driver and that is why I was working on a custom version of vmulti.
- Cut off mouse distance remainder
To help smooth out the mouse pointer, cutting off the remainder used for mouse distances is a technique that can be used. The only version I had left in my local copy was a full remainder cutoff version so I don't remember what a good value is. Example of what to use in the JoyButton::moveMouseCursor method. In this example, the remainder would be cut off at every hundredth of a pixel; 100 would be a full cutoff.
finalx = finalx - (fmod(finalx * 100.0), 1.0) / 100.0);
- Make mouse distance limit event handler dependent
While experimenting with vmulti initially, I had seen that the relative mouse distance is stored in the report as a single byte. That is why the movement range of [-127, 127] was initially implemented in the JoyButton::moveMouseCursor method. However, it seems that restriction is not the same with all backend implementations that antimicro supports. It seems that the limit information should be stored in the event handler and the program should use that info instead of using one set value.
- Add mouse distance offset
While experimenting with the Wiimote, I had seen that the very low end seemed a bit sluggish even when using a high sensitivity. I wanted the cursor to be fairly smooth even when moving the Wiimote slightly past the assigned dead zone. The solution to the problem was to add a small offset for mouse movement so that the curve does not start at 0.0. That suggestion later helped with the Steam Controller as well. I had been using a slightly higher value for antimicro while I was experimenting with it before but the current value of 0.025 feels pretty good. Here is an example of what to include in the JoyButton::mouseEvent method.
double currentoffset = 0.025;
distance = (mousespeed * JoyButtonSlot::JOYSPEED * timeElapsed * .001 - currentoffset) * difference + currentoffset
- Change delta acceleration
This one had been asked about previously. I had played around with a looser implementation of delta acceleration. Right off the bat, I can't even remember the justification for what I did. I did not leave any comments either. The one thing that I can remember is that no additional acceleration offset is added while moving along different zones anymore; the additional offset made mouse movement too loose. I think the main change on continuing acceleration along one zone was how the low end cutoff works. The tweaked version has caused the range to be extended. I have included a diff based on an old commit before I quit this project. Beware of colorful language.
https://dl.dropboxusercontent.com/u/31073509/antiroughchanges.diff
I'm sure I will get flack from some disingenuous people and the Wiimote brigade but here it is. Some of these suggestions come from experimenting with the Wiimote and the Steam Controller.
This one is my fault. I had been using a customized version of vmulti and I had been building antimicro using that VID+PID combination. Because of this, I was the only person who was ever able to use vmulti support. It is a great driver and it can be used to work around many problems that the SendInput implementation has; I had come across the driver while playing with Touchmote. Some of the benefits are being able to work with games that use HackShield or equivalent anti-cheat software without worrying about getting banned (seen as a real KB+M), working through UAC prompts, and not having to worry about running antimicro as the administrator for some games. Performance seems to be a little bit better as well but that could just be my perception. The main downside is that some multimedia keys are not mapped in the vanilla driver and that is why I was working on a custom version of vmulti.
To help smooth out the mouse pointer, cutting off the remainder used for mouse distances is a technique that can be used. The only version I had left in my local copy was a full remainder cutoff version so I don't remember what a good value is. Example of what to use in the JoyButton::moveMouseCursor method. In this example, the remainder would be cut off at every hundredth of a pixel; 100 would be a full cutoff.
finalx = finalx - (fmod(finalx * 100.0), 1.0) / 100.0);While experimenting with vmulti initially, I had seen that the relative mouse distance is stored in the report as a single byte. That is why the movement range of [-127, 127] was initially implemented in the JoyButton::moveMouseCursor method. However, it seems that restriction is not the same with all backend implementations that antimicro supports. It seems that the limit information should be stored in the event handler and the program should use that info instead of using one set value.
While experimenting with the Wiimote, I had seen that the very low end seemed a bit sluggish even when using a high sensitivity. I wanted the cursor to be fairly smooth even when moving the Wiimote slightly past the assigned dead zone. The solution to the problem was to add a small offset for mouse movement so that the curve does not start at 0.0. That suggestion later helped with the Steam Controller as well. I had been using a slightly higher value for antimicro while I was experimenting with it before but the current value of 0.025 feels pretty good. Here is an example of what to include in the JoyButton::mouseEvent method.
This one had been asked about previously. I had played around with a looser implementation of delta acceleration. Right off the bat, I can't even remember the justification for what I did. I did not leave any comments either. The one thing that I can remember is that no additional acceleration offset is added while moving along different zones anymore; the additional offset made mouse movement too loose. I think the main change on continuing acceleration along one zone was how the low end cutoff works. The tweaked version has caused the range to be extended. I have included a diff based on an old commit before I quit this project. Beware of colorful language.
https://dl.dropboxusercontent.com/u/31073509/antiroughchanges.diff