1

Topic: Another Neverball + Wii Fit hack

First of all, many thanks for a great open source game!

Last December we had a bit of fun at Virginia Tech DISIS and hacked together a Wii Fit + Neverball setup. The hack is rather simple--we retrofitted Neverball to receive control data over network (so that we can experiment with various controllers without having to recompile the app) and connected it to a Wii Fit board through MaxMSP software. Below is a quick video:

http://www.youtube.com/watch?v=Qlv8uqhUJDQ

Enjoy!

2

Re: Another Neverball + Wii Fit hack

Impressive, I would like to try that too thwomps/happy
Thx for the video and for your comment!

3

Re: Another Neverball + Wii Fit hack

That's pretty cool thwomps/smile

Your network input wrapper sounds interesting. Is there any chance you are interested in submitting the patch?

Josh Bush
==========
Fearless Leader
Valiant Systems

4

Re: Another Neverball + Wii Fit hack

Cheeseness wrote:

That's pretty cool thwomps/smile

Your network input wrapper sounds interesting. Is there any chance you are interested in submitting the patch?

Many thanks all for your kind comments!

I'll gladly forward you the diffs (it's just 2 files, I think) although please note that they are really ugly hacks. OTOH, they do not impede the game from operating otherwise. The way it is currently implemented you could do silly things where both mouse and networked data are "fighting" each other for control (had a couple really funny moments with this feature where a student started claiming that the balance board was broken thwomps/laugh).

Last edited by ico (2009-02-06 04:03:00)

5

Re: Another Neverball + Wii Fit hack

It sounds interesting. If you're comfortable, throw it up on the forum here. Others might be interested too (it could be tidied and make its way into a branch as an extra input abstraction layer.

Josh Bush
==========
Fearless Leader
Valiant Systems

6

Re: Another Neverball + Wii Fit hack

Cheeseness wrote:

It sounds interesting. If you're comfortable, throw it up on the forum here. Others might be interested too (it could be tidied and make its way into a branch as an extra input abstraction layer.

Haven't figured out how to attach a file to this post, so below is URL where you can get a tarball with the patched files. Sorry, but I haven't had a chance to create diffs, so the tarball contains 5 source files with alterations. That being said, the alterations should be all noted inside the source and there is also a README in the tarball providing additional information.

If you do get a chance to look at the source, I would love to hear why do you think the UDP packets start falling behind if their frequency supersedes the speed of the main loop even though the single packet read command inside the main loop should be capable of grabbing literally dozens of packets. I ended up including an extra UDP packet read at the end to compensate for this, but isn't UDP meant to simply read whatever is on the socket at the time and not worry about the rest?

At any rate, here's the code:

http://ico.bukvic.net/Misc/neverball_ne … ack.tar.gz

NB: The patches go against the 1.4.0 source (or more precisely 1.4.0-6 Ubuntu 8.10 package).

Hope this helps!

Best wishes,

Ico

Last edited by ico (2009-02-07 16:13:11)

7

Re: Another Neverball + Wii Fit hack

ico wrote:

If you do get a chance to look at the source, I would love to hear why do you think the UDP packets start falling behind if their frequency supersedes the speed of the main loop even though the single packet read command inside the main loop should be capable of grabbing literally dozens of packets. I ended up including an extra UDP packet read at the end to compensate for this, but isn't UDP meant to simply read whatever is on the socket at the time and not worry about the rest?

UDP is a message-oriented protocol, and a UDP recv will return at most one message.  All others will remain in the system network queue.  If the application doesn't read these fast enough, then the network queue will fill up.  (Its size is given by /proc/sys/net/core/rmem_max and defaults to 128K).  If the queue fills up, any incoming UDP datagrams will be ignored.

It is very important to do your recv in a loop, taking care not to let it block.  Any datagram queuing will be perceived by the user as latancy, which is bad.  With each update, keep recving until the socket is dry, and act only on the last datagram received.

Incidentally, there's a new framework in 1.5.0 for adding new tilt-sensing devices. It is found in share/tilt.c, and it implements Wiimote sensing as an example.  It would be trivially easy to hide your UDP protocol behind this API, which would integrate it smoothly with the game.

8

Re: Another Neverball + Wii Fit hack

Ah, that makes perfect sense. Many thanks for the clarification!

Best wishes,

Ico

9

Re: Another Neverball + Wii Fit hack

Small world.  Seems ico is visiting my university tomorrow.  I'm scheduled to take him out to lunch.  thwomps/grin