Using Managed DirectX to Write a Game

Using Only the Lights You Need - Rather than the all-or-nothing approach used in the code here, you could instead perform a "layered" check of the light support. In this scenario, you would first detect if at least one light was supported, and if so, turn that light on. Then you could check if a second light was supported, and turn that one on if so. This enables you to have a fallback case (one light) even for devices that don't have the support you want (two lights). This example wouldn't look very good with only one directional light, so the layered check wasn't done. If it was, though, it would look something like this:

  // Do we have enough support for lights?
  if ((device.DeviceCaps.VertexProcessingCaps.SupportsDirectionalLights) &&
    ((unit)device.DeviceCaps.MaxActiveLights > 0))
  {
    // First light
    device.Lights[0].Type = LightType.Directional;
    device.Lights[0].Diffuse = Color.White;
    device.Lights[0].Direction = new Vector3(1, -1, -1);
    device.Lights[0].Commit();
    device.Lights[0].Enabled = true;
    if ((unit)device.DeviceCaps.MaxActiveLights > 1))
    {
    // Second light
      device.Lights[1].Type = LightType. Directional;
      device.Lights[1].Diffuse = Color.White;
      device.Lights[1].Direction = new Vector3(-1, 1, -1);
      device.Lights[1].Commit();
      device.Lights[1].Enabled = true;
    }
  }

Nothing new here, unless you consider the background color being black new or exciting. Now you can get ready to put in the first game play object, the road. The source code on the CD includes a .X file that will hold the road mesh data, so naturally we will need to declare the variables for the road mesh:

You will also use a variation of the load mesh function you wrote in the previous chapter. The major differences here are that it will be static, since it will need to be called from more than one class, and you will pass in all the material and texture information rather than relying on the class level variables that were used before. Add the method from Listing 6.4 to your code.

Listing 6.4 Generic Mesh Loading Routine

This function has already been discussed in depth before, so there's no need to go into it once more. You will use this function to load the road's mesh, and you should do this in the device reset event function. At the end of that function, add the following code:

Make sure you have copied the road mesh and texture file to your source code location. This code will load our road mesh, including the textures, and store the textures, materials, and mesh. Now, you will want to render this road mesh more than once per frame; you should create a function to do the rendering. Add the following function to your code:

You should recognize this function, since it's remarkably similar to the one used to render the mesh before. You translate the mesh into the correct position and render each subset. The plan for rendering the road is to render two sections at a time: the section the car is currently driving on and the section immediately after that. In all actuality, the car will not be moving at all; we will instead move the road.

The reasoning behind doing it this way is two-fold. First, if the car was moved every frame, you would also need to move the camera every frame to keep up with it. That's just extra calculations you don't need. Another reason is precision: If you let the car move forward, and the player was good, eventually the car would be so far into the "world" that you could lose floating point precision, or worse overflow the variable. Since the "world" will not have any boundaries (there won't be any way to "win" the game), you keep the car in the same relative position, and move the road below it.

Naturally, you will need to add some variables for controlling the road. Add the following class level variables and constants:

The mesh being used for the road is a known commodity. It is exactly 100 units long and 10 units wide. The size constant reflects the actual length of the road, while the two location constants mark the center of the lanes on either side of the road. The last two constants are designed to control the actual gameplay (once it is implemented). The maximum road speed you want to allow the game to get to is 250 units per second, and every time you increment the speed, you will want to increment it one half of a unit.

Finally, you need to maintain the depth location of the two road sections. You should initialize the first section at zero, with the second section initialized directly at the end of the first (notice that this is the same as the road size variable). With the basic variables and constants needed to draw (and move) the road, let's add the calls to do the actual drawing. You will want to draw the road first, so immediately after your BeginScene call in your rendering function, add the two DrawRoad calls:

Running the application now, you can see that the road is definitely being drawn; however, the "asphalt" of the road looks extremely pixilated. The cause of this pixilation is the way Direct3D determines the color of a pixel in the rendered scene. When one texel happens to cover more than one pixel on the screen, the pixels are run through a magnify filter to compensate. When there can be multiple texels covering a single pixel, they are run through a minifying filter. The default filter for both minification and magnification is a Point filter, which simply uses the nearest texel as the color for that pixel. This is the cause of our pixilation.

Now, there are multiple different ways to filter our textures; however, the device may or may not support them. What you really want is a filter that can interpolate between the texels to give a more smooth look to the road texture. In the OnDeviceReset function, add the code found in Listing 6.5.

Listing 6.5 Implementing Texture Filtering

As you can see here, you first detect whether your device can support anisotropic filtering for minification or magnification. If it can, you use that filter for both filters. If it cannot, you next see whether the device supports a linear filter for both, and use that if it's available. If neither of these is available, you should do nothing and live with the pixilation of the road. Assuming your card supports one of these filtering methods, running the application now will show a much less-pixilated road.

Now the road is in the middle of the screen, but it's not yet moving. You will need a new method that will be used to update the game state, and do nifty things like moving the road and detecting when the car has collided with an obstacle. You should call this function as the first thing you do in your OnPaint method (before the Clear method):

You will also need to add this method to your application. Add the method from Listing 6.6 to your code.

Listing 6.6 Per Frame Updates

This function will get much larger before the game is finished, but for now, all you really want it to do is move the road. Ignoring the elapsed time (which I'll get to briefly), the only thing this function currently does is move the road and then remove road sections you've already passed, and place them at the end of the current road section. When determining the amount of movement the road should have, we use the current road speed (measured in units per second), and multiply that by the amount of elapsed time (measured in seconds), to get the "fraction" of movement this frame should have. You will also need to include the reference to the elapsedTime variable in your declaration section:

Using Real-Time to Move Objects - Why do we need the time? For the sake of argument, let's say you decided to just increment the road position a constant amount for every frame. On your computer, it runs just perfectly, so why wouldn't it run just as well on other systems? So you try it out on your buddy's system, which happens to be quite a bit slower than yours. What's this? The road seems to be moving amazingly slow. Trying it out on a machine faster than yours shows the road moves much faster than it should as well.

The reason for this is that you are doing your calculations based on frame rate. For example, let's say on your system, you run at a near constant 60 frames per second. So when doing your calculations, you base everything off of this static frame rate. However, machines that only run at 40 frames per second, or faster ones that run at say 80 frames per second, will naturally provide different results. Since it should be a goal that your game runs identically on every system (as far as speed is concerned), using frame rate to do your calculations should always be avoided.

A better way to deal with this problem is to define your movements and calculations per some unit of time. For example, our maximum road speed constant is defined as 250 units per second. Our first goal would be to retrieve the amount of time that has passed since our last "update." The .NET Runtime has a built-in property (tick count) that can be used to determine the current tick count of the system, but this has its problems; mainly the low resolution of the timer. This property will only update approximately every 15 milliseconds, so on a system where you are running a high frame rate (above 60 frames per second), the movement will appear choppy, since the times used won't be smooth.

The DirectX SDK includes a class called DirectXTimer that uses a high-resolution timer (usually 1 millisecond) if it's available on your machine. If this timer isn't available on your machine, it will revert back to the tick count. The examples in this book will use this timer as the mechanism for timing. It already includes the code for a high-precision timer, so why should we reinvent the wheel?