Prev/Next Blog
by date

TGWii Code

Name:	Rob Terrell
Date Posted:	Apr 08, 2007
Rating:	4.5 out of 5
Public:	YES
Comments:	YES
RSS Feed:	or Subscribe with .
Profile Page:	View profile page for Rob Terrell

Blog post

TGWii code! My apologies to anyone who was waiting for this. My original plan was to make a resource that was complete (i.e. support the nunchuck) and more abstracted (i.e. so Windows code could be easily added). However, other stuff in life forced their way up the priority queue, and it's taken me this long to get free and think about this again. I just sent my code to Vinh Tran, who's been kicking ass on the Windows Wiimote side. I've asked Vinh to work together on a cross-platform resource.

And, in case I disappear for three months again, I'm posting the code I've got so far.

This is based on code from the DarwinRemote project (on sourceforge). They did all the hard stuff; I just bolted it onto Torque. It's not imported into the project as a framework. I was mucking around inside some of the DarwinRemote code to fix a scaling bug they had, and it was simpler to just import it all and trace through their code.

I'd like to abstract the engine-level interfaces to the point where the code for each platform's wii controller implementation can be in a single file, for each platform's target. Perfectly obvious, right, but I didn't make it work that way from the get-go.

In macCarbInput.cc I added a call to my wiiMote_kickstart() in Input::Init(). wiimote_kickstart() sets up the cocoa stuff (basically, it allocates an autorelease pool for cocoa objects) and starts the bluetooth device discovery. It would probably make more sense to enable this via script. This is to support Cocoa objects from Carbon, because the DarwinRemote code is Cocoa, and TGE is Carbon. (Mac OS X has two APIs -- Cocoa is Objective-C and Carbon is C/C++).

There's a callback from the bluetooth stack when data is received; when that happens, I call into a function I added to macCarbEvents.cc:

void _OnWiiData(float mdx, float mdy, bool aBtnDown, bool aBtnUp, bool bBtn)

The X and Y values are posted to the Game's event queue. The A button is mapped to KEY_BUTTON2 and the b button is mapped to KEY_BUTTON0. Up and Down events for the A button are fired into the queue separately; for the B button, a down and then an up is queued automatically. (This is because, if the first method is used for a button, that button can't be used for walking; if the second method is used, that button can't be used for firing.)

It probably makes sense to map the coordinates to Joystick events, but the Joystick functions are noops in the Mac code, and I would need to understand the Windows input code better before I could try to make that work.

I'm not sure what should be exposed to scripts. I do have a function for rumble exposed to scripting:

extern wiimote_rumble ( double l );

In my TGWii demo, when the player takes damage, he gets a rumble.

The code is here: robterrell.com/Wiimote.zip

I guess that's it. Keep an eye out for any progress from Vinh or myself.

Recent Blog Posts

List:	08/09/08 - iPhone games! 04/08/07 - TGWii Code 12/21/06 - Wii Remote Beta Binary 12/18/06 - Wii Remote + IR Sensor Bar 12/15/06 - Wii Remote Control in TGE is Working

Submit your own resources!

Matt Troup (Apr 08, 2007 at 07:31 GMT)

Just wanted to say thanks. I'm not a true programmer myself, but I do my best at scripting thanks to Torquescript. I'll say you were the last domino to fall and talk me into getting a macbook, which I now have OSX/Windows running just fine together. I've toyed around with the TGWii demo, and I can't wait to see what's in store for this code. Hopefully I can offer some insight at the very least as to what useful functions would be to expose to script, or possibly what other demos would make good use of the script for demonstration purposes (killer kork can make things a bit hairy if you're trying to test out this or that).

Rob Terrell (Apr 08, 2007 at 20:15 GMT)

In case you need a little more help getting started -- you can add these files to your stock 1.5 project, replacing the old files with the same names (haven't tried with 1.5.1 yet, I assume a quick diff would work for that). You will need to turn on the Objective-C++ compiler for "macCocoaWii.m" -- you can do that by getting info on the file in the XCode project window and changing the associated compiler for the file.

I used starter.fps for the mod. I added in the Killer Kork resource to give you something to shoot at, and also threw in some rumble on damage. That would be on Line 855 of /server/scripts/player.cs:

wiiRumble(%flash);

Also, I made some GUI screens at startup that tell the player to press the Wii remote connect button, etc. That much you probably already know how to do. For fun, I also threw in the TGWii icon that I made, because I spent way too much time on it.
Edited on Apr 08, 2007 20:18 GMT

Matt Troup (Apr 09, 2007 at 02:10 GMT)

The damn cool icon didn't go unnoticed.

Clint Herron (Apr 09, 2007 at 16:33 GMT)

Thanks so much, Rob. :) I think all the work you did on this is fantastic, and I for one am really appreciative.

You rock!

Thomas Bennett (Jun 03, 2007 at 22:25 GMT)

Just spent a few hours trying to figure out a linking error with IOBluetoothDeviceInquiry. I finally figured out the issue was because I was building for 10.3.9, which doesn't include this class. Building for 10.4 was fine though. Just figured I mention this and hopefully save some people some trouble.

Thomas Bennett (Jun 04, 2007 at 02:51 GMT)

Could you post the scripts for the level?

Vilain Design (Aug 07, 2007 at 00:01 GMT)

Hello,

I have just put darwiin's code into TGE 1.5. Looks like the replies from the inquiries I make when getting the remote with kick_start() are getting pilled up and not sent back into my delegate's functions. I sniffed with the bluetooth logger and the replies are sent back but are getting stuck somewhere. When I do an [inquiry stop] call, then I get the callback into "deviceInquiryDeviceFound" and right after a call to "deviceInquiryComplete" with the abort boolean on.

Does that ring a bell to anyone? Do I have to stop the inquiry to get the devicefound call?

Thanks in advance...

PS. I am new to ObjectiveC but getting the hang of it...
Edited on Aug 21, 2007 03:08 GMT

Rob Terrell (Aug 21, 2007 at 18:34 GMT)

Vilain, you shouldn't have to [inquiry stop] to get the device. Here a thought -- are you using any other bluetooth devices? I'm not, and the code works perfectly fine as is. I'll see if I can dig up a bluetooth mouse and see if it makes a difference.

Nicolas Buquet (Sep 17, 2007 at 20:25 GMT) Resource Rating: 4

Hi Vilain,

having toyed myself with Rob work, I found that in my configuration, the bluetooth callbacks aren't called if I compile TGE in multithreaded mode. The bluetooth stuff need to be in the main thread (as told in an Apple dev-list), and I blocked on inter-thread communication.

So, I compiled TGE in monothreaded mode, and that worked, except that my application crash if I try to change the screen resolution.

Hope that can help you.

You must be a member and be logged in to either append comments or rate this resource.