wiiuse
Current Version: v0.12

SourceForge.net Logo
Support This Project (through SorceForge)
GPLv3

Random Projects Using wiiuse
See More
Wiiuse is a library written in C that connects with several Nintendo Wii remotes. Supports motion sensing, IR tracking, nunchuk, classic controller, and the Guitar Hero 3 controller. Single threaded and nonblocking makes a light weight and clean API.

Licensed under GNU GPLv3 and GNU LGPLv3 (non-commercial).
Website downtime
Posted by para on 10 Oct 2008 at 22:52
We had some website downtime recently when sourceforge (the hosting company) moved datacenters. The move appeared to have changed the PHP version, and a single line in one of the php files was no longer valid syntax. wiiuse.net also uses the Smarty template engine which requires some directories be set with certain permissions -- these directories had to be recreated as the datacenter move didn't copy everything. During the move, sourceforge disabled their shell account which I had been using for file management, and I was unaware until recently that sftp was available instead.

But, as you can see, we're back up and running now. Yay.
[ 1 comments | Add comment ]

libogc rolls out wiimote support
Posted by para on 09 May 2008 at 16:23
Shagkur has been working pretty hard on porting the lwbt bluetooth stack and wiiuse to the Wii, and making them work in combination. It seems as though the day has come, and wiiuse is now part of libogc (it's in the CVS). Wiimote support should now be stable and ready for integration into homebrew apps. Wiimote support is exposed in libogc as a set of WPAD_ functions.

Shagkur did all the work here -- from porting lwbt, to choosing wiiuse as the wiimote support, to making significant core modifications to the wiiuse library to make it compatable with the bluetooth stack. Thanks to all his hard work, it's awesome to see wiiuse being used on an even wider variety of platforms and benefiting even more developers.

There is still an issue with the Y coordinate from the pointing system (ir.y). I will take a look at this and get a fix submitted asap. Until it is fixed, you might try using the first IR dot (ir.dot[0].x/y). There may also be an issue with the IR cursor being a little rough (first noticed in dhewg's scummvm port). I hope to fix this, or at least improve it, soon. There are also some other minor features that are missing from wiiuse in general that I would like to begin working on as well; in particular Mii and Balance Board support (I don't have a board yet being here in the states).

Big thanks to Shagkur and dhewg for the development work and the testing.

If you notice any bugs other than what was said here, please let me know.
[ 6 comments | Add comment ]

Wii?
Posted by para on 20 Apr 2008 at 16:36
If you aren't aware, a lot has been going on in the Wii homebrew world recently. It started with Bushing, segher, and tmbinc cracking open a Wii and doing what they called a 'tweezer attack' on it. The attack involved effectively shorting a circuit that allowed them to dump some memory (using GameCube homebrew code) that was normally locked out when entering GameCube mode (the Wii has 'Wii mode' and 'GameCube mode' for backwards compatibility reasons with GameCube games). There's a video of Bushing talking about it here from the 24c3 a few months ago. With this memory dump, they extracted some system keys that can be used to encrypt, decrypt, and sign various system files.

They have an amazing understanding of reverse engineering and were able to find a couple of bugs (and probably a lot more that they haven't told anyone about). Two in particular were a buffer overflow with Zelda Twilight Princess, and a bug in the way Nintendos signing algorithm works. Using these newly found holes they were able to create an exploit titled the Twilight Hack, a Zelda save game (the signing bug is not used on the save game file) that uses a stack smash to overflow the horses name and take control of the system. Homebrew was made possible with this exploit.

The Wii is a lot like a GameCube, and GameCube homebrew has been around for a while. Shagkur -- author, developer, and maintainer of the libogc project (which is available under DevKitPro, a toolchain project managed by WinterMute) -- has been working recently on expanding libogc (the unofficial GameCube SDK) to include Wii support. Within the past few weeks he has added bluetooth support to libogc. As a proof of concept, and to test that the bluetooth stack functioned correctly, he ported wiiuse to the Wii. All went well and it seemed to spur a roar in the homebrew community, up until then no one had touched the wiimote in any homebrew applications.

Shagkur informed me of his work and I was obviously very excited. The bluetooth stack (lwbt) was added to the libogc CVS, and immediately a couple of other wiiuse ports popped up, most notably Rhys's (which was very clean and #ifdef'ed). I started with Rhys's since it was a pretty good base. I reworked most of what he did, and started fixing bugs where wiiuse didn't port over so well (not everything worked right off the bat).

Rhys gave his port to a couple of other people, and it leaked around to various developers in #wiidev. Now I have no problem with that at all, hell the code is freely available here at wiiuse.net, but as it turned out people began adding wiimote support to their applications without realizing it was unstable code -- wiiuse can (and very well may) crash at any given point. The reasons for this I won't get into, but the current state is no wiimote support for the Wii is considered stable yet.

At first everything appeared to have ported over very nicely to the Wii, except for IR. Enabling IR crashed (or froze) the Wii console. The bug turned out to be beyond my ability to find, much less fix. A crude work around was first introduced by NoNameNo, who wrote some nice looking code called GRRLib. Now by looking at his code I can say he's a fine coder, but he didn't understand wiiuse to the point that he knew why his work around worked, much less what the actual problem was. He told me what his method was (which I had already known but had not released) and it was pretty much as I expected, it worked but it was extremely unstable. I should point out that by 'unstable' I mean that I could get the 'work around' to function properly almost 100%, but afterwards the state of the application could degrade suddenly and without warning.

Another problem NoNameNo ran into was that he couldn't get 2 IR sources to work with calculating the cursor position. So his demo releases (which he, IMO, incorrectly labeled as 'proof of concept') used just the first seen IR dot (dot[0].x and dot[0].y) for cursor position. I took a look at this and found the issue -- there were actually 3 problems which I was able to correct. IR calculations on the Wii can now correctly use 1 or 2 IR dots (just like the Linux and Windows versions).

Now the wiimote, and more specifically IR support, seems like a big deal with the homebrew developers. So NoNameNo released GRRLib (which is a set of a dozen or so frame buffer rendering functions) along with Rhys's wiiuse port. There was some confusion as to where the wiimote support actually came from, and many believed it was from GRRLib since it was the first to make a public release. Now I don't so much care about that, but what I was concerned with was NoNameNo did not say that the wiimote code was unstable. Being a full release (GRRLib v2.0) it can be assumed the entire code base should not be experimental, but that is not the case. As I said before, any and all wiimote code currently in use on the Wii is not stable. This is one of the reasons I didn't release anything yet -- I don't want people to start using wiimote code only to have their applications crash and find themselves scratching their heads for hours trying to figure out why. I knew this would happen, so as soon as I saw NoNameNo had started releasing demos I asked him not to release any wiimote code until it was ready. He agreed, but a week later the code was released anyhow. Debugging on the Wii is hard enough (it's made easier with the USB Gecko) especially given the actual bug is very obscure, a back trace will just lead you in circles unless you are as familiar with the microkernel (libogc) as shagkur is. I have no doubt that there are people out there right now who are trying to debug problems with their programs and do not realize the actual issue has to do with wiimote support -- this is exactly the type of thing I didn't want to see happen. It would have been better to wait until it was stable and make an official public release for everyone to use.

So, after having said all of that, the wiiuse port is still under way. Now that I have fixed the IR issue, I decided it was time to show a little (unstable) demo. I took the asteroids game, written by Andy Sommerville (aksommerville) and available here, and added wiimote support to it. Rather than use the GameCube controller to turn and shoot the space ship, you can use point and click functionality with the wiimote :) The download is on the same page as the original source.

edit: I should clarify a few things.

I am not saying not to use wiiuse (I want you do, that's why I wrote it), but just be aware it is not stable and could cause issues.

Secondly, I feel some thanks are in order.
[ 2 comments | Add comment ]

Version 0.12 Released
Posted by para on 03 Apr 2008 at 01:46
Wiiuse version 0.12 has been released.

This release includes minor fixes. The most interesting part is the change in the licensing. See below for details.

ChangeLog:

Added:
Fixed:
Changed:
Download it from http://sourceforge.net/project/showfiles.php?group_id=187194.
Documentation has been updated at http://wiiuse.net/docs/.

License Changes

So I've noticed there are some projects (even some talked about here) that appear to be breaking the license for wiiuse. Since up to this point the only option was the GNU GPLv3, that meant that anything you've written that uses wiiuse had to also be GNU GPLv3, thus being free and open source. I realize that this is not what many of you want, so I'm granting the option to use the GNU LGPLv3 license instead if you so choose. I encourage you to use the GPL if you can, because open source lets other people improve upon your work and continue to fix bugs if you or other maintainers should abandon the project for whatever reason, the software does not have to simply die out.

The new license option has a condition that it can only be used for non-commercial and non-proprietary programs. In a nutshell, the LGPL will allow you to use wiiuse in a closed source (non-commercial) program with the exception that any changes made to wiiuse itself must also be released (if any, like the GPL) if you release the modified object code.

I feel these licenses will give everyone much more flexibility while still keeping wiiuse free and open for everyone to enjoy.

Please let me know if you have any questions and I will be happy to answer them.

Until then, enjoy v0.12.
[ 6 comments | Add comment ]

Java wrapped, WiiuseJ
Posted by para on 11 Mar 2008 at 18:07
guiguito has written a Java API, WiiuseJ, that wraps and binds wiiuse for Java developers.

Check out the WiiuseJ homepage for downloads and more information.
There is also a thread here on the forums.
[ 4 comments | Add comment ]


Archived News [ 27 topic(s) not displayed ]