Some Suggestions

[Ryochan7]

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.

1. 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.

2. 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);

3. 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.

4. 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

5. 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

[jsbackus]

Helloooo @Ryochan7! Good to hear from you! Thanks for the input - very helpful.

Re: vmulti - interesting! I wasn't familiar with the project, beyond references in the code. Yeah, I think that would be a very useful feature to get working. Not surprised if performance seems a little better. SendKeys / SendInput, etc. have to go through all kinds of security checks each call.

Re: mouse improvements - very, very helpful. Thanks! I haven't even started trying to wrap my head around how all of that works. No worries re: foul language. I figure if Microsoft can get away with it, we all deserve a little slack. Bonus points for incorporating BACON into your debug code. 😃

I've created separate issues so that we can tackle these one at a time. We'll try to get as many of these in the next release as we can.

If you have a moment, I'd like to pick your brain regarding XInput vs. DInput (#21). Any thoughts on how we can transition a DInput profile to XInput? Do you remember if there is a way to force SDL to use DInput even when XInput is available?

Thanks again for your input and insight. Please feel free to jump in anytime!

[Papermanzero]

@Ryochan7
Thanks a lot for the suggestions. :)

I have also a question with regard to the Wiimote. I saw your Youtube Videos which are amazing.
Do you plan to release an application to configure the Wiimote on the PC (something like Antimicro, however only for the Wiimote)?

[Ryochan7]

@Papermanzero

Probably not. I don't have a real need to make a new project for using the Wiimote. MoltenGamepad works fairly well although it can be a hassle to keep recompiling in order to test different settings. Touchmote was decent but that project is hardly ever active and there are some pressing problems with the software that should have been fixed a while ago. I should upload a patch for MoltenGamepad at some point so people can test the changes for themselves.

Getting more use out of my Wiimote has been a good thing. My TR Wiimote got more use in 2016 than my Steam Controller. The last game I ended up beating with the Wiimote was SOMA. Although, some changes made to the Kozec sc-controller program has now made the Steam Controller a much better option than it was before; I pretty much gave up on Valve's implementation a long time ago.

[Papermanzero]

That's a pity. I saw already MoltenGamepad and your improvements, however it is only for Linux.
I know that the Wiimote has a lot of potential, unfortunately it is currently unused.
Therefore I am looking for years for a solution which can be used for Windows/Linux(Mac).

[Ryochan7]

It is too bad that support for the TR version of the Wiimote is spotty at best on Windows. Neither the working versions of WiimoteLib nor Wiiuse can obtain the data from the gyro. Although IR mode can work I much prefer to use the gyro. Getting an older Wiimote and the dedicated Motion Plus extension is an option but I like the TR remote and I would prefer to use that instead. The TR Wiimote works on Linux natively so I am able to play a majority of what I would want to play with it.

[Papermanzero]

Yes, I saw that in your videos and I am still amazed.

In general an approach to configure the wiimote in 3 ways would be great.

• An absolute system based on the pointer (which is useful for strategy games or RPG games)
• A relative system based on the pointer (the metroid prime 3 approach, which you implemented in Touchmote)
• A relative system based on gyro (Skyward Sword solution)

However all three systems have to be configurable e.g acceleration and sensitivity. An antimicro solution would be great. This is what no other available solution can provide. However I see the main issue in the remote data which is strongly depend on the Bluetooth stack and the driver. Julian Loehr wanted to extend his project to exactly provide these possibilities.
https://github.com/jloehr/HID-Wiimote
However (as usual) time is missing.

The wiimote is pretty special as controller and has a lot of potential (especially the combination of gyro and pointer). However unfortunately nobody is using it.