Wiimote Support In Torque?
by Nate Eight · in Torque 3D Professional · 05/18/2013 (9:22 pm) · 8 replies
Hi, Torquers! I'm a lifelong gamer who was inspired by the Oculus Rift to finally try my hand at building some games. I don't have much in the way of experience - I can get Python+wxpython to do useful stuff, and I'm branching into C for Arduino programming, but I've never publicly released any code - so I hope to make up for this with passion, ambition, and wide-eyed experimentation. So far I'm enjoying the journey immensely, and things are only going to get more exciting once I have a Rift and start exploring 3D game design. Torque 3D seems to have a lot going for it, and my first major game project will be to see how far I can get with a Rift-only FPS concept using Torque 3D. Before I really throw myself into that, however, I'm trying to tie up a previous hardware project, and I have a question that relates to both of them: Will Torque ever offer native support for the Nintendo Wii Remote, or has anyone released integration code to accomplish this?
Scoff all you like at "motion controllers" - I tend to believe they'll be far better for all sorts of VR experiences than gamepads and mice will ever be, and with Torque 3D 3.0 offering native support for the Rift, the Razer Hydra, and the Leap Motion, T3D has a real chance of being a major player in what I hope will be the coming VR revolution. Wiimotes are also valuable as VR input controllers because they're cheap, wireless, fairly responsive, and ubiquitous. The primary reason they don't see much use as PC inputs is simply because there isn't much software out there that utilizes them, and only the fringe experimenter types want to bother with alternative Bluetooth stacks and GlovePIE scripts. Apparently, Torque has an official Wii branch for licensed Wii developers - wouldn't it be fairly simple to rip the Wiimote interface code out of that branch and merge it with the new event management code of T3D 3.0, or is all the Bluetooth negotiation required by the PC too much of a headache?
If this isn't something to expect from the GG developers, has anyone else gotten Wiimotes working to the degree that their code is ready to share? All I could find by scouring these forums was one aspirational blog post, Vinh Tran's "preliminary" cWiiMote approach, and Nicolas Buquet's Mac-focused WiiYourself! implementation. These are all half-finished resources from developers who haven't logged in since T3D 1.5 - what is the state of community-driven Wiimote support in 3.0? After much research, I agree with Michael Perry when he says that WiiYourself! is the best Wii library currently available (and being C++ should make integration with T3D fairly painless), but it's been over ten years since I compiled anything and I wouldn't know where to start with this.
Wiimote support in T3D 3.0 is very clearly possible, but is this support planned for official release, successfully hacked in by someone willing to share their code, under development by anyone planning to share their code, or an open problem I'm going to have to clumsily wrestle with myself? Thanks!
Scoff all you like at "motion controllers" - I tend to believe they'll be far better for all sorts of VR experiences than gamepads and mice will ever be, and with Torque 3D 3.0 offering native support for the Rift, the Razer Hydra, and the Leap Motion, T3D has a real chance of being a major player in what I hope will be the coming VR revolution. Wiimotes are also valuable as VR input controllers because they're cheap, wireless, fairly responsive, and ubiquitous. The primary reason they don't see much use as PC inputs is simply because there isn't much software out there that utilizes them, and only the fringe experimenter types want to bother with alternative Bluetooth stacks and GlovePIE scripts. Apparently, Torque has an official Wii branch for licensed Wii developers - wouldn't it be fairly simple to rip the Wiimote interface code out of that branch and merge it with the new event management code of T3D 3.0, or is all the Bluetooth negotiation required by the PC too much of a headache?
If this isn't something to expect from the GG developers, has anyone else gotten Wiimotes working to the degree that their code is ready to share? All I could find by scouring these forums was one aspirational blog post, Vinh Tran's "preliminary" cWiiMote approach, and Nicolas Buquet's Mac-focused WiiYourself! implementation. These are all half-finished resources from developers who haven't logged in since T3D 1.5 - what is the state of community-driven Wiimote support in 3.0? After much research, I agree with Michael Perry when he says that WiiYourself! is the best Wii library currently available (and being C++ should make integration with T3D fairly painless), but it's been over ten years since I compiled anything and I wouldn't know where to start with this.
Wiimote support in T3D 3.0 is very clearly possible, but is this support planned for official release, successfully hacked in by someone willing to share their code, under development by anyone planning to share their code, or an open problem I'm going to have to clumsily wrestle with myself? Thanks!
About the author
Virtual reality zealot, online loudmouth, lifelong gamer, HCI tinkerer, aspiring game developer
Recent Threads
#2
1. Make use of the new input system Dave has added to T3D 3.0.
2. WiiYourself! is still the first library I would try, but I would still do some research first. The Wii homebrew community isn't as big as it used to be, but I'm sure their wikis contain updated information.
3. If any solution still requires bluetooth stack hackery, I wouldn't even consider it. The two Wii remote projects I worked on forced me to use a proprietary installation of a bluetooth stack on Windows Vista. I don't even want to know what kind of problems would be faced with Windows 7 or Windows 8. There are now better input devices that work better than the Wii remotes. If I was doing an internal project for demonstrations, I'd probably be ok with it. However, I would not force that work on an end user.
Not really. That code is actually tightly protected under an agreement with Nintendo. It is part of their official Wii SDK, which cannot be shared with unlicensed developers.
05/19/2013 (8:12 am)
I can't speak for the T3D development team, nor the T3D community. However, here are my notes:1. Make use of the new input system Dave has added to T3D 3.0.
2. WiiYourself! is still the first library I would try, but I would still do some research first. The Wii homebrew community isn't as big as it used to be, but I'm sure their wikis contain updated information.
3. If any solution still requires bluetooth stack hackery, I wouldn't even consider it. The two Wii remote projects I worked on forced me to use a proprietary installation of a bluetooth stack on Windows Vista. I don't even want to know what kind of problems would be faced with Windows 7 or Windows 8. There are now better input devices that work better than the Wii remotes. If I was doing an internal project for demonstrations, I'd probably be ok with it. However, I would not force that work on an end user.
Quote:wouldn't it be fairly simple to rip the Wiimote interface code out of that branch and merge it with the new event management code of T3D 3.0
Not really. That code is actually tightly protected under an agreement with Nintendo. It is part of their official Wii SDK, which cannot be shared with unlicensed developers.
#3
The best way to implement the support that you cannot advertise directly would be to use a third-party homebrew solution as Mich notes.
05/19/2013 (12:55 pm)
As Mich notes, to do this outside of Nintendo's licensing--which means no official Wii support or any trademark usage/recognition on your product, including Wiimote(r) or Wii(r). So, unless you work directly with Nintendo and get a devkit, you cannot legally use any of the NDEV codebase. On top of that, if you did get the license, you would not be able to use it on non-Nintendo devices due to the licensing.The best way to implement the support that you cannot advertise directly would be to use a third-party homebrew solution as Mich notes.
#4
Michael, I agree that a Razer Hydra is superior to a Wiimote in most usage cases, and I love that you GG people are supporting all this tech so enthusiastically. I have plans for at least two games that will use Hydras as their preferred input device, but I still worry that limiting my audience to people who own both a Rift and a Hydra is tantamount to not releasing a game at all. Giving players a second input option, particularly one with 10s of millions of devices in the wild, would seem advantageous. I also see Wiimotes as a potential stopgap solution to the Rift's positional tracking problem, and I'm following the work of some people experimenting with the Balance Board - it is perhaps embarrassing for PC input manufacturers that an officially unsupported Nintendo thing is the best foot controller currently available, but here we are. There's another big reason for my interest in Wiimote integration, as well, but I can't talk about it yet (and it's killing me, ahh!)
I also appreciate the stern warning about PC Bluetooth middleware being a horrific pile of kludgey code whose management should never be forced on end users. I'm in the process of tracking down a cheap Win7 license so I can perform more rigorous testing, but WiiYourself!'s little test app seems to give me results more accurately and reliably than GlovePIE whether I'm using the default MS stack or the slightly superior Toshiba one. BlueSoleil may be better still, but for a commercial game I think it's sensible to draw the line at requiring non-free Bluetooth middleware and/or a certain licensed dongle; even demanding that users switch to the Toshiba stack might be pushing it. I can see a lot of productive non-game uses for what I've built, though, so I intend to continue to pursue this even if it gets a little hacky and complicated to set up correctly.
The good news is WiiYourself! is probably pretty close to good enough if we'll never see "official" Wiimote support in T3D, I'm just not at all confident I'm the guy to tackle this. I think I'll send Nicolas Buquet an email asking what ever happened with his WiiYourself! integration; perhaps I can lure him back here to discuss it. In the meantime, if anyone has a link to a newbie tutorial about recompiling the T3D codebase with third-party libraries, it would save me some searching.
Thanks for the comments, guys!
05/20/2013 (8:15 pm)
Quote:[Wiimote] code is actually tightly protected under an agreement with Nintendo. It is part of their official Wii SDK, which cannot be shared with unlicensed developers.Blarg, I hadn't even considered that there might be a licensing roadblock here, and I've been thinking a lot about hardware licensing issues lately, too. I tend to believe Nintendo's brand would actually be strengthened by providing first-party Wiimote drivers for PCs - they're already used in some teaching applications, supposedly hospitals use Wiimotes for medical computing tasks, and if I'm right about this VR stuff it could even drive a few sales - but the people making the calls at Nintendo seem to be going entirely in the opposite direction with their intellectual property strategies.
Michael, I agree that a Razer Hydra is superior to a Wiimote in most usage cases, and I love that you GG people are supporting all this tech so enthusiastically. I have plans for at least two games that will use Hydras as their preferred input device, but I still worry that limiting my audience to people who own both a Rift and a Hydra is tantamount to not releasing a game at all. Giving players a second input option, particularly one with 10s of millions of devices in the wild, would seem advantageous. I also see Wiimotes as a potential stopgap solution to the Rift's positional tracking problem, and I'm following the work of some people experimenting with the Balance Board - it is perhaps embarrassing for PC input manufacturers that an officially unsupported Nintendo thing is the best foot controller currently available, but here we are. There's another big reason for my interest in Wiimote integration, as well, but I can't talk about it yet (and it's killing me, ahh!)
I also appreciate the stern warning about PC Bluetooth middleware being a horrific pile of kludgey code whose management should never be forced on end users. I'm in the process of tracking down a cheap Win7 license so I can perform more rigorous testing, but WiiYourself!'s little test app seems to give me results more accurately and reliably than GlovePIE whether I'm using the default MS stack or the slightly superior Toshiba one. BlueSoleil may be better still, but for a commercial game I think it's sensible to draw the line at requiring non-free Bluetooth middleware and/or a certain licensed dongle; even demanding that users switch to the Toshiba stack might be pushing it. I can see a lot of productive non-game uses for what I've built, though, so I intend to continue to pursue this even if it gets a little hacky and complicated to set up correctly.
The good news is WiiYourself! is probably pretty close to good enough if we'll never see "official" Wiimote support in T3D, I'm just not at all confident I'm the guy to tackle this. I think I'll send Nicolas Buquet an email asking what ever happened with his WiiYourself! integration; perhaps I can lure him back here to discuss it. In the meantime, if anyone has a link to a newbie tutorial about recompiling the T3D codebase with third-party libraries, it would save me some searching.
Thanks for the comments, guys!
#5
I still regularly keep me informed to what happen on the T3D side of the world, with pleasure :-)
But I don't go to the forums part (no enough time, too much work on the iOS side : I'm essentially doing native C/objective-C dev for iOS nowadays).
I did finalize a wiimote integration that was working on Windows and Mac, that was handling wiimote (acceleration and IR), nunchuk, wii classic pas, wii balance board, a was handling of course multiple wiimotes connection (up to 5; more than that saturate the bluetooth bandwith it seems).
I made it work up to T3D 1.2 (if I recall correctly) and I think it was deployed on win7 computers.
In general, I installed a blueSoleil stack because it was the easiest to use to connect the wiimote to Windows (on the mac side, the connnection of the wiimote was handled by framework and integrated in T3D, so it was simpler for the user, and did permit to handle deconnection/reconnection from within the app).
I'm ok to share my implementation with you, but I will need (I think) to have authorization from GarageGame to share T3D 1.2 source code because it was not MIT code.
Nicolas Buquet
www.buquet-net.com/cv/
05/27/2013 (2:09 am)
Hi Nate,I still regularly keep me informed to what happen on the T3D side of the world, with pleasure :-)
But I don't go to the forums part (no enough time, too much work on the iOS side : I'm essentially doing native C/objective-C dev for iOS nowadays).
I did finalize a wiimote integration that was working on Windows and Mac, that was handling wiimote (acceleration and IR), nunchuk, wii classic pas, wii balance board, a was handling of course multiple wiimotes connection (up to 5; more than that saturate the bluetooth bandwith it seems).
I made it work up to T3D 1.2 (if I recall correctly) and I think it was deployed on win7 computers.
In general, I installed a blueSoleil stack because it was the easiest to use to connect the wiimote to Windows (on the mac side, the connnection of the wiimote was handled by framework and integrated in T3D, so it was simpler for the user, and did permit to handle deconnection/reconnection from within the app).
I'm ok to share my implementation with you, but I will need (I think) to have authorization from GarageGame to share T3D 1.2 source code because it was not MIT code.
Nicolas Buquet
www.buquet-net.com/cv/
#6
Can anyone comment on the sharing and use of 1.2 code in the post-MIT-license world, or at least direct me to the person I should pester for official answers? Even if using Nicolas' work would be legally troublesome, seeing how he pulled it off would be a tremendous help to me, but I certainly wouldn't want to have him share something he's not supposed to. Anyone know where we can go from here?
06/04/2013 (4:47 pm)
Nicolas, many thanks for reappearing and offering up your Wiimote integration! People keep saying this community is one of the most helpful and supportive around, and I'm starting to believe it. Can anyone comment on the sharing and use of 1.2 code in the post-MIT-license world, or at least direct me to the person I should pester for official answers? Even if using Nicolas' work would be legally troublesome, seeing how he pulled it off would be a tremendous help to me, but I certainly wouldn't want to have him share something he's not supposed to. Anyone know where we can go from here?
#7
If you're just sharing your own work then that isn't an issue. If you want to share whole source files from T3D 1.2 that you made modifications to, then that would be a problem. But all you need to do is take one of the MIT version (such as the latest 3.0, or even the first MIT release back in September 2012 as that was based on the 1.2 commercial version) and merge across your changes. Then you would be fine in sharing those.
- Dave
06/06/2013 (12:39 pm)
@Nicolas:If you're just sharing your own work then that isn't an issue. If you want to share whole source files from T3D 1.2 that you made modifications to, then that would be a problem. But all you need to do is take one of the MIT version (such as the latest 3.0, or even the first MIT release back in September 2012 as that was based on the 1.2 commercial version) and merge across your changes. Then you would be fine in sharing those.
- Dave
#8
06/06/2013 (6:07 pm)
Won't get much more official than that. Thanks, Dave - you're the best! I'm hopeful Nicolas and I can work this out soon, perhaps even give his code the proper release it always deserved. I have big VR-related plans for these Wiimotes, and I'm beyond excited to show everyone here what I've been cooking up. Stay tuned! 
Torque Owner Lukas Joergensen
WinterLeaf Entertainment
2nd i like the idea, would prevent you from forcing people into buying a new controller to play your game.