Slashdot Mirror

Wii uses ffmpeg??!

If you're running Linux on it probably could.
WiiLi

Since the Wiimote uses Bluetooth to communicate with the Wii, it can be used with a PC. There is some software that takes advantage of it, though if you are interested there is http://www.wiili.org/ . The site documents the Wiimote communication protocol and lists some drivers available for the Linux, Windows, MacOS X and Java.

I wonder whether the intention of using Bluetooth was to use off the shelf equipment for the Wii, to facilitate development for it or even a bit of both?

I think the wiimote still wins out. The only thing that I would change with the wiimote is give it a higher resolution IR camera, but maybe that was too expensive for Nintendo (that may also have been a reason they didn't do high def?)

Cost is a big thing with the Wii. Currently the controller does the job for most people and at a cost that they can afford. There are better accelerometers and gyros around, but they tend to be expensive. If they could create a new and improved Wiimote, at a cost the market is willing to pay, it would have to be backwards compatible with the current set of games, and the new games would have to be backwards compatible with the original Wiimote.

Also you can already use the wiimote on a PC [wiiuse.net] for free and have millions of potential customers already owning one. So why would anyone want to pay royalties to use this thing?

Another site is http://www.wiili.org/ . There is even an API for developing with Java. BTW If you wish to play around with development for the Wiimote I highly recommend buying a battery based IR-bar.

The breakthrough here is giving the GameCube HomeBrew Scene access to the Wii's unique features (Motion Sensitive Controllers shown in video)

1. First you need a sensor bar that is no dependent of your Wii. You can make one or buy one.
2. You need a bluetooth module
3. A driver to handle requests for your Wiimote and translate them into mouse movements, etc. Linux, Mac and Windows drivers
4. (optional) I mapped my buttons to multimedia keys and bound some of them to commands
5. You need some software. In my case I've written my own called faultBox. I'll be releasing the code to the public probably this spring.

You can get other kinds of data, it's just not that usefull as the x/y coordinates.

BTW, since you mention the Wii, I will feel free to point out it would never be used for anything other than playing games because it simply doesn't have the processing power to do anything else.

...or you can imagine a situation where console still contain very weird innovations, but still provide a simple common layer.

Games are either manufacturer-exclusive and exploit all special bells-and-whistles (original new controller, clever usage of the steam coprocessors or whatever) or games target a special set of API and hardware capabilities that exist across all major player.

The concept is somewhat similar to what currently happens with some developing toolset that let developers cross compile software for several consoles (id software's next engine which works on PC, XBox 360 and Playstation with one single toolset is such an example).

The only difference is that current such tools are done by 3rd party, have to be acquired separately, and finally produce console-specific disc wich bundles game data with console-specific runtime layer, whereas EA's idea could be implemented if every console offered in it's firmware a "standarised environment".
It could be something similar to what smart phones (and to some extend, the interactive capabilities of high definition disc players are doing) are already doing : most of them have different and specific hardware and OS platform (Symbian, Linux, Windows CE, Palm OS, ...) but all have Java MIDP which can be targeted as a standard unified platform, it doesn't provide all the niceties of native binary but is the kind of "one target to rule them all" that developer are looking for.

In the console realm, an open-source stack based around Linux + SDL + OpenGL + some scripting language (like python's pygame. Or better Parrot Bytecode engine for more language flexibility) could provide such a unified target. Specially since some console already have linux (PS3, PS2) and other are getting it hacked in (Wii) or have already had (Xbox 360, DS, PSP (somewhat. An uCLinux proof-of-concept currently),XBox, GameCube, Dreamcast... )

Actually, in contrary of what they think, allowing linux on the consoles could somewhat drive piracy down. Currently both pirated games, linux and homebrew all share the same need to circumvent the cryptographic locks that exist inside consoles (either to crack the games, or just to be able to run their own non-signed code). So efforts are shared among all those groups.
If Linux gets an official support from companies, the linux community won't need modchips and such anymore, and in addition to commercial game developers looking for a standard platform, homebrewer will get a platform they can target too, without needing to circumvent cryptography. Thus less efforts go into the development of methods to circumvent the cryptographic lock around vendor specific platform for games.

The only draw back is that cross-platform developers targeting Linux for commercial games won't benefit any more from the copy protection provided by the cryptographic locks and will have to either invent other protections that will work on this standard platform (cue in StarFuck and all associated problems), count on log-ins for on-line games or accept risk and take into account the possibility of being easily copied.

However, as I'm thinking about it now, I guess the original idea isn't too bad. The basic solution is that you would have to have a Wiimote mounted on each bone in the simulated hand (one for the palm, 3 for each finger, 2 for the thumb, so 15 Wiimotes for a whole hand). Then for each bone, obtain the angle, then just use simple vector addition to get the relative positions for each of the joints. However, this still leaves you with the quandry that you have no idea where in space your hand is located, or if there is any yaw (left to right twisting), and you're back to needing a static reference point like the IR sensor bar. In other words, you would have a very accurately simulated human hand that would be correct as long as it wasn't accellerating, and it wouldn't let you simulate anything from the wrist-up. If you mounted 2 more Wiimotes to the player (one to the forearm, and one to the bicep), then you could have shoulder-down reproduction, and that would give you some decent control to pick up objects (again, just in a plane, since the Wiimotes could not detect yaw for the arm to turn from right-to-left).

I guess now all we need is some smart-guy to strap about 13 Wiimotes to his body and use the vector addition to make a simple stick-figure of himself dance around on the screen. :) It wouldn't be nearly as accurate as standard motion-capture tools (since the pitch/roll angle calculations are so limited by assuming zero linear accelleration), but it would be accurate enough to make a cool YouTube video and get posted on Slashdot. :)

From what I've heard the rumours about the disc spinning constantly or backwards compared to normal drives were myths from the GameCube discs, which turned out to be regular DVDs with a slightly different encoder or something.

"The motion of the remote is sensed by a 3-axis linear accelerometer located slightly left of the large A button. The integrated circuit is the ADXL330, manufactured by Analog Devices. This device is physically rated to measure accelerations over a range of at least +/- 3g with 10% sensitivity.

Inside the chip is a small micromechanical structure which is supported by springs built out of silicon. Differential capacitance measurements allow the net displacement of the tiny mass to be converted to a voltage, which is then digitized. It is important to note that the sensor does not measure the acceleration of the Wiimote, but rather the force exerted by the test mass on its supporting springs. Due to the sign convention used, this quantity is proportional to the net force exerted by the player's hand on the Wiimote when holding it. Thus, at rest on a flat table, the accelerometer reports vertical force of +g (the mass can be normalized away into the aribitrary units), and when dropped reports a force of nearly zero."

All the geeky details at WiiLi http://www.wiili.org/index.php/Wiimote

The wiimote is a bluetooth device and there are lots of people working on driver software for various operating systems.

You can start at wiili.

Investment cost is about £40 for the mote plus about £10 for the bluetooth dongle.

Ill bite Wii Internals.
Have a good luck arounnd WiiLi for more Wii goodness.

...which sells in europe for abt. 40 EURs. The wii remote uses ordinary bluetooth, drivers exist for ALL common OSes (win, osx, linux, see http://wiihacks.blogspot.com/ and http://www.wiili.org/ for further infos) and you got:
- a precise mouse-like pointing device (you've got to build yourself a simple "sensor bar" which consists only of a couple of IR LEDs as wii (hoho) all know)
- 3 dimensional acceleration/motion sensors
- couple of buttons
...and you're done!