Even More .NET-based Wiimote Applications

I've received a few more emails from folks using my Managed Wiimote Library to do some cool things with the Nintendo Wiimote in Windows.  Here are a few more:

Amazingly fantastic stuff.  I've created a list of projects using the library here.

If anyone out there is using my library for a project, please let me know and send me a link so I can add you to the list!

Read More

C# MVP

Woo hoo!  I was notified earlier today that I've been awarded the 2007 Microsoft MVP Award for Visual Developer - Visual C#!

A gigantic thank you goes out to John Papa for nominating me for the award, and to the entire Microsoft MVP team for selecting me.

Read More

New Wiimote Goodness

My latest article has been posted at MSDN's Coding4Fun site.  This article explains how to create a Wiimote Controlled Car using my Managed Library for Nintendo's Wiimote.  At the end of the article, you will have a remote controlled car that can be driven with a standard Nintendo Wiimote.

Also note that my original Wiimote library and article have been updated with some new features including x64 support, a potential fix for those with incompatible Bluetooth adapters/stacks, and a Microsoft Robotics Studio service.

As always, comments and questions welcome.  Enjoy!

Read More

XNA Timing Bug

Update - 12/24/07: This issue has been fixed in XNA Game Studio 2.0.  Woo hoo!

While working on my game for Maker Faire (which you'll be able to download in about a month), I came across a timing bug on the Xbox 360 using XNA.  For an application that requires very accurate timing (millisecond precision), one can use the StopWatch object in .NET 2.0.  This was working quite well in my PC build, but on the Xbox 360 build, I would notice that time would drift with no explanation.  After digging around for a couple days and writing a simple sample to prove the point, I determined that the time value returned by the StopWatch object would drift by about 150ms/minute, which is considerable when precision within a few milliseconds is required (and considerable when it should be accurate to begin with).

I eventually found a workaround:  DateTime.UtcNow.Ticks is perfectly accurate on both platforms.  So a quick rewrite to use this property in all locations requiring accurate timing fixed everything quite nicely.

Read More