Dawn of the Geeks

For Christmas I picked up Sesame Street Elmo’s World My First TV Fun & Games because it was only $5 at a store that was going out of business. My daughter is only 21 months and likes to play with the Nintendo DS because she can use the pen and make it do things. I figured that since this thing has all of three giant buttons she might be able to make use of it.

Here’s a sample screenshot:

She enjoys it because it has Elmo. However the graphics are dreadful and it features no actual music or sound effects related to Elmo. The graphics are primitive NES quality. Worse than Super Mario Bros 1. So I’ve decided to remake the games using the Wiimote and the XNA Game Studio.

It’s coming along nicely. The soccer game is mostly done. I’m just hunting for my Elmo sound effects. For as popular as he is there is a distinct lack of Elmo media on the net. I guess when most of your fans are still in their diapers you can’t expect too many fan sites to pop up.

On top of being something that my daughter can actually do (she likes swinging the Wiimote around and seeing Elmo move) it’s a good demonstration of how to put together a game using the Wiimote and XNA Game Studio.

I like my software rendering stuff because I’m doing a lot more. But the XNA Game Studio is my choice for this project. The focus is less on learning graphics programming and more on making games with the Wiimote. It’s ridiculous how easy the XNA stuff is to learn. There is no shortage of sample code to do anything you want. It even integrates with Visual Studio Express so you can get started making 2D or 3D games with little to no effort. And best of all, no cost.

Sesame Street really should look into releasing games for the Wii and DS. Parents would love it. There are so many educational games out there that just have terrible graphics and/or require sub-par gaming systems and there’s no reason for it. My parents didn’t have video games. These days kids are growing up with parents that played and still play video games. Parents today are going to have an XBox, Playstation or Wii. Why require that they buy yet another console or handheld system when they already have one or five?

I’d rather buy an educational title for a system we already own than have to buy yet another console just to have educational titles. With Nintendo’s expandable Wiimote it would be ideal for companies that not only want to create simple games but also have simple controls. I’d happily pay $15 for a Wiimote extension with 3 giant buttons for a toddler to use if I could get simple games for her to play as well. That makes more sense than $5 for yet another game system that she’ll quickly grow out of.

In the meantime, I’ll have to stick to making use of my talents to create my own educational titles for my kid to play.

One of the early mistakes people made in understanding how the Wii works was thinking that the Wii Sensor Bar actually did anything. After all it plugged into the Wii with what looks like a USB cable and you must have it on or the Wii Remote doesn’t work. Turns out that it’s essentially just a flashlight with infrared LEDs. You can put two candles on top of your TV and play the Wii.

The second misconception seems to revolve around what the Wii Remote actually does. I e-mailed Brian Peek who wrote the Managed Wiimote Library and he was apparently unaware that there was anything missing in his library. He was under the impression (as are a lot of people) that the points returned by the Wiimote for the infrared sensors indicate where the Wiimote is pointing. He didn’t realize that you can’t use those values by themselves to use the Wiimote as a pointing device.

It appears to work in some cases but once you start rotating the Wiimote (you know, twisting your wrist) things don’t work anymore.

Those values are actually where the infrared points appear in the camera. They do not by themselves indicate where the wiimote is actually pointing.

There’s a very good reason for that: the Wiimote is a collection of sensors that reports back the raw data to the Wii. It is not a computer. The individual sensors are not communicating with each other. The camera finds the x and y coordinates of its light sensor that are activated by the infrared light that hits it. The accelerometers measure their respective g-forces. There is also circuitry that indicates what buttons are being pressed. All of those parts feed their data into a bluetooth transmitter.

The reason that the Wiimote is not doing calculations is because it would add additional cost to the controller for no good reason since there is a perfectly good computer sitting on your entertainment center. All that raw data is feed to the Wii and the Wii crunches the data and spits out usable information that games can make use of. The Wii takes the positions of the infrared points of light that the camera sees and combines it with the data from the accelerometers and generates the X and Y coordinate indicating where on the screen the controller is pointing.

If the remote were to do that it would require some sort of CPU and memory and custom software, etc. As it is the Wiimote is not a programmable device. All it does is take data from the sensors and feed it through a bluetooth transmitter for more sophisticated hardware to deal with. It’s genius in its simplicity.

Anyway, the point is that the Managed Library is a great start but like the Wiimote, it only gets you the raw data. You still have to do calculations to realize the full potential of that data. The biggest missing piece is being able to use the Wiimote as a pointing device. I’ve got a good start on that as I’ve mentioned in previous posts. I’ve started work incorporating my pointer code into an XNA project to create a few sample games using the Wiimote as the pointing device.

Yes, that’s right, I’m using a game programming library intended to be used to create XBox games to create Wiimote based games. My software rendering library I wrote from scratch is nice and all and is fun to work with but it’s not going to cut it for making the types of games I want to create now that I can make better use of the Wiimote.

Hopefully I’ll have a release of some games this weekend. The games I’m currently working on are designed for a 21 month old. Perfect for demoing the capabilities of my Wiimote code without burying it under complex game code.

This is a higher resolution of the sample Wii Pointer app in action.

You can download the app from
wiimote_pointer.zip

Everything is precompiled and ready to go. All the source code is also included. Just follow the directions at Brian Peek’s blog to get your Wiimote connected to your PC. You must have a sensor bar for this app to work properly.

Hit “+” on the number pad to increase the resolution (not the “+/=” key). You can also drag the corners of the app to change the resolution.

common\input_buffer\wiimote_class.cs contains the logic for figuring out where the Wiimote is pointing.

I updated the code to be able to approximate the location of the pointer when one of the IR sensors goes out of range. It works best when you stand several feet back from your computer monitor.

I’m sure there are some potential improvements that could be made but it is an excellent starting point for using the Wiimote as a pointing device in your own games. The sample app uses software rendering so you don’t need DirectX or OpenGL to try it out.

I’ll have some sample DirectX games created in a week or two that make use of this library.

In my previous post I simply checked the orientation of the two IR points to determine if the Wiimote is upside down. After playing around a bit I noticed something strange. If I moved the Wiimote off the screen and then back on the screen sometimes the two points would reverse and the pointer image would flip upside down. Apparently the order of the IR points depends on which one the Wiimote registers first, not how they appear on screen. So you can hold the Wiimote perfectly horizontal, move it down off screen and back up and (what are the blue and red indicators in the above screenshot) will flip position.

So that method doesn’t actually work. What does work is even simpler: the roll angle is the atan of the z acceleration and the x acceleration. The pitch angle is the atan of the z acceleration and the y acceleration.

In C# that’s simply


//WiimoteLib.AccelState acc passed into the method
roll = (float)(Math.Atan2(acc.Values.Z, acc.Values.X) * 180.0 / Math.PI) - 90.0f;
pitch = (float)(Math.Atan2(acc.Values.Z, acc.Values.Y) * 180.0 / Math.PI);


I subtract 90 degrees so that horizontal is 0 degrees. I think the pitch could use a fixed adjustment as well but I haven’t made use of it yet so I haven’t looked into it. I use degrees in my code in various places but you could just leave it in radians.

Now the hard part is figuring out what the Wiimote is pointing at. I finally downloaded and tried out the head tracking demo that became very popular on YouTube. I was very disappointed to find that the IR values were being used as pointer position values directly. What that meant is that the demo only seemed to work because the sensor bar was kept horizontal. If you rotated the bar the motion was no longer correct. In other words, it was clever but the hard part was glossed over.

So let me make this clear: the IR values cannot be used directly as the location that the Wiimote is pointing at.

Hunting around on the internet I found a lot of references to triangulation and doing rotations but nobody had any equations. There’s a mouse demo out there were if you hold the Wiimote still but roll it slightly the cursor shoots across the screen. The reason is because it’s misusing the accelerometer data. Rotating the Wiimote in any direction doesn’t not necessarily imply acceleration: and the Wiimote knows this if you do the math right.

So what is the math?


position = new point_class((1.0-ir.Midpoint.X) * (double)sx, ir.Midpoint.Y * (double)sy);


If you’ve looked at the Wiimote Library test app you’ve seen something that looks like that. It’s basically unchanged except for one “minor” detail: the x-axis is flipped.

And you’re not done. That equation gives you the midpoint of the two IR sensors with the x-axis flipped. That doesn’t give you where the Wiimote is pointing just yet.

To finalize the equation you move the position point to the origin. In my code you subtract the point in the center of the screen from the position. You then rotate that point using the value of Roll. Now, add the center of the screen point back to position.

Done. That’s it. That’s the secret of using the Wiimote as a pointer.

Is it perfect? No. You can’t get all the way to the edges because this method requires that both IR sources be visible. It also may not be getting the exact spot on the screen that the Wiimote is pointing at but it’s close enough that I can’t tell. If I point the Wiimote in the upper left corner and roll the Wiimote the pointer stays in the upper left hand corner and so on with the rest of the quadrants.

So it’s a very good start. The basic thing to keep in mind is that input has to be simple. The equations for processing input have to be simple and fast otherwise you’re wasting CPU cycles that should be used for graphics and game play. So there was no reason for me to believe that you have to be doing complex 3D equations to get the pointer going.

Maybe that’s ultimately what Nintendo is doing, but you don’t have to. I’ll have the full code and download available soon so you can try it out yourself and maybe find ways to improve it.

One of the things the Wiimote doesn’t know by default is whether or not it’s upside down. This presents a mild problem when using the Wiimote Library and you want to rotate the pointer most every Wii game does.

The trick is realizing that the Wiimote is calculating the angle based on the two outer points. To know if you’re upside down you simply check to see which point is to the left of the other. You then invert the angle if the points are flipped.

The angle given by the Wiimote is from -1 to 1 so you subtract the angle from 2 when the remote is upside down. You multiply the given angle by 90 degrees to get the 0-360 degree angle.

In Wii-Land the x axis is pointing into the screen so we use the x axis rotation to determine how to rotate the pointer on the screen.

You can see in the code below that the x pos is flipped. That’s because 1024 is the left side of the screen and 0 is the right side of the screen according to the Wiimote. I flip that as well to simplify things.

This is all part of the work I’ve been doing with software rendering. I finally got a wireless Wii sensor bar to use with my computer so I can start making games that make use of the Wiimote and other Wii controllers.


if (ws.IRState.IRSensors[0].Found && ws.IRState.IRSensors[1].Found)
{
remote.rot_x = accel.X;
remote.rot_y = accel.Y;
remote.rot_z = accel.Z;

if (ws.IRState.IRSensors[0].Position.X < ws.IRState.IRSensors[1].Position.X)
remote.rot_x = 2.0f - remote.rot_x;

remote.pos_x = 1.0f - (float)ws.IRState.RawMidpoint.X / 1024.0f;
remote.pos_y = (float)ws.IRState.RawMidpoint.Y / 768.0f;
}

Free Ringtone Heaven is currently being purged and reloaded. It’ll probably be an hour or two before it’s back up. The biggest change is to the file and directory structure both on the server and in the database. Previously all stats were tied to file ids. Now they’re tied to the file hash. What this means is that in the future I can do some reorganization on the files without having to take the whole site down. And no stats will be lost.

The next step is to separate the physical file location from the virtual directory structure. That will make it even easier to adjust the location of files without having to reupload all the ringtone files. With all the current changes, that switch should be transparent and require no down time.

Free Ringtone Heaven.com is getting a redo. When first designing a web-site you tend to whip things up quickly and get them out there to see what happens. Then over time you tweak it here and there and maybe add a feature or 10. And eventually the site becomes stale and ugly.

That’s when you get to go in and force yourself to do things right. It’s time to clean up the code, apply better code design practices, update the interface, tweak the database, etc. And finally when it’s all done you get to tear down the old site and replace it with the brand new one.

In the case of Free Ringtone Heaven there is myMobile which users could use to upload their own files. However, it was so poorly implemented I’ve decided to just tear it down. People weren’t really using it anyway. So there will be a brand new myMobile launched. So when the new myMobile launches you will need to create a new account.

In that sense, I got lucky. There’s nothing about the old site I have to save. Except for the ringtones of course. I’ve got the backend pretty much complete with far more intelligent usage tracking. myMobile will have a password recovery feature finally. I’ve also cleaned up the ringtone directory structure a bit which should make it easier to find what you’re looking for.

The coming changes are too numerous to list them all. My goal is to have the new version launched sometime this weekend. FunkyCatz.com is my other ringtone web-site which I used to try out some things that are now being applied to Free Ringtone Heaven.

There is an old saying “if it ain’t broke don’t fix it.” Well technically Free Ringtone Heaven ain’t broke but it certainly has a lot of room for improvement. My main goals are to fix some of the stale aspects of FRH with the new download tracking and improve myMobile.

Sometimes it’s good to go back deep into the code of a site you built long ago and give it a redo. You’ll discover things you could improve, simplify and maybe even learn more for your next project.

One of the nice things about being able to run a server off your home internet connection is that you can do whatever you want. You can build the server you want, install the software you want, run the web-sites you want. The downside is that home internet connections aren’t always reliable. They’re also much slower than you can get with a hosting company like GoDaddy.

However, they are a good way to test out web-site concepts before spending the money on hosting them somewhere else. There used to be a lot of misconceptions about the cost of running web-sites and they probably still exist. The biggest misconception is what hardware is required. A “server” is just a PC. My home server is a run of the mill dual core Intel processor running at 1.7Ghz per core. The motherboard and the CPU cost less than $100 combined. In addition I have four harddrives (OS, website files, database files, log files) although one would suffice if you’re just getting started. Everything is contained in a standard mid-tower case which cost around $35.

You can purchase more expensive computers that are designed to handle high volume traffic. But you don’t need to. I think the misconception about what hardware is needed comes from what server computers typically look like; long and flat. That’s because they are typically stored in a rack and every unit of rack space costs money. A lot of money. With a home server you don’t have to worry about saving money by not having to pay for space to store your system. It can be as bulky as you want it to be. That means you can buy whatever parts you want. You don’t have to buy expensive parts designed to fit into a confined space.

So now you know that you don’t need special hardware to run a web-server. You can build from parts or buy a pre-built desktop system. The next misconception is the software. The software is really what separates a server from a home computer. A lot of people will probably tell you that you should run Linux because it’s “faster” or “more secure.” Both things are essentially false. If you happen to like Linux and want to use it then great. But more than likely when you bought he system or built it, you put some version of Windows on it. You can leave Windows on it. I would actually recommend it. There’s enough to learn about the actual server software that you shouldn’t subject yourself to a foreign operating system.

When people talk about “Linux” being faster or more secure in the context of web servers, they’re not talking about the operating system. They’re talking about Apache and IIS. Even professional highly paid writers who specialize in technology often can’t tell the difference between an operating system and applications. IIS is the web-server application that comes with professional and server versions of Windows. Apache is a lightweight web-server application that was originally made for Linux but, guess what, it also runs on Windows. Apache is just as fast and just as secure on Windows as it is on Linux.

I prefer Apache although I also develop for IIS. Apache is free and will run on anything. I once handled over 1 million requests in a month with Apache running on Windows Millenium. The simple fact is, the operating system doesn’t matter. It’s the software that runs on top of it that matters.

The typical software that people use to run hobby web-sites is Apache, MySQL, PHP and Subversion. All the software is 100% free and runs just as well and just as securely on Windows as it does Linux.

The security of Apache comes from the fact that it does the bare minimum. It only serves up web-pages. The lack of security for IIS (or the difficulty of making it secure) comes from the fact that IIS does a lot. If IIS only did what Apache did it would be just as secure out of the box.

What makes the operating system secure is only having the ports open that you want people to use. Namely, the port that Apache is using to serve up web-pages. Typically that’s port 80. A $30 router will lock down your network as well as anything.

So you can see that running a server may involve a bit of education on your part. But it doesn’t require a lot of money. The software is free. You can use any old computer you have lying around. And then you can go to town making whatever web-sites you want to make. If a web-site becomes very popular then you can look into other options for how to host the site. But until then, don’t waste your money.

Back in the early to mid 1990’s I decided to create a racing game called “Hyperspeed.”

You can actually download it from here although I’m not sure how functional it is. There was nothing fancy to it. There were three track pieces: straight, left and right. Shifting shades of gray were used to simulate movement. It was written in BASIC.

After mucking around with Bunnies for quite awhile now (going on 5 years) I’ve decided to take a stab at bringing “Hyperspeed” back to life in the form of a Super Mario Kart clone. I was expecting it to be complex. Turns out that the techniques used to create Super Mario Kart are 100% identical to Bunnies minus the walls. So actually, it’s easier.

I originally created a new code branch for Hyperspeed but have now compiled a number of pieces into libraries in a “common” folder. Bunnies has been modified to use the new common code. Hyperspeed has been linked up with the Bunnies server. Earlier I had added a feature to the Bunnies website where you could upload a large image, break it into tiles and auto generate the floor of a map from it. Well, that’s why.

The floor is just the first step. Racing games like Super Mario Kart also need a collision map and way points. After playing Tower Defense for awhile and seeing some sample code I realized that you can simply use way-points like in Tower Defense to create racing AI and ensure that the player is going the right direction and not cheating.

A collision map is simply a gray-scale image that indicates whether a position within a tile slows the player down and by how much or if it stops the player entirely.

Currently you have to apply bump and depth maps one tile at a time. I’ll be adding a feature to allow collision maps and make it possible to apply them all to an entire image. There’s a very good chance that the maximum file dimensions will be going up. 2048×2048 works but I’d like to allow higher resolutions. 2048 gets you about 64 pixels per floor tile. I’d like to at least double that. The limit on the site is rather arbitrary. I could just remove the restriction.

Hyperspeed will probably not be released for at least a month. There’s a lot of work to be done to make it a game. In the mean time there’s a new release of Bunnies and an updated game server which fixed a few major bugs. Part of this project is to demonstrate the versatility of the Bunnies game engine and web-site. Once Hyperspeed is ready to be released Bunnies and Hyperspeed will be part of the same download package.

Sin & Cos: The Programmer’s Pals! is probably the most straight forward example of Mode 7 implemented in a C like language available. You may be wondering what Mode 7 is.

F-Zero and Mario Kart for the SNES made use of Mode 7 and it has been used in quite a few games since. Mode 7 is a term to describe the ability to scale and rotate a texture. It simply translates the height of a texture into the depth.

Not so surprisingly you will find that the equations used to render Mode 7 are essentially identical to the equations used to render the ceilings and floors in Bunnies. Mode 7 is Bunnies without the walls.

The above link provides the basic rendering function but gets the key part of the equation wrong. Fortunately, Bunnies gets it right so I just used the equation from Bunnies.

I’ve started translating the old SoftGel C++ code to C# and this Mode 7 stuff is going to be the first to make use of the new library. I’m going to try to find time to start writing more tutorials. Bunnies is pretty advanced at this point and so I think I’ll begin developing a simple racing game and writing tutorials to explain how it all works. Eventually I may work the tutorials back to Bunnies.

You may be wondering what the point is with OpenGL and DirectX available. There are a number of reasons. The main one is that I’ve been there and done that with OpenGL and DirectX. I want to learn the math behind the rendering. The second reason is that most of the work that goes into making a game has nothing to do with rendering graphics. And also, you’ll find many of the same concepts that are used to render graphics are also used to implement game mechanics.

And finally, software rendering works on any platform that can plot a pixel. Not all gaming systems have 3D capabilities. If you can figure out the 3D stuff in software you’ll have no trouble doing it in DirectX or OpenGL.