Game Loop Tutorial

In this article I talk about the basic high-level structure of a typical Managed  application. Most  applications will have code that looks something like this.

Let's face it: most people that are using  are probably doing it because they want to write a game. So it makes sense that the typical, top-level structure of a Managed  application would be called the "Game Loop". (I stole the term from the mediocre book The Zen of  Game Programming.) This code or a variant of it will appear in many Managed  applications, including the sample code that Microsoft ships with the . The code looks something like this:

Straightaway you can see it's strikingly different from a "normal" WinForms application. It certainly blew me away to see a tight loop - the while (app.Created) bit - in a graphical application. I'm much more used to seeing the a call to Application.Run, which waits for events like mouse or keyboard activity to happen, calls any handlers I might have set up, and exits when my program goes away. Let's walk through the code.

This bit is fairly obvious. We're going to be using stuff from these namespaces, so let's save ourselves having to type them all the time. Note that what we don't see is that we have to have the DirectX SDK installed, and we have to have a reference to both Microsoft.DirectX.dll and Microsoft.DirectX.Direct3D.dll.

The preceding code is actually fairly interesting, because it shows that we're actually writing a class that derives from System.Windows.Forms.Form, just like all the other  apps you've ever written. So all the stuff you know about Windows Forms still applies, we just have to learn how to integrate the  bits.

Here's where we create a new instance of the form (remember, Main is static, so there's no instance yet), and then call InitializeGraphics, which is a method that we write. We'll look at it in a future article. The call to app.Show() just makes the form visible.

This is the meat of the application, where it will spend most of its time. What we're doing here is checking to see if the form has been closed, and if not, calling our Render method. Render is where all the cool 3D drawing takes place, and I'll talk about it in detail in a later article (stay tuned!). The call toApplication.DoEvents is to make sure that any pending Windows events get processed - like I said, we're writing a Windows Forms application, so we can't get away with not servicing the message pump.

The reason that we do it this way, rather than - say - setting a timer and rendering when it goes off - is that our game probably wants as much CPU as it can get. So we do all our rendering in a tight loop rather than take the usual, "Oh, I'll only do something when a windows event happens" approach. But of course we still have to process messages from Windows.

Of course we need to clean up when we're done, so we provide a DisposeGraphics method to get called whenever someone shuts down our application. We'll talk about this more later, too.

You can go ahead and compile this code - it should run just fine if you provide do-nothing InitializeGraphics, Render, and DisposeGraphics methods. Of course, it'll just be a blank form. To do anything interesting, we need a Direct3D Device, which we'll talk about .