IR-Mouse and Gamepad simultaneous

larsiusprime commented 9 years ago

If possible, it would be great to have the IR Camera pointer mapped to two independent analog axes, would be most useful in "just wiimote" and "wiimote + nunchuk" combinations. Not really necessary for pro controller if the two analog sticks are eating up axes, though if there's room would be good there too in case you need to quickly use the wiimote as a screen pointer to click something.

jloehr commented 9 years ago

The idea is good, especially in the Wiimote + Nunchuck Combination and the option to have it as separate mouse device. With #3 and its custom mapping this is going to be possible.

But currently there are some contras for implementing it right away:

Battery Drain: The IR-Camera has a certain battery drain, so having it always active, even when it is not used is not good for the battery life.
You can't control the screen pointer, unless the program/game implements it or it is exposed as a mouse device by my driver (like the IR-Mouse Version). But then again, you would have another mouse device that might report an input, when the user doesn't want to. There are a lot of natural and other IR-Sources, so having it active all the time might confuses and frustrate normal users.

larsiusprime commented 9 years ago

Ah interesting, I didn't realize that it was a battery drain! Is it possible to turn it on and off via the driver? Or does that require the separate configuration tool?

Having it as a "true" mouse device would certainly be cool, but isn't 100% necessary (for my purposes at least). For our own API, if we can just get the X/Y inputs as separate axes we can rig up a "virtual" mouse pointer that's just as good as the real thing, or alternatively let the game programmer decide how they want to use those inputs.

jloehr commented 9 years ago

With the Config Tool it would be activated when there is a mapping/it is used.

However, this is not a API nor library, but a device minidriver that is serving the HID Class driver. The HID Class driver in turn exposes the device as interface, which can be accessed through either DirectInput or the Usermode HID API.

The purpose of HID and DirectInput is to abstract from the specific device and just have a generic API/Specification to serve several different device layouts. So every device has its own buttons and inputs.

I have to point out that the Wii Remote does not conform HID therefore not all of its features can be mapped to HID. Especially it is not possible to expose all its inputs at once.

When you need to use the specific Wiimote Features and you know the device is a Wiimote, i strongly recommend to use a Wiimote Library which exposes all the Wiimote Features.

Again the purpose of this driver is to make the Wiimote accessible by the DirectInput (and later Xinput), so it can be used by games that do not have build in Wiimote Support.

larsiusprime commented 9 years ago

Cool, I understand. I think this should be more than necessary for my purposes, just trying to get a feel for where the boundaries are. As for a Wiimote library, do you know of any? I've searched before but been unable to find anything, perhaps I've just been looking in the wrong places.

jloehr commented 9 years ago

http://wiibrew.org/wiki/Wiimote/Library lists some

larsiusprime commented 9 years ago

Thanks, this one looks neat: http://wiiyourself.gl.tter.org/

jloehr / HID-Wiimote

IR-Mouse and Gamepad simultaneous #8