wiiuse Forums

Here's my modest submission of a WIN32 program that allows the Wiimote to serve as a limited function mouse - plus C source code! Get it at:



You'll need the IR light bar.

First start the program, a WIN32 console application with no command line arguments. The B button toggles the driver state (Wiimote controlled on or off). The A button functions like the mouse left button. The Home button exits the program.

You'll find that even with averaging the position stream, the Wiimote is a poor pointing device compared to a mouse.

Thanks Para for the great library.

Enjoy, John Speth.

did you think this [1] when you wrote the wiimouse driver?

fedda

[1] http://blogs.msdn.com/coding4fun/archiv ... 84678.aspx

Thanks for pointing me to the MSDN article. The missing piece to the puzzle as I've implemented it is the "dead zone" processing. I did the poor man's version using a small boxcar filter. Regrettably, I'm no haptic device expert. Obviously, the Wii does some extra mouse position processing because it's much more stable than my mouse driver.

JJS

I haven't had a chance to look at it yet. What is the problem?

> I haven't had a chance to look at it yet. What is the problem?

The problem is that the raw data stream is noisy and, without some special filtering that the MSDN article describes, the mouse position will be shakey. That observation has been mentioned on other references to a Will mouse driver on the web (no web page to cite tho).

I think the missing piece is the dead-zone filter that will completely ignore noise (seen as tiny mouse movements) when the cursor is only moving a little bit (probably not moving at all as intended by the user). When the user wants to move the mouse (identified by large mouse movements), the dead-zone filter is relaxed and the shakiness is tolerable and not so noticeable. I wouldn't be surprised if the common desktop mouse is also subjected to similar processing.

JJS

What resolution is your screen? I'm guessing you changed it with wiiuse_set_ir_vres() to be higher?

The IR support was not designed to point on higher resolutions than a TV -- I don't think any filtering algorithm you use is going to fix this.

Think about it like this, you have a 100x100 screen resolution, and the wiimote has a 100x100 resolution camera. If you move the wiimote enough then the IR sources the camera sees will move 1 pixel, so you can move your mouse 1 pixel. Now suppose you have a 500x500 screen resolution, but the wiimote still has a 100x100 resolution camera. You move the wiimote enough and the IR sees a movement of 1 pixel, your mouse cursor has to move 5 pixels in order to maintain the same ratio. Now you have a 'skip' in your movement. You are basically expanding a single dot into a small 5x5 square, but your mouse can only ever be on one of the corners.

As others have suggested, yes you could interpolate between point A and point B so the mouse appears smooth. However this is merely a visual trick, there is still a 'grid' of positions your mouse can be on, you won't be able to stop the cursor between the points on that grid. If you've ever played any of the old Mario games where you move around a world from level to level based on a path, it would be like that. You can move Mario from one level to another, and the game interpolates his position between those two points, but you can not stop along the path at any point, you must continue until you get to the next level.

The cost of upgrading to a higher resolution camera was probably too expensive for Nintendo to maintain the low price of the console, and since the Wii doesn't output in high definition anyhow the wiimote was perfect for that screen size. The wiimote does not scale up on the PC very well, and never will IMO.

edit: I may have misunderstood your question, the article linked does not use any IR tracking: