WiiJuce 0.2 released


2007-11-29 Johan Euphrosine proppy@aminche.com

* Release 0.2	
* platform_specific_code/wiijuce_linux_bluetooth.cpp (class LinuxBlueToothDevice):
set LinuxBlueToothDevice sockets to nonblocking mode

2007-11-19 Francis Maes francis.maes@gmail.com

* wiijuce_WiiRemote.cpp, wiijuce_sample.cpp, wiijuce_gui.cpp:
Add IR sensor support

2007-11-19 Johan Euphrosine proppy@aminche.com

* Add comments and references
* COPYING: Switch to GPLv3
* README: Add Credits section

The coding style and philosophy match JUCE code base.
The threading code, and the gui code strongly rely on JUCE classes.

Did you see these videos about the other secrets of the Wiimote.
Videos on how to use the build in infrared camera of your wiimote.

some really wicked stuff.


Hey there!

I just had a play with your Wii code, and though I’d give a few comments.

First of all, I think you should definitely rethink the way you’ve put everything into the Juce namespace. That’s really reserved for Juce classes and code, and this certainly isn’t part of it! There’s really no need to put it in there, so I’d remove all the JUCE_API and namespace stuff from it.

The other thing is that it doesn’t really seem to actually follow the Juce style like you say - the way it interacts with the bluetooth base isn’t really clear at all. I hope this doesn’t sound like I’m being cruel or anything - you’ve done a great job! It’s just not particularly clear how to actually use it.

I’ve dug out my own Wii code again; my new job has me actually developing games for the Wii, so it’s beneficial to be able to experiment with the remote at home away from my devkit. I’m going to have a go at merging our ideas and code, to see if I can get something a little easier to use. When I think of a ‘Juce style’ system, I imagine something like the audio/midi classes; just open a device and use it. For example,

WiiMote* wiimote = WiiMote::openDevice(0);

… where everything else is hidden. This is the sort of thing I’d had going before, but it looks like I need to grab the DDK again as I’m missing some headers.

I imagine I’m probably missing something though - I haven’t had the longest look at your code yet [I will be looking closer later this weekend], so please let me know if there’s a straightforward way of using it!

I hope this doesn’t read like I’m panning your work, as I’m really not. I’d just really like to get it to a point where it really is as simple as the rest of the Juce stuff is.

Hi haydxn,
Nice that you are able to develop games for the Wii. I did a lot of little projects with the Wiimote and at my studio we play Wii tennis after every lunch :wink:

Anyway, im really interested in the Wiijuce framework, so if you can get it up to Juce standards that would be great.
Let me know if you need someone to test.



Thanks for the intereset you put into wiijuce,

I’ll definitly agree that the higher level of the API has been rushed and has to be given more love.

Your suggestions makes a lot of sense (patches welcome):

  • Using a separate namespace.
  • Using openDevice static method, to be able to connect without dealing with enumeration.

If you want to start something of your own, I think that you could make a good use of the lower stack self contained in:

  • It has low dependencies upun juce (only for thread and error message IIRC).
  • And provides plain C low level fonction (read/write/open/close) to the wiimote for each plateform,

Feel free to report your progress here.

…anyone still working with this? I made my own simple Wii remote code based on the DarwinWiiremote stuff (actually, the MaxMSP/pd object port) but that’s Mac-only.

BTW I get linker errors due to duplicate “Warper” class defs, just #include-ing “wiijuce_Warper.h” sees to fix that instead of the duplicate def but perhaps there was a reason it was like that?