Audio audio = new Audio("AudioFileName");

Audio audio = new Audio();

audio.Open("AudioFileName");

audio.Play();

audio.Pause();

audio.Stop();

audio.Dispose();

private void _audio_Ending(object sender, EventArgs e)

{

    audio.Play();

}

audio.Open("//www.audiofile.com/music.mp3");

While playing the audio file you can control the volume and balance of the file.

Volume: Volume is expressed as an integer. Somewhat counterintuitive is that a setting of 0 is full volume. Smaller values decrease the volume up to a setting of -10,000 which is silent.

audio.Volume = 0; // Maximum

audio.Volume = -10000; // Silent

audio.Balance = -10000; // Only Left channel

audio.Balance = 10000; // only Right channel

audio.Balance = 0; // balanced

State	Method	Event	Property (Boolean)
Started	Play	Starting	Playing*
Paused	Pause	Pausing	Paused
Stopped	Stop and StopWhenReady	Stopping	Stopped**
Ended	N/A	Ending

* While playing the audio class indicates the current position of the stream with the CurrentPosition property.

** The audio class also provides a property, StopPosition, which indicates the position in the audio stream where the file is stopped

You can also use the State property of the Audio class to determine its state. This property returns a StateFlags enumeration with the possible values of: Running, Paused and Stopped.
Also of interest is the SeekingCaps property of the Audio class. This read only property indicates the seeking capabilities of the playback stream. It is represented in the form of the SeekingCaps structure. This structure indicates whether the stream supports the following seek actions:

Action	SeekingCaps property (Boolean)
Current position	CanGetCurrentPostion
Duration	CanGetDuration
Stop position	CanGetStopPostition
Absolute	CanSeekAbsolute
Seek Forwards	CanSeekForward
Seek Backward	CanSeekBackward

You should check the capabilities of the stream before calling SeekCurrentPosition, SeekStopPosition or checking the Duration property.

Ok, let's package this simple class into a Jukebox. I want the Jukebox class to pull files from a predetermined location so I can just point it at a media folder within the games directory structure. I also want the Jukebox to either play all the files it finds in order or play a single file in a looping fashion.

Finally I want this class to play a specific file on demand, for example, when I am on the splash screen I want to play the intro tune, while on the main game screen I want some other background music.

NOTE: I am not providing any audio files with the source code. By default the SoundTrack class reads from C:\Documents and Settings\All Users\Documents\My Music\Sample Music where you should have two WMA files on a standard XP machine. If you do not have those files you need to change the directory and point it at a location that has sound files.

Creating the SoundTrack class

The first step is to add a reference to the Microsoft.DirectX.AudioVideoPlayback assembly.
Next we add a new class and call it Soundtrack. At the top of the class we need add the using statement for the AudioVideoPlayback namespace.

using Microsoft.DirectX.AudioVideoPlayback;

public void Dispose()

{

    Dispose(true);

    GC.SuppressFinalize(this);

}

protected virtual void Dispose(bool disposing)

{

    if (!this._disposed)

    {

        if (disposing)

        {

            if (_audio != null)

            _audio.Dispose();

        }

    }

    _disposed = true;

}

// Use C# destructor syntax for finalization code.

~SoundTrack()

{

    // Simply call Dispose(false).

    Dispose(false);

}

private bool _disposed;

public SoundTrack ( string[] songCollection, bool repeat )

{

    _songList = songCollection;

    _isRepeat = repeat;

    if ( _songList.Length == 0 )

        _enabled = false;

    else

        _audio = new Audio ( _songList[ _songCounter ].ToString ( ) );

}

private Audio _audio;

private string[] _songList;

private int _songCounter = 0;

private bool _isRepeat;

private bool _enabled = true;

public void Play()

{

    if ( !_enabled )

        return;

    _audio.Play();

    _audio.Ending += new EventHandler(_audio_Ending);

}

private void _audio_Ending(object sender, EventArgs e)

{

    if ( _isRepeat )

    {

        Stop ( );

        Play ( );

    }

    else

        NextSong ( );

}

public void NextSong ( )

{

    if ( !_enabled )

        return;

    _songCounter++;

    if ( _songCounter == _songList.Length )

        _songCounter = 0;

    if ( _audio.Playing == true )

        _audio.Stop ( );

    _audio.Open ( _songList[ _songCounter ].ToString ( ) );

    _audio.Play ( );

}

The only remaining method we now need is to stop the player

public void Stop ( )

{

    if ( !_enabled )

        return;

    if ( _audio != null )

        _audio.Stop ( );

}

To allow us to control the balance and volume we simply add two properties to the SoundTrack class that expose the identical properties of the Audio class. Since we know the upper and lower bounds of the values, we add a simple check to the property setter to ensure we only pass valid values. This is more efficient than passing an invalid value and having to check for exceptions. In general you should enforce boundaries whenever possible.

   1: public int Volume

   2: {

   3:     get { return _audio.Volume; }

   4:     set 

   5:     {

   6:         if ( value > 0 | value < -10000 )

   7:             return;

   8:         

   9:         _audio.Volume = value; 

  10:     }

  11: }

  12:  

  13: public int Balance

  14: {

  15:     get { return _audio.Balance; }

  16:     set 

  17:     {

  18:         if ( value > 10000 | value < -10000 )

  19:             return;

  20:         

  21:         _audio.Balance = value; 

  22:     }

  23: }

Now we can integrate the new class into the game. First we add a reference to the new class to the GameEngine class.

private SoundTrack _mainSoundTrack;

_mainSoundTrack = new SoundTrack ( Directory.GetFiles ( @"C:\Documents" + 

    "and Settings\All Users\Documents\My Music\Sample Music" ), true );

// Control the Sound

if ( _keyboard.State[ Key.P ] )

    _mainSoundTrack.Play ( );

if ( _keyboard.State[ Key.M ] )

    _mainSoundTrack.Stop ( );

if ( _keyboard.State[ Key.N ] )

    _mainSoundTrack.NextSong ( );

if ( _keyboard.State[ Key.UpArrow ] )

    _mainSoundTrack.Volume += 10;

if ( _keyboard.State[ Key.DownArrow ] )

    _mainSoundTrack.Volume -= 10;

if ( _keyboard.State[ Key.RightArrow ] )

    _mainSoundTrack.Balance += 10;

if ( _keyboard.State[ Key.LeftArrow ] )

    _mainSoundTrack.Balance -= 10; 

Summary

Now we have pretty much completed the pass through the basic functionality of the all the DirectX namespaces. There are many more advanced topics that could cover additional graphics classes such as HLSL (High Level Shader Language), but in the next articles we are going to focus on two non DirectX parts of game development - Artificial Intelligence (AI) and Physics.

Without good AI and Physics, even the best designed games are no fun to play. Nothing shatters the illusion of reality more than predictable enemies or rocks floating in mid air.

Together with game Physics, AI represents a major portion of the game that has no support in DirectX and limited support in other (free) libraries. We are not going to be able to fill that gap and write a fully featured AI engine, but we can cover most of the principles and techniques behind some of the more basic AI problems, such as chasing and evading and path finding.

Until then: Happy coding.

Derek Pierson is a software developer with 12 years experience designing and developing enterprise applications using a variety of programming languages. He is an enthusiastic teacher of the art of programming and believes that elegance and simplicity are defining features of good software.

Filed under: arcade, gaming

Previous Articles:

1. Beginning Game Development Part 1 - Introduction
2. Beginning Game Development Part II - Introduction to DirectX
3. Beginning Game Development: Part III - DirectX II
4. Beginning Game Development: Part IV - DirectInput
5. Beginning Game Development: Part V - Adding Units
6. Beginning Game Development: Part VI - Lights, Materials and Terrain
7. Beginning Game Development: Part VII –Terrain and Collision Detection
8. Beginning Game Development: Part VIII - DirectSound
9. Beginning Game Development: Part VIII - DirectSound II
10. Beginning Game Development: Part VIII - DirectSound III

New Game Loop

In a number of post it was pointed out that the game was not running as fast as some of the DirectX samples. The reason behind this is that the game used an older and less efficient version of the game loop. Let's go ahead and change the code to use the new game loop based on this blog by Tom Miller.

First create a new class called NativeMethods and paste the Message struct and extern method declaration into it. The finished class should look like this.

 1: using System;

 2: using System.Runtime.InteropServices;

 3:  

 4: namespace BattleTank2005

 5: {

 6: class NativeMethods

 7: {

 8: [StructLayout ( LayoutKind.Sequential )]

 9: public struct Message

 10: {

 11: public IntPtr hWnd;

 12: public uint msg;

 13: public IntPtr wParam;

 14: public IntPtr lParam;

 15: public uint time;

 16: public System.Drawing.Point p;

 17: }

 18:  

 19: [System.Security.SuppressUnmanagedCodeSecurity] // We won't use this maliciously

 20: [DllImport ( "User32.dll", CharSet = CharSet.Auto )]

 21: public static extern bool PeekMessage ( out Message msg, IntPtr hWnd, uint messageFilterMin, uint messageFilterMax, uint flags );

 22: }

 23: }

Make sure to reference the System.Runtime.InteropServices namespace at the top of the class.

Next, add the OnApplicationIdle method into the GameEngine class

 1: public void OnApplicationIdle ( object sender, EventArgs e )

 2: {

 3: while ( AppStillIdle )

 4: {

 5: // Render a frame during idle time (no messages are waiting)

 6: _deltaTime = HiResTimer.GetElapsedTime ( );

 7: 

 8: CheckForInput ( );

 9: 

 10: Render ( );

 11: }

 12: }

Then add the AppStillIdle property to the GameEngine class.

C#

 1: private bool AppStillIdle

 2: {

 3: get

 4: {

 5: NativeMethods.Message msg;

 6: return !NativeMethods.PeekMessage ( out msg, IntPtr.Zero, 0, 0, 0 );

 7: }

 8: }

In the Program class change the Main method so it reads:

C#

 1: [STAThread]

 2: static void Main ( )

 3: {

 4: using ( GameEngine engine = new GameEngine ( ) )

 5: {

 6: engine.Initialize ( );

 7: System.Windows.Forms.Application.Idle += new EventHandler ( engine.OnApplicationIdle );

 8: Application.Run ( engine );

 9: }

 10: }

Finally, remove the entire OnPaint method from the GameEngine class. You can also remove the following line from the constructor of the game engine class.

C#

 1: this.SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.Opaque, true);

You should see a pretty good improvement over the previous game loop. Just remember that there really is not big benefit it your game runs at 700 fps and is no fun to play, so don't get caught up in the speed over all other facets of the game.

Sound effects in Games

After adding the sound to BattleTank2005 in the last article, why would we bother with sound effects now? If we record the sounds ahead of time then they is really no reason to add effects to them - or is there. Sound effects are added to further manipulate sounds based on the active environment of the game. The simplest example would be to manipulate the base sound of footsteps and add an echo when the player is in a tunnel.

As you will see a little later, DirectSound also adds an effect which allows for the manipulation of sounds to match specific pre-defined environments.

Effects

There are nine sound effects in the DirectSound namespace which are referred to officially as Microsoft DirectX Media Objects (DMOs). Each class also has a large number of effect specific properties you can manipulate to pretty much get any sound effect you want. Here is the information from the SDK in a simple table format for easy reference.

Effect Name	Description
Chorus	A voice-doubling effect created by echoing the original sound with a slight delay and slightly modulating the delay of the echo.
Compressor	A reduction in the fluctuation of a signal above a certain amplitude.
Distortion	Adding harmonics to the signal in such a way that, as the level increases, the top of the waveform becomes squared off or clipped.
Echo	Causes sounds to be repeated after a fixed delay, usually at a diminished volume. As the repeated sounds are fed back into the mix, they are repeated again.
Flanger (Flange)	An echo effect in which the delay between the original signal and its echo is very short and varies over time.
Gargle	Modulates the amplitude of the signal.
Interactive3DLevel2Reverb (Reverb)	Environmental reverberation in accordance with the Interactive 3-D Audio, Level 2 (I3DL2) specification, published by the Interactive Audio Special Interest Group. See more on this later.
ParamEq	Amplifies or attenuates signals of a given frequency
WavesReverb	Intended for use with music and based on the Waves MaxxVerb technology, which is licensed to Microsoft. http://www.waves.com/

Out of these effect classes the Interactive3DLevel2Reverb is a special class, since it provides what amounts to a large set of pre-built settings representing various environments.

The principle behind this class is based on the effects of the environment on the sounds we hear.

Basically sound we hear has three temporal components:

1. Direct Path: Straight from the source to the listener.

2. Early Reflections: Sounds that reach the listener after reflecting of one or two surfaces first. Surprisingly sounds that reflect of one surface are called first-order reflections; sounds that reflect of two surfaces are called second-order reflections and so on. Humans normally hear only first and second order reflections.

3. Late Reverberations: These are the combined of lower-order reflections.

In addition to the AllParameters property that all the other effect classes share, the Reverb effect has two additional properties: Quality and Preset. The Quality property is simply an integer value with larger values representing higher quality at the cost of processing time. The default value is 2 and the values are bounded by QualityMax and QualityMin.

The Preset property is an EffectsEnvironmentPreset enumeration value that allows you to select pre-made environment settings without having to set the individual properties such as rolloff factors, diffusion etc. The enumeration includes 30 settings including settings for: Mountains, UnderWater, Bathroom and PaddedCell. This means that you can easily manipulate pre-recorded sounds to fit your game world better without having to record and ship sounds for each possible environment.

The ParamEqclass also has a non standard feature not shared by any of the other sound effect classes. You can use this effect class multiple times on the same buffer to achieve similar control over the sound as you would with a hardware equalizer.

Update the SoundEffects class
The first effect we are going to use in BattleTank2005 is the Interactive3DLevel2Reverb effect set to a preset value of Hangar (You have to play with the presets, some sounds do not come over very well. I originally wanted to use Plain as the preset, but one of the sounds ended up being distorted).

We want this effect to apply to all the sounds in the game, so we are going to add it to the constructor of the SoundEffectsClass.

First we need to update the SoundEffects class (slightly unfortunately named) and set the ControlEffect property of the buffer to true. This enables the buffer to be used with sound effects. In the constructor of the SoundEffects class add the following line of code.

C#

bufferDescription.ControlEffects = true;

Next we create the EffectDescription array, initializing it to the correct size. If you plan to add other effects make sure to change the size of the array accordingly. After the catch statement in the constructor add the following code.

C#

Microsoft.DirectX.DirectSound.EffectDescription[] effects = new Microsoft.DirectX.DirectSound.EffectDescription[ 1 ];

Next we set the desired effect class using the DSoundHelper class.

C#

effects[ 0 ].GuidEffectClass = DSoundHelper.StandardInteractive3DLevel2ReverbGuid;

Then we add the effect to the SecondaryBuffer for this sound.

C#

AddEffects ( effects );

After setting the effect we need to get it back out to set its parameters. Use the correct casting method as explained above.

C#

Interactive3DLevel2ReverbEffect enviroEffect = GetEffect ( 0 ) as Interactive3DLevel2ReverbEffect;

Check the effect variable for null before doing anything. If we have the right effect you have two choices.

C#

if ( enviroEffect != null ){}

You can either get the Effects parameters from the AllParameter property of the class and then set each separate value to give you very fine grained control over the effect you are adding.

C#

 1: if ( enviroEffect != null )

 2: {

 3: // Set all the various parameters

 4: EffectsInteractive3DLevel2Reverb enviroEffects = enviroEffect.AllParameters;

 5: 

 6: enviroEffects.DecayHfRatio = 2.0f;

 7: enviroEffects.DecayTime = 2.0f;

 8: enviroEffects.Density = 1.0f;

 9: enviroEffects.Diffusion = 2.0f;

 10: enviroEffects.Reflections = 1;

 11: enviroEffects.Reverb = 2;

 12: 

 13: // Set them back on the effect class

 14: enviroEffect.AllParameters = enviroEffects;

 15: }

You must remember to assign the modified Effects structure back to the AllParameter property of the class.

Or, for the  Interactive3DLevel2ReverbEffect you can chose one of the preset environments and simply update the Preset property of the effect class.

C#

 1: if ( enviroEffect != null )

 2: {

 3: // Choose a preset

 4: enviroEffect.Preset = EffectsEnvironmentPreset.Hangar;

 5: }

Note that you do not have to set the effects class back to the SecondaryBuffer since you were manipulating only its value and you had to set it in the first place to get it. What's even cooler is that all effects can be changed while the buffer is playing but there is one caveat.

Changes to sounds may not be heard immediately since DirectX buffers about 100 milliseconds of sound starting at the play cursor. If you call any of these methods and then change the parameters then buffer rule is in effect and the changes are not heard immediately.

SecondaryBuffer.SetCurrentPosition
SecondaryBuffer.SetEffects
SecondaryBuffer.Stop
SecondaryBuffer.Write

To overcome the buffer rule either call Stop or SetCurrentPostion. We take advantage of the built in Stop method of our SoundEffects class which stops the sound and resets the stream position to the beginning of the stream, in effect clearing the buffered sound.

C#

 1: public void Stop()

 2: {

 3: _secondaryBuffer.Stop();

 4: _secondaryBuffer.SetCurrentPosition(0);

 5: }

In the SoundEffects class add the following method. Before you can add effects to a SecondaryBuffer you first need to stop the buffer. Then you can add the EffectDescription array passed into the method to the secondary buffer and restart it.

C#

 1: public bool AddEffects ( EffectDescription[] effectDescription )

 2: {

 3: Stop ( );

 4: EffectsReturnValue[] effectreturn = _secondaryBuffer.SetEffects ( effectDescription );

 5: Play ( );

 6: 

 7: return true;

 8: }

Adding effects to a SecondaryBuffer simply requires you to pass an array of EffectDescription structs to the SetEffects method of the secondary buffer. This method returns an array of EffectsReturnValue enumerations to report the result of the operation. The return value can be any combination of seven values, including failure.

Next we add the method to get the effect back from the buffer

C#

public object GetEffect ( int position )

{

return _secondaryBuffer.GetEffects ( position );

}

Note that the effects are returned as objects and must be cast to their correct types before use.

That's it for the changes required to the SoundEffect class. You have now successfully added you first effect to the game.

As a caveat, the documentation points out that effect might not work well on very small buffer of less than 150 millisecond length.

Update the GameEngine class

The first step is to reference the Microsoft.DirectX.DirectSound in the GameEngine class since we are going to be creating the effects classes and structures in the ConfigureSounds method of this class.

C#

using Microsoft.DirectX.DirectSound;

Since we now have two namespaces references that contain a Caps class we need to update the Caps class in the ConfigureDevice method to be fully qualified to avoid namespace collisions.

C#

Microsoft.DirectX.Direct3D.Caps caps = Microsoft.DirectX.Direct3D.Manager.GetDeviceCaps ( adapterOrdinal, Microsoft.DirectX.Direct3D.DeviceType.Hardware );

In the ConfigureSounds method of the GameEngine class add all the following code right after the creation of the engineSound1

C#

 1: Microsoft.DirectX.DirectSound.EffectDescription[] effects = new Microsoft.DirectX.DirectSound.EffectDescription[ 1 ];

 2: effects[ 0 ].GuidEffectClass = DSoundHelper.StandardGargleGuid;

 3: engineSound1.AddEffects ( effects );

 4:  

 5: // Get the effect back so we can set it to the value we want

 6: GargleEffect gargle = engineSound1.GetEffect ( 0 ) as GargleEffect;

 7:  

 8: if ( gargle != null )

 9: {

 10: EffectsGargle gargle_params = gargle.AllParameters;

 11: gargle_params.WaveShape = 1;

 12:  

 13: gargle.AllParameters = gargle_params;

 14: }

Next we rinse and repeat for engineSound2 using a different effect.

 1: effects = new Microsoft.DirectX.DirectSound.EffectDescription[ 1 ];

 2: effects[ 0 ].GuidEffectClass = DSoundHelper.StandardGargleGuid;

 3: engineSound2.AddEffects ( effects );

 4:  

 5: // Get the effect back so we can set it to the value we want

 6: FlangerEffect flanger = engineSound2.GetEffect ( 0 ) as FlangerEffect;

 7:  

 8: if ( flanger != null )

 9: {

 10: EffectsFlanger flanger_params = flanger.AllParameters;

 11: flanger_params.Waveform = 1;

 12:  

 13: flanger.AllParameters = flanger_params;

 14: }

All done. Combined with the 3DListener the three effects we have applied to the game should make it easier to change the few sound we have.

Granted, we did not make extensive use of all the available effects. But at this point you should know how to assign any effect you wish to the sounds in the game. Experiment with the various effects and their parameters and choose those that you think fit your game the best.

Summary

Now we have pretty much completed the pass through the basic functionality of the DirectSound namespace. There are a lot of different effects you can implement using the effects provided with DirectSound. As always, the best way to learn and understand all of them is to experiment. In the next article we are going to use the DirectXAudioVideoPlayback namespace to play MP3 files to provide a soundtrack for the game. Then we are going to focus on some non DirectX parts of game development - Artificial Intelligence (AI). Until then: Happy coding.

Derek Pierson is a software developer with 12 years experience designing and developing enterprise applications using a variety of programming languages. He is an enthusiastic teacher of the art of programming and believes that elegance and simplicity are defining features of good software.

Introduction

Welcome to the seventh article on beginning game development. In the last article, we covered how lights and materials can add realism to a scene. We also discussed how to create a terrain from a heightmap, and finally added fonts to the application. In this article, we are going to refine the way the terrain looks and start incorporating it into our game.

Before we start, let's do the obligatory code cleanup, incorporating all the feedback I received.

Code cleanup

The cleanup for this article consists of some minor refactoring to keep the code clean and some changes to the lights and normals for the lighting.

• Handle DeviceResizing event.
• Manage Device events (see next section).
• Changed the ambient and diffuse light to be darker. If you use Color.White for the ambient light, there is already 100% so any other light is not visible. Instead, I am now using Color.FromArgb ( 64, 64, 64 ) for the ambient and Color.FromArgb ( 128, 128, 128 ) for the diffuse light.
• Added _device.RenderState.NormalizeNormals = true; so that the normals are recalculated when scaling the terrain. You can remove this call if you are not scaling the terrain since it has some performance cost.
• In the last article, I incorrectly stated that presentParams.AutoDepthStencilFormat = DepthFormat.D16; was setting up a DepthStencil, this code is actually settings up a DepthBuffer. For a clarification check out these links:
  • http://en.wikipedia.org/wiki/Depth_buffer
  • http://en.wikipedia.org/wiki/Stencil_buffer

Device Handling

Up to this point we have pretended that once we have initialized the graphics device nothing can go wrong until we are done using it. In the real world things do go wrong, and in the DirectX world losing the device can happen in response to a number of user actions, such as Alt-tabbing from application to application, minimizing a window, or certain power management functions.

Once the device has been lost, all render functions will silently fail and the render operations will not return an error code even though they are really failing. Any calls to render functions, such as DrawIndexedPrimitives are discarded until the device is reset. Any call to Device.Present however will cause an exception.

There are two exceptions that are associated with lost devices:

DeviceLostException: The device is lost and cannot be reset.

DeviceNotResetException: The device is lost and can be reset.

To detect the device lost state, DirectX provides the DeviceLost event for the Device object. Once the Device has been lost, it must be reset to function properly. You can also check if a device is in the lost state using the CheckCopperativeLevel property of the device.

Once the Device is lost the application will query the Device and determine if it can be restored to the operational state. If it can be restored, then all video memory resources placed in Pool.Default and swap chains are destroyed and the Reset method is called. Resources created in Pool.Managed are backed by system memory and do not have to be destroyed and recreated. If the device cannot be reset then the application waits until it can be restored.

The Reset method is the only method that has any effect on the application once a device has been lost and is the only way to change a device from the lost state to the operational state. The Reset method will fail unless the application has released all resources allocated, so resources created in the DeviceReset event should be destroyed in the DeviceLost event.

Enough theory. We need to update BattleTank2005 to detect the device reset and lost events and react to them.

At the bottom of the ConfigureDevice method of the GameEngine class add the following code:

Visual C#

_device.DeviceReset+=new EventHandler(OnDeviceReset);
_device.DeviceLost+=new EventHandler(OnDeviceLost);
_device.Disposing+=new EventHandler(OnDeviceDisposing);
OnDeviceReset ( this, null );

Visual Basic

AddHandler m_device.DeviceLost, AddressOf OnDeviceLost
AddHandler m_device.DeviceReset, AddressOf OnDeviceReset
AddHandler m_device.Disposing, AddressOf OnDeviceDisposing
OnDeviceReset(Me, Nothing)

Now add the following three methods to the GameEngine class:

Visual C#

private void OnDeviceReset(object sender, EventArgs e)
{
    if ( _font != null )
        _font.OnResetDevice ( );
    // Turn on some low level ambient light
    _device.RenderState.Ambient = Color.LightGray;
}
private void OnDeviceLost(object sender, EventArgs e)
{
    if ( _font != null && _font.Disposed == false )
        _font.OnLostDevice ( );
}
private void OnDeviceDisposing(object sender, EventArgs e)
{
    if ( _mouse != null )
        _mouse.Dispose ( );
    if ( _keyboard !=null )
        _keyboard.Dispose ( );
    if ( _terrain != null )
        terrain.Dispose ( );
}

Visual Basic

Private Sub OnDeviceReset(ByVal sender As Object, ByVal e As EventArgs)
    If (Not (m_font) Is Nothing) Then
        m_font.OnResetDevice()
    End If
    m_device.Transform.Projection = m_camera.Projection
    ' Turn on some low level ambient light
    m_device.RenderState.Ambient = Color.FromArgb(64, 64, 64)
    m_device.RenderState.NormalizeNormals = True
End Sub
Private Sub OnDeviceLost(ByVal sender As Object, ByVal e As EventArgs)
    If Not (m_font Is Nothing) AndAlso m_font.Disposed = False Then
        m_font.OnLostDevice()
    End If
End Sub
Private Sub OnDeviceDisposing(ByVal sender As Object,
  ByVal e As EventArgs)
    If (Not (m_mouse) Is Nothing) Then
        m_mouse.Dispose()
    End If
    If (Not (m_keyboard) Is Nothing) Then
        m_keyboard.Dispose()
    End If
    If (Not (m_terrain) Is Nothing) Then
        m_terrain.Dispose()
    End If
End Sub

Check out the comments in the code for a more detailed explanation.

Textures

In the last article we used a single texture file and stretched it across the terrain to make the terrain more realistic. Textures provide us with the ability to map images onto the surfaces of our shapes

When you apply a 2D texture to a 3D shape you need to somehow match the texture coordinates to the coordinates of the shape. You accomplish this by mapping the coordinates of the texture to the coordinates of the shape. The Tu and Tv values are nothing other than the X/Y coordinates of the texture (a single u,v pair is also called a "texel"). The main difference is that texture coordinates are two dimensional and fall into the range of 0.0f – 1.0f.

In the code we simply assign each texture coordinate to the matching mesh coordinate by dividing it by the number of quads. Doing this results in a single texel spanning a single quad of the terrain.

Visual C#

vertex.Tu = (float)x / _numberOfQuadsX;
vertex.Tv = (float)z / _numberOfQuadsZ

Visual Basic

vertex.Tu = CType(x, Single) / _numberOfQuadsX
vertex.Tv = CType(z, Single) / _numberOfQuadsZ

In addition to this simple approach you could also use multiple textures at a time. This is called multitexturing and is a topic well worth exploring for any developer trying to create the most realistic terrain. We are only using single texture right now, but multitexturing explains why we passed a zero to the SetTexture call in the Render method of the Terrain class. The zero, as you may have guessed identified the texture as the first texture to be used.

Visual C#

_device.SetTexture ( 0, _terrainTexture );

Visual Basic

_device.SetTexture(0, _terrainTexture)

There are a number of other tweaks you can do to the way the texture is displayed but none really changes the way we are using the terrain texture in code.

DirectX uses a technique called "Filtering" to smooth out any distortions caused when a texture triangle is magnified or minified to fit the screen triangle. You should experiment with changing the SamplerStageStates value passed to the Device.SetSamplerState method. As always you are making a tradeoff between speed and detail.

Another solution to the distortion problem is to use mipmaps. This approach uses a series of smaller lower resolution textures chained together. If you use the FromFile method of the TextureLoader, DirectX automatically generates a mipmap chain. If you are graphically inclined or want to squeeze the best possible result from the texture you can also use the texture editor included with the DirectX SDK (DxTex.exe) to generate a mipmap chain. (This editor is also useful in a number of other texture manipulation functions.)

The result we achieved using the Down.jpg file in BattleTank2005 was passable but it was pretty boring. If you use a third party tool you can create a terrain texture customized for your heightmap with much better results than we achieved, but what if you want to generate random terrain for each level? The answer is procedural terrain generation.

Procedural Terrain Generation

The texture we used was the bottom of the skybox, and the coloration and highlights in the texture had no relationship to the landscape created by the heightmap. Another option is to use this same technique, but use a texture file specifically created for the heightmap (or more accurately the heightmap and texture are created at the same time) using a program such as Terragen. This approach lets you fiddle with the texture file until it is exactly the way you want it, but it is fairly labor intensive, especially if you want to offer the player a large number of maps to play on.

Yet another approach is to generate the texture file with a heightmap and a couple of texture files using a process called "Procedural Texture Generation." With this approach you can use texture files to represent the terrain at various heights. For example, you could specify a sand texture for low elevations, grass texture for the next elevation levels, rock texture for the next and finally a snow texture for the highest elevations.

The first step is to separate the terrain into regions by elevations. Remember for the last article that we can represent 256 distinct elevations using a grayscale heightmap. If you divide that value by four then each region covers 64 elevation units.

Each of these regions is associated with a texture file which means that the resulting terrain texture will use the color of the texture at that location.

There is one more refinement we need to add, however. Rather than simply using the same color for all elevations within a range we want to blend the textures so that there is a more gradual change of textures from region to region. We accomplish this by calculating the percentage of each texture at each elevation and then blending the colors.

To create the texture map I added another Solution to the source code called TerrainGenerator. This console application takes four texture files and one heightmap in RAW format and creates the terrain texture. If you were using some of the methods I mentioned in my previous article to automatically generate the heightmap, you could combine these two features and auto-generate the terrain for each level on the fly. I will leave that implementation up to you.

All of the code in the main method simply manages the input parameters and does some validation so I will not cover it in detail. The real meat of the application is the CreateTerrainTexture method. After setting up some arrays and variables to hold the various pieces of data we enter a double loop which performs the actual work.

Visual C#

for ( int z = 0; z < _numberOfVerticesZ; z++ )
{
    for ( int x = 0; x < _numberOfVerticesX; x++ )
    {
        // Implementation code below
    }
}

Visual Basic

Dim z As Integer = 0
While z < _numberOfVerticesZ
    Dim x As Integer = 0
    While x < _numberOfVerticesX
        'Implementation code below
        x = x + 1
    End While
    z = z + 1
End While

The first step is to get the elevation value at the coordinates in question.

Visual C#

elevation =(float) heightmap[ ( z * _numberOfVerticesZ ) + x ];

Visual Basic

elevation = CType(heightmap(((z * _numberOfVerticesZ) + x)), Single)

Using this value we then compute the texture percent (for example, how much of each texture is visible at that elevation). Since we have four textures in this sample we do this four times.

Visual C#

textureFactor[0] = ComputeTexturePercent ( 256, elevation );
textureFactor[1] = ComputeTexturePercent ( 192, elevation );
textureFactor[2] = ComputeTexturePercent ( 128, elevation );
textureFactor[3] = ComputeTexturePercent ( 64, elevation );

Visual Basic

textureFactor(0) = ComputeTexturePercent(256, elevation)
textureFactor(1) = ComputeTexturePercent(192, elevation)
textureFactor(2) = ComputeTexturePercent(128, elevation)
textureFactor(3) = ComputeTexturePercent(64, elevation)

The actual ComputeTexturePercent method returns a value between 0.0 and 1.0 representing the percent of the texture visible at a given height.

Visual C#

private static float ComputeTexturePercent ( float h1, 
    float elevation)
{
    float regionSize = 256/4;
    float texturePercent = ( regionSize - Math.Abs ( elevation-h1 ) )
     / regionSize;
    if ( texturePercent < 0.0f )
        texturePercent = 0.0f;
    else if ( texturePercent > 1.0f )
        texturePercent = 1.0f;
    return texturePercent;
}

Visual Basic

Private Function ComputeTexturePercent(ByVal h1 As Single,
  ByVal elevation As Single) As Single
    Dim regionSize As Single = (256 / 4)
    Dim texturePercent As Single = ((regionSize - Math.Abs((
        elevation - h1))) / regionSize)
    If (texturePercent < 0.0!) Then
        texturePercent = 0.0!
    ElseIf (texturePercent > 1.0!) Then
        texturePercent = 1.0!
    End If
    Return texturePercent
End Function

The next step is to get the RGB values for the coordinate from each of the textures.

Visual C#

for ( int i = 0; i < 4; i++ )
{
    Color color = textures[i].GetPixel ( x, z );
    oldR[i] = color.R;
    oldG[i] = color.G;
    oldB[i] = color.B;
}

Visual Basic

Dim i As Integer = 0
Do While (i < 4)
    Dim color As Color = textures(i).GetPixel(x, z)
    oldR(i) = color.R
    oldG(i) = color.G
    oldB(i) = color.B
    i = (i + 1)
Loop

This "old" value is then used together with the texture factor to compute the new RGB value.

Visual C#

Dim i As Integer = 0
Do While (i < 4)
    Dim color As Color = textures(i).GetPixel(x, z)
    oldR(i) = color.R
    oldG(i) = color.G
    oldB(i) = color.B
    i = (i + 1)
Loop

Visual Basic

newR = ((textureFactor(0) * oldR(0)) + 
       ((textureFactor(1) * oldR(1)) + 
       ((textureFactor(2) * oldR(2)) + 
       (textureFactor(3) * oldR(3)))))
newG = ((textureFactor(0) * oldG(0)) + 
       ((textureFactor(1) * oldG(1)) + 
       ((textureFactor(2) * oldG(2)) + 
       (textureFactor(3) * oldG(3)))))
newB = ((textureFactor(0) * oldB(0)) + 
       ((textureFactor(1) * oldB(1)) + 
       ((textureFactor(2) * oldB(2)) + 
       (textureFactor(3) * oldB(3)))))

The final step is to create the new color and set the pixel in the terrain texture to that color.

Visual C#

Color newColor = Color.FromArgb ( (int)newR, (int)newG, (int)newB );
finalTexture.SetPixel ( x, z, newColor );

Visual Basic

Dim newColor As Color = Color.FromArgb(CType(newR, Integer), 
    CType(newG, Integer), CType(newB, Integer))
finalTexture.SetPixel(x, z, newColor)

When all is said and done, this is the result.

The approach we took to create the terrain texture is the simplest approach possible. As I stated in the last article there are people that do nothing else but work on better ways to create realistic-looking terrain. Some enhancements that could be made to our approach are:

• Take into account slope. For example: Snow would not stick to an almost vertical surface, instead the underlying terrain would show. You could represent this as showing the snow texture when the slope is between 0% and 80% but show rock when the slope is greater then 80%.
• Angle of the sun and the shade areas resulting from this. Snow might exist at lower elevations that are in the shade, but not at higher elevations not in the shade.
• Climate. Different vegetation will grow in wetter climates and the terrain will drain differently depending on slope and ability of the water to run off.
• Using a number of different textures for the same elevation range (i.e. different grass textures) increases the realism.

Regardless of how precise you are when creating the terrain, the resolution of the terrain texture has the single biggest impact on how realistic the scene looks. As usual you must learn how to balance the cost of loading a large texture file that provides a high level of detail with the performance cost.

Before we integrate the terrain generated we need to (or I want to) update the way we move the camera around.

New Camera

The camera class we have used so far does its job, but I want to replace it with a more traditional implementation of a First Person Shooter camera.

Check out this article to see the theory behind the changes: http://www.toymaker.info/Games/html/camera.html.

As we are moving around on the terrain we maintain the pitch values provided by the mouse. To make the camera a more realistic first person camera we need to take control the Yaw, Roll and Pitch of the camera. This way we can adjust the camera to the underlying terrain. For example: if we are driving up the side of a steep hill, the pitch and roll of the camera should be equal to the slope we are on. The Yaw of the camera is the same as the heading and changes only based on user input, not on any terrain features.

Yaw, Pitch and Roll combine to describe the attitude of an object. Yaw expresses the rotation around the Y axis, Pitch the X axis and Roll the Z axis.

To implement this change we are going to add a couple of methods to the camera class and make some other minor modifications.

First we add a method each to control the Yaw, Pitch and Roll.

Visual C#

public void AdjustYaw ( float radians )
{
    Matrix rotation = Matrix.RotationAxis (_up, radians );
    _right = Vector3.TransformNormal ( _right, rotation );
    _look = Vector3.TransformNormal ( _look, rotation );
}
public void AdjustPitch ( float radians )
{
    _pitch -= radians;
    if ( _pitch > _maxPitch )
    {
        radians += _pitch - _maxPitch;
    }
    else if ( _pitch < -_maxPitch )
    {
        radians += _pitch + _maxPitch;
    }
    Matrix rotation = Matrix.RotationAxis ( _right, radians );
    _up = Vector3.TransformNormal ( _up, rotation );
    _look = Vector3.TransformNormal ( _look, rotation );
}
public void AdjustRoll ( float radians )
{
    Matrix rotation = Matrix.RotationAxis( _look, radians );
    _right = Vector3.TransformNormal( _right, rotation );
    _up = Vector3.TransformNormal( _up, rotation );
}

Visual Basic

Public Sub AdjustYaw(ByVal radians As Single)
    If (radians = 0.0!) Then
        Return
    End If
    Dim rotation As Matrix = Matrix.RotationAxis(_up, radians)
    _right = Vector3.TransformNormal(_right, rotation)
    _look = Vector3.TransformNormal(_look, rotation)
End Sub
Public Sub AdjustPitch(ByVal radians As Single)
    If (radians = 0.0!) Then
        Return
    End If
    _pitch = (_pitch - radians)
    If (_pitch > _maxPitch) Then
        radians = (radians _
                + (_pitch - _maxPitch))
    ElseIf (_pitch _
                < (_maxPitch * -1)) Then
        radians = (radians _
                    + (_pitch + _maxPitch))
    End If
    Dim rotation As Matrix = Matrix.RotationAxis(_right, radians)
    _up = Vector3.TransformNormal(_up, rotation)
    _look = Vector3.TransformNormal(_look, rotation)
End Sub
Public Sub AdjustRoll(ByVal radians As Single)
    If (radians = 0.0!) Then
        Return
    End If
    Dim rotation As Matrix = Matrix.RotationAxis(_look, radians)
    _right = Vector3.TransformNormal(_right, rotation)
    _up = Vector3.TransformNormal(_up, rotation)
End Sub

Then we change the Update method to compute the View matrix.

Visual C#

public void Update (  )
{
    if ( Vector3.Length ( _velocity ) > _maxVelocity )
    _velocity = Vector3.Normalize ( _velocity ) * _maxVelocity;
    // Update 
    _postion += _velocity;
    // Stop
    _velocity = new Vector3 ( );
    _lookAt = _postion + _look;
    
    Vector3 up = new Vector3 ( 0.0f, 1.0f, 0.0f );
    _viewMatrix = Matrix.LookAtLH ( _postion, _lookAt, up );
    _right.X = _viewMatrix.M11;
    _right.Y = _viewMatrix.M21;
    _right.Z = _viewMatrix.M31;
    _up.X = _viewMatrix.M12;
    _up.Y = _viewMatrix.M22;
    _up.Z = _viewMatrix.M32;
    _look.X = _viewMatrix.M13;
    _look.Y = _viewMatrix.M23;
    _look.Z = _viewMatrix.M33;
 
    float lookLengthOnXZ = (float)Math.Sqrt ( _look.Z * _look.Z +
    _look.X * _look.X );
    _pitch = (float)Math.Atan2 ( _look.Y, lookLengthOnXZ );
    _yaw = (float)Math.Atan2 ( _look.X, _look.Z );
 
    ComputeViewFrustum ( );
}

Visual Basic

Public Sub Update()
    If (Vector3.Length(_velocity) > _maxVelocity) Then
        _velocity = (Vector3.Normalize(_velocity) * _maxVelocity)
    End If
    ' Update 
    _postion = (_postion + _velocity)
    ' Stop
    _velocity = New Vector3
    _lookAt = (_postion + _look)
    Dim up As Vector3 = New Vector3(0.0!, 1.0!, 0.0!)
    _viewMatrix = Matrix.LookAtLH(_postion, _lookAt, up)
    _right.X = _viewMatrix.M11
    _right.Y = _viewMatrix.M21
    _right.Z = _viewMatrix.M31
    _up.X = _viewMatrix.M12
    _up.Y = _viewMatrix.M22
    _up.Z = _viewMatrix.M32
    _look.X = _viewMatrix.M13
    _look.Y = _viewMatrix.M23
    _look.Z = _viewMatrix.M33
    Dim lookLengthOnXZ As Single = CType(Math.Sqrt(((_look.Z * _look.Z) _
                    + (_look.X * _look.X))), Single)
    _pitch = CType(Math.Atan2(_look.Y, lookLengthOnXZ), Single)
    _yaw = CType(Math.Atan2(_look.X, _look.Z), Single)
    ComputeViewFrustum()
End Sub

We also added a max pitch value and a control value for the camera speed. The camera speed is adjusted using the deltaTime variable to yield a smoother motion.

Visual C#

m_maxPitch = Geometry.DegreeToRadian( 89.0f )
m_maxVelocity = 1.0f;

Visual Basic

Dim _maxPitch As Single = Geometry.DegreeToRadian(89.0F)
Dim _maxVelocity As Single = 1.0F

Next we need to instantiate the camera a little differently. In the Initialize method of the GameEngine class add the following code.

Visual C#

_camera = new Camera ( );
_camera.MaxVelocity = 100.0f;
_camera.Position = new Vector3 ( 0.0f, 0.0f, 0.0f );
_camera.LookAt = new Vector3 ( 0.0f, 0.0f, 0.0f );
_camera.Update ( );

Visual Basic

m_camera = New Camera
m_camera.MaxVelocity = 100.0F
m_camera.Position = New Vector3(0.0F, 0.0F, 0.0F)
m_camera.LookAt = New Vector3(0.0F, 0.0F, 0.0F)
m_camera.Update()

With these changes to the camera class, integrating the terrain into the game will be a lot easier. It also shows you that there are many ways of accomplishing the same task. You should experiment with the various versions and choose the one you like best.

Terrain Elevation

In the last article you may have noticed that we used the Scaling matrix to change the size of the terrain mesh before rendering. These scale variables must be applied to any coordinate resolutions, so I moved them into separate variables. Remember to set add _device.RenderState.NormalizeNormals = true to recompute the normals.

At the bottom of the Terrain class add the following code.

Visual C#

private float _scaleX = 1.0f;
private float _scaleZ = 1.0f;
private float _scaleY = 0.3f;

Visual Basic

Dim _scaleX As Single = 4.0!
Dim _scaleZ As Single = 4.0!
Dim _scaleY As Single = 0.5!

In the Render method of the Terrain class change the line of code that computes up the scaling matrix to:

Visual C#

_device.Transform.World = Matrix.Scaling ( _scaleX, _scaleY, _scaleZ );

Visual Basic

_device.Transform.World = Matrix.Scaling(_scaleX, _scaleY, _scaleZ)

Now we can determine the height (Y) of the terrain at any given coordinate set, taking into account the scale applied. Add the following method to the Terrain class.

Visual C#

public float TerrainHeight ( int x, int z )
{
    x = x / (int)_scaleX;
    z = z / (int)_scaleZ;
    if ( _isHeightMapRAW )
    return (float)( _elevationsRAW[ ( z * _numberOfVerticesZ )
        + x] ) * _scaleY;
    else
    return (float)( _elevations[(int)x,(int)z] ) / _scaleY;
}

Visual Basic

Public Function TerrainHeight(ByVal x As Integer, ByVal z As Integer) As Single
    x = (x / CType(_scaleX, Integer))
    z = (z / CType(_scaleZ, Integer))
    If m_isHeightMapRAW Then
        Return (CType(_elevationsRAW(((z * _numberOfVerticesZ) + x)),
            Single) * _scaleY)
    Else
        Return (CType(_elevations(CType(x, Integer), CType(z, Integer)), 
           Single) / _scaleY)
    End If
End Function

All we are doing is retrieving the Y value from the elevation array based on the X and Z coordinates passed in. Make sure to change the scaling values from multiplication to division when the scaling value is greater then 1.

Now we need to adjust the Y coordinate of the camera to the appropriate Y value of the terrain. In the Render method of the GameEngine class add the following line of code immediately after the call to the Update method of the camera.

Visual C#

camera.SetHeight ( _terrain.TerrainHeight ( (int)_camera.Position.X, (int)_camera.Position.Z ) );

Visual Basic

m_camera.SetHeight(m_terrain.TerrainHeight(m_camera.Position.X, 
    m_camera.Position.Z))

At this point you would probably want to disable the Q and Z keys so the players cannot change the Y values on their own. The last step is to add a new method to the camera class that allows us to directly set the height of the camera. The heightOfTurret variable ensures that we are slightly above the terrain to avoid clipping as we drive around. Go ahead and change the value to 0 to see what I mean.

Visual C#

public void SetHeight ( float y )
{
    float heightOfTurret = 1.5f;
    _postion.Y = y + heightOfTurret;
}

Visual Basic

Public Sub SetHeight(ByVal y As Single)
    Dim heightOfTurret As Single = 1.5!
    _postion.Y = (y + heightOfTurret)
End Sub

The net effect of these changes is that we can now "drive" across the terrain. You need to make sure to disable the input for moving along the Y axis (Q and Z) when you are doing this. There are a number of other changes that need to be made to make the camera and the terrain work together for a smooth game experience. I am out of space but you can see how you would constrain the movement of the player/camera to the extents of the terrain (to make sure we don't fall of the terrain mesh). You could also adjust the pitch and roll of the camera based on the slope of the terrain. Hint: the heading is important in both instances.

Summary

There are a number of more advanced terrain concepts which I purposely skipped for right now but will return to later on. If you search for "Terrain DirectX" you will get more information then you can possibly digest, but then remember that some developers specialize in nothing else.

Until then: Happy coding.

Introduction

Welcome to the sixth article on beginning game development. Last time I promised we would discuss lighting, terrain building and collision detecting in this article, but there is enough information in terrain building alone to cover multiple articles and the same holds true for collision detection. So instead, I am going to cover Lights and Materials and give a very basic introduction to terrain building in this article, and go into more depth about terrain building and collision detection in the next article.

Before we start, let's do the obligatory code cleanup, incorporating all the feedback I received.

Code cleanup

The cleanup for this article consists mainly of version upgrades and some minor performance improvements.

• Updated to the release version of Visual Studio Express
  
• Updated to the October 2005 DirectX SDK.
  
• Added the following code to the ConfigureDevice method. Depth stencils enable the application to mask sections of the rendered image so they are not displayed, which increases performance. This code simply enables a 16-bit Z-Buffer depth stencil.
  
• presentParams.AutoDepthStencilFormat = DepthFormat.D16;
  
• presentParams.EnableAutoDepthStencil = true;
  
• Added ClearFlags.ZBuffer to the Device.Clear method call in the Render method. This is to support the Depth Stencil added.
  
• Added a speed parameter to the constructor of the Tank class.

Fonts

The only feedback provided to the game player so far has been the frame rate that was displayed in the title bar of the form. We also have written out some information to the console window, but that isn't very useful when running the game as an executable. In addition to the frame rate, I want to be able to display the location and heading. To do this we are going to start using DirectX fonts. The example here is the simplest case of drawing text to the screen; see the Text3D sample in the DirectX SDK for a more extensive explanation and detailed samples.

The first step is to declare the variable in the GameEngine class. I am using a fully qualified name, so there are no namespace collisions between the Font class in the Direct3D namespace and that in the System.Drawing namespace.

Visual C#

private Microsoft.DirectX.Direct3D.Font _font;

Visual Basic

Private m_font As Microsoft.DirectX.Direct3D.Font

Next initialize the Font class in the constructor of the GameEngine class.

Visual C#

font = new Microsoft.DirectX.Direct3D.Font(_device, 
   new System.Drawing.Font("Arial", 14.0f, FontStyle.Italic));

Visual Basic

m_font = New Microsoft.DirectX.Direct3D.Font(m_device, 
   New System.Drawing.Font("Arial", 14.0F, FontStyle.Italic))

The parameters should be self explanatory. Note that the DirectX Font class uses a Drawing Font class in its constructor.

All of the functionality to draw the various values to the screen is encapsulated in the RenderFonts method of the GameEngine class. This class uses the DrawText method of the Font class to actually render the text to the screen.

Visual C#

private void RenderFonts()
{
    // display the heading and pitch
    _font.DrawText(null, string.Format(
        "Heading={0:N000}, Pitch ={1:N000}", 
        _camera.Heading, _camera.Pitch), 
        new Rectangle(0, 0, this.Width, this.Height),
        DrawTextFormat.NoClip | DrawTextFormat.ExpandTabs |
        DrawTextFormat.WordBreak, Color.Yellow);

    // Display the Postion Direction
    _font.DrawText(null, string.Format("X={0}, Y={1}, Z={2}",   
        _camera.Position.X, _camera.Position.Y, _camera.Position.Z), 
        new Rectangle(0, 20, this.Width, this.Height),
        DrawTextFormat.NoClip | DrawTextFormat.ExpandTabs |  
        DrawTextFormat.WordBreak, Color.Yellow);

    // Display the frame rate
    _font.DrawText(null, string.Format("FPS={0}", 
        FrameRate.CalculateFrameRate()), 
        new Rectangle(0, 60,this.Width, this.Height),
        DrawTextFormat.NoClip | DrawTextFormat.ExpandTabs | 
        DrawTextFormat.WordBreak, Color.Yellow);

    // display Lighting state
    _font.DrawText(null, string.Format("Lights={0}", 
        _lightOn ? "On" : "Off"), 
        new Rectangle(this.Width - 110, 0,this.Width, this.Height),
        DrawTextFormat.NoClip | DrawTextFormat.ExpandTabs | 
        DrawTextFormat.WordBreak, Color.Yellow);
}

Visual Basic

Private Sub RenderFonts()

        ' display the heading and pitch
        m_font.DrawText(Nothing, String.Format(
            "Heading={0:N000}, Pitch ={1:N000}", 
            m_camera.Heading, m_camera.Pitch), 
            New Rectangle(0, 0, Me.Width, Me.Height), 
            DrawTextFormat.NoClip Or DrawTextFormat.ExpandTabs Or 
            DrawTextFormat.WordBreak, Color.Yellow)

        ' Display the Postion Direction
        m_font.DrawText(Nothing, String.Format(
            "X={0}, Y={1}, Z={2}", m_camera.Position.X,
            m_camera.Position.Y, m_camera.Position.Z), 
            New Rectangle(0, 20, Me.Width, Me.Height),
            DrawTextFormat.NoClip Or DrawTextFormat.ExpandTabs Or
            DrawTextFormat.WordBreak, Color.Yellow)

        ' Display the frame rate
        m_font.DrawText(Nothing, String.Format(
            "FPS={0}", FrameRate.CalculateFrameRate()), 
            New Rectangle(0, 60, Me.Width, Me.Height),
            DrawTextFormat.NoClip Or DrawTextFormat.ExpandTabs Or
            DrawTextFormat.WordBreak, Color.Yellow)

        ' display Lighting state
        If m_lightOn = True Then
            m_font.DrawText(Nothing, "Lights=On", 
                New Rectangle(Me.Width - 110, 0, Me.Width, Me.Height),
                DrawTextFormat.NoClip Or DrawTextFormat.ExpandTabs Or
                DrawTextFormat.WordBreak, Color.Yellow)
        Else
            m_font.DrawText(Nothing, "Lights=Off", 
                New Rectangle(Me.Width - 110, 0, Me.Width, Me.Height),
                DrawTextFormat.NoClip Or DrawTextFormat.ExpandTabs Or
                DrawTextFormat.WordBreak, Color.Yellow)
        End If

    End Sub

The first two calls to the DrawText method of the GameEngine class add the heading and pitch information and position of the camera. These two pieces of information now allow me to properly orient myself in the 3D world. The last two items add the frame rate counter (I removed the one in the title of the form) and a lighting state indicator that is useful when experimenting with lighting.

The location of the text on the screen is determined by the Rectangle class. The first two values determine where the upper left hand corner of the rectangle is (in screen coordinates), while the last two determine the size of the rectangle.

Lighting

Up to this point we have turned lighting off by setting the Lighting property of the RenderState to false. This means that every object vertex is drawn solely based on its defined color. Turning lighting on adjusts the color of each vertex by combining:

• Its current Material color
  
• Texels in associated texture maps
  
• Diffuse and Specular colors
  
• Color and intensity of all lights in the scene, including the ambient light

DirectX breaks light into two groups:

1. Ambient: Ambient light is a special type of light that has been scattered so much that it no longer has a direction or source. Ambient light illuminates equally in every direction. For ambient light you can only define color and intensity. Ambient light does not contribute to specular reflection and the level of ambient light is independent of any other lights in the scene. Ambient light is the least expensive (in terms of computational needs) of all the lights. Without ambient light, objects in the shadows would be completely black. In DirectX ambient light is implemented in the Device RenderState.
   
   
2. Directional: As is implied in the name, directional light has a specified direction in addition to a color and intensity. When direct light is reflected it does not contribute to the ambient light level of the scene, but it is used to compute specular highlights. Directional lights are represented by three types of lights which are added to the Lights array of the Device. In DirectX, direction is the distance from the logical origin, regardless of the position of the light in the scene. A direction vector of (0,0,1) points straight into the scene and a direction vector of (0,-1,0) points straight down. You can also create angles by mixing and matching the values in the direction vector.
   • Directional. This is a light source that has no position and produces light that travels parallel in one direction. In games, the sun and the moon are most often modeled as directional lights. Directional lights are relatively inexpensive but should be used in moderation, as adding many of them will negatively impact your frame rate.

     

   • Point. A Point light has a position and radiates light equally in all directions. Examples of point lights are bare light bulbs and torches. Point lights are more expensive than directional lights. Unlike Directional lights, a point light has an attenuation (how the light level decreases over distance) and a range (the maximum distance the light will travel).

     

   • Spot. A spot light is like a flashlight or car headlight. It is the most complex and expensive of all the light types. A spot light has a position and a direction. The light is separated by intensity into two cones: in the inner cone the light shines more brightly than in the outer cone. Only objects that fall within the cone (theta) are illuminated. In addition to defining the position, direction, range and attenuation of the light, you also must define the cone size and amount of falloff between the cones.

     

Materials

In the last article we briefly touched on materials. Materials define how lights reflect off a surface. For each material in DirectX you can set properties that define how it reflects ambient, diffuse and specular light.

Normal: For all this lighting stuff to work, DirectX has to know the vector normal for each face of the object (a cube would have 6 faces). A normal is nothing other than a vector that points away from the face at a 90 degree angle. (Check out the managed SDK documentation, as it has an excellent description of a normal. Go to Introducing DirectX 9.0 > Direct3D Graphics > Getting Started with Direct3D > 3-D coordinate Systems and Geometry > Face and Vertex Normal Vectors.)

Color

DirectX describes color in terms of four components: Red, Green, Blue and Alpha (RGBA). The values of these components can range from 0.0f to 1.0f. While both materials and lights use the same color structure, they use color differently.

For lights, the color values are the amount of light emitted by that color component. A value of 0.0f means that the component is turned off and a value of 1.0 means that it is at max brightness. The Alpha value is not used. You can also set the value to a number higher than 1.0f to create a very bright light or to a negative number to create a light that actually removes light from a scene.

For materials, the color values are the amount of light that is reflected by a surface. A value of 0.0f means that no light for that component is reflected and a value of 1.0f means that all light is reflected for that component.

Color Types

Each type of light can emit four colors. The color of the light interacts with the counterpart in the material to produce the final color used to render the object: e.g. the diffuse color of the light interacts only with the diffuse property of the material.

1. Ambient: Ambient light is the general background light and is the same everywhere in the scene.
   
2. Diffuse: Diffuse light is scattered but still maintains an overall direction. A diffuse surface reflects incoming lights across all angles; this causes the material to look dull or matte.
   
3. Specular: This is the opposite of Diffuse. Specular light is not scattered at all and makes a surface appear reflective. To use specular lighting you must first enable it at the Device Render State.
   
4. Emissive: DirectX also has the principle of Emissive light. This is light that is emitted by objects. Emissive light is not cast onto other objects.

Now enough with the theory, and on to the code.

Adding Lights

The first step is to change the RenderState.Lighting property to true. You can also remove the line entirely, since true is the default value. If you forget this step, then no lights will show regardless of how many lights are enabled. We do this in the ConfigureDevice method, since this is a global setting.

At the bottom of the ConfigureDevice method, add the following code:

Visual C#

_device.RenderState.Lighting = true;

Visual Basic

m_device.RenderState.Lighting = True

Each scene can only contain a single ambient light, but multiple lights of the other three types. For this reason the Ambient light is implemented at the RenderState level while the other lights are stored in the Lights array of the Device class. For BattleTank2005 we add some ambient white light.

At the bottom of the ConfigureDevice method, add the following code immediately after the previous added line of code:

Visual C#

_device.RenderState.Ambient = Color.White;

Visual Basic

m_device.RenderState.Ambient = Color.White

Most modern graphics cards support advanced lighting techniques, such as directional lights, and up to 8 simultaneous active lights (but you can define as many lights as you want and then turn them on/off depending on the scene). The DeviceCaps.MaxActiveLights property of the Device determines the exact number. If the value is zero, you can not use any lights and must default to ambient lighting only. You can also query the graphics card to see how many other lights it supports, and then adjust your lighting strategy accordingly.

Add a method called CreateLights to the GameEngine class with the following code:

Visual C#

if ( _device.DeviceCaps.MaxActiveLights == 0 )
{
    _device.RenderState.Ambient= Color.White;
}

Visual Basic

If m_device.DeviceCaps.MaxActiveLights = 0 Then
    m_device.RenderState.Ambient = Color.White
End If

For BattleTank2005 we are going to add just one directional light to simulate the sun. In the CreateLights method add the following code.

Visual C#

else
{
    if ( _device.DeviceCaps.MaxActiveLights > 1 )
    {
        // This directional Light is our "sun"
        _device.Lights[0].Type = LightType.Directional;
        // Point the light straight down
        _device.Lights[0].Direction = new Vector3( 0f, -1.0f, 0f);
        _device.Lights[0].Diffuse = System.Drawing.Color.LightYellow;
        _device.Lights[0].Enabled = true;
    }
}

Visual Basic

Else
    If m_device.DeviceCaps.MaxActiveLights > 1 Then
        ' This directional Light is our "sun"
        m_device.Lights(0).Type = LightType.Directional
        ' Point the light down
        m_device.Lights(0).Direction = New Vector3(0.0F, -1.0F, 0.0F)
        m_device.Lights(0).Diffuse = System.Drawing.Color.White
        m_device.Lights(0).Enabled = True
    End If
End If

The last step is to call this method. Add the following code to the constructor of the GameEngine class immediately after the call to CreateTanks.

CreateLights ( );

One other change to make is to turn off the lights when rendering the skybox so it remains unaffected by any light settings. In the Render method of the Skybox class, add the following code immediately after the code disabling the Z-Buffer.

Visual C#

_device.RenderState.Lighting = false;

Visual Basic

m_device.RenderState.Lighting = False

After rendering the skybox we need to make sure to turn the lights back on. Add the following code immediately after the code enabling the Z-buffer.

Visual C#

_device.RenderState.Lighting = true;

Visual Basic

m_device.RenderState.Lighting = True

That's all we need to add lighting. The best way to really understand lighting and materials is seeing them in action. Go ahead and add some of the other light types to the game, or change the materials and see what happens when you manipulate the RGBA values.

Adding Terrain

Have you ever noticed how most games are set in space or indoors? The reason is that creating realistic looking outdoor terrain, without bringing the game to a grinding halt, is very difficult.

Terrain creation is an extensive subject to cover. Some developers specialize in nothing else, so have developed incredibly refined algorithms and methods to display the most realistic terrain, using the least amount of resources. While it is not possible to cover all the methods available, I do want to try to give you an understanding of the basics so that you can enhance Battletank2005 with more a refined technique of your choosing.

Height Map

A terrain starts out as a regular grid mesh. In a regular grid mesh, all the points are equally distant from one another. Each point consists of its X,Z location and a Y value to express the height of the terrain at that point. If we were to create a simple 3x3 terrain the grid would look like this.

This simple 3x3 terrain consists of 18 triangles (or 9 quads) and it takes 36 vertices to define the points required to draw the 18 triangles. These numbers are important to understand because we will use them extensively in creating the terrain.

The easiest way to store the height data is in a height map represented by a grayscale image. Each pixel in the image represents one point in the grid with the height information represented by the gray scale values. Darker colors are lower elevations and lighter colors are higher elevations. Since the number of shades of gray is 256 (0-255) we can represent 256 distinct height values.

Sample Height map

Most applications use the RAW format, which is basically a linear array of bytes. You can think of a RAW file as an image file with the header and footer information stripped out. Loading the height data from a RAW file is much faster than loading it from an image file. I have included methods for both in the code, so you can experiment with them and see for yourself. The big advantage in using an image file over a RAW file is that you can see the heightmap. You can also export image files to a RAW file using a number of free conversion utilities available if you use a program like HME or Terragen to create the height map.

In addition to creating the heightmap manually, you can use algorithms such as Fault Formation or Midpoint Displacement to create them programmatically. This approach would be useful if you include a terrain generator with your game or if you want to support a large number of random terrain setups.

Regardless how you choose to create or load your height information, the entire process of starting with a height map and ending up with a realistic-looking 3D terrain involves the following steps:

1. Load the height information from the height map into an array.
   
2. Store the vertices for the regular grid mesh in a vertex buffer.
   
3. Store the indexes for the regular grid mesh in an index buffer.
   
4. Compute the normals for each triangle.
   
5. Render the vertices as a triangle strip.

Terrain Class

To represent the terrain in BattleTank2005, I added a terrain class. This class will encapsulate all terrain-related logic. The terrain class will be initialized in the constructor and rendered in the regular render loop. To render the terrain we are going to use a single TriangleStrip, a Vertex Buffer and Index Buffer.

The first step is to actually load the height data into memory. The code also contains the method for loading this data from an image, but the preferred method is to load the data from a RAW file.

Visual C#

public void LoadHeightMapFromRAW ( string fileName )
{
    _isHeightMapRAW = true;
    _elevations = null;
  
    using ( Stream stream = File.OpenRead ( fileName ) )
    {
        _elevationsRAW = new byte[(int)stream.Length];
        stream.Read ( _elevationsRAW, 0, (int)stream.Length );
        ComputeValues ( (int)Math.Sqrt( (double)stream.Length ), 
                        (int)Math.Sqrt( (double)stream.Length ));
    }

    // Now load the buffers
    LoadVertexBuffer ( );
            
    LoadIndexBuffer ( );
}

Visual Basic

Public Sub LoadHeightMapFromRAW(ByVal fileName As String)
        m_isHeightMapRAW = True
        _elevations = Nothing

        Dim stream As New FileStream(fileName, FileMode.Open)
        _elevationsRAW = New Byte(stream.Length) {}
        stream.Read(_elevationsRAW, 0, CType(stream.Length, Integer))

        ComputeValues(CType(Math.Sqrt(CType(stream.Length, Double)),
        Integer), CType(Math.Sqrt(CType(stream.Length, Double)), Integer))

        ' Now load the buffers
        LoadVertexBuffer()
        LoadIndexBuffer()
End Sub

The first two lines are only present to support loading height data from both format types. The meat of the method is the stream.Read method. This method copies the content of the stream buffer into the elevation buffer byte array. Accessing the stream inside of the using statement ensures that the stream is properly closed and disposed.

Once the data has been loaded, we use the length of the stream to compute the various values that we will need for terrain generation.

Visual C#

private void ComputeValues ( int width, int height )
{
    // Vertices
    _numberOfVerticesX = width;
    _numberOfVerticesZ = height;
    _totalNumberOfVertices = _numberOfVerticesX * _numberOfVerticesZ;

    // Quads
    _numberOfQuadsX = _numberOfVerticesX - 1;
    _numberOfQuadsZ = _numberOfVerticesZ - 1;
    _totalNumberOfQuads  = _numberOfQuadsX * _numberOfQuadsZ;

    _totalNumberOfTriangles = _totalNumberOfQuads * 2;
    _totalNumberOfIndicies = _totalNumberOfQuads * 6;
}

Visual Basic

 Private Sub ComputeValues(ByVal width As Integer, 
    ByVal height As Integer)

        ' Vertices
        _numberOfVerticesX = width
        _numberOfVerticesZ = height
        _totalNumberOfVertices = _numberOfVerticesX * _numberOfVerticesZ

        ' Quads
        _numberOfQuadsX = _numberOfVerticesX - 1
        _numberOfQuadsZ = _numberOfVerticesZ - 1
        _totalNumberOfQuads = _numberOfQuadsX * _numberOfQuadsZ

        _totalNumberOfTriangles = _totalNumberOfQuads * 2
        _totalNumberOfIndicies = _totalNumberOfQuads * 6

    End Sub

Once the height data has been loaded and the various dimensions computed, we can populate the vertex buffer.

Visual C#

   private void LoadVertexBuffer ( )
{
    // This is the buffer we are going to store the vertices in
    _vb = new VertexBuffer ( typeof(CustomVertex.PositionNormalTextured),  
        _totalNumberOfVertices, _device, Usage.WriteOnly, 
        CustomVertex.PositionNormalTextured.Format, Pool.Managed );
            
    // All the vertices are stored in a 1D array
    _vertices = new CustomVertex.PositionNormalTextured[
       _totalNumberOfVertices];
            
    // Load vertices into the buffer one by one
    for ( int z = 0; z < _numberOfVerticesZ; z++ )
    {
        for ( int x = 0; x < _numberOfVerticesX; x++ )
        {
            CustomVertex.PositionNormalTextured vertex;
            vertex.X = x;
            vertex.Z = z;
            
            // Set the Y to the elevation value in the elevation array
            if ( _isHeightMapRAW )
            vertex.Y = (float)_elevationsRAW[ 
               ( z * _numberOfVerticesZ ) + x];
            else
            vertex.Y = _elevations[x,z];
            
            // Set the u,v values so one texture covers the entire terrain
            vertex.Tu = (float)x / _numberOfQuadsX;
            vertex.Tv = (float)z / _numberOfQuadsZ;
            
            // Set up a bogus normal
            vertex.Nx = 0;
            vertex.Ny = 1;
            vertex.Nz = 0;
            
            // Add it to the array
            // Note: this is the same formula used in the elevations 
            //computation
            // to map the 2D array coordaintes into a 1D array
            _vertices[ (  z * _numberOfVerticesZ ) + x ] = vertex;
        }
    }
    
    // No overide the bogus normal computations with a real one
    ComputeNormals ( );
    
    // finally set assign the vertices array to the buffer
    _vb.SetData ( _vertices, 0, LockFlags.None );
}

Visual Basic

Private Sub LoadIndexBuffer()
    Dim numIndices As Integer = (_numberOfVerticesX * 2) *     
                (_numberOfQuadsZ) + _numberOfVerticesZ - 2
    _indices = New Integer(numIndices) {}
    _ib = New IndexBuffer(GetType(Integer), _indices.Length, _device,
        Usage.WriteOnly, Pool.Managed)
    Dim index As Integer = 0
    Dim z As Integer = 0
    While z < _numberOfQuadsZ
        If z Mod 2 = 0 Then
            Dim x As Integer
            x = 0
            x = 0
            While x < _numberOfVerticesX
              _indices(System.Math.Min(
                  System.Threading.Interlocked.Increment(index), 
                  index - 1)) = x + (z * _numberOfVerticesX)
              _indices(System.Math.Min(
                  System.Threading.Interlocked.Increment(index), 
                  index - 1)) = x + (z * _numberOfVerticesX) + 
                  _numberOfVerticesX
                                                    
              System.Math.Min(System.Threading.Interlocked.Increment(x), 
                  x - 1)
            End While
            If Not (z = _numberOfVerticesZ - 2) Then
               _indices(System.Math.Min(
                   System.Threading.Interlocked.Increment(index), 
                   index - 1)) = System.Threading.Interlocked.Decrement(x)
                   + (z * _numberOfVerticesX)
            End If
        Else
            Dim x As Integer
            x = _numberOfVerticesX - 1
            x = _numberOfVerticesX - 1
            While x >= 0
                _indices(System.Math.Min(
                    System.Threading.Interlocked.Increment(index), 
                    index - 1)) = x + (z * _numberOfVerticesX)
                _indices(System.Math.Min(
                    System.Threading.Interlocked.Increment(index), 
                    index - 1)) = x + (z * _numberOfVerticesX) 
                    + _numberOfVerticesX
                System.Math.Max(System.Threading.Interlocked.Decrement(x), 
                    x + 1)
            End While
            If Not (z = _numberOfVerticesZ - 2) Then
                _indices(System.Math.Min(
                    System.Threading.Interlocked.Increment(index),
                    index - 1)) = 
                    System.Threading.Interlocked.Increment(x) + 
                    (z * _numberOfVerticesX)
            End If
        End If
        System.Math.Min(System.Threading.Interlocked.Increment(z), z - 1)
    End While
    _ib.SetData(_indices, 0, 0)
End Sub

This method loops over the dimensions of the terrain and creates a vertex for each point, consisting of the X, Z coordinates and the height information (Y) for each point. At this stage we do not actually compute the normal, since we are going to average the vector values of the neighboring vertices later on and need the entire buffer to do so.

The Tu and Tv values determine how the Texture for the landscape is applied to the vertex. You can think of the Tu and Tv values as the X and Y values respectively of the texture. The values are floating-point values in the range of 0.0 to 1.0. A pair of u.v coordinates is called a Texel. We will cover textures and terrain in more detail in the next article. Right now we are just covering the terrain using a single terrain texture. (Actually, we are using the bottom of the skybox to do so; this ensures that the terrain matches the skybox closely.)

Now that we have the entire vertex buffer, we can go back and compute the normal for each vertex.

Visual C#

private void ComputeNormals ( )
{
    // compute normals
    for ( int z = 1; z < _numberOfQuadsZ; z ++)
    {
        for ( int x = 1; x < _numberOfQuadsX; x 

++)
        {
            // Use the adjoing 

vertices along both axis to compute the new 
            //normal
            Vector3 X = Vector3.Subtract ( 
                _vertices[ z * _numberOfVerticesZ + x + 1 ].Position, 
                _vertices[  z *_numberOfVerticesZ + x - 1].Position );
            Vector3 Z = Vector3.Subtract ( 
                _vertices[ (z+1) * _numberOfVerticesZ + x ].Position, 
                _vertices[(z-1)*_numberOfVerticesZ+x].Position );
            Vector3 Normal = Vector3.Cross ( Z, X );
            Normal.Normalize();
            _vertices[ ( z *_numberOfVerticesZ ) + x].Normal = Normal;
        }
    }
}

Visual Basic

Private Sub ComputeNormals()
    ' compute normals
    Dim z As Integer = 1
    While z < _numberOfQuadsZ
        Dim x As Integer = 1
        While x < _numberOfQuadsX
            ' Use the adjoing vertices along both axis to 
            ' compute the new normal
            Dim VX As Vector3 = Vector3.Subtract(
                _vertices(z * _numberOfVerticesZ + x + 1).Position,
                _vertices(z * _numberOfVerticesZ + x - 1).Position)
            Dim VZ As Vector3 = Vector3.Subtract(_vertices((z + 1) *
                _numberOfVerticesZ + x).Position, _vertices((z - 1) *
                _numberOfVerticesZ + x).Position)
            Dim Normal As Vector3 = Vector3.Cross(VZ, VX)
            Normal.Normalize()
            _vertices((z * _numberOfVerticesZ) + x).Normal = Normal
            x = x + 1
        End While
        z = z + 1
    End While

We simply use the two neighboring values along the X and Z axes to compute an average normal for the vertex.

Note   If you are just dying to go into detail for normal computations, read this paper: http://www.gamedev.net/reference/articles/article2264.asp.

After creating the vertex buffer, we need to create the index buffer. Index buffers are a DirectX mechanism for sharing vertex data by storing the indices into vertex buffers. Basically, they are a way to store information more efficiently. (Go to Introducing DirectX 9.0 > Direct3D Graphics > Getting Started with Direct3D > Direct3D Rendering > Rendering Primitives > Rendering from Vertex and Index Buffers in the DirecxtX managed SDK for an excellent discussion of vertex and index buffers.)

In terrain creation, the large number of vertices makes the use of index buffers essential for good performance.

Visual C#

private void LoadIndexBuffer ( )
{
    int numIndices = (_numberOfVerticesX * 2) * (_numberOfQuadsZ) + 
                     (_numberOfVerticesZ - 2);
    
    _indices = new int[numIndices];

    _ib = new IndexBuffer ( typeof( int ), _indices.Length, 
        _device, Usage.WriteOnly, Pool.Managed );

    int index = 0;

    for ( int z = 0; z < _numberOfQuadsZ; z++ )
    {
        if ( z % 2 == 0 )
        {
            int x;
            for ( x = 0; x < _numberOfVerticesX; x++ )
            {
                _indices[index++] = x + (z * _numberOfVerticesX);
                _indices[index++] = x + (z * _numberOfVerticesX) + 
                                    _numberOfVerticesX;
            }
            if ( z != _numberOfVerticesZ - 2)
            {
                _indices[index++] = --x + (z * _numberOfVerticesX);
            }
        }
        else
        {
            int x;
            for ( x = _numberOfVerticesX - 1; x >= 0; x-- )
            {
                _indices[index++] = x + (z * _numberOfVerticesX);
                _indices[index++] = x + (z * _numberOfVerticesX) + 
                                    _numberOfVerticesX;
            }
            if ( z != _numberOfVerticesZ - 2)
            {
                _indices[index++] = ++x + (z * _numberOfVerticesX);
            }
        }
    } 
    _ib.SetData( _indices, 0, 0 );
}

Visual Basic

Private Sub LoadIndexBuffer()
    Dim numIndices As Integer = (_numberOfVerticesX * 2) * 
    (_numberOfQuadsZ) + _numberOfVerticesZ - 2
    _indices = New Integer(numIndices) {}
    _ib = New IndexBuffer(GetType(Integer), 
        _indices.Length, 
        _device, Usage.WriteOnly, 
        Pool.Managed)

    Dim index As Integer = 0
    Dim z As Integer = 0
    While z < _numberOfQuadsZ
        If z Mod 2 = 0 Then
            Dim x As Integer
            x = 0
            x = 0
            While x < _numberOfVerticesX
                _indices(System.Math.Min(
                    System.Threading.Interlocked.Increment(index), 
                    index - 1)) = x + (z * _numberOfVerticesX)
                _indices(System.Math.Min(
                    System.Threading.Interlocked.Increment(index), 
                    index - 1)) = x + (z * _numberOfVerticesX) 
                    + _numberOfVerticesX

                System.Math.Min(System.Threading.Interlocked.Increment(x),
                    x - 1)
            End While
            If Not (z = _numberOfVerticesZ - 2) Then
                _indices(System.Math.Min(
                System.Threading.Interlocked.Increment(index), 
                index - 1)) = System.Threading.Interlocked.Decrement(x) 
                + (z * _numberOfVerticesX)
            End If
        Else
            Dim x As Integer
            x = _numberOfVerticesX - 1
            x = _numberOfVerticesX - 1
            While x >= 0
                _indices(System.Math.Min(
                   System.Threading.Interlocked.Increment(index), 
                   index - 1)) = x + (z * _numberOfVerticesX)
                _indices(System.Math.Min(
                   System.Threading.Interlocked.Increment(index), 
                   index - 1)) = x + (z * _numberOfVerticesX) 
                   + _numberOfVerticesX
                System.Math.Max(System.Threading.Interlocked.Decrement(x),
                    x + 1)
            End While
            If Not (z = _numberOfVerticesZ - 2) Then
                _indices(System.Math.Min(
                    System.Threading.Interlocked.Increment(index),
                    index - 1)) =System.Threading.Interlocked.Increment(x) 
                    + (z * _numberOfVerticesX)
            End If
        End If
        System.Math.Min(System.Threading.Interlocked.Increment(z), z - 1)
    End While
    _ib.SetData(_indices, 0, 0)

End Sub

Building the index buffer is probably the most difficult to understand, and there are multiple ways of doing this. The method shown here builds a single TriangleStrip in a snake-like motion from the bottom to the top. Even rows are built left-to-right and odd rows right-to-left.

The tricky part is moving from the last triangle in the row to the next row up. If we go straight up and the next vertex is not in line, then we end up with an extra triangle at the end. To suppress this extra triangle, we render a degenerate triangle (a triangle with no volume) by simply repeating the last vertex in each row. Since each adjoining triangle has the opposite winding, we have to repeat the vertex once more, otherwise the triangle would be considered back-facing and not rendered.

If you don't understand this at first, don't worry; neither did I. Play with the VertexBuffer and IndexBuffer creation methods using a small grid (like 3x3) to see the vertices and plot them one by one on paper creating the TriangleStrip by hand.

The last step is to provide a way to render the terrain.

Visual C#

public void Render ( )
{
    _device.Material = _material;

    // Adjust the unit to the selected scale
    _device.Transform.World = Matrix.Scaling ( 1.0f, 0.3f, 1.0f );
    _device.SetTexture ( 0, _terrainTexture );
    _device.Indices = _ib;
    _device.SetStreamSource ( 0, _vb, 0 );
    _device.VertexFormat = CustomVertex.PositionNormalTextured.Format;
    _device.DrawIndexedPrimitives ( PrimitiveType.TriangleStrip, 0, 0,
        _totalNumberOfVertices, 0, _indices.Length - 2 );
}

Visual Basic

Public Sub Render()

    _device.Material = _material

    ' Adjust the unit to the selected scale
    _device.Transform.World = Matrix.Scaling(1.0F, 0.3F, 1.0F)
    _device.SetTexture(0, _terrainTexture)
    _device.Indices = _ib
    _device.SetStreamSource(0, _vb, 0)
    _device.VertexFormat = CustomVertex.PositionNormalTextured.Format
    _device.DrawIndexedPrimitives(PrimitiveType.TriangleStrip, 0, 0,
        _totalNumberOfVertices, 0, _indices.Length - 2)

End Sub

This code should look very familiar from the earlier articles. The main difference between this render call and previous ones is the use of the index buffer and the corresponding DrawIndexedPrimitives call. We are also using the scaling matrix to make the terrain less hilly by scaling it down on the Y axis. You can also scale it up on the Z and X axis to get a larger terrain without having to load in a larger height map.

To integrate the terrain class into the game, we need to add a variable to the GameEngine class.

Visual C#

private Terrain 

_terrain;

Visual Basic

Private m_terrain 

As Terrain

Then we initialize the Terrain class and call the appropriate LoadHeightMap method in the constructor of the GameEngine class.

Visual C#

_terrain = new Terrain ( "Down.jpg", this._device );
_terrain.LoadHeightMapFromRAW ( " Heightmap256.raw" );

Visual Basic

m_terrain = New Terrain("Down.jpg", m_device)
m_terrain.LoadHeightMapFromRAW("Heightmap256.raw")

And finally we add the Terrain class to the Render loop.

Visual C#

_terrain.Render (  );

Visual Basic

_terrain.Render (  );

The finished result should look something like the picture below.

(click image to zoom)

In this particular picture I am rendering in wire-frame mode, so the skybox is rendered as a simple wire-frame cube, the corner of which is visible in the bottom of this screenshot. Zooming in closer, you can clearly see the regular grid mesh with Y values.

(click image to zoom)

For this version I have added support for switching among the various render modes. Press F1 to see the scene rendered in wire-frame mode, F2 to see it rendered in solid mode, and F3 to see it rendered in Point mode. I also set up the F4 and F5 keys to toggle the directional light on and off, so you can easily see the difference.

Summary

Wow! That was a lot to cover and I haven't even started talking about automatic texture mapping, height-based lighting, light-maps, Level Of Detail, ROAM, Geomipmapping, quadtrees and culling. I also still need to cover collision detection, and finally, I want to adjust our camera pitch, yaw and roll to conform to the underlying terrain, so the game provides a realistic "driving" experience. As usual, I hope you experiment with the code to gain a good understanding of the issues we just covered. Next time we will address more advanced terrain and cover creating and rendering issues as well as collision detection.

Until then: Happy coding.

Welcome to the eighth article on beginning game development. We have spent a lot of time working with the graphics capabilities of DirectX. We also covered how the DirectX API allows us to control input devices. Now we are going to look at another facet of DirectX, the ability to control sound devices. This capability is found in the DirectSound and AudioVideoPlayback namespaces.

Sound in Games

Sound creates an ambiance in a game that provides for a more immersive game experience. Imagine how dull a game would be without sound effects; nothing would indicate when you fire your cannon or an explosion occurs. Sounds also can be used to increase the drama of a scene by increasing the tempo as the action increases.

Sound effects also provide the same audible cues we expect in real life, such as the direction and speed of a person approaching us based on the volume, direction, and frequency of the footsteps. These sound effects add realism to the game just like proper physical behavior of objects do (something I will cover in an upcoming article about physics). Games also provide background music to make playing the game more fun. In newer games, artists who have their music included in a sound track for a popular game see an upswing of sales — it is not unusual for well-known artists to provide music for a game soundtrack. In effect, games have reached the same level as movies with the regards to the importance of soundtracks.

In BattleTank2005 I want to integrate sound in the following way. First, I want standard sound effects for shooting, explosions, and engine noise, and I want that sound to be directionally accurate. What I mean is that when I am getting shot at by an enemy to my left, I want the sound to come from the left and the volume to be an indicator of the proximity of the unit.

Secondly, I want to be able to play background music during game play and I want to control what music plays when in the game. This means I want to have one song play during the splash screen and game setup, another while playing the game, and yet another during the HiScore capturing (we are going to add these screens and states in a later article).

I am going to cover the first requirement in this article, and then cover sound effects and playing MP3 and WMA files with the AudioVideo namespace in the next article. Before we add these features, let's review the capabilities of DirectSound.

DirectSound

The DirectSound namespace only supports playing 2 channel waveform audio data at fixed sampling rates (PCM). While I have no idea what that really means, it is safe to state that you should use DirectSound to play short WAV files and the AudioVideoPlayback namespace for longer MP3 or WMA files. I am not going to cover how to use the sound capturing/recording capabilities of DirectSound namespace — but remember that they exist so you know where to look if your game requires recording sounds as well as playing them.

The DirectSound namespace provides the ability to play and capture sound with three-dimensional positioning effects. DirectSound also provides the ability to add sound effects to the audio played or recorded. Just like in the DirectX3D and the DirectInput namespaces, the actual hardware device used is abstracted into a device class. Just like the device classes in those two namespaces, the DirectSound device uses buffers, has a cooperative level, and has device capabilities. I am not going to cover the sound effects in this article, but they are not forgotten; they will be covered in detail in the next article.

Device

A device is the interface to the audio hardware on the computer. You can either create a Device class using a default GUID (DSoundHelper.DefaultPlaybackDevice) or enumerate all the devices on a system. Like the other device classes, each enumerated device has a list of capabilities stored in a Caps structure in the Caps property for the device. Once you have chosen your device, you instantiate the device class using a specific GUID.

Audio devices also have a cooperative level like the input devices did. The three possible values are: Normal, Priority, and Write Primary. These values are set via the CooperativeLevel enumeration.

Buffers

All the sounds in DirectX are controlled via buffers. These buffers can exist in the memory of the computer or on the sound card itself. The two buffers used in DirectSound are called the primary buffer and secondary buffer.

The primary buffer contains the actual audio data that is sent to the device and is automatically created and managed by the DirectX API. The API mixes the sound in the primary buffer with any secondary buffers. If you need to interact directly with the primary buffer, make sure to change the Cooperative level of the device to Write Primary.

Secondary buffers hold a single audio stream and must be explicitly created by the application. Each application must create at least one secondary buffer to store and play sounds. Each secondary buffer also has a specific waveform format (described in the WaveFormat structure), and only sound data that matches that format can be loaded into that secondary buffer. An application can play sounds of differing formats by creating a separate secondary buffer for each format and letting the API mix them into a common format in the primary buffer. To mix sounds in two different secondary buffers, simply play them at the same time and let the API mix them in the primary buffer. The only limitation to the number of different secondary buffers that can be mixed is the processing power of the system, but remember that any additional processing required will also slow down your game. We have not added any AI or physics computations, but we should be careful with the available processing power.

Any secondary buffer can be used for the life of the application, or it can be created and destroyed as needed. A single secondary buffer can contain the same data throughout the entire game or it can be loaded with different sounds (as long as they match the format). The sound in the secondary buffer can be played once or set up to loop. If the sound to be played is short, it can be loaded into the buffer in its entirety (called a static buffer), but longer sounds must be streamed. It is the responsibility of the application to manage the streaming of the sound to the buffer.

When a buffer is created you have to specify the control options for that buffer using the BufferDescription class. If you use a property of the buffer without first setting it in the control properties, an exception is thrown. The control options can be combined by either setting each property to true or combined in the Flag property.

 1: BufferDescription bufferDescription = new BufferDescription ( );

 2: // Use the seperate properties

 3: bufferDescription.ControlVolume = true;

 4: bufferDescription.ControlPan = true;

 5: // or combine them in the Flags property

 6: bufferDescription.Flags = BufferDescriptionFlags.ControlVolume | BufferDescriptionFlags.ControlPan;

Controlling Volume, Pan, and Frequency

To control these settings of the buffer you must first set the ControlPan, ControlVolume, and ControlFrequency properties of the buffer to true. You can then set the pan, volume, and frequency values using the buffer's Pan, Volume, and Frequency properties.

Volume is expressed in hundredths of a decibel and ranges from 0 (full volume) to -10,000 (completely silent). The decibel scale is not linear, so you may reach effective silence well before the volume setting reaches true silence at -10,000. There is also no way to increase the volume of the sound above the volume it was recorded at, so you have to make sure to record the sound with a high enough volume to at least match the desired maximum volume in the game.

Pan is expressed as an integer and ranges from -10,000 (full left) to +10,000 (full right), with 0 being center.

The frequency value is expressed in samples per seconds and represents the playback speed of the buffer. A larger number plays the sound faster and raises the pitch while a smaller number slows the speed down and lowers the pitch. To reset the sound to its original frequency, simply set the frequency value to 0. The minimum value for frequency is 100 and the maximum value is 200,000.

At this point you may think that we could use the volume, pan, and frequency settings to manipulate the sound and make it reflect the direction and distance of its origin. This was, after all, one of our original requirements. But instead of us performing the calculations to determine the relative locations and distances of each object, DirectX provides an API to do just that for us.

3D Sound

The 3D features of DirectX allow us to locate sounds in space and apply Doppler shift to moving sounds.

Note   Check out this excellent explanation of the Doppler effect at Wikipedia, or use this applet to help yourself to visualize what it is.

Before describing how DirectX handles sound in three dimensions, it is probably useful to talk about how we perceive sound. DirectX uses these same principles to make the sound appear as realistic as possible.

1. The volume of a sound decreases at a fixed rate as the distance to the listener increases. This effect is called Rolloff. The relationship between the volume of a sound and its distance from the listener is inverse-proportional, meaning that if the distance is halved the volume doubles. (See: http://en.wikipedia.org/wiki/Inverse_square_law)
   
   
2. The listener perceives sounds coming from the left as louder in the left ear than the in right ear (interaural intensity difference) and also hears sounds coming from the left sooner in the left ear than the right ear (interaural time difference). (See: http://en.wikipedia.org/wiki/Interaural_Intensity_Difference)
   
   
3. The shape of the ear produces an effect called "muffling": sounds coming from the front are perceived as louder than those coming from the back. This is, of course, because the human ear is directed towards the front of the head.
   
   
4. The ridges of the earlobe slightly alter the sound arriving from different directions. This provides cues to the brain about the location of the sound source. This effect can be modeled mathematically and is called the Head Related Transfer Function (HRTF). (See: http://en.wikipedia.org/wiki/Head_Related_Transfer_Function)

We already know that DirectX uses the left-handed Cartesian coordinates system and Vectors to express position and directional information. This same system is also used by DirectSound in its computations. One important piece of information when dealing with 3D sound is that the default unit of measurement for distance is the meter and the default measurement for velocity is meters per second. You need to make sure to use a common system of measurement in the game. You can change this by setting the DistanceFactor property of the Listener3D object to a value that represents the meters per application-specified distance unit. If you have been using feet in all your calculations up to this point, simply set this value to 0.3048 (there are 0.3048 meters in a foot).

Also, since we are leaving the manipulation of the sound to DirectX (as opposed to us changing the volume, pan, and frequency), we must ensure that the sound source we are using is a mono and not stereo source. Finally, make sure to set the Control3D property of the buffer to true to enable 3D sounds.

DirectSound uses two objects to manage 3D sounds in the application: Buffer3D and Listener3D.

3D Buffers

Unlike the SecondaryBuffer, a Buffer3D object does not inherit from the Buffer class. Instead you create a 3D Buffer object by passing it a SecondaryBuffer in the constructor. The 3D Buffer exposes a number of properties that determine how the sound is processed.

The MinDistance property determines at which distance the sound volume is no longer increased. You can also use this setting to make certain sounds appear louder even if they were recorded at the same volume (see the DirectX documentation for a detailed explanation of this). The default value for this property is 1 meter, meaning that the sound is at full volume when the distance between the listener and the sound source equals 1 meter.

The MaxDistance property is the opposite and determines the distance after which the sound no longer decreases in volume. The default value for this property is 1 billion meters, which is well beyond hearing range anyway. To avoid unnecessary processing, you should set this value to a reasonable value and set the Mute3DAtMaximumDistance property of the BufferDescription to true.

Finally, we can also specify values for the sound cone if the sound is directional. A sound cone is almost identical to the cone produced by a spotlight (see article 6). It consists of a set of angles, one for the inside and one for the outside cone, and orientation, and an outside volume property. Check out the DirectX documentation for more detail on sound cones.

3D Listeners

While the 3D Buffer describes the source of a sound, the 3D Listener describes the, well, listener. Just as the position, orientation, and velocity of the buffer affects the sound, so does the position, orientation, and velocity of the listener. The default listener in DirectX is located at the origin pointing toward the positive z-axis, and the top of the head is along the positive y-axis. Each application can only have one Listener3D object.

To change the way the player hears the sound in your game, you manipulate the position, orientation, and velocity of the Listener. You can also control global settings of the acoustic environment like the Doppler shift or Rolloff factor.

Note   The DopplerFactor and RolloffFactor properties are a number between 0 and 10. Zero means that the value is turned off. One represents the real world values of these acoustic effects. All other values are multiples, so that a 2 means doubling the real world effect, 3 means tripling it, and so on.

In BattleTank2005 we are going to add three new classes; a SoundDevice class to represent the actual audio device, a SoundListner class to encapsulate the Listener3D object, and a SoundEffects class to represent each separate sound effect. Each tank in BattleTank2005 can have multiple sounds associated with it, such as engine noise and the noise made when firing. To integrate sound we are going to update the Tank class to play these sounds at the appropriate time and with the appropriate position information. I did not add this functionality to the UnitBase class because the stationary objects (the obstacles) will not have any sounds associated with them.

Before we start adding these classes we need add a reference to the Microsoft.DirectX.DirectSound.DLL assembly. Make sure to choose the 1.0 and not the 2.0 version. BattleTank2005 has not yet been updated to use the beta versions of the 2.0 DirectX API. Add a new class called SoundDevice and add the using statement for Microsoft.DirectX.DirectSound. All three of the classes will implement the IDisposable interface and use the same Dispose pattern that we used in the Keyboard and Mouse classes. (I omitted that portion from the code samples below to keep them more compact and easy to understand).

Following the now familiar patterns we add a private variable called _device to the SoundDevice class and instantiate it in the constructor. We also need to set the CooperativeLevel before we can use the device. As discussed earlier, we will use CooperativeLevel.Priority setting. We also pass a reference of the game form to this method so that the device can receive Windows messages. Finally, we surround the device creation code with a Try/Catch, since things can go wrong whenever we work with devices.

 1: using System;

 2: using Microsoft.DirectX.DirectSound;

 3:  

 4: namespace BattleTank2005

 5: { 

 6: class SoundDevice : IDisposable 

 7: { 

 8: public SoundDevice( System.Windows.Forms.Form parentForm ) 

 9: { 

 10: try

 11: {

 12: _device = new Microsoft.DirectX.DirectSound.Device(); _device.SetCooperativeLevel(parentForm, CooperativeLevel.Priority); } catch

 13: {

 14: // Can not use sounds

 15: }

 16: }

 17: 

 18: public Microsoft.DirectX.DirectSound.Device AudioDevice 

 19: { 

 20: get { return _device; } 

 21: } 

 22: 

 23: private Microsoft.DirectX.DirectSound.Device _device; 

 24: }

 25: }

The next class we need is the SoundListener class. After adding the using statements for DirectSound and DirectX, we construct the class by passing a reference to the SoundDevice class created earlier. The Listener needs to be associated with the Primary Buffer of the audio card so it can "hear" the final mixed sounds. Even so, the SoundListener class is largely passive, so we do need to update its position, velocity, and orientation to enable 3D sounds on the buffer. Once the buffer is created we pass it to the constructor of the Listener3D class to create the Listener. The final step is to store the Listener3DSettings of the listener in a local variable so we can access them in the Update method.

The Update method provides the way in which we pass the position information to the Listener object.

The last step is to apply the updated values to the Listener. We do this by calling the CommitDeferredSettings method of the Listener3D class after updating the Listener3DSettings values. This method simply commits all changes made to the Listener3DSettings since the last time the method was called. When all is done, the SoundListener class is positioned at the correct location in the game.

 1: using System;

 2: using Microsoft.DirectX;

 3: using Microsoft.DirectX.DirectSound;

 4:  

 5: namespace BattleTank2005

 6: { 

 7: class SoundListener : IDisposable 

 8: { 

 9: public SoundListener(SoundDevice soundDevice) 

 10: { 

 11: BufferDescription bufferDescription = new BufferDescription(); 

 12: bufferDescription.PrimaryBuffer = true; 

 13: bufferDescription.Control3D = true; 

 14: 

 15: // Get the primary buffer

 16: Microsoft.DirectX.DirectSound.Buffer buffer = new Microsoft.DirectX.DirectSound.Buffer(bufferDescription, soundDevice.AudioDevice); 

 17:  

 18: // Attach the listener to the primary buffer

 19: _listener3d = new Listener3D(buffer); 

 20: 

 21: // Store the initial parameters

 22: _listenerSettings = new Listener3DSettings(); 

 23: _listenerSettings = _listener3d.AllParameters; 

 24: } 

 25:  

 26: public void Update(Vector3 position ) 

 27: { 

 28: _listener3d.Position = position; 

 29: _listener3d.CommitDeferredSettings(); 

 30: } 

 31: 

 32: private Microsoft.DirectX.DirectSound.Listener3D _listener3d; 

 33: private Listener3DSettings _listenerSettings; 

 34: }

 35: }

Now that we have classes representing the audio device and a class to "listen" to the sounds, we need to actually create the sounds. For this we add the SoundEffect class. Once again we need to add the using statement for the DirectSound namespace. We also need to add a using statement for the DirectX namespace because we are going to use the Vector3 class.

A SoundEffect is created by passing a reference to the SoundDevice and a path to a WAV file containing a sound. In the constructor, we create a BufferDescription object that will "turn on" all of the capabilities we want. For right now we want the ability to control sounds in 3D, adjust the volume, and change the frequency. Next we create a secondary buffer passing in the path to the sound file and the BufferDescription we just created. To create the Buffer3D that we need to play 3D sounds, we pass the SecondaryBuffer to the Buffer3D class on instantiation, and voila! we have a 3DBuffer.

Once the Buffer3D class is set up we can access the properties and change the settings. We set the MaxDistance to a more manageable number. This setting combined with the Mute3DAtMaximumDistance setting on the SecondaryBuffer ensures that sounds too distant to hear are not played at all and don't consume any processing cycles.

To actually use the SoundEffect in the game we provide three public methods: one to play the sound one to stop the Sound (if it is looping) and one to update the class. The Play method either plays the sound once or loops the sound depending on the setting of the _isLooping variable. If the sound is looping, we need to be able to stop it, and that is what the Stop method does. The Update method is the way in which we pass the updated position of the tank the sound is associated with to the sound buffer so it can be accurately calculated.

 1: using System;

 2: using Microsoft.DirectX.DirectSound;

 3: using Microsoft.DirectX;

 4:  

 5: namespace BattleTank2005

 6: { 

 7: public class SoundEffects : IDisposable 

 8: { 

 9: public SoundEffects( SoundDevice soundDevice, string soundFile) 

 10: { 

 11: BufferDescription bufferDescription = new BufferDescription(); 

 12: bufferDescription.Control3D = true; 

 13: bufferDescription.ControlVolume = true; 

 14: bufferDescription.ControlFrequency = true; 

 15: bufferDescription.Mute3DAtMaximumDistance = true; 

 16: 

 17: try

 18: {

 19: _secondaryBuffer = new SecondaryBuffer(soundFile, bufferDescription, soundDevice.AudioDevice); 

 20: _3dBuffer = new Buffer3D(_secondaryBuffer); 

 21: _3dBuffer.MaxDistance = 10000; 

 22: }

 23: catch

 24: {

 25: // Can not use sounds

 26: }

 27: }

 28: 

 29: public void Update(Vector3 position){ 

 30: _3dBuffer.Position = position; 

 31: } 

 32: 

 33: public void Play() 

 34: { 

 35: if (_isLooping == true) 

 36: _secondaryBuffer.Play(0, BufferPlayFlags.Looping); 

 37: else

 38: _secondaryBuffer.Play(0, BufferPlayFlags.Default);

 39: }

 40:  

 41: public void Stop() 

 42: { 

 43: _secondaryBuffer.Stop(); 

 44: _secondaryBuffer.SetCurrentPosition(0); 

 45: } 

 46: 

 47: public bool IsLooping 

 48: { 

 49: set { _isLooping = value; } 

 50: } 

 51:  

 52: public int Volume 

 53: { 

 54: set { _secondaryBuffer.Volume = value; } 

 55: } 

 56:  

 57: public int Frequency 

 58: { 

 59: set { _secondaryBuffer.Frequency = value; } 

 60: } 

 61:  

 62: private SecondaryBuffer _secondaryBuffer; 

 63: private Buffer3D _3dBuffer; 

 64: private bool _isLooping; 

 65: }

 66: }

Now we need to integrate these new classes into the overall game. The first step is to add a private variable to the GameEngine class to hold a reference to the SoundDevice and SoundListener classes because we can only have one of each of these classes. At the bottom of the GameEngine class, add the following code:

private SoundDevice _soundDevice;

  
private SoundListener _soundListener;

Next, we need to instantiate each class. The Initialize class of the GameEngine is the perfect spot for this, but to keep sound-related items together we will create a method called ConfigureSounds. In the GameEngine class add the following method:

private void ConfigureSounds()

  
{

  
_soundDevice = new SoundDevice(this);

  
_soundListener = new SoundListener(_soundDevice);

  
}

Now add a call to the ConfigureSounds method to the Initialize method of the GameEngine right after the call to the ConfigureDevice method.

ConfigureDevice();
    
ConfigureSounds()

With regard to the SoundDevice class, this is all we have to do. After creation all we need this class for is its reference to the Device object. The SoundListener class, however, needs to be updated with the correct position information in each frame. The Render method of the GameEngine class is the perfect place for this. We simply pass in the position of the camera class since it represents our location in the game. In the Render method of the GameEngine class, add the following code immediately after the call to the Update method of the camera.

Each tank gets a unique instance of the SoundEffect class for each sound it can make. First we need to add some private variables to hold the two sound effects we want the tank to make. At the bottom of the Tank class add the following code:

private SoundEffects _engineSound;

  
private SoundEffects _fireSound;

To make sure each tank has the necessary sound we will pass them in the constructor. Update the constructor of the Tank class to look as follows (the new code is in bold):

 1: public Tank(Device device, string meshFile, Vector3 position, float scale, 

 2: float speed, SoundEffects fireSound, SoundEffects engineSound)

 3: : base(device, meshFile, position, scale)

 4: { 

 5: _speed = speed; 

 6: _engineSound = engineSound; 

 7: _engineSound.IsLooping = true; 

 8: _engineSound.Play(); 

 9: _fireSound = fireSound; 

 10: }

Once the sound effects are associated with the tank instance we start the engine sound after setting it to looping.

The next step is to change the Update method of the Tank class to add updating the 3D buffer with the position of the tank. Add the following code to the end of the Update method:

if (_engineSound != null)

  
{

  
_engineSound.Update(base.Position);

  
}

The shooting sound of the tank is not continuous, and whether or not the tank shoots will be determined by the AI we are going to add later on. For now, all we are going to do is create the necessary framework to play the shooting sound. Add the following method to the Tank class:

public void Shoot()

  
{

  
if (_fireSound != null)

  
{

  
_fireSound.Update(base.Position);

  
_fireSound.Play();

  
}

  
}

The final step for updating the tank class to be sound ready is to update the CreateTanks method of the GameEngine. We need to create the SoundEffect for the engine noise and the firing noise, and pass them to the tank class on creation. Change the CreateTanks method to look as follows:

private void CreateTanks()

  
{

  
_tanks = new List<UnitBase>();

  
SoundEffects engineSound1 = new SoundEffects(_soundDevice, @"EngineSound1.wav");

  
engineSound1.Volume = -1000;

  
engineSound1.Frequency = 100000; // Set to a value between 100 - 200000 SoundEffects engineSound2 = new SoundEffects(_soundDevice, @"EngineSound2.wav");

  
engineSound2.Volume = -1000;

  
engineSound2.Frequency = 10000; // Set to a value between 100 - 200000 SoundEffects fireSound = new SoundEffects(_soundDevice, @"Fire.wav");

  
Tank newTank1 = new Tank(_device, @"bigship1.x", new Vector3(0.0f, 20.0f, 100.0f), 

  
 1f, 10.0f, fireSound, engineSound1);

  
Tank newTank2 = new Tank(_device, @"bigship1.x", new Vector3(100.0f, 20.0f, 100.0f), 

  
 1f, 10.0f, fireSound, engineSound2);

  
_tanks.Add(newTank1);

  
_tanks.Add(newTank2);

  
}

This is where you can experiment with changing the volume or frequency of the sound effect. Fly around and get closer to each spaceship, and the sound will vary in direction and volume according to your position. Change the frequency, and the pitch will change, and you can guess what the volume setting does.

Summary

When you play BattleTank2005 now, you should hear the engine noises of the various enemy tanks properly adjusted for their spatial relationship to the listener (you). At this point, we have integrated the first set of the audio features we want to add to BattleTank2005. You should definitely experiment with the various settings to hear their effect. I have left several optional settings commented in the code so you can easily change them. In the next article we are going to cover how to use the built-in sound effect manipulation of DirectSound to change the sounds, and how to play a regular MP3 file for the soundtrack using the AudioVideoPlayback namespace.

Until then: Happy coding!

1. Beginning Game Development Part 1 - Introduction
2. Beginning Game Development Part II - Introduction to DirectX
3. Beginning Game Development: Part III - DirectX II
4. Beginning Game Development: Part IV - DirectInput
5. Beginning Game Development: Part V - Adding Units
6. Beginning Game Development: Part VI - Lights, Materials and Terrain
7. Beginning Game Development: Part VII –Terrain and Collision Detection
8. Beginning Game Development: Part VIII - DirectSound
9. Beginning Game Development: Part VIII - DirectSound II
10. Beginning Game Development: Part VIII - DirectSound III

Welcome to the fifth article on beginning game development. At this point we have a working 3D environment and can manipulate the camera direction and location using the keyboard and mouse. In this article we are going to add 3D objects to the game using predefined mesh files and implement some simple culling.

Code cleanup

The cleanup in this article consists mainly of fixing the navigation keys and removing some items we no longer need. The following changes have already been integrated into the code for this article:

• Replaced the radian/degree conversion methods in the Camera class with the utility classes in the Geometry class.
• Fixed the key assignments in the CheckForInput method in the GameEngine class so that:
  • W and S adjust the Z-axis. W is forward (positive) and S backward (negative)
  • A and D adjust the X-axis. A is left (negative) and D is right (positive).
  • Q and Z adjust the Y-axis. Q is up (positive) and Z is down (negative). Movement along the Y-axis is going to be removed later on, since our tank can not fly.
• Adjusted the initial position of the camera to be above the surface level by setting the _z variable in the Camera class to 10. This represents our vantage point in the tank, which should be higher than zero.
• Removed the Joystick class.
• Updated to the August SDK.
• Changed the GetElapsedTime method in the HiResTimer class to return a float and changed _deltaTime in GameEngine to a float.
• Removed HiResTimer.Reset from the GameEngine Render method, moved HiResTimer.Start into the constructor of the GameEngine class.

IDispose

You may have noticed that some of the classes, such as the Keyboard and Mouse classes, implement the IDisposable interface. This is an implementation of the Dispose pattern in .NET as explained in the .NET Framework Reference topic Implementing Finalize and Dispose to Clean Up Unmanaged Resources.

The Dispose pattern in .NET is intended to be used when a program makes use of resources that are not managed by the .NET runtime. These "unmanaged" resources need to be cleaned up in a special way to ensure that they are released in a deterministic manner. Since the .NET garbage collection is non-deterministic, we need to use a particular set of steps to ensure this cleanup is done correctly. These steps are defined in the Dispose pattern.

We use a lot of unmanaged resources in game development, so it is best to implement the Dispose pattern in every class that interacts with DirectX or file resources (almost all of our classes). This will protect us against memory leaks and increase the performance of the game.

You can read the topic mentioned above to get more background information on this pattern and garbage collection for .NET. I have added the Dispose pattern in all of the classes for this article, and will do so going forward.

What we need in BattleTank 2005 now are units. If you go back to the screenshot of the original game shown in the first article, you see that we need to add shapes and opposing tanks. The shapes are obstacles for you or the enemy tanks to use as cover. The enemy tanks are what we are going to eventually shoot at. These objects also aid us in navigation in the otherwise bare landscape. You may remember that we had to write out the camera location to the console to see that we were moving because there were no reference points in the scene. In the next article we will complete the scene by adding some terrain.

Units

For BattleTank 2005 we are going to have two types of 3D objects: Obstacles and Tanks. The main difference between them is that tanks can move and obstacles can not. Since we are going to have lots of obstacles and tanks, we are going to organize them so that they can be manipulated in bulk. We do this by adding them to a collection.

We could add both types of objects to a single collection, but it makes sense to separate each type into its own collection. Separating the objects in this manner allows us to concentrate on a particular group without incurring the overhead of testing each unit for its type, which improves performance. We can then update the position of the mobile units while skipping the stationary units.

Generics

In previous versions of .NET, creating a collection class to hold the units and ensuring that it was type-safe was pretty involved. Each collection in .NET 1.0 and 1.1 was a collection of objects. This meant that it accepted any value or reference type, making it very flexible. But this also meant that we had to cast the object to its proper type whenever we retrieved an object from the collection. This meant we ran the danger of the object cast failing. Accounting for the possible exception and testing each object before the cast incurred more overhead.

With .NET 2.0 we can use Generics to create type-safe collections for us with minimum effort. These collection classes are safer and perform better than regular collection. This is only one of the possible uses of generics, but probably the most common.

To learn more about generics check out these articles at MSDN:

• An Introduction to C# Generics
• MSDN Magazine: Introducing Generics in the CLR

All units, regardless of their purpose, have a number of things in common. To make the application easier to maintain, we are going to factor all of the common characteristics of the unit into a single base class. All units will derive from the common base class and be extended with custom properties and methods.

Creating a base class and derived classes creates an object hierarchy that then allows us to treat all units polymorphically, which is a very powerful concept in object oriented programming. Check out these Visual Studio .NET topics on polymorphism at MSDN:

• Visual Basic Reference: Polymorphism
• Visual Basic and Visual C# Concepts: Polymorphism in Components

The resulting base class looks like this.

Visual C#

public abstract class UnitBase : IDisposable
{
    public UnitBase (Device device, string meshFile,
        Vector3 position, float scale )
    public void Render ( Camera camera )

    public bool IsCulled
    public Vector3 Position
    public float Radius
    private void LoadMesh ( )
    private void ComputeRadius ( )

    private Vector3 _position;
    private float _radius;
    private bool _isCulled;
    private Device _device;
    private string _meshFile;
    private float _scale;
    private Mesh _mesh = null;
    private Material[] _meshMaterials;
    private Texture[] _meshTextures;
}

Visual Basic

Public MustInherit Class UnitBase
    Implements IDisposable
    Public Sub New(ByVal device As Device, _
        ByVal meshFile As String, ByVal position As Vector3, _
        ByVal scale As Single)

    Public Sub Render(ByVal camera As Camera)

    Public Property IsCulled() As Boolean
    Public Property Position() As Vector3
    Public Property X() As Single
    Public Property Y() As Single
    Public Property Z() As Single
    Public ReadOnly Property Radius() As Single
    Public Sub Dispose() Implements IDisposable.Dispose
    Protected Overridable Sub Dispose(ByVal disposing As Boolean)
    Protected Overrides Sub Finalize()
    Private _disposed As Boolean
    Private Sub LoadMesh()
    Private Sub ComputeRadius()
    Private m_position As Vector3
    Private m_radius As Single
    Private m_isCulled As Boolean
    Private m_device As Device
    Private m_meshFile As String
    Private m_scale As Single
    Private m_mesh As Mesh = Nothing
    Private m_meshMaterials As Material()
    Private m_meshTextures As Texture()
End Class

While most of this should make sense, you may be wondering what a mesh file is and why we are loading it.

3D Modeling

At some point you realize that creating complex 3D objects in code line by line is pretty silly. The simple cube we created for the skybox alone was almost 200 lines of code. There has to be a better way to create 3D objects.

Most 3D models are created by artists using dedicated modeling programs such as Maya or 3ds Max. These programs store the information about their models in proprietary file formats (iff for Maya and 3ds for 3DS Max). DirectX can not directly read these file formats, but it can read a format called the X file.

X Files

DirectX defines a file format called the X file format. It contains the definition for a 3D model. We can use these files to dramatically reduce the amount of code we need to write when loading 3D models into our game by loading them from the X file. In DirectX lingo, the X files are mesh files.

Mesh

If you remember from our previous article, a mesh is data that describes a 3D shape. Mesh data includes a list of vertices that comprise the shape, information on how the vertices are connected to each other, and texture information for all vertices.

There are also conversion programs available that convert 3D objects files from other formats into the X file format. The DirectX SDK actually ships with plug-ins for Maya and 3ds Max that allow you to convert files created with these programs into the X file format.

So where can you get some X files to start working with? The DirectX SDK includes a folder called Media under the Samples folder which contains a number of X files that you can use. The DirectX SDK also includes a number of utilities that allow you to work with the X files such as the DirectX viewer and MeshViewer. All of the utilities are located in the Utilities folder. Check out these and the other utilities that come with the SDK, as they can save you time and effort.

Free 3D models: Unless you are very graphically talented it is probably best for an artist to create the models for your game. There are a large number of free 3D models available on the internet created by artists to show of their skills. Generally they don't mind if you use their work for you own gratification, but if you use it in a commercial game, that's a whole other issue. Make sure to read and understand the usage rules for each model before using it. A good site for free models is: http://www.3dcafe.com/.

Using X files with predefined models opens up an entirely new world of integrating 3D objects into our game. No longer do we need to worry abut the low-level details of each object, we can simply load a previously created mesh file.

Updating the Skybox

The first place we are going to use this newfound knowledge is to clean up the skybox code. The SDK includes a file called lobby_skybox.x in the Samples\Media\Lobby folder that describes a cube like the one we are currently using for our sky box. I copied this file to the Resources folder as skybox.x and updated the texture files to match the names of our texture files.

Changing textures: Most X files can be opened in a simple text editor. You can search the file for the references to the texture files (look for TextureFilename) and replace them with your own, or you can substitute your own texture files during the mesh loading phase by passing the texture file name to the TextureLoader.FromFile method. If you want to see something cool, copy the lobby_skybox.x files and all of the JPG files from the SDK media folder to the resource folder, then change the name of the X file in the skybox LoadMesh method to this X file. The resulting skybox is the lobby of the building where all the game developers work at Microsoft.

In the Skybox class remove the SetupCubeFaces method, the six methods starting with Copy (CopyLeftFaceVertexBuffer, CopyFrontFaceVertexBuffer, etc.) and the RenderFace method. You can also remove all of the private variables declared at the bottom of the class except for the Device variable. In the Render method, remove the lines of code that check the Pitch and Heading of the camera. Finally, replace the call to SetupCubeFaces in the constructor with a call to LoadMesh.

Now add the following three variable declarations at the bottom of the class.

Visual C#

private Mesh _mesh = null;
private Material[] _meshMaterials;
private Texture[] _meshTextures;

Visual Basic

Private m_mesh As Mesh = Nothing
Private m_meshMaterials As Material()
Private m_meshTextures As Texture()

We already know what a mesh and a texture is, but what is the material?

Material

Materials describe how polygons reflect ambient and diffuse light, as well as information about specular highlights and if the polygons appear to emit light. The main thing to remember is that while textures define how polygons look, materials define how they reflect light.

Loading a Mesh

Loading the mesh from a file is very simple. All you have to do is to call the FromFile method of the Mesh class. (You should spend some time to familiarize yourself with the Mesh class and its methods, since it is one of the core classes you will use.)

In the Skybox class add the following code.

Visual C#

private void LoadMesh ( )
{
    ExtendedMaterial[] materials = null;
    Directory.SetCurrentDirectory ( 
        Application.StartupPath + @"\..\..\..\Resources\" );
    _mesh = Mesh.FromFile (@"skybox.x",
        MeshFlags.SystemMemory, _device, out materials);
    if ( ( materials != null ) && ( materials.Length > 0 ) )
    {
        _meshTextures = new Texture[materials.Length];
        _meshMaterials = new Material[materials.Length];
        for ( int i = 0 ; i < materials.Length ; i++ )
        {
            _meshMaterials[i] = materials[i].Material3D;
            _meshMaterials[i].Ambient = _meshMaterials[i].Diffuse;
            if (materials[i].TextureFilename != null && 
                    (materials[i].TextureFilename != string.Empty))
                _meshTextures[i] = TextureLoader.FromFile ( _device, 
                    materials[i].TextureFilename );
        }
    }
}

Visual Basic

Private Sub LoadMesh()
    Dim materials As ExtendedMaterial() = Nothing
    Directory.SetCurrentDirectory(Application.StartupPath _ 
        & "\..\..\..\Resources\")
    m_mesh = Mesh.FromFile("skybox.x", MeshFlags.SystemMemory, _
        m_device, materials)

    If (Not (materials Is Nothing)) AndAlso _
        (materials.Length > 0) Then
        m_meshTextures = New Texture(materials.Length) {}
        m_meshMaterials = New Material(materials.Length) {}
        Dim i As Integer = 0
        While i < materials.Length
            m_meshMaterials(i) = materials(i).Material3D
            m_meshMaterials(i).Ambient = m_meshMaterials(i).Diffuse
            If Not (materials(i).TextureFilename Is Nothing) AndAlso _
                    (Not (materials(i).TextureFilename = String.Empty)) Then
                m_meshTextures(i) = TextureLoader.FromFile( _
                    m_device, materials(i).TextureFilename)
            End If
            System.Math.Min(System.Threading.Interlocked.Increment(i), i - 1)
        End While
    End If
End Sub

While DirectX handles most of the work of reading the X file and converting it into an object for us (i.e. the creation of the vertex and index buffers etc.) we have to manually manage loading the materials and textures for the mesh.

The last step to integrate the X file and textures into the Skybox is to modify the Render method of the Skybox class. Immediately after the _device.RenderState.CullMode = Microsoft.DirectX.Direct3D.Cull.None; line add the following code.

Visual C#

for ( int i = 0 ; i < _meshMaterials.Length ; i++ )
{
    _device.Material = _meshMaterials[i];
    _device.SetTexture ( 0, _meshTextures[i] );
    _mesh.DrawSubset ( i );
}

Visual Basic

While i < m_meshMaterials.Length
    m_device.Material = m_meshMaterials(i)
    m_device.SetTexture(0, m_meshTextures(i))
    m_mesh.DrawSubset(i)
    System.Math.Min(System.Threading.Interlocked.Increment(i), i - 1)
End While

Once again we iterate over the meshMaterials and then call the DrawSubset method of the Mesh to draw each subset in turn. That's it; the entire Skybox class is now only about 80 lines long and much easier to read.

Returning to the UnitBase class, the next item we need to look at is the IsCulled flag.

Culling

We briefly covered culling in the third article. Culling is simply the removal of entire objects from the scene so they will not be rendered. The logic to determine what objects should be removed can range from the very simple to the very complex. In BattleTank 2005 we are going to cull all of the objects that do not fall into the view frustum of the scene.

To determine if the unit is in the view frustum, we enhance the Camera class to provide us the info about the current view frustum so that we can check each object and see if it falls inside or outside of the frustum. To perform this check, we use the Radius property of the UnitBase class which is computed in the ComputeRadius method.

The BoundingSphere method of the Geometry class (the same one we use now for converting radians to degrees and vice versa) computes a sphere that completely contains all the points in the mesh using a vertex data of the mesh. The mesh contains this information in the vertex buffer. To access this buffer, it is best to lock it before access and unlock it when done. You should also make sure to dispose the vertex buffer when you are done. The safest way to do this is to leverage the using statement that will ensure that Dispose is called regardless of what happens.

Visual C#

private void ComputeRadius ( )
{
    using ( VertexBuffer vertexBuffer = _mesh.VertexBuffer )
    {
        GraphicsStream gStream = vertexBuffer.Lock ( 0, 0,
            LockFlags.None );
        Vector3 tempCenter;

        _radius = Geometry.ComputeBoundingSphere (gStream,
            _mesh.NumberVertices, _mesh.VertexFormat, 
            out tempCenter ) * _scale;

        vertexBuffer.Unlock ( );
    }
}

Visual Basic

Private Sub ComputeRadius()
    Dim vertexBuffer As VertexBuffer = Nothing
    Try
        vertexBuffer = m_mesh.VertexBuffer
        Dim gStream As GraphicsStream = _
            vertexBuffer.Lock(0, 0, LockFlags.None)
        Dim tempCenter As Vector3
        m_radius = Geometry.ComputeBoundingSphere(gStream, _
            m_mesh.NumberVertices, m_mesh.VertexFormat, tempCenter) * _
            m_scale
    Finally
        vertexBuffer.Unlock()
        vertexBuffer.Dispose()
    End Try
End Sub

You can probably understand why using the radius of the object is a very rough way of culling objects. It works fine and is fairly accurate if the objects are simple shapes, but for more complex shapes the bounding sphere becomes much larger than the basic object itself.

In a commercial game a lot of effort is invested in creating a culling routine that eliminates the most objects it can. We could also get fancy here and identify objects that are only partially in the frustum, but without the corresponding ability to render only a portion of the unit, we are just wasting our time. Instead we will treat any unit that has even a single point in the view frustum as being completely in the frustum.

So now that we have the radius of the unit, we need to know what the frustum is so we can check the radius against it.

View Frustum

Adding the frustum info to the camera is easy. First we add some data structures to hold the information about the view frustum. If you recall from the previous article, a frustum resembles a pyramid with the top cut off. This means that we need to store the corners of the top and bottom square and the plane for each side. For the corners we use an array of the familiar Vector3 structure. For the planes DirectX provides a convenient Plane structure.

Visual C#

private Vector3[] _frustumCorners;
private Plane[] _frustumPlanes;

Visual Basic

private Vector3[] _frustumCorners;
private Plane[] _frustumPlanes;

We then initialize the arrays in the constructor (two squares with four corners equals 8 points, and the four sides of the polygon plus the top and bottom make six planes).

Visual C#

_frustumCorners = new Vector3[8];
_frustumPlanes = new Plane[6];

Visual Basic

m_frustumCorners = New Vector3(8) {}
m_frustumPlanes = New Plane(6) {}

The next step is to compute the frustum using the current view and projection matrices.

Visual C#

private void ComputeViewFrustum ( )
{
    Matrix matrix = _viewMatrix * _perspectiveMatrix;
    matrix.Invert ( );

    _frustumCorners[0] = new Vector3 ( -1.0f, -1.0f, 0.0f ); // xyz
    _frustumCorners[1] = new Vector3 ( 1.0f, -1.0f, 0.0f ); // Xyz
    _frustumCorners[2] = new Vector3 ( -1.0f, 1.0f, 0.0f ); // xYz
    _frustumCorners[3] = new Vector3 ( 1.0f, 1.0f, 0.0f ); // XYz
    _frustumCorners[4] = new Vector3 ( -1.0f, -1.0f, 1.0f ); // xyZ
    _frustumCorners[5] = new Vector3 ( 1.0f, -1.0f, 1.0f ); // XyZ
    _frustumCorners[6] = new Vector3 ( -1.0f, 1.0f, 1.0f ); // xYZ
    _frustumCorners[7] = new Vector3 ( 1.0f, 1.0f, 1.0f ); // XYZ
    for ( int i = 0 ; i < _frustumCorners.Length ; i++ )
        _frustumCorners[i] = Vector3.TransformCoordinate (
            _frustumCorners[i], matrix );

    // Now calculate the planes
    _frustumPlanes[0] = Plane.FromPoints (
        _frustumCorners[0], 
        _frustumCorners[1], 
        _frustumCorners[2] ); // Near
    _frustumPlanes[1] = Plane.FromPoints ( 
        _frustumCorners[6], 
        _frustumCorners[7], 
        _frustumCorners[5] ); // Far
    _frustumPlanes[2] = Plane.FromPoints ( 
        _frustumCorners[2], 
        _frustumCorners[6], 
        _frustumCorners[4] ); // Left
    _frustumPlanes[3] = Plane.FromPoints ( 
        _frustumCorners[7], 
        _frustumCorners[3], 
        _frustumCorners[5] ); // Right
    _frustumPlanes[4] = Plane.FromPoints ( 
        _frustumCorners[2], 
        _frustumCorners[3], 
        _frustumCorners[6] ); // Top
    _frustumPlanes[5] = Plane.FromPoints ( 
        _frustumCorners[1], 
        _frustumCorners[0], 
        _frustumCorners[4] ); // Bottom
}

Visual Basic

Private Sub ComputeViewFrustum()
    Dim matrix As Matrix = m_viewMatrix * m_perspectiveMatrix
    matrix.Invert()
    m_frustumCorners(0) = New Vector3(-1.0F, -1.0F, 0.0F)
    m_frustumCorners(1) = New Vector3(1.0F, -1.0F, 0.0F)
    m_frustumCorners(2) = New Vector3(-1.0F, 1.0F, 0.0F)
    m_frustumCorners(3) = New Vector3(1.0F, 1.0F, 0.0F)
    m_frustumCorners(4) = New Vector3(-1.0F, -1.0F, 1.0F)
    m_frustumCorners(5) = New Vector3(1.0F, -1.0F, 1.0F)
    m_frustumCorners(6) = New Vector3(-1.0F, 1.0F, 1.0F)
    m_frustumCorners(7) = New Vector3(1.0F, 1.0F, 1.0F)
    Dim i As Integer = 0
    While i < m_frustumCorners.Length
        m_frustumCorners(i) = _
            Vector3.TransformCoordinate(m_frustumCorners(i), matrix)
        System.Math.Min( _
            System.Threading.Interlocked.Increment(i), i - 1)
    End While
    m_frustumPlanes(0) = Plane.FromPoints(m_frustumCorners(0), 
        m_frustumCorners(1), m_frustumCorners(2))
    m_frustumPlanes(1) = Plane.FromPoints( _
        m_frustumCorners(6), _
        m_frustumCorners(7), _
        m_frustumCorners(5))
    m_frustumPlanes(2) = Plane.FromPoints( _
        m_frustumCorners(2), _
        m_frustumCorners(6), _
        m_frustumCorners(4))
    m_frustumPlanes(3) = Plane.FromPoints( _
        m_frustumCorners(7), _
        m_frustumCorners(3), _
        m_frustumCorners(5))
    m_frustumPlanes(4) = Plane.FromPoints( _
        m_frustumCorners(2), _
        m_frustumCorners(3), _
        m_frustumCorners(6))
    m_frustumPlanes(5) = Plane.FromPoints( _
        m_frustumCorners(1), _
        m_frustumCorners(0), _
        m_frustumCorners(4))
End Sub

First we combine the view and projection matrices by multiplying them. Next we initialize the eight corners of the frustum as a cube immediately in front of the camera. These corners are then transformed and used to create the 6 planes using the FromPoints method of the plane.

The frustum is computed upon initialization of the class and on each render loop. Add a call to ComputeViewFrustum( ) to the bottom of the constructor of the Camera class and at the end of the Render method of the Camera class. (It needs to be at the end so it can use the newly computed view and projection matrices.) Now we can use the computed frustum and the radius for each unit to determine whether any part of the unit is in the frustum and should be rendered. The IsInViewFrustum method returns true if the unit is inside the frustum and false otherwise.

Visual C#

public bool IsInViewFrustum ( UnitBase unitToCheck )
{
    foreach ( Plane plane in _frustumPlanes )
    {
        if ( plane.A * unitToCheck.Position.X + plane.B *
             unitToCheck.Position.Y + plane.C * unitToCheck.Position.Z + 
             plane.D <= ( -unitToCheck.Radius ) )
        return false;
    }
    return true;
}

Visual Basic

Public Function IsInViewFrustum(ByVal unitToCheck As UnitBase) As Boolean
    For Each plane As Plane In m_frustumPlanes
        If plane.A * unitToCheck.Position.X + plane.B * _
            unitToCheck.Position.Y + plane.C * unitToCheck.Position.Z + _
            plane.D <= (-unitToCheck.Radius) Then
            Return False
        End If
    Next
    Return True
End Function

The process of culling should take place before the unit is rendered. We accomplish this in the Render method of the BaseUnit class by checking the frustum of the camera before actually rendering the mesh. By placing it into the actual Render method, we avoid having to check the cull state elsewhere in the code.

Visual C#

if (camera.IsInViewFrustum ( this ) == false )
    return;

Visual Basic

If camera.IsInViewFrustum(Me) = False Then
    Return
End If

Now that we have the basic infrastructure in place, it's time to start adding units. But the UnitBase class is abstract, so it can not be instantiated. The entire purpose of the base class was to keep common unit properties and functionality together. Now it's time to create some classes that represent the objects we are going to use in BattleTank 2005, namely obstacles and tanks.

Visual C#

public class Obstacle : UnitBase
{
    public Obstacle ( Device device, string meshFile, 
        Vector3 position, float scale )
         : base ( device, meshFile, position, scale )
    {
    }
}

Visual Basic

Public Class Obstacle
    Inherits UnitBase

    Public Sub New(ByVal device As Device, ByVal meshFile As String, _
    ByVal position As Vector3, ByVal scale As Single)
        MyBase.New(device, meshFile, position, scale)
    End Sub
End Class

The Obstacle class currently does nothing more than call its base class, but we are going add to this class later on.

Visual C#

public class Tank : UnitBase
{
    public Tank ( Device device, string meshFile, 
        Vector3 position, float scale ) 
        : base ( device, meshFile, position, scale )
    public void Update ( float deltaTime )
    private float _speed = 10.0f;
}

Visual Basic

Public Class Tank
    Inherits UnitBase

    Public Sub New(ByVal device As Device, ByVal meshFile As String, _
        ByVal position As Vector3, ByVal scale As Single)
        MyBase.New(device, meshFile, position, scale)
    End Sub
    Public Sub Update(ByVal deltaTime As Single)
        MyBase.Z -= (m_speed * deltaTime)
    End Sub
    Private m_speed As Single = 10.0F
End Class

The Tank class adds a _speed property we need to describe and an Update method.

Using time to simulate movement

The Update method takes in a float that describes the amount of time in seconds that has passed since the last render loop. In the second article we added a variable called deltaTime which we used to compute the frame rate. This value is the value we want to use from now on to compute the position of moving objects. We use the principle of time to ensure a similar experience on each computer regardless of the speed of the computer and make the movement appear fluid. For example, if we updated the position of a moving object by 1 in each pass through the render loop, the object would move fast on faster computers since they are able to complete a render loop faster. You may have seen this behavior when experimenting with the rotating cube. Another problem is that each pass through the render loop is not performed at the same speed, depending on the other operations the CPU is performing, so that the movement may appear choppy. (Again, the easiest way to understand this is to experiment. Change the increment of the Z axis by one instead of the speed * time formula and see what happens.)

Notice that we only need to update the tanks since the obstacles do not move.

Visual C#

foreach ( Tank tank in _tanks )
{
    tank.Update ( _deltaTime );
}

Visual Basic

For Each tank As Tank In m_tanks
    tank.Update(m_deltaTime)
Next

The actual Update method in the tank simply moves the tank towards the origin for now, using a predefined speed.

Visual C#

public void Update ( float deltaTime )
{
    base.Z -= ( _speed * deltaTime );
}

Visual Basic

Public Sub Update(ByVal deltaTime As Single)
    MyBase.Z -= (m_speed * deltaTime)
End Sub

Next we create two generic collections in the GameEngine class to hold the mobile and stationery units.

Visual C#

private List<UnitBase> _obstacles;
private List<UnitBase> _tanks;

Visual Basic

private List<UnitBase> _obstacles;
private List<UnitBase> _tanks;

The actual units are added to the collection in the CreateObstacles and CreateTanks methods.

Visual C#

private void CreateObstacles ( )
{
    _obstacles = new List<UnitBase> ( );
    _obstacles.Add ( new Obstacle ( _device, @"car.x", 
        new Vector3 ( 0, 0, 200 ), 1f ) );
    _obstacles.Add ( new Obstacle ( _device, @"car.x", 
        new Vector3 ( 60, 0, 100 ), 1f ) );
    _obstacles.Add ( new Obstacle ( _device, @"car.x", 
        new Vector3 ( -60, 0, 150 ), 1f ) );
    _obstacles.Add ( new Obstacle ( _device, @"car.x", 
        new Vector3 ( 60, 0, -100 ), 1f ) );
    _obstacles.Add ( new Obstacle ( _device, @"car.x", 
        new Vector3 ( -60, 0, -150 ), 1f ) );
}

private void CreateTanks ( )
{
    _tanks = new List<UnitBase> ( );
    _tanks.Add ( new Tank (_device, @"bigship1.x", 
        new Vector3 ( 0, 0, 200 ), 1f ) );
    _tanks.Add ( new Tank (_device, @"bigship1.x", 
        new Vector3 ( 100, 0, 300 ), 1f ) );
    _tanks.Add ( new Tank (_device, @"bigship1.x", 
        new Vector3 ( -100, 0, 500 ), 1f ) );
    _tanks.Add ( new Tank (_device, @"bigship1.x", 
        new Vector3 ( 100, 0, -200 ), 1f ) );
    _tanks.Add ( new Tank (_device, @"bigship1.x", 
        new Vector3 ( -100, 0, -400 ), 1f ) );
}

Visual Basic

Private Sub CreateObstacles()
    m_obstacles = New List(Of UnitBase)()
    m_obstacles.Add(New Obstacle(m_device, "car.x", _
        New Vector3(0, 0, 200), 1.0F))
    m_obstacles.Add(New Obstacle(m_device, "car.x", _
        New Vector3(60, 0, 100), 1.0F))
    m_obstacles.Add(New Obstacle(m_device, "car.x", _
        New Vector3(-60, 0, 150), 1.0F))
    m_obstacles.Add(New Obstacle(m_device, "car.x", _
        New Vector3(60, 0, -100), 1.0F))
    m_obstacles.Add(New Obstacle(m_device, "car.x", _
        New Vector3(-60, 0, -150), 1.0F))
End Sub
Private Sub CreateTanks()
    m_tanks = New List(Of UnitBase)
    m_tanks.Add(New Tank(m_device, "bigship1.x", _
        New Vector3(0, 0, 200),1.0F))
    m_tanks.Add(New Tank(m_device, "bigship1.x", _
        New Vector3(100, 0, 300), 1.0F))
    m_tanks.Add(New Tank(m_device, "bigship1.x", _
        New Vector3(-100, 0, 500), 1.0F))
    m_tanks.Add(New Tank(m_device, "bigship1.x", _
        New Vector3(100, 0, -200), 1.0F))
    m_tanks.Add(New Tank(m_device, "bigship1.x", _
        New Vector3(-100, 0, -400), 1.0F))
End Sub

If you look at the coordinates for the obstacles and tanks, you will see that I placed them along similar axes to help me orient myself. You could also modify these methods to create a random number of obstacles and tanks placed at random coordinates. Just make sure to add logic to avoid objects overlapping each other or being too close to the origin and obscuring the camera.

Levels

A more flexible and extensible solution is to read the number, type and location of obstacles and tanks from a file. This file could also contain other play-specific settings and be loaded automatically based on some internal logic. The most common use of this scenario is for predefined levels. A player would have the ability to advance to more difficult levels after meeting some completion criteria. This allows you to easily create an ever-changing play experience and fine-tune the playability of each level, something you can't do with random placement. Setting the game up that way also allows players to customize the game for themselves. You would normally provide a level editor when following this route.

The final step is to call these methods. The best place is the constructor of the GameEngine class right after the Camera class is created.

Visual C#

public GameEngine ()
{
    InitializeComponent ( );
    this.SetStyle (ControlStyles.AllPaintingInWmPaint | 
                    ControlStyles.Opaque, true );
    ConfigureInputDevices ( );
    ConfigureDevice ( );
    _skyBox = new SkyBox ( this._device );
    _camera = new Camera ( );
    CreateObstacles ( );
    CreateTanks ( );
    this.Size = new Size ( 800, 600 );
    HiResTimer.Start ( );
}

Visual Basic

Public Sub New()
    InitializeComponent()
    Me.SetStyle(ControlStyles.AllPaintingInWmPaint Or _
        ControlStyles.Opaque, True)
    ConfigureInputDevices()
    ConfigureDevice()
    m_skyBox = New SkyBox(Me.m_device)
    m_camera = New Camera
    CreateObstacles()
    CreateTanks()
    Me.Size = New Size(800, 600)
    HiResTimer.Start()
End Sub

On each render loop all we have to do is to iterate over the appropriate collection and render those that are in the frustum. We call the RenderUnits method in the Render method of the GameEngine class immediately after rendering the skybox.

Visual C#

private void RenderUnits ( )
{
    foreach ( UnitBase ub in _obstacles )
    {
        ub.Render ( _camera );
    }

    foreach ( UnitBase ub in _tanks )
   {
        ub.Render ( _camera );
    }
}

Visual Basic

Private Sub RenderUnits()
    For Each ub As UnitBase In m_obstacles
        ub.Render(m_camera)
    Next
    For Each ub As UnitBase In m_tanks
        ub.Render(m_camera)
    Next
End Sub

That's all. Now we have units.

Conclusion

If you run the game now you will notice three things.

• The units seem to float in mid-space.
• The units are all white.
• You can drive right through each unit.

The first problem can be solved by adding a terrain to the game to show a solid surface along the Y axis. The second problem can be solved by adding lights to the scene. The final issue will be solved once we add collision detection to the game. Other then these items, the game is getting more playable by the day. In the next article we are going to add the missing terrain using a heightmap, add lights so we can see the colors of the units, and add some collision detection.

As you may have noticed, I have changed (and will continue to do so) the various graphics in the game from article to article. This is intended to encourage you to implement your own graphics to change the underlying game into something completely different. You could easily change this game to be set in space, or turn it into a powerboat racing game by just changing the graphics. Give it a try.

As usual, I ran out of time. In the last article I had promised to add the HUD back, but I ran out of space. I will try to accomplish this in the coming articles. I also wanted to discuss Action mapping to enhance the way we are tracking the keyboard and mouse inputs, but this subject will have to be covered in a later article. In addition, I am planning to add a simple debugging console to the game.

Along with these features, the next articles are going to discuss adding Artificial Intelligence to the opposing tanks, making our game conform to realistic physical forces, and some cool sounds to make playing the game more fun. So stay tuned.

Until then: Happy coding.

1. Beginning Game Development Part 1 - Introduction
2. Beginning Game Development Part II - Introduction to DirectX
3. Beginning Game Development: Part III - DirectX II
4. Beginning Game Development: Part IV - DirectInput
5. Beginning Game Development: Part V - Adding Units
6. Beginning Game Development: Part VI - Lights, Materials and Terrain
7. Beginning Game Development: Part VII –Terrain and Collision Detection
8. Beginning Game Development: Part VIII - DirectSound
9. Beginning Game Development: Part VIII - DirectSound II
10. Beginning Game Development: Part VIII - DirectSound III

Welcome to the fourth article on beginning game development. In this article we are going to cover the input device portion of DirectX, called DirectInput. Using DirectInput you can control joysticks, a mouse or the keyboard.

Before we start I need to cover a couple of items that were brought to my attention via feedback from the readers (thank you everyone for taking the time to do this) and changes not directly related to the items covered in this article.

Code Cleanup

To make adding the code for this section easier and to make the code more reusable I have moved some of the code from the GameEngine class into separate classes such as Camera. Encapsulating the camera functionality in a separate object makes the code easer to change and to read. The following changes have already been integrated into the code for this article.

1. I moved the FrameworkTimer class out of the DirectX support code into a class called HiResTimer and removed the using statements for Microsoft.Samples.DirectX.UtilityToolkit. For the VB version I converted the FrameworkTimer class into VB and removed the reference to the DirectX Sample Framework library.
2. I refactored the device creation code in the constructor of the GameEngine class into the ConfigureDevice method.
3. I refactored all code that deals with the device in the OnPaint method of the GameEngine class into the Render method.
4. I refactored the code that sets up the camera in the OnPaint method of the GameEngine class into the Camera class.
5. I removed the CreateCrossHairVertexArrayTop, CreateCrossHairVertexArrayBottom, CreateTestTriangle, and CreateTestCube methods from the GameEngine Class.
6. Removed the System.Collections.Generic, System.ComponentModel, System.Data and System.Text using statements from the GameEngine class.
7. I removed all of the code used for experimenting with the camera settings.

In addition to these general housekeeping changes I added some code that I needed to make the DirectInput portion more interesting.

Skybox

The infinite 3D space we have created has one problem: it's infinite. We have no distinguishing terrain features to orient us and, as such, have no idea in which direction we are facing. We could create a number of complex 3D objects to draw a realistic terrain, but this is very slow and we really do not need 'real' terrain, but only to create the look of real terrain. To create this illusion of seeing a horizon and terrain in the distance, we make use of a technique called the skybox. A skybox creates the effect you get when placing your head into a cardboard box, the inside of which is painted with a landscape: Regardless where you are and where you look you see the inside of the box and nothing else.

In our game we create a cube and display textures (or pictures for us that prefer to use more normal definitions) on the inside walls of the cube. The top would be textured like the sky, the bottom like the ground and the remaining four sides have a texture applied to them that shows a horizon and terrain. The pictures for the four sides are designed in such a manner that they match perfectly at the edges and produce a seamless landscape. These four sides could then represent cardinal directions such as east, west, north and south (if your game is set on Earth).

To achieve the correct effect, we need to ensure that all objects are drawn on top of the skybox. This is done by disabling Z-buffering before drawing the skybox and enabling it after we are done.

Visual C#

_device.RenderState.ZBufferWriteEnable = false; 
// draw the skybox here 
_device.RenderState.ZBufferWriteEnable = true;

Visual Basic

_device.RenderState.ZBufferWriteEnable = False
'draw the skybox here
_device.RenderState.ZBufferWriteEnable = True

The next thing we need to ensure is that the player can never actually get close to or beyond the skybox (otherwise they would notice the illusion). We accomplish this by ensuring that the viewpoint is always in the center of the skybox.

First we assign an Identity matrix to the world matrix. Since the vertices of the skybox are in model space (offset around zero), this ensures that they are not translated into world space. Then we set the use the View matrix of the camera to set the View matrix of the skybox.

Visual C#

Matrix worldMatrix = Matrix.Identity;
Matrix viewMatrix = cam.View;

viewMatrix.M41 = 0.0f;
viewMatrix.M42 = 0.0f;
viewMatrix.M43 = 0.0f;

_device.Transform.View = viewMatrix;
_device.Transform.World = worldMatrix;

Visual Basic

Dim worldMatrix As Matrix = Matrix.Identity
Dim viewMatrix As Matrix = cam.View
viewMatrix.M41 = 0.0F
viewMatrix.M42 = 0.0F
viewMatrix.M43 = 0.0F
_device.Transform.View = viewMatrix
_device.Transform.World = worldMatrix

Drawing the actual skybox uses the techniques we have discussed in the previous articles and I am not going to cover them in detail. The basic steps are as follows.

1. Define a PositionNormalTextured vertex array to hold the data for the four corners of each cube face and texture information.
2. Load the texture for each cube face from a file.
3. Setup the Vertex buffer for each face.
4. On each Render loop readjust the skybox.
5. On each Render loop disable Z-buffering.
6. On each Render loop use the Camera object passed in to determine the direction the camera is facing and draw the appropriate face.
7. On each Render loop turn Z-buffering back on.

If you look at the RenderFace method of the SkyBox class, you will notice that it is identical to the code we used to draw the triangle and cube in the last article.

Visual C#

_device.SetStreamSource ( 0, faceVertexBuffer, 0 );
_device.VertexFormat = CustomVertex.PositionNormalTextured.Format;
_device.SetTexture ( 0, faceTexture );
_device.DrawPrimitives ( PrimitiveType.TriangleStrip, 0, 2 );

Visual Basic

_device.SetStreamSource(0, faceVertexBuffer, 0)
_device.VertexFormat = CustomVertex.PositionNormalTextured.Format
_device.SetTexture(0, faceTexture)
_device.DrawPrimitives(PrimitiveType.TriangleStrip, 0, 2)

Camera Class

The other major refactoring I did for this article is to move all the camera-related code into the Camera class. The fixed values such as FoV and aspect ratio used in the Perspective matrix are set as internal properties with the appropriate default values. I have also added methods that allow the camera to be moved left or right and up or down, and a method that moves the position of the camera. Why I added these methods will become clear once we integrate user input later in the article.

Now that all of the graphics for the game except the enemy units are done, let's get the tank moving so we can explore our new world.

Controlling Input

Controlling input devices is not nearly as cool as graphics manipulation or artificial intelligence, but without it you couldn't have a game. Reacting to user input allows the user to move around in and manipulate the 3D world we have created.

The DirectInput API allows you to control the mouse, keyboard, joystick, game-pad, or force feedback device. Some games also provide the ability for voice input to control the game, but that is beyond the scope of our game.

Adding DirectInput

The first step when adding input support to an application is to reference the Microsoft.DirectX.DirectInput.dll assembly. The next step is to add the using statement to each class in which you plan to use the DirectInput classes (unless you really like typing).

Detecting Devices

A good API provides a common way to access similar devices. This is true in DirectX where physical devices such as video cards, sound cards, and input devices are abstracted into the Device class. This class shields us as developers from knowing any of the hardware-specific details. In the DirectInput namespace a Device represents any of the potential input devices.

Another familiar construct is the Manager class. We used the Manager class from the Direct3D namespace to get information about the adapters and to retrieve device capabilities for each adapter. In DirectInput the process is very similar.

To get a list of specific devices such as all keyboards connected to the computer, you use the GetDevices method of the Manager class and pass in the DeviceClass or DeviceType and one of the EnumDevicesFlags enumeration values to filter the list further. A computer can have many input devices but as a minimum it should have a keyboard and mouse.

Note: Most of the time you are going to use EnumDevicesFlags.AttachedOnly to get only the attached devices of a particular type.

To make things a little more obscure, a mouse is considered a Pointer type in the DeviceClass enumeration. You can use any combination of to retrieve a custom list of input devices.

Each call to GetDevices returns a DeviceList class. This DeviceList in turn contains a DeviceInstance structure for each device. The DeviceInstance structure contains the information about each device, the most important of which is the InstanceGuid. This is a unique identifier for each device on our system that we need to know so we can communicate with that device.

Note: Just because a device is in the DeviceList does not mean that it is actually attached. You can use the InstanceGuid and the GetDeviceAttached method to determine if the device is attached.

The Manager class exposes a Devices property that contains a DeviceList.

Note that the DeviceInstance structure is not actually a device; there is nothing we can do with it in terms of connecting to it. The only use it has is to provide a GUID which we can then use to actually connect to or acquire that device.

Connecting to a Keyboard

The first device we are going to connect to is the keyboard. This is probably the most common device used to interact with games. Most modern games enable the user to control the game using the keyboard and the mouse, as there are too many actions to perform to use just one of these devices. Depending on your audience, you need to choose the primary input device and decide whether to offer configurable choices for secondary devices. You also need to remember that some computers, such as slate-mode Tablet PCs, have no keyboard, so offering alternate input means broadens your potential audience.

Regardless of what input options you offer, the steps to set up any input device are the same.

1. Instantiate a Device class passing the type of device.
2. Set the cooperation level of the device.
3. Set the format of the data returned for the device.
4. Acquire the device.
5. Poll the device.
6. Read the state data to determine what actions the user did.

Using good OO practices, we first create a keyboard class that will encapsulate all keyboard-specific functionality and provide a single access point for the rest of the game to any keyboard functionality.

The first step is to create a Device object for the keyboard. We do this using the Keyboard value of the SystemGuid enumeration. This lets us connect to the default keyboard. Using the default keyboard is safer than enumerating the devices and picking a specific one, because you don't know beforehand what devices all your users might have.

Visual C#

_device = new Device ( SystemGuid.Keyboard );

Visual Basic

_device = New Device(SystemGuid.Keyboard)

The next step is to set the Cooperative level of the device. The values of the CooperativeLevelFlags enumeration determine how much control we chose to take over the device and how much control we leave to other applications.

The CooperativeLevelFlags enumeration contains five values.

• Exclusive
• NonExclusive
• Foreground
• Background
• NoWindowsKey

The Background and Foreground values are mutually exclusive, as are the Exclusive and NonExclusive values. The Foreground option states that we only want data from the device if the window we passed into the SetCooperativeLevel method has the focus. The Background option simply means that we always want data from the device. Exclusive means that we want priority for control of the device while NonExclusive means we don't. Even when using the Exclusive option it is still possible to lose the device, which is why we add the reacquire logic to the Poll method to ensure we can get the device back when we want to read its state. The NoWindowsKey option can be combined with any of the other settings and specifies that we want to ignore the Windows logo key on the keyboard. This setting is important when running in full screen mode, because the Windows key causes the application to loose focus.

For BattleTank 2005 we combine the Background and NonExclusive values to allow other applications maximum control over this device.

We also need to pass in a reference to the window we are using so DirectX knows which window's input we are interested in.

Visual C#

_device.SetCooperativeLevel ( form, CooperativeLevelFlags.Background | 
    CooperativeLevelFlags.NonExclusive ); 

Visual Basic

_device.SetCooperativeLevel(form, CooperativeLevelFlags.Background Or _ 
    CooperativeLevelFlags.NonExclusive)

The next step is to determine the data format we expect this device to return. We cover the contents of this data structure a little later in the article.

Visual C#

_device.SetDataFormat ( DeviceDataFormat.Keyboard ); 

Visual Basic

_device.SetDataFormat(DeviceDataFormat.Keyboard)

The last step is to actually acquire the device. You can think of this like opening a communications channel to the device. Since there are lots of things that could go wrong at this point, it is best to wrap the Acquire call into a try/catch block.

Visual C#

try
{
    _device.Acquire ( );
}
catch ( DirectXException ex )
{
    Console.WriteLine ( ex.Message );
}

Visual Basic

Try
    _device.Acquire()
Catch ex As DirectXException
    Console.WriteLine(ex.Message)
End Try

After acquiring the device we can read its state, which is a byte array. The first 256 values of this array hold the state of the keyboard; the next 8, the state of the mouse; and the last 32, the state of the joystick. Setting the device data format simply restricts the returned array to the set of values for the specified device. The KeyboardState structure, for example, only contains the first 256 bytes of the raw state.

Visual C#

private KeyboardState _state; 

Visual Basic

Private _state As KeyboardState

To get this state from the device we first call the Poll method. This method communicates with the actual hardware. Then we copy the state into a local data structure (the _state variable).

Since we are going to do this on every frame, I placed this particular sequence of calls into their own public method called Poll. In the game loop we then call _keyboard.Poll() and use the state data structure to see what keys were pressed. This is where we deal with a device which may have been acquired by another application by attempting to reacquire it.

Visual C#

try
{
    _device.Poll ( );
    _state = _device.GetCurrentKeyboardState ( );
}
catch ( NotAcquiredException )
{
    // try to reqcquire the device
    try
    {
        _device.Acquire ( );
    }
    catch ( InputException iex )
    {
        Console.WriteLine ( iex.Message );
        // could not get the device
    }
}
catch ( InputException ex2 )
{
    Console.WriteLine ( ex2.Message );
}

Visual Basic

Try
    _device.Poll()
    _state = _device.GetCurrentKeyboardState
Catch generatedExceptionVariable0 As NotAcquiredException
    Try
        _device.Acquire()
    Catch iex As InputException
        Console.WriteLine(iex.Message)
    End Try
Catch ex2 As InputException
    Console.WriteLine(ex2.Message)
End Try

The only step remaining is to examine the state data returned to see what actions the user performed.

In addition to managing the device state each time we poll the device, we want to make sure to release it when we are finished using it. We accomplish this by calling the Unacquire method of the device in the Dispose method.

Visual C#

if ( _device != null )
    _device.Unacquire ( );

Visual Basic

If Not (_device Is Nothing) Then
    _device.Unacquire()
End If

Connecting to a Mouse

Connecting to a mouse is almost identical to connecting to a keyboard. The differences are the SystemGuid passed to the Device constructor, the DeviceDataFormat, the data structure used to store the state information, and the method call used to retrieve the device state.

Visual C#

_device = new Device ( SystemGuid.Mouse );
_device.SetDataFormat ( DeviceDataFormat.Mouse );
private MouseState _state;
public void Poll ( )
{
    _device.Poll ( );
    _state = _device.CurrentMouseState;
}

Visual Basic

_device = New Device(SystemGuid.Mouse)
_device.SetDataFormat(DeviceDataFormat.Mouse)
Private _state As MouseState
Public Sub Poll()
        _device.Poll()
        _state = _device.CurrentMouseState
End Sub

Using the mouse also provides the ability to define how the X, Y and Z (No, don't pick up your mouse, the Z value is the value for the mouse scroll wheel on certain mice) values are reported on each poll. Setting the AxisModeAbsolute value to true returns the coordinates in screen coordinates, while setting this value to false returns the change in pixels from the previous poll. We set this value as soon as we have acquired the device.

Visual C#

_device.Acquire ( );
_device.Properties.AxisModeAbsolute = false;

Visual Basic

_device.Acquire()
_device.Properties.AxisModeAbsolute = False

Using the false option is valuable if you want to determine the speed in which the user moved the mouse using the time elapsed between polls and the distance traveled in that time frame while the first option is more valuable if the user is selecting something from the screen.

Connecting to a Joystick

Connecting to a joystick follows the same general steps as for the keyboard and mouse, but, since there is no such thing as a default joystick, no corresponding SystemGuid value exists. Instead, we need to use the GetDevices method of the Manager class, passing in GameControl type for the DeviceClass and AttachedOnly for the EnumDevicesFlags to enumerate any attached joysticks. You would probably want to present some type of UI to the user to let them choose from a list of devices found or you could just use the first device as the code snippet does.

Visual C#

DeviceList gameControllerList = 
    Manager.GetDevices(
        DeviceClass.GameControl, 
        EnumDevicesFlags.AttachedOnly);

if (gameControllerList.Count > 0)
{
    foreach (DeviceInstance deviceInstance in gameControllerList)
    {
        _device = new Device(deviceInstance.InstanceGuid);
        _device.SetCooperativeLevel(form,
            CooperativeLevelFlags.Background | 
            CooperativeLevelFlags.NonExclusive);
        break;
    }
}

Visual Basic

Dim gameControllerList As DeviceList
gameControllerList = Manager.GetDevices(DeviceClass.GameControl, _
    EnumDevicesFlags.AttachedOnly)
If (gameControllerList.Count > 0) Then
    Dim deviceInstance As DeviceInstance
    For Each deviceInstance In gameControllerList
        _device = New Device(deviceInstance.InstanceGuid)
        _device.SetCooperativeLevel(Form, CooperativeLevelFlags.Background 
        Or CooperativeLevelFlags.NonExclusive)
        Break()
    Next
End If

The next step is to specify a new DeviceDataFormat and new type for the _state data structure. Finally you need to retrieve the joystick state from the device inside the Poll method.

Visual C#

_device.SetDataFormat ( DeviceDataFormat.Joystick );
private JoystickState _state;
public void Poll ( )
{
    _device.Poll ( );
    _state = _device.CurrentJoystickState;
}

Visual Basic

_device.SetDataFormat(DeviceDataFormat. Joystick)
Private _state As JoystickState
Public Sub Poll()
        _device.Poll()
        _state = _device.CurrentJoystickState
End Sub

In BattleTank 2005 we are not going to use a joystick, but feel free to add this capability on your own if you have a joystick. If you own a force-feedback device you might also want to experiment with using it in the game.

Now that we have access to the various forms of input devices, and know how to retrieve their state we need to know how to read the various state data structures to determine user actions.

Determining User Actions

Each of the data structures for the state are byte arrays. The KeyboardState is a byte array 256 bytes long. Each byte represents the state of a key on the keyboard and the position in the array matches the value of the Key enumeration. The indexer for the KeyboardState returns a Boolean value for each index checked. For example, to see if the user pressed the Escape key you simply test that the most significant bit is set at that index location (position 1 for Escape) in the array. If this expression returns true then the user pressed the Escape key, otherwise it returns false.

Each poll method may return values for multiple keys such as when the user pressed certain key combinations (Ctrl+Alt+Delete is a common one for me when I program). DirectInput supports a maximum of five key values, but you should be nice to your users and stick to single key actions if possible.

Visual C#

_state[Key.Escape] 

Visual Basic

_keyboard.State(Key.Escape)

The MouseState is a structure that provides three public properties for the X, Y and Z values, as well an eight byte long array for the state of the mouse buttons that is retrieved by calling the GetMouseButtons method.

Checking for the button information is the same for the mouse buttons as it was for the keyboard keys. You simply check the most significant bit at each position to determine if the corresponding button was pressed.

Visual C#

if ( 0 != mouseButtons[0])
    Console.WriteLine ( "Primary Button pressed" );

Visual Basic

If Not (0 = _mouse.MouseButtons(0)) Then
    Console.WriteLine("Fire!")
End If

The 0 position represents the primary button which could be the left or right mouse button depending on how the user configured the mouse.

Depending on the AxisModeAbsolute setting, the X, Y and Z values return the absolute or relative position of the mouse. Regardless of this setting the values for the X axis are always positive to the right and negative to the left, positive forward and negative backward for the Y value, and positive when spinning the scroll wheel forward and negative backward for the Z value.

Reacting to User Action

Now that we can detect what the user is doing, it is time to take that input and use it to manipulate our world. First we create a method called CheckForInput that will contain all of the input-related code. (In a later article I will show you why this is not the best way of tracking and reacting to user input and how a system called Action Mapping can be used to reduce the amount of code and avoid code duplication.) For right now we are going to set up BattleTank 2005 to use the cursor keys to change the heading and pitch of the camera (move it up/down and left/right). Note that this does not change the location of the camera. The first step is to poll the devices to retrieve the latest state information.

Visual C#

_keyboard.Poll ( );
_mouse.Poll ( );

Visual Basic

_keyboard.Poll()
_mouse.Poll()

Then we test the state for the keys we are interested in and react accordingly.

Visual C#

if ( _keyboard.State[Key.LeftArrow] )
    _camera.MoveCameraLeftRight ( -0.5f );

if ( _keyboard.State[Key.RightArrow] )
    _camera.MoveCameraLeftRight ( 0.5f );

if ( _keyboard.State[Key.UpArrow] )
    _camera.MoveCameraUpDown ( -0.5f );

if ( _keyboard.State[Key.DownArrow] )
    _camera.MoveCameraUpDown ( 0.5f );

Visual Basic

If _keyboard.State(Key.LeftArrow) Then
    _camera.MoveCameraLeftRight(-0.5F)
End If
If _keyboard.State(Key.RightArrow) Then
    _camera.MoveCameraLeftRight(0.5F)
End If
If _keyboard.State(Key.UpArrow) Then
    _camera.MoveCameraUpDown(-0.5F)
End If
If _keyboard.State(Key.DownArrow) Then
    _camera.MoveCameraUpDown(0.5F)
End If

We also want to use the mouse to move the camera, so we add another set of checks for the mouse input.

Visual C#

if ( 0 != ( _mouse.State.X | _mouse.State.Y ) )
{
    _camera.MoveCameraLeftRight ( _mouse.State.X / 10 );
    _camera.MoveCameraUpDown ( _mouse.State.Y / 10 );
}

Visual Basic

If Not (0 = (_mouse.State.X Or _mouse.State.Y)) Then
    _camera.MoveCameraLeftRight(_mouse.State.X / 10)
    _camera.MoveCameraUpDown(_mouse.State.Y / 10)
End If

You can adjust the increments used in the MoveCameraLeftRight and MoveCameraUpDown methods to make the movement slower or faster.

The final step is to add a key that enables us to exit the application. The Escape key is the natural choice:

Visual C#

if ( _keyboard.State[Key.Escape] )
{
    Application.Exit ( );
}

Visual Basic

If _keyboard.State(Key.Escape) Then
    Application.Exit()
End If

In addition to moving the camera around, we also want to move the location of the camera since that is how we are going to simulate driving around in our tank. The only problem is that, with no fixed items in the world, we can't really tell when we have moved, since the only reference point is the skybox, which never changes position. To overcome this limitation until we add units in the next article, I am simply writing out the new camera location to the Console whenever it changes.

Visual C#

if ( _keyboard.State[Key.W] )
    _camera.MoveCameraPosition ( 10, 0, 0 );

if ( _keyboard.State[Key.S] )
    _camera.MoveCameraPosition ( -10, 0, 0 );

if ( _keyboard.State[Key.A] )
    _camera.MoveCameraPosition ( 0, 10, 0 );

if ( _keyboard.State[Key.D] )
    _camera.MoveCameraPosition ( 0, -10, 0 );

if ( oldX != _camera.X )
{
    Console.WriteLine ( _camera.X + ", " + _camera.Y );
    oldX = _camera.X;
}

Visual Basic

If _keyboard.State(Key.W) Then
    _camera.MoveCameraPosition(10, 0, 0)
End If
If _keyboard.State(Key.S) Then
    _camera.MoveCameraPosition(-10, 0, 0)
End If
If _keyboard.State(Key.A) Then
    _camera.MoveCameraPosition(0, 10, 0)
End If
If _keyboard.State(Key.D) Then
    _camera.MoveCameraPosition(0, -10, 0)
End If
If Not (oldX = _camera.X) Then
    Console.WriteLine(_camera.X & ", " & _camera.Y)
    oldX = _camera.X
End If

The last piece of input-checking we need to add is checking the mouse buttons. For right now, let's assume that the default button on the mouse causes the tank to fire. We are going to add more exciting action later on, but all we can do now is to write "Fire!" to the Console.

Visual C#

if ( 0 != _mouse.MouseButtons[0] )
    Console.WriteLine ( "Fire!" );

Visual Basic

If Not (0 = _mouse.MouseButtons(0)) Then
    Console.WriteLine("Fire!")
End If

That's it for input. As I mentioned before, there are better ways of relating keyboard and mouse keys and movement to actions in the game. You may also notice that when moving the camera, sometimes a single button click causes two movements. This is due to the fact that the game loop is faster than we are and the key is pressed long enough to be picked up in two game loops. We are also going to fix that in the next article.

Summary

Once again I find myself running out of space before being able to cover all of the items I wanted, but I hope there is enough stuff here to let you experiment on your own. We are going to continuously refine the game in each iteration rather than trying to get it perfect the first time; that is the sprit of Agile development. The important things to remember are how to use the Device class to acquire and then poll an input device, and how to determine the input from the State objects.

Even though we are now able to maneuver through the 3D world, it is not very exciting, since other than the skybox there are no other items in our world. In the next article we are going to fix that by adding units, both stationary and mobile, and work on collision detection. We are also going to refine the camera to help us in reducing the number of items we need to render by tacking the frustum. Oh—yes, I do know that the targeting crosshairs are gone; they will be back in the next article in the form of a real Heads-Up-Display (HUD) class.

Until then: Happy coding.

Introduction

Welcome to the third article on beginning game development. In this article we are going to cover some of the more advanced DirectX principles such as transforms, matrices, culling and clipping.

Before we start, I need to cover a couple of items that were brought to my attention via feedback from the readers (thank you everyone for taking the time to do this) and changes not directly related to the items covered in this article.

Code Cleanup

These changes have already been integrated into the code for this article.

1. I updated to the June 2005 version DirectX SDK. I did have an issue with the DirectX assemblies being added to the Global Assembly Cache (GAC), so if you have any build errors, update the references to: C:\Program Files\Microsoft DirectX 9.0 SDK (June 2005)\Developer Runtime\x86\DirectX for Managed Code.
2. In the last article you surrounded the IsWindowed setting for the PresentParameters with a #if DEBUG statement. To enable this option you must go to the Project settings and enable it:
   • Right-click the BattleTank2005 project and select Properties.
   • Select the Build tab.
   • In the general section, check the Define DEBUG constant option.
3. Change the color in the device.Clear method call from DarkBlue to Black.
4. Add the following code at the very end of the GameEngine constructor to make the form a more standard size.

Visual C#

// force the window to a standard size
// the provides the correct aspect ratio of 1.33
this.Size = new Size ( 800, 600 );

Visual Basic

'force the window to a standard size
' the provides the correct aspect ratio of 1.33
Me.Size = New Size(800, 600)

5. Change the Startup position of the form to CenterScreen.
   • Right-click the GameEngine form and select View Designer.
   • In Properties, change the StartPosition property to CenterScreen

Now we can actually draw something on the screen and start creating the game.

Drawing the targeting crosshairs.

In BattleTank 2005 we are sitting inside of a tank and looking through the targeting scope at the world around us. We use the targeting crosshairs to make it easier to hit and destroy the enemy. In real life the crosshairs are fixed in the optics of the cannon, so they are always visible and located in the same spot when looking through the targeting scope as a Heads-up Display (HUD).

In our game we have two choices when drawing the crosshairs.

1. Draw them directly onto the center of the screen using screen coordinates.
2. Draw them using world coordinates and ensure that the view point is located such that they are visible and centered on the screen.

The tradeoff here is between speed and extensibility. If we choose the first option we do not have to transform the coordinates, since they are already in screen coordinates, which is faster. In effect, we are removing the targeting crosshairs from the model space we are creating. The downside is that if we chose to change the game later on and allow the player to leave the tank, the crosshairs would also be visible when they walk around. The second option requires the coordinates to be adjusted and transformed, but provides us with the ultimate flexibility to change the game later on.

I am going to use option 2 because it is the most flexible and I am not going to waste time trying to optimize the game for speed before knowing that it is slow. When you write a game you will be faced with design choices like this and you have to understand the tradeoffs you are making.

Before we move on, let's define a model that will make it easier to describe and (we hope) understand the terms we are going to cover in this article.

A Model

Imagine an empty room. I determine where in the room the X, Y, Z origin is located. In this example let's say that the front left corner of the room is the origin in this world. This room becomes my World Space. (A real world space is infinite, but for now we can make do with the finite space of the room.)

World Space: An infinite three-dimensional Cartesian space. You place your objects anywhere you want in this world to create the environment you want.

Now I place a chair in the room at a predefined location. Each point on the chair can be accurately described using a set of Cartesian coordinates (X, Y, Z) and optional information about each point such as color (Color) and texture (Tu, Tv). If you think back to the last article you will notice that this makes each point a vertex. Since we have lots of separate vertices, we store all of them in a vertex array. When this array is loaded into memory it becomes a vertex buffer.

Vertex buffer

Vertex buffers are ideally suited for the complex transformations that DirectX needs to perform. DirectX provides a number of predefined vertex types representing the most common vertex formats. These types are defined as structures in the CustomVertex class.

We are going to use the PositionColored vertex for the targeting crosshairs. This vertex provides X, Y, Z properties and a Color property, which is exactly what we need. This vertex also defines the coordinates' world space rather than screen space, which is what we decided to do.

Add the following methods to the GameEngine class after the OnPaint method.

Visual C#

private CustomVertex.PositionColored[] CreateCrossHairVertexArrayTop ( )
{ 
    CustomVertex.PositionColored[] crossHairs = 
        new CustomVertex.PositionColored[7];
    float zval = 0f;
    
    // top of targeting crosshairs
    crossHairs[0].Position = new Vector3 ( -1f, 1f, zval );
    crossHairs[1].Position = new Vector3 ( -1f, 2f, zval );
    crossHairs[2].Position = new Vector3 ( 0f, 2f, zval );
    crossHairs[3].Position = new Vector3 ( 0f, 3f, zval );
    crossHairs[4].Position = new Vector3 ( 0f, 2f, zval );
    crossHairs[5].Position = new Vector3 ( 1f, 2f, zval );
    crossHairs[6].Position = new Vector3 ( 1f, 1f, zval );
    
    crossHairs[0].Color = Color.Green.ToArgb ( );
    crossHairs[1].Color = Color.Green.ToArgb ( );
    crossHairs[2].Color = Color.Green.ToArgb ( );
    crossHairs[3].Color = Color.Green.ToArgb ( );
    crossHairs[4].Color = Color.Green.ToArgb ( );
    crossHairs[5].Color = Color.Green.ToArgb ( );
    crossHairs[6].Color = Color.Green.ToArgb ( );
        
    return crossHairs;
}
    
private CustomVertex.PositionColored[] CreateCrossHairVertexArrayBottom ()
{
    CustomVertex.PositionColored[] crossHairs = 
        new CustomVertex.PositionColored[7];
    
    // bottom of targeting crosshairs
    float zval = 0f;
    
    // bottom of targeting crosshairs
    crossHairs[0].Position = new Vector3 ( 1f, -1f, zval );
    crossHairs[1].Position = new Vector3 ( 1f, -2f, zval );
    crossHairs[2].Position = new Vector3 ( 0f, -2f, zval );
    crossHairs[3].Position = new Vector3 ( 0f, -3f, zval );
    crossHairs[4].Position = new Vector3 ( 0f, -2f, zval );
    crossHairs[5].Position = new Vector3 ( -1f, -2f, zval );
    crossHairs[6].Position = new Vector3 ( -1f, -1f, zval );
    
    crossHairs[0].Color = Color.Green.ToArgb ( );
    crossHairs[1].Color = Color.Green.ToArgb ( );
    crossHairs[2].Color = Color.Green.ToArgb ( );
    crossHairs[3].Color = Color.Green.ToArgb ( );
    crossHairs[4].Color = Color.Green.ToArgb ( );
    crossHairs[5].Color = Color.Green.ToArgb ( );
    crossHairs[6].Color = Color.Green.ToArgb ( );
    
    return crossHairs;
}

Visual Basic

Private Function CreateCrossHairVertexArrayTop() As _
        CustomVertex.PositionColored()
    Dim crossHairs(7) As CustomVertex.PositionColored
    Dim zval As Single = 0.0F
    ' top of targeting crosshairs
    crossHairs(0).Position = New Vector3(-1.0F, 1.0F, zval)
    crossHairs(1).Position = New Vector3(-1.0F, 2.0F, zval)
    crossHairs(2).Position = New Vector3(0.0F, 2.0F, zval)
    crossHairs(3).Position = New Vector3(0.0F, 3.0F, zval)
    crossHairs(4).Position = New Vector3(0.0F, 2.0F, zval)
    crossHairs(5).Position = New Vector3(1.0F, 2.0F, zval)
    crossHairs(6).Position = New Vector3(1.0F, 1.0F, zval)

    crossHairs(0).Color = Color.Green.ToArgb()
    crossHairs(1).Color = Color.Green.ToArgb()
    crossHairs(2).Color = Color.Green.ToArgb()
    crossHairs(3).Color = Color.Green.ToArgb()
    crossHairs(4).Color = Color.Green.ToArgb()
    crossHairs(5).Color = Color.Green.ToArgb()
    crossHairs(6).Color = Color.Green.ToArgb()

    Return crossHairs
End Function
Private Function CreateCrossHairVertexArrayBottom() As _
        CustomVertex.PositionColored()
    Dim crossHairs(7) As CustomVertex.PositionColored

    ' bottom of targeting crosshairs
    Dim zval As Single = 0.0F

    ' bottom of targeting crosshairs
    crossHairs(0).Position = New Vector3(1.0F, -1.0F, zval)
    crossHairs(1).Position = New Vector3(1.0F, -2.0F, zval)
    crossHairs(2).Position = New Vector3(0.0F, -2.0F, zval)
    crossHairs(3).Position = New Vector3(0.0F, -3.0F, zval)
    crossHairs(4).Position = New Vector3(0.0F, -2.0F, zval)
    crossHairs(5).Position = New Vector3(-1.0F, -2.0F, zval)
    crossHairs(6).Position = New Vector3(-1.0F, -1.0F, zval)

    crossHairs(0).Color = Color.Green.ToArgb()
    crossHairs(1).Color = Color.Green.ToArgb()
    crossHairs(2).Color = Color.Green.ToArgb()
    crossHairs(3).Color = Color.Green.ToArgb()
    crossHairs(4).Color = Color.Green.ToArgb()
    crossHairs(5).Color = Color.Green.ToArgb()
    crossHairs(6).Color = Color.Green.ToArgb()

    Return crossHairs
End Function

Remember that the coordinates for the Position property of each vertex are defined in world space coordinates. We will transform them to screen coordinates in a while. Also note that you must call the ToArgb method to convert Color to the 32-bit integer format required by DirectX.

Before we continue we need to let the device know which type of vertex we chose. We accomplish this by setting the VertexFormat property of the Device class to the Format property of the vertex we used. This property determines the fixed function pipeline the device will use. Don't worry what exactly that is for right now; you just need to know that we are using the position and colored pipeline.

In the OnPaint method, immediately following the device.Clear method add the following code.

Visual C#

device.VertexFormat = CustomVertex.PositionColored.Format;

Visual Basic

device.VertexFormat = CustomVertex.PositionColored.Format

With the crosshairs defined, we must now tell the device to actually render the object described in the vertex buffer to the screen. This is accomplished using the DrawUserPrimitives method of the device class. So what are Primitives?

Drawing Primitives

Drawing Primitives are collections of vertices that define a single three-dimensional object. There are six primitives in DirectX listed in the PrimitiveType enumeration.

1. Line List: Mainly used for adding Heads-up Display (HUD) information to a screen. The primitive count is equal to the number of points divided by two. The number of points must be even for this type to work.
2. Line Strip: This has the same uses as the Line List but renders a single continuous line. The primitive count is equal the number of vertices minus 1.
3. Point List: Mainly used for rendering individual points in particle images such as explosions or stars in the night sky. The primitive count is equal to the number of points in the vertex buffer.
4. Triangle Fan: This is most useful when drawing an oval object.
5. Triangle List: This is the most commonly used primitive. The primitive count is the number of vertices divided by three,
6. Triangle Strip: These are most useful when rendering rectangular objects.

In our case we choose the LineStrip type to draw the crosshairs to the screen since it is an HUD. In the OnPaint method, immediately following the device.Clear method add the following code.

Visual C#

device.DrawUserPrimitives ( PrimitiveType.LineStrip, 6, 
    CreateCrossHairVertexArrayTop ( ) );
device.DrawUserPrimitives ( PrimitiveType.LineStrip, 6, 
    CreateCrossHairVertexArrayBottom ( ) );

Visual Basic

device.DrawUserPrimitives(PrimitiveType.LineStrip, 6, _
    CreateCrossHairVertexArrayTop())
device.DrawUserPrimitives(PrimitiveType.LineStrip, 6, _
    CreateCrossHairVertexArrayBottom())

The DrawUserPrimitives method requires us to pass in the PrimitiveType, the count of primitives to render, and the source of the vertex data for the object. Since we are using the LineStrip primitive, the seven points in each vertex buffer create six lines.

Up to this point we have not actually drawn anything to the screen, just cleared the device; so we need to tell the device that we are planning to do so. This is accomplished with the BeginScene method of the device class.

Begin Scene/End Scene

As I mentioned in the first article, there are a lot of correlations between movies and a DirectX game. The first we encountered was frame. Now we are going to add Scenes and little later a camera.

We use the BeginScene and EndScene methods of the device to define the starting and ending points of a scene. The BeginScene method prepares the device for the actions that follow by locking the back buffer. The EndScene method tells the device that we are finished drawing and unlocks the back buffer. You must always call EndScene after calling BeginScene otherwise the back buffer will remain locked. The BeginScene and EndScene methods work closely together with the Present method to mange the back buffer; if one of these method calls fails the others will fail also.

In the OnPaint method of the GameEngine class, add calls to BeginScene and EndScene. The call to BeginScene needs to occur immediately after the Clear method call.

Visual C#

device.Clear ( ClearFlags.Target, Color.Black, 1.0f, 0 );
// Tell DirectX we are about to draw something
device.BeginScene ( );

Visual Basic

device.Clear(ClearFlags.Target, Color.Black, 1.0F, 0)
' Tell DirectX we are about to draw something
device.BeginScene()

And the EndScene method needs to be called immediately before the Present method call.

Visual C#

// Tell DirectX that we are done drawing
device.EndScene ( );
// Flip the back buffer to the front
device.Present ( );

Visual Basic

' Tell DirectX that we are done drawing
device.EndScene()
' Flip the back buffer to the front
device.Present()

Now we are almost done. The last step remaining is to convert the world coordinates of each three-dimensional object into screen coordinates.

In the last article we covered a lot of the DirectX terminology you need to understand. We are almost done with new terms, but before we can successfully render a 3-D world to the screen we need to cover one last set of definitions.

Lights, Camera, Action

In our model we have described each point on the chair using Cartesian coordinates and a color value and stored these points in a vertex buffer. But DirectX still can't render the chair for me. Why? The missing pieces of information are our location in the room and the direction we are looking. We also need to determine how to handle the projection. Only with this information can the 3-D world be converted into the 2-D picture displayed on the screen.

In DirectX our (the viewer's) location is called the camera location and it is defined by the View Matrix. From now on consider the terms view and camera to be synonymous. The projection is the way distance is applied to the objects and can be compared to the lens setting of the camera.

Cameras are very powerful tools in creating cool 3-D games. You can attach the camera to a moving object to get the feeling of actually being inside, or offset it slightly to the rear to get a chase view. You can also set up multiple static cameras in your world and view the action by switching from camera to camera.

All of the computations involved in converting the world coordinates to screen coordinates are performed used a Matrix. These computations are called Transforms. Almost all of the heavy lifting performed in DirectX is the transformation of coordinates using Matrices.

Transforms (http://en.wikipedia.org/wiki/Transformation_%28mathematics%29): Transformations change the coordinates of three-dimensional objects based on the view, projection type and world transform specified. These transformations are accomplished via a set of 4x4 matrices.

Matrix (http://en.wikipedia.org/wiki/Matrix_%28mathematics%29): A rectangular table of numbers that is very efficient in transformations.

You could spend a lot of time understanding the exact details of transformations with matrices. Understanding how they work is important, but you will not have to perform any manual calculations on your own, so we can skip the details for now. The Matrix class contains a number of the most common methods for manipulating matrices.

The first step is placing and orienting the camera in our three-dimensional world.

View Transform

The view matrix defines the location of the camera and the orientation of the camera (by specifying a target). The view matrix also includes a value to determine which direction is considered to be up in our world. This is almost always the Y axis. You can either define your own matrix or use the built-in Matrix.LookAtLH and Matrix.LookAtRH methods. Since we are using the left handed coordinate system we naturally use the LookAtLH method (LH stands for Left Handed). Even if you do not explicitly define a view, then DirectX uses a default view.

In the OnPaint method of the GameEngine class, add the following code immediately after the device.Clear method call.

Visual C#

device.Transform.View = Matrix.LookAtLH(new Vector3 (0, 0, 5f), 
    new Vector3(0, 0, 0), new Vector3(0, 1, 0));

Visual Basic

device.Transform.View = Matrix.LookAtLH(New Vector3(0, 0, 5.0F), _
    New Vector3(0, 0, 0), New Vector3(0, 1, 0))

In Battle Tank 2005 we are placing the camera at the origin (0,0) and slightly forward on the Z axis. We then point the camera at the origin, and identify the Y axis as up by providing a value for Y.

After placing and orienting the camera we need to define the projection we are going to use.

Projection Transform

In DirectX there are two types of projections to choose from:

• Perspective (http://en.wikipedia.org/wiki/Perspective)
• Orthogonal (http://en.wikipedia.org/wiki/Orthogonal_projection)

The Perspective projection is the most commonly used projection and is how humans see the world. In this projection objects appear smaller the further away from us they are and become deformed at some distance (like a road appears to converge toward the horizon).

Orthogonal projection, on the other hand, ignores distance (the Z value) so items retain their size regardless of their distance from the camera.

We are going to use the Perspective Projection in BattleTank 2005. The projection determines how the vertices of the objects in the viewing frustum (http://en.wikipedia.org/wiki/Viewing_frustum) are transformed. The viewing frustum defines the three-dimensional space in which objects are visible to the camera. You can visualize this as a pyramid with the top cut off. The base of the pyramid is the far plane, the top the near plane, and the field of view is the angle at the apex. To perform this transformation we need to know four pieces of information.

1. Field of View (FoV): This is typically 45 degrees or ¼ of p (Math.PI / 4). Reducing the FoV value is like zooming in on the scene, while a larger FoV value is like zooming out. A value greater then 45 degrees is like looking at the scene through a fisheye lens.
2. Aspect Ratio: This is identical to the aspect ratio of your TV or Monitor and is always calculated as the viewport Width/Height. The viewport is nothing other than the form onto which we are rendering the game. Standard aspect ratios for computer screens are 1.33 (640x480 or 1280x1024).
3. Near Clipping Plane: Objects closer to the camera than this plane are not rendered.
4. Far Clipping Plane: Objects beyond this plane are not rendered.

   Radians (http://en.wikipedia.org/wiki/Radian): In DirectX most angles are expressed as radians rather than degrees. To convert from degrees to radians, simple multiply the degree value by p/180, where n is the measure of the angle in degrees. The DirectXDX library contains helper functions to perform the conversion for you in the Geometry class.

Using these values and some fancy math, DirectX transforms the vertices of each object from world coordinates to screen coordinates. To a certain extent, this transformation is what we do in our heads when we draw a picture of a three-dimensional space. We draw distant objects smaller, even though the actual object has not really changed its size, and we distort objects further away.

In the OnPaint method of the GameEngine class, add the following code immediately after the device.Transform.View method call added in the previous step.

Visual C#

device.Transform.Projection = Matrix.PerspectiveFovLH ( (float)Math.PI / 
    4, this.Width / this.Height, 1.0f, 100.0f);

Visual Basic

device.Transform.Projection = Matrix.PerspectiveFovLH ((single)Math.PI / _
    4, Me.Width / Me.Height, 1.0f, 100.0f)

For BattleTank 2005 we used the traditional setting for the FoV of 45 degrees. Next we set the aspect ratio base and then define the viewing frustum as between 1 and 100 in our world coordinate space. The values for the clipping planes define the size of our visible world and can represent anything we want. One unit equals 10 meters in BattleTank 2005 so we have a 1 kilometer playing field.

At this point you have to use some common sense when defining the viewing frustum. We could easily declare that each unit equals one kilometer, making the viewable area 100 kilometers deep. However, if we make the tanks regular size, you will never be able to see them beyond a couple of kilometers, so why waste resources rendering them to the screen if the player cannot see them?

While the View and Projection Matrices describe the camera and camera lens, the world transformation matrix converts the model space coordinates into world space coordinates. These world space coordinates are then converted to screen coordinates in the View and Projection transforms.

World Transform

The last transform is a world transform. This transforms the object we are rendering from model space into world space.

In a world transform you can move, rotate and scale each object. This transform applies to all objects drawn after setting the transform, until a new transform is specified.

Model Space: We define each object by defining each vertex with respect to the model.

In BattleTank 2005 we are not going to use the World transform at this time, but I have included a transform in the code for this article that uses a test cube for you to experiment with. I suggest you play with changing the values for all three transforms and see how the results look on the screen. That is the easiest way to really understand what the various settings do. See the Experimenting section for details on how to do this.

Lights

Whenever we draw a primitive using world coordinates, DirectX uses lighting to determine the color of each pixel. But since we have not yet defined a light source, we can simply turn the lights off at this time. If we do not turn lighting off, then DirectX assumes no lights are shining on the scene and renders each pixel as black.

In the OnPaint method of the GameEngine class, add the following code immediately after the device.Transform.Projection method call added in the previous step.

Visual C#

// turn off the light source
device.RenderState.Lighting = false;

Visual Basic

' turn off the light source
device.RenderState.Lighting = False

In addition to controlling the lighting, the RenderState also allows us to control the culling behavior.

Culling

Culling is an operation that eliminates entire objects (unlike clipping, which removes only portions) from the scene that fall outside of the viewing frustum to reduce the total set of objects to render. The overall goal is of course speed; by eliminating the non essential objects the scene can be rendered faster.

Clipping: Clipping discards portions of any single object that fall outside of the viewing frustum. Clipping is automatically managed by DirectX and requires no further intervention.

When drawing a three-dimensional object, DirectX does not render the primitives (triangles) that comprise the faces of those objects that do not face the camera. This is called back face culling.

DirectX determines which side of an object is facing the camera by using the order (winding) of the vertices. If you choose either clockwise or counterclockwise, then the vertices that are wound the opposite are on the back of the object and are culled. The default mode is counterclockwise culling, so you need to make sure to define your vertices in a clockwise order.

The culling options are set in the RenderState by assigning one of the Cull enumeration settings to the device.RenderState.CullMode property.

In the OnPaint method of the GameEngine class, add the following code immediately after device.RenderState.Lighting code added in the previous step.

Visual C#

// Turn off backface culling
device.RenderState.CullMode = Cull.None;

Visual Basic

 ' Turn off backface culling
device.RenderState.CullMode = Cull.None

In the code that accompanies this article I have added a couple of extra items to make it easier for you to experiment with the various settings we just covered.

Experimenting

To remove the HUD display, comment out the following lines: 122 and 123 (in VB.NET the lines are 92 and 93).

You can also display a rotating cube by un-commenting lines 98, 101, 120 and commenting line 95 (VB.NET: 68, 71, 87, 90 and 65). You can change any of the values in the models or adjust the View, Projection and World transforms to see the effect of your changes.

Line Numbers: To turn on line numbers, go to Tools | Options | Text Editor | All Languages and check the Line Numbers box in the Display group. If you don't see the full options tree, just check the Show all Settings option in the lower left of the Options dialog.

Summary

In these first three articles we have covered a lot of ground. The steps in the upcoming articles build upon the foundation laid in these first three articles. At this point you should know how to create a device and hook it to a Windows form and create a game loop using the OnPaint and Invalidate methods. You should be able to create and draw your own three-dimensional objects using vertex buffers and the DrawUserPrimitives method, set up a camera, and transform the models into world space.

If something is unclear at this time, you should review the links provided in the articles, the DirectX SDK, or go to one of the resources listed on the web. Once you have fully understood these principles, the rest of the game development process will be much easier.

With this knowledge you are ready to perform all but the most advanced operations in DirectX. The only steps required to add more objects to our world in BattleTank 2005 are to define them in model space, store them in a vertex buffer, and render them to the screen. As you imagine, complex objects consist of thousands of separate vertices, and defining them all in code is almost impossible, very error prone and extremely boring. So in the next article I will cover how to accomplish this task more efficiently. In the next article we are also going to finish of the last graphic pieces and then focus on controlling the tank using the classes in the DirectInput namespace.

Until then: Happy coding!

Introduction

Welcome to the second article on beginning game development. In this article we are going to cover the basics of DirectX.

DirectX is a multimedia API that provides a standard interface to interact with graphics and sound cards, input devices and more. Without this standard set of APIs you would have to write different code for each combination of graphics and sound cards and for each type of keyboard, mouse and joystick. DirectX abstracts us from the specific hardware and translates a common set of instructions into the hardware specific commands.

Like all new tools, DirectX has a number of new terms and definitions that you need to understand. In addition to these new terms you also are going to have to brush up on your math skills. DirectX and game development in general is pretty math intensive, and it helps if you understand the basics. There is no need to get out the old calculator however, the idea is to understand the goal and the way to get to that goal, the rest we do in code with a number of pre-prepared math libraries.

DirectX Overview

DirectX first appeared in 1995 and was then called the “GameSDK”. In its original form it was targeted at developers using C and C++. Only with the release of the first managed version (9.0) of the API in December 2002 has it been possible to use C# or VB.NET with DirectX (actually you can use any CLR compliant language if you want to).

While much has been said and written about the performance of managed DirectX when compared to the unmanaged version, the fact that commercial games have already been created using managed DirectX should settle that argument once and for all. While certain games with extreme performance needs might need to use unmanaged code, most games can be created with managed code or using a mix of managed and unmanaged code. Writing in managed code makes the developers more productive and thus write more code and produces safer code.

After installing the DirectX SDK you should have a directory at C:\WINDOWS\Microsoft.NET\Managed DirectX with a subdirectory for each version of the SDK that has been installed on your machine. I am on my fourth version on the machine I am using and consequently I have four subdirectories. In each of these subdirectories you should have nine DLL and nine XML files. Since the managed world of .NET allows us to have multiple versions of the same DLL file on the same computer without causing the problems previously referred to as DLL-hell we can have multiple versions of the managed DirectX libraries available to us. This allows you to easily roll back to a previous version after installing a new version.

If you have previous experience with DLL files in Windows you might be worried that having multiple versions of the same file installed on the same computer will cause problems. These versioning issues are no longer an issue since the introduction of side-by-side versioning in .NET.  This means you can use the multiple versions to check for compatibility issues when a new version of the SDK is released without having to commit yourself to an upgrade.

The nine DLL files roughly correspond to the ten namespaces in DirectX. As we create our game we'll use a number of these namespaces to provide support for input devices, sound, network play and of course 3D graphics.

Figure 1. List of DirectX 9.0 namespaces.

Before we go any further we need to complete some unfinished business from the last article. After adding the FrameworkTimer class we were no longer able to build the project because we were missing the references to DirectX. Let's fix that now and add them.

• Right-click References in the Solution Explorer and select Add Reference.
• On the .NET tab scroll down until you find the component named Microsoft.DirectX
• While pressing the CTRL key select the following components: Microsoft.DirectX, Microsoft.DirectX.Direct3D and click OK.
• The last step we need to complete before we can finally build the solution is to comment out the portions of the dxmutmisc.cs file we do not need.
• Open the dxmutmisc.cs file and comment out all of the code other than that in the Native Methods and Timer regions.
• Now build the solution (press F6). If you did everything right the solution will now build.

 My GPU is Bigger than Yours

Before we dig into the DirectX API let's take a step back and think about what we are trying to do. To create a fast game we need to use some type of processor that allows us to compute the actual picture that will be shown on the monitor. Since none of us have 3D monitors that image will be 2D. So we need to do some math to compute each and every frame by converting 3D models into 2D images. If we used the CPU of the computer for all of these calculations our game would run slower, since we also have to use the same CPU to compute the AI, check for input, and oh by the way, we still need to run the operating system and all the background processes. If we can pass the computation of the graphics portions to a separate processor we can speed things up.

Modern graphics cards have their own processor called a Graphics Processing Unit or GPU. These GPUs are specialized processors optimized to do the type of calculations we need. In addition each graphics card also has its own memory, in effect making it a separate computer inside our computer. This means that regardless how big and fast your basic computer is, graphics speed is dependent more on the GPU and video memory than anything else.

Adapters and Devices

Most graphics cards allow only one monitor to be connected at a time, but some provide support for multiple monitors. You could also have more than one graphics card in your computer at a time. Regardless of your setup, each graphics card has an Adapter. You can think of this as the physical video card in your computer.  The adapters have “names” in the computer sense, with the first, or default adapter, being “named” 0, the second adapter 1 and so on. In DirectX you do not directly interact with the adapter. Instead you connect to an adapter using a Device.

A device represents a connection to a specific adapter; each adapter can have multiple devices associated with it. DirectX supports three types of devices: Hardware, References and Software. We will use the Hardware type for our game as it provides the speed we need to run our game.

Now its time to create the device we are going to use for our game. Add the following code to the constructor of the GameEngine form after the existing code. We are using the constructor because we can guarantee that any code in it will be run before anything else. This ensures that we always have a valid device object to reference later on.

• Add the following code to the GameEngine constructor immediately following the this.SetStyle statement

Visual C#

// Get the ordinal for  the default adapter    
int adapterOrdinal =  Manager.Adapters.Default.Adapter;     
// Get our device capabilities so  we can check them to set up the      
// CreateFlags    
Caps caps = Manager.GetDeviceCaps(adapterOrdinal, DeviceType.Hardware);
CreateFlags createFlags;     
// Check the capabilities of the  graphcis card is capable of    
// performing the vertex-processing  operations    
// The HardwareVertexProcessing  choice is the best    
if  (caps.DeviceCaps.SupportsHardwareTransformAndLight)    
{
    createFlags = CreateFlags.HardwareVertexProcessing;
}    
else
{
    createFlags = CreateFlags.SoftwareVertexProcessing;
}
// If the graphics card supports  vertex processing check if the device
// can do rasterization, matrix  transformations, and lighting and     
//shading operations    
// This combination provides the  fastest game experience    
if  (caps.DeviceCaps.SupportsPureDevice && createFlags ==  
    CreateFlags.HardwareVertexProcessing)
{
    createFlags |= CreateFlags.PureDevice;
}     

// Set up the PresentParameters  which determine how the device behaves    
PresentParameters presentParams = new PresentParameters();    
presentParams.SwapEffect = SwapEffect.Discard;

// Make sure we are in windowed  mode when we are debugging    
#if DEBUG       
     presentParams.Windowed = true;
#endif
// Now create the device    
device = new  Device(adapterOrdinal,DeviceType.Hardware,this, 
     createFlags,presentParams);

Visual Basic

' Get the ordinal for the  default adapter
Dim adapterOrdinal As Integer = Manager.Adapters.Default.Adapter
' Get our device capabilities so we  can check them to set up the
 ' CreateFlags    
Dim caps As Caps =  Manager.GetDeviceCaps(adapterOrdinal,
    DeviceType.Hardware)    
Dim createFlags As CreateFlags       

 ' Check the capabilities of the  graphcis card is capable of   
 ' performing the vertex-processing  operations   
 ' The HardwareVertexProcessing  choice is the best    
If  caps.DeviceCaps.SupportsHardwareTransformAndLight Then
    createFlags = createFlags.HardwareVertexProcessing    
Else
    createFlags = createFlags.SoftwareVertexProcessing
End If
' If the graphics card supports  vertex processing check if the device
' can    
' do rasterization, matrix  transformations, and lighting and shading
 ' operations   
 ' This combination provides the  fastest game experience   
If  caps.DeviceCaps.SupportsPureDevice AndAlso createFlags = _
        createFlags.HardwareVertexProcessing Then
    createFlags = createFlags Or createFlags.PureDevice
End If
' Set up the PresentParameters  which determine how the device behaves
Dim presentParams As New PresentParameters()
presentParams.SwapEffect = SwapEffect.Discard

' Make sure we are in windowed mode  when we are debugging
#If DEBUG Then
    presentParams.Windowed = True
#End If
' Now create the device
device = New  Device(adapterOrdinal, DeviceType.Hardware, Me, _
    createFlags, presentParams)

• At the end of the form, right after the declaration of the deltaTime variable, add the following code:

Visual C#

private Device device;

Visual Basic

Private device As Device

This is a lot of code just to get a Device configured, but this approach to setting up the device is the safest way of ensuring that we maximize the performance of our game based on the graphics card's hardware. The easiest way to understand this block of code is to break it into four distinct pieces.

1. The first line of code simply gets the name of the default adapter which is usually 0. Instead of betting that it is zero it is safer to use the Manager class to get the name of the default adapter. This way things don't go south if for some reason the default adapter name is really 2.
2. The next section of code is used to determine the settings of the CreateFlags enumeration that we pass to the Device constructor and which governs the behavior of the device after creation. Again we use the Manager to get a listing of the capabilities (called Caps for short) for the default adapter. We then use this listing of capabilities to determine whether to perform vertex processing in hardware (which is faster) or in software (which is slower but guaranteed to always work). This is actually a misnomer, as the SoftwareVertexProcessing really means that we use the CPU while the HardwareVertexProcessing uses the GPU. We then perform another check to see if our adapter can support a pure device, meaning the graphics card can do rasterization, matrix transformations and lighting and shading calculations. If the device can and the previous check determined that we can use hardware vertex processing we add the PureDevice setting to the CreateFlags enumeration. The combination of HardwareVertexProcessing and PureDevice provides us with the best possible performance, so we want to use it if we can.
3. The final parameter required to create the Device is the PresentParameters object. This object determines how the device presents its data to the screen, hence the name. First we set the SwapEffect enumeration, which determines how the buffer and the device relate to each other. By selecting the Discard option we are choosing to simply discard the back buffer and write directly to the front buffer. Inside the If statement we determine if the application is running in Debug mode. If we are in debug mode we do not want to run in full screen mode, which is the default, because it makes debugging very difficult. Using this method to determine the configuration is better than hard coding it and then forgetting to switch it when releasing the game.
4. The final step is to actually create the device. We pass in the ordinal of the default adapter, the window we want to bind the device to, the device type, and then pass in the CreateFlags and PresentParameters objects we created previously.

The net effect of all of this code is that we have a valid device we can use to draw to the screen with. To actually use the device we need to add two lines of code inside the render loop.

• Add the following code in the OnPaint method immediately following the FrameworkTimer.Start() statement.

Visual C#

device.Clear(ClearFlags.Target, Color.DarkBlue, 1.0f, 0);
device.Present();

Visual Basic

device.Clear(ClearFlags.Target, Color.DarkBlue, 1.0F, 0)
device.Present()

The first line clears the window with the color indicated in the second parameter (you can use any of the predefined windows colors in the Color enumeration). The last two parameters of the Clear method describe the z-depth and stencil values and are not important at this time.

The Present method of the device causes the device to display the contents of the back buffer to the screen. The screen is also called the front buffer and how these buffers interact is the determined by the SwapEffect enumeration you set earlier.

Now we run the solution and viola – we have a blue screen. While this is not very impressive and it seems like a lot of code to get a simple blue screen we have now successfully integrated DirectX into our GameEngine.

3D Graphics Terminology

Before we continue and render the terrain and units we need to step back for a minute and cover some of the principles and definitions used in three-dimensional graphics programming. We are not doing this so we can sound smart among our friends, but because these principles and terms provide the foundation for programming with three-dimensional graphics.

The game I am currently playing is called Brothers in Arms: Road to Hill 30 (www.brothersinarmsgame.com). It is a first person shooter game set in Normandy France in 1942. All of the terrain, buildings, roads, rivers, etc. in this game are exact replicas of the original terrain in Normandy in 1942. The game creators used aerial photographs and maps to recreate the terrain and traveled to France to survey the terrain themselves. They used this information to recreate the original terrain for the game. When we need to describe where in the world something is located, such as the Space Needle in Seattle, we commonly use a coordinate system called the geographic coordinate system (http://en.wikipedia.org/wiki/Geographic_coordinate_system). In this system we express each point as a unique Latitude/Longitude pair (the Space Needle is located at: Lat: 47.62117, Long: -122.34923).

When the creators of the game transferred the terrain to the computer they could not just provide the Latitude/Longitude coordinates to DirectX because the computer has no idea how to represent geographic coordinates. To be able to place objects into a three-dimensional world we have to come up with a coordinate system the computer does understand and transform the coordinates from one system to another. The coordinate system used in DirectX is the left-handed Cartesian coordinate system.

Cartesian Coordinate system

To properly place objects into a three-dimensional world we need to know where to place them and how to define each point unambiguously. We accomplish this using the Cartesian coordinate system. This Cartesian coordinate system is comprised of three axes at right angles to each other with the point of intersection being called the origin (the one you are probably more familiar with is the two-dimensional version with only the x and y axes used in High School geometry). Two additional properties are needed to fully define this three-dimensional coordinate system: handedness and orientation.

Handedness

To make life just a little bit more challenging, there are actually two ways to represent a three-dimensional Cartesian coordinate system: Left-handed and right-handed. If you follow this link (http://en.wikipedia.org/wiki/Cartesian_coordinate_system) you can find out more behind the reason for this, but the main thing to remember is that DirectX uses the left-handed coordinate system. The net effect of using the left-handed coordinate system is that the greater the Z value the greater the distance, while in the right-handed system the values get smaller as the distance increases. You need to know the handedness of the coordinate space to compare two objects using their Z values and to know which one is further away from you.

Orientation

The only other thing of note about the three-dimensional Cartesian coordinate system is that it can have different orientations depending on how the z-axis is drawn. If it is drawn vertically as pictured below on the left then it is called the world coordinates orientation if it is drawn as on the right it is called the local or body coordinates orientation.

Regardless of the orientation you use to reference your points to, the coordinates must be transformed to screen coordinates (two-dimensional screen space) in order to be drawn on the screen.

Figure 2: 3D Cartesian Coordinate systems

Vector

Each point in the three-dimensional coordinate system is defined by three values, the X, Y and Z values. To make life a little easier DirectX provides us with a structure called a Vector3 that lets us store these coordinates. This is purely for our convenience though, as a vector is defined as an object that denotes both direction and velocity and not a location. The methods of the vector class are used towards that end, but for now it's a convenient structure to store the three values in. Depending on your need can also use the Vector2 or Vector4 structures.

Vertex

In the code we added to connect to our device you may have noticed that we needed to determine if we should do vertex processing in software or hardware. So what is vertex processing and what is a vertex? A vertex is a point that is part of a three-dimensional object. A vertex consists of a vector and additional information concerning texture mapping.

Texture

A texture is simply a 2D bitmap that is applied to a 3D object to provide it with some type of look (texture) such as grass, concrete etc.

Mesh

We are not going to cover using meshes in this article; the definition of a mesh is tied to that of a vertex, so let's get it out of the way now. A mesh is the data that describes a three-dimensional shape. This data includes the list of vertexes for the shape as well as information describing how the vertexes are connected and information concerning the textures that cover them.

As you can see, a Mesh is made up of vertices, which in turn contain a vector. Each level simply adds some information concerning how the separate pieces are related to each other. From now on when you hear vector think point, when you hear vertex think point and data, and when you hear mesh think many points and more data.

Triangles

Now that you know that a vertex is really just a point in 3D space, we need to cover how the points are combined to form the objects. Every object in DirectX is composed of one or more triangles. While this may seem awkward at first, it is actually possible to represent any 2D or 3D shape using triangles. The reason for this is simple: triangles are the simplest polygon that is coplanar (all the points of the triangle are on the same plane). This simplifies the math needed to perform all calculations.

While all of this seems to be a lot of new terms to learn, it is important to understand these basic ideas before moving on to matrices. We are going to cover them and the principle behind a camera (in the DirectX sense of the word) and transformations in the next article. We are also going to explain what meshes are and how the texture mapping information of a vertex is used.

A Frame Rate Counter

As I mentioned in the first article, we are going to add a frame rate counter to our game. Knowing the frame rate of your game is important because it determines the speed of your game. Additionally, knowing what the frame rate is now before we add any code to the render loop will show us how each addition affects the speed of the game.

• Add a new class to the project and name it FrameRate.
• Add the following code inside the class declaration.

Visual C#

public static int CalculateFrameRate()
{
    if  (System.Environment.TickCount - lastTick >= 1000)
    {
        lastFrameRate = frameRate;
        frameRate = 0;
        lastTick = System.Environment.TickCount;
    }
    frameRate++;
    return lastFrameRate;
}

private static int lastTick;
private static int lastFrameRate;
private static int frameRate;

Visual Basic

Public Shared Function CalculateFrameRate() As Integer
    If  System.Environment.TickCount - lastTick >= 1000 Then
        lastFrameRate = frameRate
        frameRate = 0
        lastTick = System.Environment.TickCount
    End If     frameRate += 1
    Return lastFrameRate
End Function 'CalculateFrameRate 

Private Shared lastTick As Integer
Private Shared lastFrameRate As Integer
Private Shared frameRate As Integer

• In the GameEngine OnPaint method add the following line of code immediately after the assignment of deltaTime.

Visual C#

this.Text = string.Format("The framerate is {0}", 
    FrameRate.CalculateFrameRate());

Visual Basic

Me.Text = String.Format("The framerate is {0}", _
    FrameRate.CalculateFrameRate())

This frame rate counter uses the TickCount property of the System class which is a wrapper to the GetTickCount method of the WIN32 API and has a precision of approximately 15 milliseconds. While the FrameworkTimer class is more accurate, this precision is good enough to compute the frame rate.

Code Housekeeping

Before we finish up there are two code changes I made to the original code. First I removed the Application.EnablRTLMirroring() statement from the Program class. This method has been deprecated in the Beta2 version of the .NET Framework. The other change I made is to wrap the creation of the GameEngine class into a using statement. This ensures that regardless of what happens in the GameEngine class it will always be properly disposed when we close the application.

Summary

At this point you might be wondering if we are ever going to start working on our game. One of the challenges with learning game development is that you have to create a good foundation at the beginning so the more advanced ideas make sense later on. Once you understand the 3D graphics terms and principles you are free to concentrate on the game creation.

In this article we introduced DirectX which is the API we are going to use for 3D graphics, input device control and sound in BattleTank 2005. Then we discussed what a GPU is and why it is so important for today's games. We also covered what an Adapter and Device are and how to configure them in DirectX. Then we entered the world of terms and definitions that we need to understand moving forward. Finally we added a frame rate counter to the game to track game performance.

In the next article we'll cover matrices and transforms, how to place a camera into the 3D world and what clipping and culling are. In that article we are also going to add the landscape for our game.

I hope that the first foray into the world of DirectX has not discouraged you too much. Because some definitions and principles are a little hard to understand just by reading them I suggest you write some code and play with the various settings to see what happens. The DirectX SDK also includes a great number of samples and tutorials that cover this same subject matter and let you experiment with the settings.

This is Part 1 of an introductory series on game programming using the Microsoft .NET Framework and managed DirectX 9.0.

WARNING: Managed DirectX is no longer supported.  If you want to do 3D graphics with the .NET Framework, please use XNA (http://creators.xna.com)

1. Beginning Game Development Part 1 - Introduction
2. Beginning Game Development Part II - Introduction to DirectX
3. Beginning Game Development: Part III - DirectX II
4. Beginning Game Development: Part IV - DirectInput
5. Beginning Game Development: Part V - Adding Units
6. Beginning Game Development: Part VI - Lights, Materials and Terrain
7. Beginning Game Development: Part VII –Terrain and Collision Detection
8. Beginning Game Development: Part VIII - DirectSound
9. Beginning Game Development: Part VIII - DirectSound II
10. Beginning Game Development: Part VIII - DirectSound III

Part I – Introduction

Welcome to the first article of an introductory series on game programming using the Microsoft .NET Framework and managed DirectX 9.0.

This series as aimed at beginning programmers who are interested in developing a game for their own use with the .NET Framework and DirectX. The goal of this series is to have fun creating a game and learn game development and DirectX along the way. Game programming and DirectX have their own terms and definitions that can be difficult to understand, but after awhile, you’ll crack the code and be able to explore a new world of possibilities. I will keep things as straightforward as possible and decode terms as they appear. Another part of the learning curve comes from the math you’ll need to deal with DirectX. I am going to point out some resources along the way that will help you brush up on, or learn, the math skills you’ll need to keep going in DirectX.

In this series, we are going to build a simple game to illustrate the various components of a commercial game. We will cover how to create great looking graphics in 3D, how to handle user input, how to add sound to a game, how to create computer opponents using Artificial Intelligence, and how to model real-world physics. In addition we are going to cover how to make your game playable over the network and how to optimize your game for performance. Along the way, I will show you how to apply principles of object-oriented development and, as well, I will share some of my experience in creating well-organized and elegant code.

Tools:

Before we start writing our first game we need to talk about the tools we will use.

The most important tool for any developer is the Integrated Development Environment (IDE). This is where you are going to spend the majority of your time writing and debugging code, so it needs be powerful and fast.

Visual Studio 2005 (also known by the codename “Whidbey") is the third version of the standard Microsoft IDE for .NET Framework-based applications. Visual Studio 2005 introduces a number of Express versions that provide most of the functionality of their more advanced counterparts but are simplified for the novice, hobbyist, and student developer and cost much less (There are express versions available for VB, C#, C++, J# and for Web Developers using ASP.NET). For this series, I am going to use both Visual C# Express and Visual Basic Express. If you have not already done so, download the C# or Visual Basic Visual Studio Express IDE at: http://msdn.microsoft.com/express.

The second important tool we need to create a great looking game is a graphics Application Programming Interface (API). Without such an API it would be extremely difficult to access the graphics capabilities of your PC. The API we are going use is the DirectX API. This API allows us to create powerful multimedia applications on the Windows platform. To work on the game, you will need to download the latest DirectX SDK at: http://www.microsoft.com/windows/directx/default.aspx. Make sure that you download the SDK and not just the runtime. The SDK includes samples and other utilities that are extremely useful when developing using DirectX.

At some point in your game development experience you are going to have to create or modify graphics. Every copy of Microsoft Windows comes with Microsoft Paint, and while it is not the most powerful program, you already own it and it is good enough for most of our needs.

As we dive deeper into DirectX and cover 3D models and sounds, you might find the need to use other programs to manipulate the image or sound files. As we cover these topics I will point you towards free or inexpensive programs and resources on the Web.

Finally, you need to know where to go to get help. One of the best places is  the public newsgroups. Here, you can ask questions and get answers from people with the same interests as you. Microsoft MVPs and employees also monitor these newsgroups and provide help for you along the way. The newsgroups that are going to be of most interest for game programming are:

• Managed DirectX: microsoft.public.win32.programmer.directx.managed
• C#: microsoft.dotnet.languages.csharp
• VB: microsoft.dotnet.languages.vb

Other places to go for inspiration and help for gaming are:

• The ZBuffer: http://www.thezbuffer.com/
• GameDev.net: http://www.gamedev.net/
• flipCode: http://www.flipcode.com/
• Gamasutra: http://www.gamasutra.com/ [Professional audience, but many articles from Game Developer, including tutorials]

 What makes a successful game?

My first experience using a computer was in 1981 on a Sinclair ZX Spectrum. The first 5 years of my computing life were spent on nothing but writing and modifying games for the Sinclair and later the Commodore 64, but, heck, what else are you going to do as a teenager? While much has changed in terms of hardware capabilities and available APIs, the properties of a great game have not.

Games today have become so complex that they require large numbers of developers, graphic artists, testers and managerial overhead to develop. They rival large commercial enterprise application in their complexity and cost many millions of dollars to develop and market. The payback, however, can be enormous and rival Hollywood blockbuster movies in sales – Halo 2 grossed $100M in its first day of availability.  

All successful games have a couple of features in common that made them stand out.

• The main ingredient for a successful game is the game idea. Regardless how cool your graphics are, how good the music is, if the idea is lame no one is going to play the game.
• The second most important feature is the playability of the game. If the game is too hard then players are quickly going to get frustrated and stop playing. Conversely, if the game play is too easy then the player is going to get bored and stop playing. A good game provides multiple levels of difficulty that continuously challenge the player without overwhelming or boring them.
• Together, the game idea and its playability are the “game design” (not to be confused with “level design,” which is the application of the overall game design to specific segments of the game). There are certain game designers who have a golden touch. Shigeru Miyamoto (the creator of Donkey Kong, Zelda, and Mario) and Will Wright (Sim-everything) are two prominent examples. Miyamoto’s keynote address to the 1999 Game Developer’s Conference is available at http://www.gamasutra.com/features/20030502/miyamoto_01.shtml and Wright’s recent discussion of the design philosophy of Spore (http://www.gamespy.com/articles/595/595975p1.html?fromint=1) are good inspirations for designers of all stripes, while the book “Theory of Fun for Game Design” by Raph Koster has gotten excellent reviews in the community.
• The third ingredient to a successful game is the set of graphics. They need to be good enough to compliment the game idea and game play but not so resource intensive or flashy that they distract from it.
• The final ingredient is performance. No one wants to play a slow game. I still remember an adventure game on my Commodore64 that took 10 minutes to render each scene. I still played it, mind you, because the game idea was great and there were no other options around but it was irritating.  Graphics and performance are closely related. The more fancy graphics you add to a game to slower the performance. The next biggest performance issue is the AI. A lot of game development today focuses on how to make things faster and not coming up with new ideas. However, when you’re learning a complex programming technique such as game programming, it’s vitally important not to optimize prematurely. An understanding of the performance pipelines, and the skills to write clean code, profile it, and improve it are much more important than any single optimized function.  

If you apply your design efforts in this order you, too, can create a great game. It may not be a refined first person shooter like Battlefield 1942, but Tetris is arguably one of the most popular games and has neither fancy 3D graphics nor Dolby digital sound. Even today, games like Gish (http://www.chroniclogic.com/index.htm?gish.htm) demonstrate what can come from creative independent developers. If you can write enough of a game to show your game idea, then maybe you can interest the large gaming companies in your game. The Independent Games Festival is the “Sundance” of the game community, runs concurrently with the professional Game Developers Conference and, believe me, is among the most closely-watched events at the show.

Our Game idea: 

Now that you know what features make a great game, the next step is to lay out the game proposal for our game.

Idea: Since coming up with a unique and creative game idea is the core of any game, I am going to cheat and use the game idea from the first 3D game I ever saw: Atari’s Battlezone. (If I had that great idea why would I let of all you know anyway?) Battlezone is a basic first-person shooter game in which you are looking through the viewfinder of a tank into a 3D landscape. The goal is to destroy as many of the opponent’s tanks as possible before getting destroyed yourself. The landscape includes random objects behind which you can hide. The game screen includes a radar to show you the location of your opponents and the current score.

Playability: The original game started out fairly slowly but kept adding more opponent tanks and other random enemies.  The game also increased the speed and intelligence of the opponents. All of this kept the game challenging but playable.

Graphics: The original game used graphics that proved just engaging enough to feel like you were in a 3D world, but because of the hardware available in 1980 (an 8-bit processor running at 1.5 megahertz) it rendered the 3D objects as wire frames. These graphics were advanced when the game first came out, but we are going to improve upon them using the magic of DirectX (and the magic of 25 years of Moore’s Law!).

Screenshot of Atari’s Battlezone game – complete with wire frame mountains, tanks, and even a wire frame moon for added realism!

Performance: This game pushed the limits of the hardware available at the time. This is evident in the use of the wire frame objects. If the game had been written to fill these objects then it would have been unplayable. With today’s advanced hardware we should not have any performance issues other than those introduced by us writing sloppy code.

Now that we have decided on a game, the next step is to write down the goals of your game. This does not need to be anything formal but the simple act of writing things down has the tendency to make ideas clearer. At a minimum you need to determine the object of the game, what the player can and cannot do and how the player interacts with the game. We also should define what the scoring system is going to be like and what are the victory conditions.

For our game these are the simple specification I came up with.

• A 3D first-person shooter game
• The goal is to destroy as many enemies as possible
• The player can move through the landscape on the ground just as a regular tank can. The tank can not fly, nor can it change speed.
• The game play will be controlled through the keyboard for moving and shooting. The mouse will be used to interact with the menus and start/stop the game. We will not support a joystick.
• The player will receive a score that is based on the distance at which the enemy tank was destroyed. The further the tank was, the higher the score. Each round fired reduces the score by a set amount, unless that round hits a target.
• The game will be divided into levels. Each level will have a pre-defined number of enemies. Once all enemies have been eliminated, the player advances to the next level. There is no limit to the levels.

Now we are ready to do some coding. In general, it is best to write down just the overall idea of the application. Spending a lot of effort upfront designing every little detail is just a waste of time. As we add more functionally to the game we will continuously do small design sessions to formulate our ideas. This iterative approach to developing software is the best way to create good software, and is more fun at the same time.

Creating the game Project:

Now we are ready to write some code. The first step is to create a new solution in Visual Studio 2005.

• Select File | New | Project and choose Windows Application from the template list. In the Name field at the bottom of the dialog, replace the default WindowsApplication1 with BattleTank2005 and click OK.

Visual Studio now creates a new solution for us called BattleTank2005 that contains a single project with the same name.

First, we need to rename the class to something more descriptive. Naming is one of the most efficient methods of keeping code well organized and understandable. Always choose names that clearly describe what the item is doing and avoid meaningless names like Class1 and Form1.

• From the Edit menu, select Find and Replace, then select Quick Replace. Set the Find What field to 'Form1', Replace What field to 'GameEngine' and the Look in field to 'Current Project' (see Figure below). Click Replace All to make this change (there should be five changes made)
• Next right-click Form1 in the Solution Explorer and select Rename. Change Form1.cs to GameEngine.cs.

Replacing Form1 text with GameEngine. You'll thank yourself later.

Another trick to keeping things organized is to ensure that the files in the Solution Explorer are named exactly the same as the classes they contain and to always create a separate file for each distinct element such as each class or enumeration.

Now we have a Windows application that we can run, but it doesn’t do anything. The form has no other controls on it such as buttons you can click or textboxes to display any information. In a regular Windows Forms application we would now add such controls to the forms to create our final application, but for our game we are going draw everything using the DirectX API rather than the Windows Forms API.

We really only need the Form for its Windows Handle, which is basically its unique name among all the other windows on the screen. We will use this handle to set up our DirectX drawing surface. The other use of the Form is that it contains an event that we are going to use to create our render loop.

Adding the Render loop

A game is much different from a regular application, such as Microsoft Word. Word presents a screen to the user that mimics a page in a typewriter and then waits for the user to do something. This something could be pressing the keys on the keyboard or selecting a menu item from the menu with the mouse. While waiting for the user to interact with the application Word does nothing. (Actually I lie: it does do things like run spell checking and auto save in the background but nothing you as the user can see). Generally, programs written using the Windows Forms library generally have the same behavior – they don’t consume CPU time unless the user is doing something (of course, it’s possible to use the Timer control or the capabilities of the System.Threading namespace to do things independent of the user).

Games are different. As you know, smooth movement in games requires the screen to be updated many times per second. The “flicker fusion threshold” at which static images begin to fuse is generally taken to be 1/16 of a second, although it actually varies depending on illumination (brighter lights like computer monitors require higher frame rates) and where on the retina the image falls (peripheral vision requires higher rates than foveal vision). Although movies are shown at 24 frames per second (FPS), 30 FPS is often considered the lowest-acceptable rate for video games, and most actiongame players tune their graphics for no less than 60 FPS.

Because the render loop is called dozens of times per second and runs nonstop, game programming almost always uses the render loop as the “stopwatch” of the game, calculating everything inside the loop, not just graphics, but physics, AI, checking for user input, and scores. (Again, you could use the Timer class or threads to write a multithreaded game, but doing so would introduce significant complexity without any clear benefits and although multithreading in the .NET Framework’s Common Language Runtime  is quite efficient, the slight overhead could knock a couple frames per second off your game.)

So how do we get the computer to run this loop? The form we added earlier has an event called the Paint event. The Paint event for a Windows Form object is called whenever the form is redrawn. This normally occurs only when you maximize a form or when a form is covered by another form that is moved.

As all Windows Forms programming, even game programming, is event-based, understanding the principles of events and event handlers is critical. Although the event is triggered automatically, we need to create a special method called an event handler to be able to intercept the event and do something in response to it..

• In the GameEngine class add the following code after the constructor.

Visual C#

protected override void OnPaint(PaintEventArgs e)
{
          
}

Visual Basic

Protected Overrides Sub OnPaint(ByVal e As PaintEventArgs)
          
End Sub

This is our event handler. When is it called? “OnPaint” – when the Paint event occurs. One thing is still missing. Even though Windows and the Windows Forms library automatically raise the event, some actions that we might expect to trigger the Paint event don’t. Minimizing a window, for example, does not trigger the Paint event, since Windows does not see the need to repaint the entire form (Windows is just being efficient since we are actually displaying less when we are shrinking the form). So we cannot rely on these automatically-created events to manage the loop we need for our game.

Luckily, we can programmatically trigger the Paint event by calling the Invalidate method of a form. This causes the Paint event to be triggered and Windows to enter back into our OnPaint event handler. Then we execute any code we want to run every frame and start all over again by calling the Invalidate method.

You might ask, “Why can’t we just add a while(true) loop directly within OnPaint() and never leave it?” The answer is that even though we’re game programmers, we’re expected to play well with others. Creating a loop within OnPaint() would starve the rest of the programs running on the system. While our game might gain a few frames per second, the rest of the system would become, at best, ugly, and at worst, unstable. So, instead of directly looping, we essentially “ask” to be called again as soon as possible.

• In the OnPaint method add the following line of code:

Visual C#     

this.Invalidate();

Visual Basic

Me.Invalidate()

That’s it, we’ve created our render loop. But there is one more problem. It turns out that not all painting is done in the OnPaint method, Windows Forms triggers another event when the background is erased and by default performs some painting (well, erasing) in response. To force our application to truly only paint inside our method handler, we need to add one more line of code to our application. Since we need to ensure that this code is run when the application starts, we place it into the constructor of the form. This means that we are guaranteed that this code is run before we call any methods on that class.

• In the GameEngine class add the following line of code to the constructor immediately following the InitializeComponent method call.

Visual C#

this.SetStyle(ControlStyles.AllPaintingInWmPaint |
    ControlStyles.Opaque, true);

Visual Basic

Me.SetStyle(ControlStyles.AllPaintingInWmPaint Or 
    ControlStyles.Opaque, True)

Setting the ControlStyles to AllPaintingInWmPaint ensures that Windows only uses the OnPaint event handler to redraw the screen. The second parameter simply informs Windows that our window is not going to be transparent.

Now we have the basic framework for our game. Everything we are going to create from now on out will be actions that occur inside the render loop.

Everything about timers

One issue with this type of loop is that fact that the speed in which the computer can accomplish the tasks in the render loop varies from computer to computer. It even varies on the same computer according to how much memory and CPU time is available for the game at any given moment. We need to have some way of accounting for these differences to make sure that we animate consistently. So instead of treating each frame the same, we are going to calculate the time elapsed between frames and apply that value to our calculations.

There are a couple of different ways of keeping track of time in Windows:

1. System.Windows.Forms.Timer: This is the most common timer used in Windows programming. While it is easy to use, it only has a resolution of 1/18^th of a second. Since we could have up to a thousand frames per second this resolution is not good enough for a game program.
2. timeGetTime: This Windows DLL provides a resolution of 1 microsecond on some versions of Windows and 5 microseconds on Windows NT. This is too variable, and we really don’t want to check the operating system our game is running on to see if we need to adjust the timer values.
3. System.TickCount: This managed call returns the number of ticks that indicate the number of milliseconds. This is close to what we want, but we can do better.
4. QueryPerformanceCounter: This is the preferred timer to use; it has a resolution of less than 1 microsecond. This is the timer most often used in game development.

The last timer is kind of tricky to write since it requires calls to a low-level DLL (kernel32 if you need to know) in Windows. Luckily for us the need for a high-resolution timer is universal and a timer class is included with the DirectX SDK. You can find the timer class in the \Samples\Managed\Common directory underneath the install directory of the SDK. The file we are interested in is called dxmutmisc.cs, but we will use most of the other files in that directory as we add more functionality to our own project.

Before we add dxmutmisc.cs we are going to create a separate folder. Organizing a solution by folders makes it easy to group related items together and keeps the project more organized.

• Selecting Add | New Folder. Name the new folder: DirectXSupport. This is where we are going to add the various support classes as we make use of them throughout this project.

Now we are going to add the existing file to our project. This copies the file to our directory structure. 

• Right-click the DirectXSupport folder and select Add | Add Existing Item and browse to C:\Program Files\Microsoft DirectX 9.0 SDK (February 2005)\Samples\Managed\Common and select the dxmutmisc.cs file.

If you want to, you can browse the contents of this file, it contains various other helper classes that save you from writing a lot of code yourself in addition to the FrameworkTimer class

Since the timer class is contained in a different namespace we are going to add a using statement so we can use the FrameworkTimer without having to write “Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer” every time.

• At the top of the class in the using directives region add the following line of code:

Visual C#

Microsoft.Samples.DirectX.UtilityToolkit;

Visual Basic

Microsoft.Samples.DirectX.UtilityToolkit

Next we need to have a way to store the value of the time elapsed. We are going to store this value in the deltaTime variable. Notice that we are declaring this variable as a double. If you declared it as an integer you would lose all of the resolution provided by our high-powered timer since everything would be rounded to an integer.

• At the end of the class above the last two braces add the following line of code.

Visual C#

private double deltaTime;

Visual Basic

Private deltaTime As Double

We want to start the timer at the last possible moment in the render loop so we can get the most accurate time possible.

• At the end of the OnPaint method right before the this.Invalidate call add the following code.

Visual C#     

FrameworkTimer.Start();

Visual Basic

Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer.Start()

We need to calculate the elapsed (or delta) time at the start of each loop, because we are going to pass it to most of the subsequent calls we are going to make.

• At the very top of the OnPaint method, before any other code, add the following line of code.

Visual C#

deltaTime = FrameworkTimer.GetElapsedTime();

Visual Basic

deltaTime = Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer.GetElapsedTime()

That’s it. We now have a way to track time. As an added bonus, in the next article, we will use this timer to compute our frame rate. You will notice that the solution now will no longer build. This is because the classes in the file we added require DirectX to be referenced. We are going to cover which parts of DirectX we need in the next article.

Summary

We have accomplished a lot in this first article. First, we covered the tools needed to created managed DirectX games and then we discussed the features that make a great game. Next, we defined our game idea and created our game project. After that, we created the render loop we are going to use throughout the game, and finally we added a high resolution timer to our project. 

The next steps all require DirectX, which we will cover in the next article. I hope that this initial article has motivated you to begin that game you always thought about. Game development can be one of the most satisfying experiences in computer programming, and as we progress through this series, I am going to teach you all the fundamentals you need to accomplish that goal.