Updating Missile Command

Posted by

Well my XBOX arrived the other day, so as you can imagine I've been rather... uh, "busy" for want of a better word. I'm sure my wife could think of a few other words :)

I haven't been totally idle, however, and I've been busy porting Missile Command over to XNA so that I can run it on my XBOX. The port itself is mostly done now, and I'm in the process of improving things. For example, XNA gives me a lot more power to use the graphics hardware, so I've implemented a simple particle system for the explosions and smoke.

Screenshot

It's hard to see in a static screen shot, but I think it looks much better than older animated one! I'd also like to use 3D models for the vehicles and turrets. That'll be the next step, I think.

Anyway, I noticed on the XNA Creator's club FAQ page that Australia will not be in the initial wave of countries supported. I asked some Microsofties and it seems like we won't even be in the second wave of supported countries. The OFLC strikes again it seems - damn you OFLC!

Still, I'll continue working. At least other XNA Creator's Club members will be able to play my game (and I can still release the Windows version). It might take a little while now, though, since I've gotta get through Gears of War first :roll:

Visual Studio 2008 crashes with a DEP exception after debugging an application

Posted by

I've had this really annoying problem for a while now where, if I attach to a process with Visual Studio 2008 to debug it, and then exit the application, Visual Studio would crash with a DEP exception

It was maddening and not just because I had to restart Visual Studio every time it crashed, but it also "forgets" all the window customizations, etc that I did before the crash. I don't know why developers choose to only save application configurations on a "normal" exit - why not save them when I make them? Anyway, that's a rant for another day.

The fix was pretty simple: disable DEP protection for the devenv.exe process. Simply fire up the command prompt as an Administrator, CD into your %VSROOT%\Common7\IDE folder and run the following command:


C:\...\Common7\IDE> editbin.exe /NXCOMPAT:NO devenv.exe

(It shouldn't trash your install, but you might want to make a backup of devenv.exe first)

That fixed the problem for me!

Now, presumably it's actually one of my Visual Studio add-ins that is crashing and not Visual Studio itself, but I couldn't be bothered to figure out which one it was an uninstall it (or report the problem to the maintainers). I'm just writing this post in case anybody else runs into the same problem...

I guess this also speaks to the problem with DEP in general - especially when your application is designed to run with add-ins - you need to make sure all code your application executes is DEP-aware before you set the NXCOMPAT flag in the image and you clearly can't do that with add-ins. You just gotta hope the add-in developers know what they're doing ;)

I won an XBOX!

Posted by

Woot! I'm so excited! I got the results from the DevSta entry and... I came third!

It's not exactly a secret (after all, the winners are now up on the devsta website), but I just wanted to thank the organisers and all the other contestants. It was a busy week, but definitely worth it. Now I just gotta wait for my XBOX to come :-)

My plan now? I'm going to port my Missile Command game over to XNA and see if I can't get it running on mah new XBOX. Weeee!

By the way, I got an invitation to the "liberation day" conference in Darling Harbour. So if anybody's going, let me know!

Rotating images in GDI+

Posted by

This is the final post in my little DevSta {Challenge 2008} "miniseries". In previous posts, I described how the vehicle "AI" works to avoid the rocks and also how the explosion animations worked. In this post, I'll describe how the vehicle images are rotated so that they look as though they're driving in the right direction.

First of all, take a look at the screenshot below:

Missile Command 2008

In this screenshot, you can see two vehicles at different angles - the blue line represents their current "heading" direction. The way I draw the actual image of the vehicle is pretty simple. I'm obviously no artist, so I simply drew one image of the vehicle pointing down, then at runtime I calculate the angle between the "down" vector and the direction I want to display the vehicle and rotate the image by that angle using the GDI+ RotateTransform method. Below is the code I used:

First, we calculate the angle between the "down" vector and the current heading (represented by the direction variable). Because the dot product basically always looks at the smaller angle, we need to negate the angle if it's on the "other side":


var down = new Vector(0, 1);
var angle = (float)Math.Acos(down.Dot(direction));
if (Direction.X > 0)
      angle *= -1.0f;

Next, we create a temporary Bitmap to hold the rotated image. The new bitmap needs to be a bit bigger than the source because rotating the image can obviously make it a bit wider (you can see in the screenshot above, when it's at an angle, the corners of the source image [represented by the inner square] are wider than the original image). We then apply a rotation and a translate matrix to rotate the original image and then translate it into the middle of the larger image:


var rotated = new Bitmap((int)(img.Width * 1.75), (int)(img.Height * 1.75));
using (var tmp = Graphics.FromImage(rotated))
{
    tmp.TranslateTransform(rotated.Width / 2.0f, rotated.Height / 2.0f);
    tmp.RotateTransform(180.0f*angle/(float) Math.PI, MatrixOrder.Prepend);

Remember, the RotateTransform takes angles in degrees, while most math functions (in this case, Math.Acos return values in radians, so we need to convert. Once we've set up the transform, it's a simple matter of using DrawImageUnscaled to draw the source to the temporary image:


    tmp.DrawImageUnscaled(img, (int)(-img.Width / 2.0f), (int)(-img.Height / 2.0f));
}

And then using that image as the final image and you're done! In the screenshot above, the two squares you can see represent the border around the original "source" image (before the transform is applied) and the square around the final image. It just gives you an indication of the rotation that took place.

Now, in my testing, I discovered that this was actually pretty quick - certainly fast enough that I didn't bother to optimize any further. The obvious optimization would be to pre-rotate the images and save off, say, 360 of them (one for each angle). But I didn't really have to because I was able to play up to level 25 (with 15-20 on screen at once) even on my lowly 1.6GHz laptop.

So that's pretty much it for this "series". The Missile Command game that I made is not particularly complicated in terms of gameplay or coding. The part that takes the longest, as I said before, was tuning all the elements to produce a game that "plays well" and isn't too hard or too easy. I hope that I've been able to get that worked out well!

Once the winners of DevSta have been announced, I'll release the game and source code here, so stay tuned :>>

The Big Bangs (explosions in Missile Command)

Posted by

There's actually only two animations that I needed to create for my DevSta { Challenge 2008 } entry, Missile Command, an "explosion" and some smoke for the missiles themselves. Both animations were created the same way, and I'll details the steps here. It's quite basic, and for anyone who's worked with any kind of animation before should understand the basic principle.

As before, here's a screenshot showing the explosion at work (it's hard to show a screen shot of an animation, but I'll try!

Missile Command, Explosion

Now, I actually didn't create my animations, they'd been lying around my hard-drive for ages... I probably got them from Google back in the days when I thought I'd be a professional game-designer by trade... ah, youth! But anyway, the basic structure of the animation is that you divide a bigger image into a bunch of smaller ones. In the case of the explosion, it was a 256x256 pixel image that I split up into 16 32x32 pixel images. So the top-left section was the first frame and the bottom-right was the last frame.

Now I knew I wanted the explosion to stay on-screen for about 1 and a half seconds so I decided that each frame should last 0.1 seconds (that actually ends up being 1.6 seconds, but that's good enough). So each game tick, you simply calculate the amount of time since the explosion started and divide by 0.1 -- giving the frame number. Then you simply call Graphics.DrawImage() to draw the correct sub-portion of the source image onto the screen.

Originally, the version of DrawImage I linked to above was actually the one I used, but I discovered that it was extremely slow. At first, I thought it was because I was actually rendering a 32x32 portion of the image to a 64x64 rectangle on screen (because I wanted the explosion to be a bit bigger) but even pre-scaled, that overload is really sloooow. In the end, I figured out that if I split the image up into 64x64 sections at the start of the game and then use Graphics.DrawImageUnscaled, it was much quicker. I don't know if it was maybe just my particular graphics card's drivers or if it's a universal thing, but I figured it's better to be safe than sorry.

The only other thing I'd mention about the explosions is those circles you can see in the screenshot above. See, if you compile with SHOWLINES, like I described last time, it draws a circle at the explosion's "circle of effect". That is, anything inside that circle will also explode (including vehicles and your rocket launchers). You can probably tell from the screenshot that as the animation progresses, the "circle of effect" also increases. If the radius didn't increase, you'd get vehicles exploding at the exact same time as the rocket exploding, which just looks funny.

One thing you discover making games like this is that much of time is spent tweaking things so that it doesn't "look funny." In fact, physical acuracy is less important (in my mind) as long as everything looks good. There are a number of parameters that I spent quite a bit of time just tweaking slightly - things such as the speed of the vehicles vs. the speed of the missiles, the rate at which the "circle of effect" of the explosion increases and so on. It was only after several hours of play-testing that I feel like I got those values at an acceptable level.

Anyway, that's about it for today. Next time, I think I'll go into the rotations that are applied to the vehicle and rocket launcher images. It was surprising to me how easy GDI+ made it to rotate the images. I remember back in the day having to write image rotation algorithms by hand... talk about "old school, new cool"! :roll: