Growing Yards and Glowing WPF

We have a new house in a new subdivision. New houses are generally surrounded by lots of dirt, plus lots of other new houses that look suspiciously similar to yours (except the colors they picked always look better). Now, a reasonable person would—under these circumstances—simply pick up the phone and call Joe’s Landscaping to come install a nice green apron around the house. You might even end up with a tree or two by accident, and some industrial bushes in a sea of woodchips against your house. Unfortunately, I’m not reasonable. I just had to go make a landscaping “design” where nothing is square (despite the fact that the whole thing is on graph paper). These “designs” require a multitude of trees, bushes, and various other plants with unspeakable Latin names, an irrigation system second only to that running under Central Park, and lots of digging in the kind of soil that would get a pottery class excited.

Making games with Windows Presentation Foundation is pretty unreasonable, too. But so far it doesn’t seem like it is going to be quite the can of worms that my landscaping “design” has turned out to be. Overall, I am impressed with WPF. I like how super-easy it is to rotate, scale, animate, and perform groovy special effects (like the “Glow” in this week’s demo that applies to any visual). It is really fun to animate the special effects. You can animate pretty much anything you want.

If any of you are just learning WPF, don’t give up! There is a very short, steep learning curve at first, but you will soon hit that “ah ha!” moment and everything is downhill from there.

A couple of snags I ran into, though: First, when laying out the planets I have to make sure nothing overlaps. To do that, I have to know what the final size of each planet is going to be after any transformations. However, WPF doesn’t tell you what the final size will be until everything has rendered the first time. But of course, I can’t render something before I’ve figured out where it should go on the screen! So I ended writing some extra event handlers and such to keep track of what the planet’s size should be regardless of whether a given visual has been rendered or loaded yet. This had the nice side-effect of giving us a good framework for high-performance collision detection.

The second WPF strangeness is how events and properties work. They are not really built in to C#, but use a lot of reflection and external “attaching” functions that just feel a bit tacked-on. This is hidden from you in XAML, but in C# where our game has to do some fancy stuff, I think the implementation could have been a bit cleaner (even without extending the C# grammar).

Otherwise, things are going fine and I only wish I had more spare time. Unfortunately, I have a lot of digging, planting, and who-knows-what-else to do in my yard. So we’ll just have to eat this elephant one juicy bite at a time.

So what are you waiting for? Head on over to my freshly-baked Scorched Earths Google Code project where you can get the “Glow” demo from the downloads section, and peruse the source code from the comfort of your home office (you aren’t reading this from work are you?!).

Proofreading...

<Apology Content="Looks like I made some typos which broke my blog for non-IE users. Those are fixed now, and I will do better about proofing my posts in the future..." />

Zoom, Baby

WPF orginally got my attention because it was designed to take advantage of modern GPUs. Also, the framework includes a software-based rendering engine in case you don't have a fancy-pants graphics card in your PC. So you can do nice UI with some special graphical effects. As a bonus, animations and transformations are baked right into the framework.

The point of this blog is to find out how well WPF handles 2D games mixed in with the usual UI elements. My guess is that it will have decent performance, but still lag begind XNA or hard-core DirectX/OpenGL programming.

My theory is, the more UI your game requires, the better suited it is for WPF. Think of puzzle-type games that require lots of clicking (like Mahjong), or mystery-style games with images, video, and text. On the other hand, when there is little UI and lots of complex graphics do render, WPF just isn't going to cut it. Finaly, some games will require stupendous effects AND lots of UI (think, Supreme Commander). This last genre is best left to crazy, insane people. People who routinely eat nVidia chips with salsa to become "one with the machine".

This past week I made good progress; I learned how to stack UI elements, so that we can have a nice HUD-like display over the game board. The trick is using a <Canvas> as the top-level element under <Window>, and then adding another <Canvas> and a <Grid> as children. The <Grid> is absolutely positioned, and as long as it is the second child, will have a higher Z order than the <Canvas>, where you will stick all your sprites. You can of course set Panel.ZOrder if you want to force this.

The other neat thing is I learned how to make a zooming effect. This is useful for our game, because the game board is actually bigger than the window. When you shoot at another space ship and the shot goes off the screen, we want to allow it to loop back around if gravity is strong enough. Therefore, I wanted to zoom out to follow the shot.

At first I thought I would have to somehow paint the whole scene onto one side of a plane in 3D space, then manipulate the camera to get the effect I wanted. While WPF does let you map pretty much and 2D element onto a 3D model, it is a bit of a pain. Fortunately I found a better way.

WPF has these things called Transforms that can scale, rotate, and otherwise "transform" an element. Now, the
really cool part about this is that a transform will apply not only to the element you declare it on, but also to all child elements. Really, really, really nice. The demo shows how animating a single transform on the sprite canvas zooms everything all at once.

One last thing about the demo. Everything you see is done through declarative XAML (the file size is almost entirely the fault of the pretty background image). Although the .exe does not require it, I included Window1.xaml so you could see what is going on.

I am told that huge animations like the zooming effect have much better performance when executed inside the static Rendering event on System.Windows.Media.CompositionTarget. This is probably where we will do much of our animating anyway, especially our shots.

Download the demo (requires Vista or .NET 3.0 on XP)

The Learning Curve

During the past couple of weeks I’ve starting digging into “Windows Presentation Foundation Unleashed.” It’s a meaty book which makes for slow reading. On the other hand, the detail-oriented writing style helps bridge your understanding between the old Win32 visual programming model and the new “Vista” model. In any case, there is a lot to learn and experiment with.

First I need to get a handle on the way the UI controls work, and then figure out how to combine them with sprites. It isn’t obvious to me right now how you overlay UI on top of background graphics, but I’m sure it can be done.

Next week I hope to have something interesting to show and tell, but right now it’s just time to muscle through the learning curve…