XNA Help

Random Movement

2008-04-04T21:11:00.001-07:00

Besides chasing and evading we can also have our enemies move in random motion. To
do this we need to add some more properties to the enemy class. We want to change
directions every so often (each enemy should have a different timer it uses to determine
when to switch directions). The direction should be random for each enemy (each enemy
will need a random velocity). The properties we need to add to our Enemy class are as
follows:
public float ChangeDirectionTimer;
public Vector3 RandomVelocity;
public int RandomSeconds;
We will create a method called MoveRandomly that will have the logic to move our
enemies in a random motion:
private void MoveRandomly(Enemy enemy, GameTime gameTime)
{
344 CHAPTER 16 AI Algorithms
if (enemy.ChangeDirectionTimer == 0)
enemy.ChangeDirectionTimer =
(float)gameTime.TotalGameTime.TotalMilliseconds;
//has the appropriate amount of time passed?
if (gameTime.TotalGameTime.TotalMilliseconds >
enemy.ChangeDirectionTimer + enemy.RandomSeconds * 1000)
{
enemy.RandomVelocity = Vector3.Zero;
enemy.RandomVelocity.X = rand.Next(-1, 2);
enemy.RandomVelocity.Y = rand.Next(-1, 2);
//restrict to 2D?
if (!restrictToXY)
enemy.RandomVelocity.Z = rand.Next(-1, 2);
enemy.ChangeDirectionTimer = 0;
}
enemy.Velocity = enemy.RandomVelocity;
enemy.Velocity *= moveUnit;
enemy.Color = Color.Orange;
}
Sometimes random movement can appear intelligent. Our method is utilizing the game
time to keep track of how long the enemy should keep moving. It is very similar to the
code we used for our fading method. This method checks to see if enough time has
passed to change directions. Once enough time has elapsed, the enemy velocity vector is
populated by random numbers ranging from -1 to 1. We need to add the following
random number variable to our code:
Random rand = new Random();
Random numbers are very important in AI work. We have taken care to not just have our
enemies be jittery by changing directions every frame. As a result we can have enemies
that look like they are searching or patrolling. None of the code we have seen has been
rocket science. All the algorithms are pretty simple but can provide great results.
We can replace our line in Update with:
MoveRandomly(enemy, gameTime);
Before we can run the code to see the results of our randomly moving enemies, we need
to initialize our properties. We do this inside of the enemy for loop in the Initialize
method:
Random Movement 345
16
enemies[i].ChangeDirectionTimer = 0;
enemies[i].RandomVelocity = Vector3.Left;
enemies[i].RandomSeconds = (i + 2) / 2;
As we run the code we can see that each enemy is just moving around randomly. They
are not moving in synchronization and they definitely appear random.

Collisions

2008-04-04T21:10:00.000-07:00

This section is going to be pretty detailed. It is something that is best read with a physics
textbook handy to get the full effect. It is not required though, and the actual code is
easier to understand than the math involved. Regardless, it is very beneficial to understand
the reason why this works so we can do further research to determine the best way
to model other important physics needed in our games.
Momentum
When the objects stay in motion, it is because of momentum. Objects in motion have
momentum. Momentum is used to measure our object’s mass and velocity. The formula
to calculate momentum is:
p = mv
p is our object’s momentum and we know that m is our object’s mass and v is the velocity.
The reason we know about mass is because of our force formula. We can substitute
our formula for acceleration in our formula for force:
F = ma = m v / t
Now we can multiply our change in time on both sides, which produces:
Ft = ma = m v
Collisions 295
14
Impulse
Ft is called an impulse. We can do some vector math and multiply our mass by our
change in velocity (the right side of our equation) and see that it can be represented by:
Ft = (mv)
Therefore, we know that our impulse is equal to the change in momentum, which can be
written as follows:
Ft = p
Conservation of Momentum
When objects collide their momentum changes. To be more precise, the magnitude of the
momentum remains the same just in the opposite direction. This is how we can model
our collision response. We can reflect our objects off of each other, knowing that whatever
their momentum was before they collided will remain, but their direction will be
reversed. We just threw two objects into the mix but have only been discussing momentum
on a single object. How does this change our momentum formula? Fortunately, it
does not. This is called the law of conservation of momentum and it means the total
momentum for the objects is constant and does not change. This is true because any
momentum changes are equal in magnitude and opposite in direction. This is expressed
with the following formula:
p1 + p2 = p1 + p2
Kinetic Energy
Now we can discuss Newton’s Third Law of Motion, which basically says that for every
action there is an equal and opposite reaction. Whatever momentum one object
decreases, the other object increases. As momentum is transferred from one object to
another there is another physical property that takes place—kinetic energy. Kinetic energy
is energy associated with moving objects. It is the amount of energy needed to make an
object that is sitting still move. It is also the amount of energy needed to make an object
moving stop and sit still. The formula for kinetic energy is:
Ek = 1⁄2 m v2
When a collision occurs and the amount of kinetic energy is unchanged it is considered
to be an elastic collision. When kinetic energy is lost it is considered to be an inelastic
collision. Objects that collide in the real world will deform and cause a loss of kinetic
energy. If the objects do not deform, no energy is lost.
Coefficient of Restitution
The coefficient of restitution is the measurement of how elastic or inelastic our collision
is based on the types of object that are colliding. The formula for coefficient of restitution
is:
296 CHAPTER 14 Physics Basics
e = (v2f - v1f) / (v1 - v2)
The coefficient of restitution models the velocity before and after a collision takes place
and the loss of kinetic energy happens. The typical value for e is between 0.0 and 1.0
inclusive. A value of 0.0 means the collision is inelastic and 1.0 means the collision is
elastic. The values in between will have a proportionate elastic collision effect. The
subscripts on the preceding formula are specifying which vectors we are using: 1 and 2 are
the two objects and f is the final velocity of that vector after the impact of the collision.
Conservation of Kinetic Energy
We need to discuss the conservation of kinetic energy, which says that the sum of the
kinetic energy of two objects before they collide will be equal to the sum of the kinetic
energy of the two objects after they collide. The formula for the conservation of kinetic
energy is:
Ek1 + Ek2 = Ek1 + Ek2
Broken down into its components, the formula becomes:
1⁄2 m1 v1
2 + 1⁄2 m2 v2
2 = 1⁄2 m1 v1f
2 + 1⁄2 m2 v2f
2
Solving Our Final Velocities
When we are modeling collisions we need to determine our final velocities (which is what
the f in the earlier formula represents). Before we can do that, we need to expand our
conservation of momentum formula from earlier. We will break down the momentum p
into its components as follows:
(m1 v1) + (m2 v2) = (m1 v1f) + (m2 v2f)
Now, we can solve for our final velocity by combining both of our earlier conservation
formulas with our coefficient of restitution formula. Our final velocities will equate to:
v1f = ( (e + 1) m2 v2 + v1(m1 - e m2) ) / (m1 + m2)
v2f = ( (e + 1) m1 v1 - v2(m1 - e m2) ) / (m1 + m2 )
This uses the conservation of kinetic energy formula with our conservation of momentum
formula, along with our coefficient of restitution, which allows us to solve our final velocity
for each object. That is all we need to start modeling realistic collisions.

Managing Game States

2008-04-04T21:09:00.002-07:00

When we think about our overall game design we should consider the different states our
game will be in. When we made the SimpleGame in Chapter 11, we just used an enumerated
type that we could pick from to change our game state. This was sufficient for that
game, although the method we are going to discuss now would still fit it well without
adding a lot of complexity to the game code.
A common question from those starting out making games is this: “How should I structure
my game code?” This is a valid question with many different answers, each having
its own merit. As with every other aspect of programming, tasks can be in completed
many different ways. For this discussion, we use a structure that is not very hard to implement
and yields some very nice results in terms of flexibility.
Consider the following as a concrete example of the problem we are trying to solve:
1. Game is loaded and the start or title screen is displayed.
2. Player presses A or Start so the start or title screen is removed and the main menu
screen appears.
3. Player selects single player game, the main menu is removed, and a submenu is
displayed.
4. The game is a trial game, so a warning message is also displayed prompting the
gamer to purchase the game or continue with limited play. The message is displayed
on top of our submenu.
Managing Game States 309
15
5. The player accepts the message and the submenu no longer has the message
obstructing the view.
6. The player selects Quick Game from the Single Player menu. The Single Player menu
is removed and we start the level by displaying a start level loading screen.
7. When the level finishes loading, the start level screen is removed and we load up
our game’s scene.
8. The player pauses the game and we bring up a paused screen that overlays our
paused game play, which is a little blurred in the background.
Most of those state changes could be done with a simple enumerated type, but there are a
couple of situations where a simple enumerated type is not sufficient, such as when we
display our message in a modal dialog box that does not allow the gamer to continue
until he or she closes the box. However, we do not want to lose sight of the state we were
just in. We might use this same message dialog box at other times in our game for a tutorial
or hints, and so on. Another example is when the gamer pauses the game. We could
just switch our current state with our paused state and then return to our playing state
when the pause button is toggled by the gamer, but then we could not display our
current game’s scene in a blurred (or grayscaled) manner behind our pause screen.
We are going to create a method that will allow us to handle both of those situations and
give us the flexibility of having access to the different states from within each state. We
are going to create a game state manager class that will control a stack of our different
game states. Instead of just switching between states, we are going to implement a stack.
WHAT IS A STACK?
The typical real-world example computer scientists use to explain a stack is a stack of
plates. We push and pop items on and off of the stack. In our plates example, we
push a plate onto the top of the stack. We can then pop a plate off the top of a stack
(but we need to be careful so we don’t break it). It is a last in, first out (LIFO) method
of processing. We do need to make sure we do not try to pop off a plate if the stack is
empty, but that is easy enough to handle.
We are going to use a stack so we can easily handle situations like adding a pause menu
on top of our currently playing scene state. This way we can continue to draw our scene
even though we are paused. We do not want to update our scene, though, as our enemies
would keep coming for us, our timer would continue to count down, and so on. So when
we pause, we really do want to pause our game play, but we still want to draw our game
scene in its paused state. In fact, we might want to use some of the postprocessing techniques
we learned about to blur out, turn gray, or change our scene some other way when
we are in a paused state. By using a stack we can accomplish any of those things.
Using a stack for game state management is also beneficial when trying to handle things
like dialog boxes, as it effectively pauses the game to give players a hint, tell them the
demo’s time is up, and so on. Another benefit is multiple menus. We can push a menu
310 CHAPTER 15 Finite State Machines and Game State Management
state on top of our game play if the user backs out (or pauses) and then offer an options
menu and sound options or controller options under that. With a stack we have the flexibility
to leave our previous menus displayed, or have our screen replace them. With a
simple switch statement on an enumerated type this would not be possible.
Fortunately, with all of this flexibility we do not increase the complexity of our code very
much. The principle is an easy one to grasp. We are going to have a game state manager
that will manage the different states in our game. It will be implementing a stack to hold
our states. Each state will contain logic that determines what happens next. The states
themselves will drive the game flow.
Each state will inherit from a base game state abstract class. This abstract class will inherit
from the DrawableGameComponent class. Each game state that inherits from our abstract
state will be a game service. There are two reasons for this. One is that we want our state
objects to be singleton objects because we do not want more than one instance of our
state created. The second reason we are making it into a game service is because our game
state manager will need access to the states.
Our game state manager also inherits from GameComponent because it is a game service
that our states need a reference to. The game state manager will include an
OnStateChange event. Normally, other objects would register for an event like this.
Instead, we are going to expose the event handler in our game states and have our game
manager manage the event registration process for our game states. The exposed event
handler in our game states will be called StateChanged.
This StateChanged method in our game state class can be overridden but by default it will
simply check to see if the current state of the game is itself. If it is, it will set its Enable
and Visible properties to true; otherwise it will set them to false. So by default, when a
state is loaded, but not at the top of the stack, it will not update itself nor will it draw
itself. All active game states will have this event handler executed whenever our game
changes state. Each state could also search the stack to see if it contains some other state
and if so do some different processing. Because our StateChanged event handler will be
protected, the actual game states can implement any functionality they want to as the
game state changes. We can see that this system is pretty flexible.
Because we want our objects to use the singleton pattern and we want our states to be
game services so each state can access other states if needed, we can combine those
two requirements because the game service collection can only have one object in its
collection with a particular interface. Therefore each one of our states will need its
own interface, but we saw earlier that this can be a blank interface. In our situation, we
are going to have an IGameState interface, but then each one of our states will have its
own interface that implements the IGameState interface.
We need to be able to make comparisons between our game states. Mainly, we need to
make comparisons between our game manager’s current state and a particular game state.
Enumerated types obviously lend themselves to comparisons easily, but what about actual
game state objects? Fortunately, we can just as easily compare our object references and
this is why it is important that there is only one instance of the object—so our reference
is always the same. We will create a property called Value, which is of type GameState.
This property allows us to perform the comparisons that we need.

Force

2008-04-04T21:09:00.001-07:00

Force changes the acceleration of an object. For example, when we hit a baseball the
acceleration of the ball is changed because we applied force (in the form of swinging a
bat) to the ball. If the ball was pitched to us, then it had a positive acceleration coming
toward us; when we hit it we changed the acceleration to the negative direction.
Force is a very important concept in physics. This is understandable because it is
constantly in effect. For example, even when we are sitting down there is a force of
gravity keeping us in the chair. The first example with the baseball is considered contact
force, as an object (the bat) made contact with the ball to make it change its acceleration.
Gravity is considered a field force (or a force-at-a-distance) because it does not have to
have contact with the object while applying force. Gravity causes items to be drawn to
the Earth’s core. This is why we can sit (and stand) and not float about. This is why we
have weight. It is all because of gravity. If there were an object on the floor it would be
sitting on the floor because of gravity. If we tried to pick it up, we would have to apply
enough force to counteract the force that gravity is applying to it. In outer space, objects
float around and are very light because regardless of their mass (assuming it is not as large
as a planet) they do not weigh much at all because there is no force pushing them down.
Mass is the amount of physical matter an object comprises. With the force of gravity our
mass has weight. The more mass an object has, the more it weighs on Earth. The larger
the mass, the more force is applied against that object to bring it toward the Earth’s core.
When we try to move an object, we have to apply enough force to accelerate the object.
CHAPTER 294 14 Physics Basics
If we do not apply as much force to lift the object upward as gravity is applying to the
object downward, the object will not move.
Newton’s Second Law of Motion describes the relationship between an object’s mass and
acceleration with the force applied to the object. The formula is:
F = ma
We know that acceleration is a vector, and force is a vector as well. This makes sense as we
think about the fact that when we hit that baseball it can go in multiple directions (pop
fly, foul ball, etc.). This is because we are creating acceleration when we apply force to the
object at different angles. Our mass is a scalar value (one dimension) and not a vector
(multiple dimensions). We could also write the preceding formula as:
a = F/m
In our previous code example we had an invisible force acting on our sphere that was
generating the acceleration of the sphere. Newton’s First Law of Motion basically states
that objects that are in motion stay in motion and objects that are sitting still stay still.
Our previous demo shows this as well, as if we do not press any keys to accelerate our
sphere it stays at rest. Once we do apply some force to the object, it accelerates and stays
in motion.

Adding Sounds

2008-04-04T21:08:00.002-07:00

We can add in some sounds to help the game out some. We already have our sound
manager class from Chapter 7, “Sounds and Music,” so we do not need to write any new
code for that. Instead of going through the hassle of creating another XACT project, we
will simply copy the XACT project and sound files from our Chapter 7 Sound Demo
project folder. We should create a Sounds subfolder in our Content folder in our project
to store the files. We only need to have the XACT project included in the project with the
wave files just in the same directory, but not in the solution itself.
We need to declare our sound manager variable and we need to initialize it in our
constructor like all of our other game components:
sound = new SoundManager(this, “Chapter7”);
Components.Add(sound);
Now, we can create our playlist just like we did in the SoundDemo project by adding the
following code to our Initialize method:
string[] playList = { “Song1”, “Song2”, “Song3” };
sound.StartPlayList(playList);
Finally, we should play the explosion sound we set up back in Chapter 7. We should do
this right after we start our explosion when our enemy dies, so we need to add the following
statement at the end of the player.Attacking condition inside of the
CheckForCollisions method:
sound.Play(“explosion”);
Now, we have our songs playing and when we kick a robot we not only see an explosion
but we hear one, too.

Using Sprite Fonts

2008-04-04T21:08:00.001-07:00

The XNA Framework 1.0 Refresh includes built-in font support. We can use any TrueType
font in our games. It also allows use of bitmaps, which can either be drawn by hand or be
generated with the Bitmap Font Make Utility (ttf2bmp). This utility can be found on XNA
Creators Club Online at
http://creators.xna.com/Headlines/utilities/archive/2007/04/26/Bitmap-Font-Maker-
Utility.aspx.
BE CAREFUL NOT TO DISTRIBUTE COPYRIGHTED FONTS
Most font files are licensed pieces of software. They are not typically sold. Most do
not allow distribution of fonts in any applications, even games. This even includes
distributing bitmap reproductions of the fonts and many of the fonts that are distributed
with Microsoft Windows. Be careful not to distribute any copyrighted fonts with
your game.
Importing TrueType Fonts
We want our library to handle fonts, so we will add a TrueType font to our XELibrary
project. We need to create a Fonts subfolder under our Content folder in our XELibrary
project. We can import TrueType fonts by following these steps:
1. Right-click the Fonts subfolder and click Add.
2. Click New Item and choose Sprite Font. We can name our file Arial.spritefont. This
will open the newly created .spritefont XML file.
188 CHAPTER 9 2D Basics
3. In the .spritefont XML file we can change the FontName element to the friendly
name of the font we want to load, Arial.
TIP
We can find the name of our font by looking in the Fonts folder in the Control Panel.
We can use any TrueType font but we cannot use bitmap (.fon) fonts.
4. (Optional) We can change the Size element to be the point size we want the font to
be. We can also scale the font, which we will see later.
5. (Optional) We can change the Spacing element, which specifies the number of
pixels there should be between each character in our font.
6. (Optional) We can change the Style element, which specifies how the font should
be styled. This value is case sensitive and can be the following values: Regular, Bold,
Italic, or Bold Italic.
7. The CharacterRegions element contains the start and end characters that should be
generated and available for drawing.
Now that we have added this spritefont file, when we compile our code the compiler will
generate the resource needed so we can utilize the font in our game. The XML file is
simply a description to the compiler as to which TrueType font to grab and which characters
to create in the .xnb file.
Creating Bitmap Fonts
Not only can we use TrueType font resources, we can make our own bitmap fonts to be
used. To do this we need to actually create the bitmap. We can either do it by hand or by
using the Bitmap Font Maker Utility mentioned at the beginning of this section. After
getting the base bitmap generated, we can modify it in our favorite paint program.
The background of the image must be a fully opaque, pure magenta color (R: 255, G: 0,
B: 255, A: 255). It needs to include an alpha channel that specifies which parts of
the characters are visible. Once the image is created or modified we can import the
image into our Fonts subfolder. XNA Game Studio Express will think it is just a normal
texture so we need to modify the Content Processor value in our properties panel to be
Font Texture.
Drawing 2D Text
Now that we have our font imported we can actually use it. We are not going to create a
demo for this. Instead, we are going to modify our ProgressBarDemo project and have it
display the text Loading … right above the progress bar. We need to add the following
private member fields:
private Vector2 loadingPosition = new Vector2(150, 120);
private SpriteFont font;
Using Sprite Fonts 189
9
We already added the font to our XELibrary project. We could have added it to our game,
but it is most likely we will want to print text out on the screen in the future so now we
have it loaded and don’t need to worry about it any more. However, we need to actually
load the font to our game. We do this just like any other content inside of our
LoadGraphicsContent method:
font = content.Load(@”Content\Fonts\Arial”);
Finally, inside of our Draw method, above our call to end our sprite batch, we need to add
the following statement:
spriteBatch.DrawString(font, “Loading ...”, loadingPosition, Color.White);
We can run our ProgressBarDemo and see the word Loading … displayed above our
progress bar. Things are shaping up nicely!

2D Basics

2008-04-04T21:07:00.004-07:00

The XNA Framework not only provides easy ways for us
to utilize 3D objects, but it also provides excellent 2D
support. There are actually a couple of ways we can achieve
2D inside of XNA. There is true 2D, which is sprite manipulation.
We will discuss this kind of 2D. The other kind is
actually setting up a 3D environment, but locking the
camera so that it is always looking at the same angle and
cannot be moved—it is a 3D world with a stationary
camera.
Whereas 3D uses models to display our scene, 2D uses
images to create and animate our scene. The two dimensions
are x and y—there is no z in 2D. It is very common
to mix 2D and 3D into the same game. Scores, menus, and
timers are examples of things that are typically 2D in a 3D
world. Even if you are not interested in writing 2D games,
the next three chapters will prove beneficial, as there will
be things that can be incorporated into your 3D masterpieces.
Sprite Batches
First we need to understand the term sprite. A sprite is an
image. XNA represents sprites with a Texture2D object. We
load them just like we load textures for our 3D applications,
as they are both images and get processed the same
way. The difference is that in 3D we texture an object with
the image, whereas in 2D we draw the image (or part of the
image) on the screen. We saw an example of drawing part
of an image in the last chapter. We applied different parts
of an image to our skybox. The concept is the same, but
the process is a little different. Really, we just pass in whole
numbers instead of floats. Sprites are represented by x and
y and as such have int values. It is impossible to draw
something at pixel location 0.3, 0.3. If these types of values
172 CHAPTER 9 2D Basics
are passed in, XNA will do some anti-aliasing to make it appear that it is partially in the
pixel area but the actual image location is rounded to a whole number.
We discussed the 3D coordinate system earlier and now we discuss the 2D coordinate
system. The top left of the screen is the origin of the screen (0,0). The x axis runs horizontally
at the top of the screen and the y axis runs vertically down the left side of the
screen. It is identical to how a texture’s coordinate system is used. The difference is that
instead of running from 0.0 to 1.0 like in a texture, the values run from 0 to the width
and height of the screen. So if the resolution is 1024 x 768, the x values would run from
0,0 to 1024,0. The y values would run from 0,0 to 0,768. x runs from left to right and y
runs from top to bottom. The bottom right pixel of the screen would be 1024,768. This
can be seen in Figure 9.1.
x+
y+
(0,0) (1024,0)
(0,768) (1024,768)
FIGURE 9.1 The 2D coordinate system origin is the top left of the screen.
Although the origin of the screen is 0,0 the origin of a sprite may or may not be. The
default is 0,0 but the origin can be overridden if needed. When we draw sprites to the
screen we need to be aware of where the origin of the sprite is because when we pass in a
coordinate (via a Vector2 type), XNA will draw the object to that location starting with
the origin of the sprite. So if we drew the sprite at location 100,200 and we did not touch
the origin of the sprite, then the top left of the sprite would get drawn in 100,200. If we
wanted 100,200 to be the center then we would either need to define the origin of our
sprite or we would need to offset our position manually. When we rotate our sprites, they
will rotate around the origin of the sprite. When we need to rotate our sprites we will
typically set the origin of the sprite to be the center of the sprite. This way the sprite will
rotate around the center. Otherwise, the sprite would rotate around 0,0. The differences
between these two can be seen in Figure 9.2.
We can also scale a sprite. Scaling comes in three different flavors. We can either give a
number to scale the entire sprite by or we can just scale one portion of the sprite. The
final way we can scale is to specify a source rectangle and then specify a destination
rectangle. XNA can scale our source rectangle to fit into our destination rectangle.
Sprite batches are simply batches of sprites. When we draw a lot of sprites on the screen it
can put a load on the machine as we have to send a separate instruction to the graphics
card each time we draw something to the screen. With a sprite batch we have the ability
to batch up our draw functions to happen within the same settings and send one draw
call to the graphics card. When we create a SpriteBatch in our code we can pass in the
following values to its Begin method: SpriteBlendMode, SpriteSortMode, and
SaveStateMode.
Sprite Blend Modes
The blend mode can be set to AlphaBlend, Additive, and None. The default blend mode is
AlphaBlend. AlphaBlend does just that: It blends the sprites drawn (source) with the pixels
it is being drawn on (destination) based on the alpha value of both. This includes transparency
but can be used to create different effects depending on blend values we provide.
We will cover overriding the blending values in the next chapter. Additive is another
common blend mode that XNA provides support for with our sprite batches automatically.
Finally, None simply does not set any blending modes. It just overwrites the destination
area with the source sprite.
Alpha blending is used for normal translucent things like glass, windows, water, and
objects that fade in or out. Additive blending, on the other hand, is good to use when
creating glowing objects like explosions, sparks, and even magic effects. We will discuss
these two blending modes and even more that are not directly supported by sprite
batches in the next chapter.
Sprite Sort Modes
The sort mode determines how different sprites that are drawn actually get displayed on
the screen. In previous times, game developers had to take great care with how they
displayed images to the screen to make sure the background did overwrite their foreground
and that textures with alpha values rendered correctly. Although we still need to
take care as we approach this task, a lot of work has been done for us so that we need to
worry about it less. We still need to be aware of how XNA handles this for us so we can
use it effectively and keep our frame rates high.
Sprite Batches 173
9
FIGURE 9.2 The origin of the sprite determines how the sprite will be rotated.
The sort mode can be set to BackToFront, Deferred, FrontToBack, Immediate, and
Texture. The sort mode defaults to Deferred when we call Begin with no parameters.
Immediate is faster than Deferred. Immediate works a little different than the rest of the
sort modes. Immediate updates the graphics device settings immediately when the Begin
method is called. Then as sprites are drawn to the screen they immediately appear with
no sorting. This is the fastest method available, but it requires us to sort the images the
way we want them to be displayed. We draw the background images first and move up to
the foreground. An interesting thing we can do with immediate mode is change our
graphics device settings after Begin is called and before we actually draw our sprites to the
screen. We will discuss this in more detail in the next chapter.
The rest of the sort modes will update the graphics device settings when End is called on
the SpriteBatch instead of Begin. This means there is only one call out to the graphics
device. The Deferred sort mode is like Immediate in that it does not do any sorting, it just
defers talking to the graphics device until the end of the process.
The next two sort modes are BackToFront and FrontToBack. When we draw our sprites we
can set our layer depth of that sprite. That value is a float between 0.0 and 1.0. The sprites
will draw in this order for the two modes. BackToFront is typically used for transparent
sprites and FrontToBack is typically used for nontransparent (opaque) sprites.
Finally, we can pass in Texture as a sort mode to our sprite batch’s Begin method. The
Texture sort mode will check to see all of the draws that are required and will sort them
so that the graphics device does not need to have its texture changed for each draw if
possible. For example, if we have five sprites drawing and three of them use the same
texture (could be different parts of the same texture) then the graphics device is sent the
texture and then the three draws. Then the other two draws occur with their textures.
This can really help performance. However, we might need foreground and background
images in the same texture. Sorting by texture alone is going to give us good performance,
but we need to also sort by our layer depth. Fortunately, we can set up two sprite
batches at the same time (as long as we are not using Immediate sort mode).
So we could have our first batch sort by texture and our second batch sort by layer depth
(BackToFront or FrontToBack). We can then draw our items including the layer depth
value, and as long as we call End on our sprite batches in the appropriate order our screen
will display as we expect and the performance will be good as well. Because the End
method is what actually does the drawing, we need to make sure we call them in order
from background to foreground. It is best to draw our opaque sprites first in one batch
and then our transparent sprites after that.
Save State Modes
As we complete different tasks inside of our Draw method, we might need to change
settings on our graphics device. For example, we might want our depth buffer to be on
when we are drawing certain items and off when drawing other items. When the sprite
batch is executed (when Begin is called in Immediate sort mode, when End is called for all
others) the graphics device will have the properties in Table 9.1 modified. We might want
to save our properties so we can reset them when the sprite batch is done.
174 CHAPTER 9 2D Basics
SaveStateMode.SaveState does exactly that. The other option is SaveStateMode.None,
which is the default and does not save any state. It is quicker if we just reset the states
ourselves if needed, especially on the Xbox 360.
TABLE 9.1 The SpriteBatch.Begin Method Modifies These Graphics Device Properties
Property Value
RenderState.CullMode CullCounterClockwiseFace
RenderState.DepthBufferEnable False
RenderState.AlphaBlendEnable True
RenderState.AlphaTestEnable True
RenderState.AlphaBlendOperation Add
RenderState.SourceBlend SourceAlpha
RenderState.DestinationBlend InverseSourceAlpha
RenderState.SeparateAlphaBlendEnabled False
RenderState.AlphaFunction Greater
RenderState.ReferenceAlpha 0
SamplerStates[0].AddressU Clamp
SamplerStates[0].AddressV Clamp
SamplerStates[0].MagFilter Linear
SamplerStates[0].MinFilter Linear
SamplerStates[0].MipFilter Linear
SamplerStates[0].MipMapLevelOfDetailBias 0
SamplerStates[0].MaxMipLevel 0
When we mix 2D and 3D together we will definitely want to set the following properties
before drawing our 3D content:
GraphicsDevice.RenderState.DepthBufferEnable = true;
GraphicsDevice.RenderState.AlphaBlendEnable = false;
GraphicsDevice.RenderState.AlphaTestEnable = false;
GraphicsDevice.SamplerStates[0].AddressU = TextureAddressMode.Wrap;
GraphicsDevice.SamplerStates[0].AddressV = TextureAddressMode.Wrap;

Using the Skybox

2008-04-04T21:07:00.003-07:00

We have gone through a lot of work, but we are almost done. All we need to do now is
actually use this Skybox object inside of our game. Let’s open the Game1.cs file and add
this private member field:
private Skybox skybox;
Now we need to add a skybox texture to our content folder. Let’s create another subfolder
under Content and call it Skyboxes. This is not required but it might be helpful to remind
us to change the processor type, which we will see how to do shortly. For now, we need
to actually add an image to this Skyboxes subfolder. We can find one on this book’s CD
under the Load3DObject\Content\Skyboxes\skybox.tga inside of the Chapter 8 source
code folder. Copy this texture and paste it into the Skyboxes folder through Solution
Explorer. Inside of the properties window we need to tell XNA Game Studio Express
165
8
LISTING 8.4 Continued
Using the Skybox
which importer and processor we want it to use when loading this content. We will leave
the importer alone as it is defaulted to Texture – XNA Framework. See the sidebar
“Creating a Custom Content Pipeline Importer.”
We will change the Content Processor property, but before we do we need to tell our
project that there is a custom processor of which it needs to be aware. We do this by
double-clicking the Properties tree node under our game projects. Inside of our project
properties we can open the last tab on the bottom: Content Pipeline. We can click Add
and browse to our pipeline project, then add the assembly in the bin folder.
We will add this exact same assembly (under the x86 subfolder) to our Xbox 360 game
project as well. This is because the assembly is only run on our PC when we are actually
building our project. However, we do need to make sure that our XELibrary_Xbox360
assembly has the same name as our Windows assembly. This is important because we
have told the SkyboxWriter where to find the Skybox type and the SkyboxReader object.
We told it XELibrary, not XELibrary_Xbox360.
Alternatively, we could have left the assembly names different and added a condition to
our GetRuntimeReader method in our SkyboxCompiler class. We could have returned a
different string depending on the target platform that is passed into that method.
Now that we have added our Content Pipeline extension to our game projects we can
select SkyboxProcessor from the list of content processors that are available in the property
window when we have our skybox texture selected.
CREATING A CUSTOM CONTENT PIPELINE IMPORTER
An example of setting up a custom importer is the following code:
[ContentImporterAttribute(“.ext”, DefaultProcessor = “SomeCustomProcessor”)]
public class CustomImporter : ContentImporter
{
public override CustomType Import(string filename,
ContentImporterContext context)
{
byte[] data = File.ReadAllBytes(filename);
return (new CustomType(data));
}
}
This code is a theoretical importer that would be inside of the pipeline project if we
needed to import a type of file that the Content Pipeline could not handle. We could
open up the file that was being loaded by the Content Pipeline and extract the data to
our CustomType that could handle the data. This CustomType would also be used as
the input inside of our processor object (where we used Texture2DContent). The
reason we did not make our own importer is because the XNA Framework’ s Content
Pipeline can handle texture files automatically.
166 CHAPTER 8 Extending the Content Pipeline
We are finally ready to run our game. We should see a star-filled background instead of
our typical CornflowerBlue background. We have successfully built a Content Pipeline
extension that takes a texture file and creates a skybox for us automatically. There is no
limit to the things we can accomplish because of the Content Pipeline’s opened architecture.
We could create a level editor and save it in any format and load it in at compile
time to our game. We could write an importer for our favorite 3D model file type and
work directly with the files. There are many opportunities to use the Content Pipeline.
Whenever we can take a hit up front at build time instead of runtime is always a good
thing.

Debugging the Content Pipeline Extension
Extending the pipeline is excellent, but what happens when something goes awry? We
cannot exactly step through the code because this is a component being loaded and run
by the IDE … or can we? Fortunately, we can. We discuss how to do that in this section.
If we have the SkyboxPipeline solution opened, we can close it and then add the project
to our Load3DDemo solution. This is not required to debug, but it can make it easier to
make sure the IDE is using the latest changes to the pipeline processor. Alternatively, we
could compile and change the stand-alone SkyboxPipeline solution and then compile the
Load3DDemo. Again, it really is just personal preference.
The goal is to make sure our SkyboxPipeline code gets compiled before our game code. To
do this we can either add the dependency directly to our game code or we can add it to
our XELibrary knowing that our game code already has a dependency on the XELibrary.
We can right-click our XELibrary projects (one at a time) and select Project Dependencies.
We can then add the check box to our SkyboxPipeline project. From now on, when we
compile, the solution will compile the SkyboxPipeline first, followed by the XELibrary
and finally compile our Load3DObject project.
Now that the SkyboxPipeline project is open, we can add the following line of code at the
top of the Process method inside of our SkyboxProcessor class:
System.Diagnostics.Debugger.Launch();
This will actually launch the debugger so we can step through the code to see what is
happening. If we run our program with this line of coded added, the CLR debugger will
get executed. We can then walk through the code like any other. We cannot edit and
continue just like we cannot do that on the Xbox 360. Regardless, being able to step
through the code at runtime is very beneficial. We can set break points wherever we need
to. This is an excellent way to visualize exactly which pieces of code are calling other
pieces and see the general flow of the Content Pipeline.

Creating a Skybox

2008-04-04T21:07:00.001-07:00

We want to add a skybox to our code. We are going to
create a project that will contain the content, content
processor, and content compiler. After creating this project
we will create another file inside of our XELibrary to read
the skybox data. Finally, we will create a demo that will
utilize the XELibrary’s Skybox Content Reader, which the
Content Manager uses to consume the skybox.
Before we actually create the project we should first
examine a skybox and its purpose in games. A skybox
keeps us from having to create complex geometry for
objects that are very far away. For example, we do not need
to create a sun or a moon or some distant city when we use
a skybox. We can create six textures that we can put into
our cube. Although there are skybox models we could use,
154 CHAPTER 8 Extending the Content Pipeline
for this chapter we are going to build our own skybox. It is simply a cube and we already
have the code in place to create a cube. We know how to create rectangles and we know
how to position them where we want them. We can create six rectangles that we can use
as our skybox. When each texture is applied to each side of the skybox we get an effect
that our world is much bigger than it is. Plus, it looks much better than the cornflower
blue backdrop we currently have!
Creating the Skybox Content Object
To start, let’s create a new Windows library project called SkyboxPipeline. There is no
need to create an Xbox 360 version of the project because this will only be run on the PC.
This SkyboxPipeline project will have three files. The first file is the SkyboxContent.cs
code file, shown in Listing 8.1.
LISTING 8.1 SkyboxContent.cs holds the design time class of our skybox
using System;
using Microsoft.Xna.Framework.Content.Pipeline.Processors;
using Microsoft.Xna.Framework.Content.Pipeline.Graphics;
namespace SkyboxPipeline
{
public class SkyboxContent
{
public ModelContent Model;
public Texture2DContent Texture;
}
}
The SkyboxContent object holds our skybox data at design time. We need to add a reference
to Microsoft.Xna.Framework.Content.Pipeline to our project to utilize the namespaces
needed.
Creating the Skybox Processor
The SkyboxContent object is utilized by the processor, shown in Listing 8.2.
LISTING 8.2 SkyboxProcessor.cs actually processes the data it gets as input from the
Content Pipeline
using System;
using System.Collections.Generic;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content.Pipeline;
using Microsoft.Xna.Framework.Content.Pipeline.Graphics;
using Microsoft.Xna.Framework.Content.Pipeline.Processors;
namespace SkyboxPipeline
{
[ContentProcessor]
class SkyboxProcessor : ContentProcessor
{
private int width = 1024;
private int height = 512;
private int cellSize = 256;
public override SkyboxContent Process(Texture2DContent input,
ContentProcessorContext context)
{
MeshBuilder builder = MeshBuilder.StartMesh(“XESkybox”);
CreatePositions(ref builder);
AddVerticesInformation(ref builder);
// Create the output object.
SkyboxContent skybox = new SkyboxContent();
// Finish making the mesh
MeshContent skyboxMesh = builder.FinishMesh();
//Compile the mesh we just built through the default ModelProcessor
skybox.Model = context.Convert(
skyboxMesh, “ModelProcessor”);
skybox.Texture = input;
return skybox;
}
private void CreatePositions(ref MeshBuilder builder)
{
Vector3 position;
//————-front plane
//top left
position = new Vector3(-1, 1, 1);
builder.CreatePosition(position); //0
//bottom right
155
8
LISTING 8.2 Continued
Creating a Skybox
position = new Vector3(1, -1, 1);
builder.CreatePosition(position); //1
//bottom left
position = new Vector3(-1, -1, 1);
builder.CreatePosition(position); //2
//top right
position = new Vector3(1, 1, 1);
builder.CreatePosition(position); //3
//————-back plane
//top left
position = new Vector3(-1, 1, -1); //4
builder.CreatePosition(position);
//bottom right
position = new Vector3(1, -1, -1); //5
builder.CreatePosition(position);
//bottom left
position = new Vector3(-1, -1, -1); //6
builder.CreatePosition(position);
//top right
position = new Vector3(1, 1, -1); //7
builder.CreatePosition(position);
}
private Vector2 UV(int u, int v, Vector2 cellIndex)
{
return(new Vector2((cellSize * (cellIndex.X + u) / width),
(cellSize * (cellIndex.Y + v) / height)));
}
private void AddVerticesInformation(ref MeshBuilder builder)
{
//texture locations:
//F,R,B,L
//U,D
//Front
Vector2 fi = new Vector2(0, 0); //cell 0, row 0
156 CHAPTER 8 Extending the Content Pipeline
LISTING 8.2 Continued
//Right
Vector2 ri = new Vector2(1, 0); //cell 1, row 0
//Back
Vector2 bi = new Vector2(2, 0); //cell 2, row 0
//Left
Vector2 li = new Vector2(3, 0); //cell 3, row 0
//Upward (Top)
Vector2 ui = new Vector2(0, 1); //cell 0, row 1
//Downward (Bottom)
Vector2 di = new Vector2(1, 1); //cell 1, row 1
int texCoordChannel = builder.CreateVertexChannel
(VertexChannelNames.TextureCoordinate(0));
//————front plane first column, first row
//bottom triangle of front plane
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, fi));
builder.AddTriangleVertex(4); //-1,1,1
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, fi));
builder.AddTriangleVertex(5); //1,-1,1
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, fi));
builder.AddTriangleVertex(6); //-1,-1,1
//top triangle of front plane
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, fi));
builder.AddTriangleVertex(4); //-1,1,1
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, fi));
builder.AddTriangleVertex(7); //1,1,1
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, fi));
builder.AddTriangleVertex(5); //1,-1,1
//————-right plane
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, ri));
builder.AddTriangleVertex(3);
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, ri));
builder.AddTriangleVertex(1);
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, ri));
builder.AddTriangleVertex(5);
Creating a Skybox 157
8
LISTING 8.2 Continued
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, ri));
builder.AddTriangleVertex(3);
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, ri));
builder.AddTriangleVertex(5);
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, ri));
builder.AddTriangleVertex(7);
//————-back pane //3rd column, first row
//bottom triangle of back plane
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, bi)); //1,1
builder.AddTriangleVertex(2); //-1,-1,1
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, bi)); //0,1
builder.AddTriangleVertex(1); //1,-1,1
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, bi)); //1,0
builder.AddTriangleVertex(0); //-1,1,1
//top triangle of back plane
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, bi)); //0,1
builder.AddTriangleVertex(1); //1,-1,1
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, bi)); //0,0
builder.AddTriangleVertex(3); //1,1,1
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, bi)); //1,0
builder.AddTriangleVertex(0); //-1,1,1
//————-left plane
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, li));
builder.AddTriangleVertex(6);
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, li));
builder.AddTriangleVertex(2);
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, li));
builder.AddTriangleVertex(0);
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, li));
builder.AddTriangleVertex(4);
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, li));
builder.AddTriangleVertex(6);
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, li));
builder.AddTriangleVertex(0);
//————upward (top) plane
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, ui));
builder.AddTriangleVertex(3);
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, ui));
builder.AddTriangleVertex(4);
158 CHAPTER 8 Extending the Content Pipeline
LISTING 8.2 Continued
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, ui));
builder.AddTriangleVertex(0);
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, ui));
builder.AddTriangleVertex(3);
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, ui));
builder.AddTriangleVertex(7);
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, ui));
builder.AddTriangleVertex(4);
//————downward (bottom) plane
builder.SetVertexChannelData(texCoordChannel, UV(1, 0, di));
builder.AddTriangleVertex(2);
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, di));
builder.AddTriangleVertex(6);
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, di));
builder.AddTriangleVertex(1);
builder.SetVertexChannelData(texCoordChannel, UV(1, 1, di));
builder.AddTriangleVertex(6);
builder.SetVertexChannelData(texCoordChannel, UV(0, 1, di));
builder.AddTriangleVertex(5);
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, di));
builder.AddTriangleVertex(1);
}
}
}
The SkyboxProcessor contains a lot of code, but the vast majority of it is actually building
and texturing our skybox. We can go ahead and create this file in our pipeline project
now.
To begin we used the [ContentProcessor] attribute for our class so the Content Pipeline
could determine which class to call when it needed to process a resource with our type.
We inherit from the ContentProcessor class stating that we are going to be taking a
Texture2D as input and outputting our skybox content type. In the Process method we
take in two parameters: input and context. To create our skybox we are going to pass in a
single texture in our game projects. The processor creates a new MeshBuilder object,
which is a helper class that allows us to quickly create a mesh with vertices in any order
we wish and then apply different vertex information for those vertices that can contain
things like texture coordinates, normals, colors, and so on. For our purposes we will be
storing the texture. We create our actual eight vertices of our skybox cube in the
CreatePositions method. We are simply passing a vertex position into the
CreatePosition method of the MeshBuilder method.
Creating a Skybox 159
8
LISTING 8.2 Continued
Next up is our call to AddVerticesInformation. This method contains the bulk of the
code but it is not doing anything fancy. It is simply creating triangles in the mesh by
passing the vertices index values to the AddTriangleVertex method of the MeshBuilder
object. These vertices need to be called in the right order. We can think of this as
building the indices of the mesh. The idea is that we created our unique vertices (in
CreatePositions) and although we could have stored the value CreatePosition returned
to us, we know that it will return us the next number starting with 0. Instead of using up
memory for the index being passed back, we just made a note in the comment next to
that vertex so we could build our triangles.
Before we actually add a vertex to a triangle of our mesh, we pass in our vertex channel
information. We created a vertex channel before we started creating triangles with the
following code:
int texCoordChannel = builder.CreateVertexChannel
(VertexChannelNames.TextureCoordinate(0));
We can have multiple vertex channels. Although we are only going to store texture coordinates,
we could also store normals, binormals, tangents, weights, and colors. Because we
could store all of these different pieces of information we need to tell the vertex channel
which type of data we are storing. We then store an index to that particular channel.
Once we have that channel index we can call the SetVertexChannelData method for each
triangle vertex we add. In fact, set the channel data for the builder before adding the
vertex. If we had more than one vertex channel to apply to a vertex, we would call all of
them in succession before finally calling the AddTriangleVertex method. The following
code shows the order in which this needs to take place:
builder.SetVertexChannelData(texCoordChannel, UV(0, 0, fi));
builder.AddTriangleVertex(4);
SetVertexChannelData takes in the vertex channel ID followed by the appropriate data
for that channel. When we set up the vertex channel to handle texture coordinates we
did so by passing the generic Vector2 because texture coordinates have an x and a y
component. This means that the SetVertexChannelData for our texture coordinate
channel is expecting a type of Vector2.
For this texture mapping code to make sense, we need to discuss how the texture asset we
are going to pass into our demo or game needs to be laid out. Instead of requiring six
different textures to create a skybox, we are requiring only one with each plane of the
cube to have a specific location inside of the texture. The texture size is 1024 x 512 to
keep with the power-of-two restriction most graphic cards make us live by. We put four
textures on the top row and two textures on the bottom row. The top row will have the
cube faces Front, Right, Back, and Left in that order. The bottom row will have Up (Top)
and Down (Bottom). If we have skyboxes in other formats we can use a paint program to
get them in this format. We can also use tools to generate skybox images and output
them into this format or one we can easily work with. The great thing about this being an
extension of the Content Pipeline is that we have free reign over how we want to read in
160 CHAPTER 8 Extending the Content Pipeline
data and create content that our games can easily use. If we stick with the current single
texture it leaves part of the texture unused. We could utilize these two spots for something
else. For example, we could create one or two cloud layers to our skybox, so instead
of just rendering a cube, it would render a cube with two additional layers that could
prove to be a nice effect. We could use it for terrain generation by reading in the values
from a gray-scaled image in one of those spots to create a nice ground layout. We do not
discuss terrain generation in this book, but there are many excellent articles on the Web
about generating terrains.
Now that we know how the texture is laid out we can discuss some of the details of the
code that is applying the texture to the different panels of the cube. In the following code
we declared a variable to hold our index of the right panel in the texture:
//Right
Vector2 ri = new Vector2(1, 0); //cell 1, row 0
We are storing 1,0 in a vector signifying that the right panel’s portion of the large texture
is in the first cell in row zero (this is zero based). In Chapter 4, “Creating 3D Objects,”
we discussed how to texture our rectangle (quad) by applying different u and v coordinates
to the different vertices of our rectangle. We are using the exact same concept here.
The only difference is that we have to take into account the fact that we are extracting
multiple textures from our one texture. For example, to texture the right-side panel of
our skybox using just one texture we could simply tell the top left vertex to use texture
coordinates 0,0 and the bottom right vertex to use texture coordinate 1,1. However, our
right-side panel’s texture is not the entire texture we have in memory; instead it is from
pixels 256,0 to 512,256. We can see this in Figure 8.1 where the right panel texture is not
grayed out.
Creating a Skybox 161
8
To handle the offset issue we created a UV method that takes in the typical 0 and 1 along
with index cell from which we need to get our updated u and v coordinates. The UV
method that calculates our u and v values is as follows:
private Vector2 UV(int u, int v, Vector2 cellIndex)
{
return(new Vector2((cellSize * (cellIndex.X + u) / width),
(cellSize * (cellIndex.Y + v) / height)));
}
This method simply takes in the u and v coordinates we would normally map on a full
texture along with the cell index we want to access in the texture and it returns the calculated
u and v coordinates. The cellSize, width, and height are private member fields. We
take the size of the cell, 256, and multiply that by the sum of our x value of our cell
index and the u value passed in. We take that value and divide it by width to come up
with the correct u position of the large texture. We do the same thing to get our v value.
We pass those actual values to SetVertexChannelData so it will associate the right texture
coordinates with that vertex.
After actually creating the Skybox vertices and setting up all of the triangles needed and
applying our texture coordinates, we can finally save the mesh. We do this by calling the
FinishMesh method on our MeshBuilder object, which returns a MeshContent type back to
us. This is convenient as that is the type of object we need to pass to the default
ModelProcessor to process our mesh (just as if we loaded a .X file through the Content
Pipeline). This is done with the following code:
MeshContent skyboxMesh = builder.FinishMesh();
skybox.Model = context.Convert(
skyboxMesh, “ModelProcessor”);
After setting our texture to the texture (our input) that was actually loaded to start this
process, we return the skybox content and the compiler gets launched. We discuss the
compiler in the next section.
Creating the Skybox Compiler
This brings us to our third and final file for our pipeline project. We need to create
another code file with the name SkyboxCompiler.cs. The code for this file is found in
Listing 8.3.
LISTING 8.3 SkyboxCompiler.cs compiles and writes out the content it is passed from the
processor
using System;
using System.Collections.Generic;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content.Pipeline.Graphics;
using Microsoft.Xna.Framework.Content.Pipeline.Processors;
162 CHAPTER 8 Extending the Content Pipeline
using Microsoft.Xna.Framework.Content.Pipeline.Serialization.Compiler;
namespace SkyboxPipeline
{
[ContentTypeWriter]
public class SkyboxWriter : ContentTypeWriter
{
protected override void Write(ContentWriter output, SkyboxContent value)
{
output.WriteObject(value.Model);
output.WriteObject(value.Texture);
}
public override string GetRuntimeType(TargetPlatform targetPlatform)
{
return “XELibrary.Skybox, “ +
“XELibrary, Version=1.0.0.0, Culture=neutral”;
}
public override string GetRuntimeReader(TargetPlatform targetPlatform)
{
return “XELibrary.SkyboxReader, “ +
“XELibrary, Version=1.0.0.0, Culture=neutral”;
}
}
}
We start off this class much like the last in that we associate an attribute with it. This
time we need to use the [ContentTypeWriter] attribute as it tells the Content Pipeline
this is the compiler or writer class. We inherit from the ContentTypeWriter with the
generic type of SkyboxContent (which we created in the first file of this project). This way
when the Content Pipeline gets the skybox content back from the processor it knows
where to send the data to be compiled.
We override the Write method and save our skybox as an .xnb file. The base class does all
of the heavy lifting and all we need to do is write our object out. The next method,
GetRuntimeType, tells the Content Pipeline the actual type of the skybox data that will be
loaded at runtime. The last method, GetRuntimeReader, tells the Content Pipeline which
object will actually be reading in and processing the .xnb data. The contents of these two
methods are returning different classes inside of the same assembly. They do not need to
reside in the same assembly, but it definitely made sense in this case. We store the
runtime type and runtime reader in a separate project. We do not add them to the
pipeline project because the pipeline project is Windows dependent and our actual
skybox type and reader object needs to be platform independent. We are going to set
Creating a Skybox 163
8
Creating the Skybox Reader
Let’s copy and open our Load3DObject project from Chapter 6, “Loading and Texturing
3D Objects.” Our XELibrary should already be inside of this project and we can add a
SkyboxReader.cs file to our XELibrary projects. This file will contain both our Skybox type
and our SkyboxReader type. We could have created separate files if we desired. If we had
them in different assemblies, however, we would need to update our GetRunttimeType
and GetRuntimeReader methods in our content writer. The code contained in
SkyboxReader.cs can be found in Listing 8.4.
LISTING 8.4 SkyboxReader.cs inside of our XELibrary allows for our games to read the
compiled .xnb files generated by the Content Pipeline
using System;
using System.Collections.Generic;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Content;
namespace XELibrary
{
public class SkyboxReader : ContentTypeReader
{
protected override Skybox Read(ContentReader input, Skybox existingInstance)
{
return new Skybox(input);
}
}
public class Skybox
{
private Model skyboxModel;
private Texture2D skyboxTexture;
internal Skybox(ContentReader input)
{
skyboxModel = input.ReadObject();
skyboxTexture = input.ReadObject();
}
public void Draw(Matrix view, Matrix projection, Matrix world)
{
foreach (ModelMesh mesh in skyboxModel.Meshes)
{
foreach (BasicEffect be in mesh.Effects)
{
be.Projection = projection;
be.View = view;
be.World = world;
be.Texture = skyboxTexture;
be.TextureEnabled = true;
}
mesh.Draw(SaveStateMode.SaveState);
}
}
}
}
Our SkyboxReader class is pretty small. It derives from the ContentTypeReader and uses a
Skybox type that we will see in a moment. We override the Read method of this class,
which gets passed in the skybox data as input as well as an existing instance of the object
that we could write into if needed. We take the input and actually create an instance to
our Skybox object by calling the internal constructor.
Inside of the Skybox class we take the input that was just passed to us and store the model
embedded inside. We expose a Draw method that takes in view, projection, and world
matrices as parameters. We then treat the model as if we loaded it from the pipeline
(because we did) and set the basic effect on each mesh inside of the model to use the
projection, view, and world matrices passed to the object. Finally, we actually draw the
object onto the screen.

Creating a Sound Demo

2008-04-04T21:06:00.002-07:00

Now we need to add in another Windows game project to our XELibrary solution. We can
call this new project SoundDemo. We can also set up our solution for our Xbox 360
project if we want to test it on the console. Now we need to make sure our game is referencing
the XELibrary project.
Once we have our XELibrary referenced correctly, we can start writing code to test out our
new sound class (and updated input class). We need to use the library’s namespace at the
top of our game class as follows:
using XELibrary;
We should also add a folder called Content with a Sounds subfolder to our solution. We
can then paste our XACT project file into our Sounds folder. The wave files should be put
in the folder, but do not need to be included in the project. When we compile our code
later, the Content Pipeline will find all of the waves from the wave bank and wrap them
into a wave bank .xwb file. It also creates a sound bank .xsb file while the audio engine is
stored in Chapter7.xgs (as that is what we had as our XACT project name).
We will now add in our InputHandler game component so we can kick off sound events
based on our input. We need to declare our private member field to hold the component
as well as adding it to our game’s components collection:
Creating a Sound Demo 147
7
private InputHandler input;
private SoundManager sound;
public Game1()
{
graphics = new GraphicsDeviceManager(this);
content = new ContentManager(Services);
input = new InputHandler(this);
Components.Add(input);
sound = new SoundManager(this, “Chapter7”);
Components.Add(sound);
}
We passed in “Chapter7” to our constructor because that is what we called our XACT
project. The next thing we need to do is set up our playlist. We can do this inside of our
Initialize method because we added the sound component in our constructor:
string[] playList = { “Song1”, “Song2”, “Song3” };
sound.StartPlayList(playList);
The code tells our sound manager we will be playing three different songs. The library
will keep checking to see if they are playing. If not, it will automatically play the next
one, looping back to the beginning song when it reaches the end of the list.
Now we can actually populate our Update method to check for our input to play all of the
sounds and songs we set up in XACT. We need to add the following code to our Update
method:
if (input.KeyboardState.WasKeyPressed(Keys.D1) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.A))
sound.Play(“gunshot”);
if (input.KeyboardState.WasKeyPressed(Keys.D2) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.B))
sound.Play(“hit”);
if (input.KeyboardState.WasKeyPressed(Keys.D3) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.LeftShoulder))
sound.Play(“attention”);
if (input.KeyboardState.WasKeyPressed(Keys.D4) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.LeftStick))
sound.Play(“explosion”);
if (input.KeyboardState.WasKeyPressed(Keys.D5) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.RightShoulder))
148 CHAPTER 7 Sounds and Music
sound.Play(“bullet”);
if (input.KeyboardState.WasKeyPressed(Keys.D6) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.RightStick))
sound.Play(“crash”);
if (input.KeyboardState.WasKeyPressed(Keys.D7) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.X))
sound.Play(“complex”);
if (input.KeyboardState.WasKeyPressed(Keys.D8) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.Y))
sound.Toggle(“CoolLoop”);
if (input.KeyboardState.WasKeyPressed(Keys.D9) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.LeftShoulder))
sound.Toggle(“CoolLoop 2”);
if (input.KeyboardState.WasKeyPressed(Keys.P) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.Start))
{
sound.Toggle(“CoolLoop”);
}
if (input.KeyboardState.WasKeyPressed(Keys.S) ||
(input.GamePads[0].Triggers.Right > 0))
sound.StopPlayList();
We are simply checking to see if different keys were pressed or different buttons were
pushed. Based on those results we play different cues that we set up in the XACT project.
A good exercise for us would be to run the demo and reread the section of this chapter
where we set up all of these sounds and see if they do what we expect when we press the
appropriate keys or buttons. In particular we can press the B button or number 2 key
repeatedly and see that the “hit” cue is queuing up as we told it to limit itself to only
playing once and to queue failed requests. We can also click down on our right thumb
stick or press the number 6 key to hear our crash. If the playlist is hindering our hearing
of the sounds we can stop it by pressing the S key or pushing on our right trigger.
The final piece of code for our sound demo is where we can set a global variable for the
RPC we set up as well as the volume of our default category cues. To start, we need to add
two more private member fields:
private float currentVolume = 0.5f;
private float value = 0;
Now we can finish up our Update method with the following code:
if (input.KeyboardState.IsHoldingKey(Keys.Up) ||
input.GamePads[0].DPad.Up == ButtonState.Pressed)
Creating a Sound Demo 149
7

Now we need to add in another Windows game project to our XELibrary solution. We can
call this new project SoundDemo. We can also set up our solution for our Xbox 360
project if we want to test it on the console. Now we need to make sure our game is referencing
the XELibrary project.
Once we have our XELibrary referenced correctly, we can start writing code to test out our
new sound class (and updated input class). We need to use the library’s namespace at the
top of our game class as follows:
using XELibrary;
We should also add a folder called Content with a Sounds subfolder to our solution. We
can then paste our XACT project file into our Sounds folder. The wave files should be put
in the folder, but do not need to be included in the project. When we compile our code
later, the Content Pipeline will find all of the waves from the wave bank and wrap them
into a wave bank .xwb file. It also creates a sound bank .xsb file while the audio engine is
stored in Chapter7.xgs (as that is what we had as our XACT project name).
We will now add in our InputHandler game component so we can kick off sound events
based on our input. We need to declare our private member field to hold the component
as well as adding it to our game’s components collection:
Creating a Sound Demo 147
7
private InputHandler input;
private SoundManager sound;
public Game1()
{
graphics = new GraphicsDeviceManager(this);
content = new ContentManager(Services);
input = new InputHandler(this);
Components.Add(input);
sound = new SoundManager(this, “Chapter7”);
Components.Add(sound);
}
We passed in “Chapter7” to our constructor because that is what we called our XACT
project. The next thing we need to do is set up our playlist. We can do this inside of our
Initialize method because we added the sound component in our constructor:
string[] playList = { “Song1”, “Song2”, “Song3” };
sound.StartPlayList(playList);
The code tells our sound manager we will be playing three different songs. The library
will keep checking to see if they are playing. If not, it will automatically play the next
one, looping back to the beginning song when it reaches the end of the list.
Now we can actually populate our Update method to check for our input to play all of the
sounds and songs we set up in XACT. We need to add the following code to our Update
method:
if (input.KeyboardState.WasKeyPressed(Keys.D1) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.A))
sound.Play(“gunshot”);
if (input.KeyboardState.WasKeyPressed(Keys.D2) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.B))
sound.Play(“hit”);
if (input.KeyboardState.WasKeyPressed(Keys.D3) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.LeftShoulder))
sound.Play(“attention”);
if (input.KeyboardState.WasKeyPressed(Keys.D4) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.LeftStick))
sound.Play(“explosion”);
if (input.KeyboardState.WasKeyPressed(Keys.D5) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.RightShoulder))
148 CHAPTER 7 Sounds and Music
sound.Play(“bullet”);
if (input.KeyboardState.WasKeyPressed(Keys.D6) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.RightStick))
sound.Play(“crash”);
if (input.KeyboardState.WasKeyPressed(Keys.D7) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.X))
sound.Play(“complex”);
if (input.KeyboardState.WasKeyPressed(Keys.D8) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.Y))
sound.Toggle(“CoolLoop”);
if (input.KeyboardState.WasKeyPressed(Keys.D9) ||
input.ButtonHandler.WasButtonPressed(0,
InputHandler.ButtonType.LeftShoulder))
sound.Toggle(“CoolLoop 2”);
if (input.KeyboardState.WasKeyPressed(Keys.P) ||
input.ButtonHandler.WasButtonPressed(0, InputHandler.ButtonType.Start))
{
sound.Toggle(“CoolLoop”);
}
if (input.KeyboardState.WasKeyPressed(Keys.S) ||
(input.GamePads[0].Triggers.Right > 0))
sound.StopPlayList();
We are simply checking to see if different keys were pressed or different buttons were
pushed. Based on those results we play different cues that we set up in the XACT project.
A good exercise for us would be to run the demo and reread the section of this chapter
where we set up all of these sounds and see if they do what we expect when we press the
appropriate keys or buttons. In particular we can press the B button or number 2 key
repeatedly and see that the “hit” cue is queuing up as we told it to limit itself to only
playing once and to queue failed requests. We can also click down on our right thumb
stick or press the number 6 key to hear our crash. If the playlist is hindering our hearing
of the sounds we can stop it by pressing the S key or pushing on our right trigger.
The final piece of code for our sound demo is where we can set a global variable for the
RPC we set up as well as the volume of our default category cues. To start, we need to add
two more private member fields:
private float currentVolume = 0.5f;
private float value = 0;
Now we can finish up our Update method with the following code:
if (input.KeyboardState.IsHoldingKey(Keys.Up) ||
input.GamePads[0].DPad.Up == ButtonState.Pressed)
Creating a Sound Demo 149
7
currentVolume += 0.05f;
if (input.KeyboardState.IsHoldingKey(Keys.Down) ||
input.GamePads[0].DPad.Down == ButtonState.Pressed)
currentVolume -= 0.05f;
currentVolume = MathHelper.Clamp(currentVolume, 0.0f, 1.0f);
sound.SetVolume(“Default”, currentVolume);
if (input.KeyboardState.WasKeyPressed(Keys.NumPad1))
value = 5000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad2))
value = 25000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad3))
value = 30000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad4))
value = 40000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad5))
value = 50000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad6))
value = 60000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad7))
value = 70000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad8))
value = 80000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad9))
value = 90000;
if (input.KeyboardState.WasKeyPressed(Keys.NumPad0))
value = 100000;
if (input.GamePads[0].Triggers.Left > 0)
value = input.GamePads[0].Triggers.Left * 100000;
sound.SetGlobalVariable(“SpeedOfSound”, value);
This completes our sound demo code and now if we run it and press the Up and Down
arrow keys or on the Dpad we can hear the volume of the sounds associated with our
“Default” category go up and down. We clamp our value between 0 and 1 because that is
what the engine takes to set the volume. This is an example of how checking for the
input state without considering the previous state can get us into trouble. The code will
turn the volume up and down very quickly because it is getting back a true on every call
every frame. Feel free to add Dpad to the updated InputHandler code.
Not only does this code let us test the volume settings, it also lets us set a global variable.
In the XACT project, if we used SpeedOfSound as one of the parameters when setting up
our curve then we can actually modify the way the cue sounds here at runtime. That is
pretty powerful.

Updating Our Input Handler

2008-04-04T21:06:00.001-07:00

Before we actually dig into the code to utilize the XACT project we just created, let’s back
up a minute and take another look at our input handler. In particular we want to extend
our keyboard and gamepad functionality. Currently, if we try to trigger any event with a
key press or a button push we will get the event kicked off several times. This is because
for every frame we are checking in our Update method, if a key is pressed for a fraction of
a second the method will return true for many frames. We already know how to solve the
problem because we did it with our Mouse class. We stored the old state and compared it
to the new state to see what has changed. We need to do the same thing here. With the
mouse code, we did it inside of the demo code, but we want this to be done inside of the
library so our game and demo code do not need to worry about the gory details. We will
not be updating the mouse code but that would be an excellent exercise to go through
once we are done with the chapter.
To get started, we need to open up the InputHandler.cs code file inside of our XELibrary
project. The code for our updated InputHandler.cs file is in Listing 7.1. We are not going
to do a deep dive on the code in this chapter (this is devoted to sound after all), but we
are going to quickly examine what has been modified from a distant view.
LISTING 7.1 InputHandler.cs
using System;
using System.Collections.Generic;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Input;
namespace XELibrary
{
public interface IInputHandler
{
KeyboardHandler KeyboardState { get; }
GamePadState[] GamePads { get; }
ButtonHandler ButtonHandler { get; }
#if !XBOX360
MouseState MouseState { get; }
MouseState PreviousMouseState { get; }
134 CHAPTER 7 Sounds and Music
#endif
};
public partial class InputHandler
: Microsoft.Xna.Framework.GameComponent, IInputHandler
{
public enum ButtonType { A, B, Back, LeftShoulder, LeftStick,
RightShoulder, RightStick, Start, X, Y }
private KeyboardHandler keyboard;
private ButtonHandler gamePadHandler = new ButtonHandler();
private GamePadState[] gamePads = new GamePadState[4];
#if !XBOX360
private MouseState mouseState;
private MouseState prevMouseState;
#endif
public InputHandler(Game game)
: base(game)
{
// TODO: Construct any child components here
game.Services.AddService(typeof(IInputHandler), this);
//initialize our member fields
keyboard = new KeyboardHandler();
gamePads[0] = GamePad.GetState(PlayerIndex.One);
gamePads[1] = GamePad.GetState(PlayerIndex.Two);
gamePads[2] = GamePad.GetState(PlayerIndex.Three);
gamePads[3] = GamePad.GetState(PlayerIndex.Four);
#if !XBOX360
Game.IsMouseVisible = true;
prevMouseState = Mouse.GetState();
#endif
}
public override void Initialize()
{
base.Initialize();
}
public override void Update(GameTime gameTime)
{
Updating Our Input Handler 135
7
LISTING 7.1 Continued
keyboard.Update();
gamePadHandler.Update();
if (keyboard.IsKeyDown(Keys.Escape))
Game.Exit();
if (gamePadHandler.WasButtonPressed(0, ButtonType.Back))
Game.Exit();
#if !XBOX360
//Set our previous state
prevMouseState = mouseState;
//Get our new state
mouseState = Mouse.GetState();
#endif
base.Update(gameTime);
}
#region IInputHandler Members
public KeyboardHandler KeyboardState
{
get { return (keyboard); }
}
public ButtonHandler ButtonHandler
{
get { return (gamePadHandler); }
}
public GamePadState[] GamePads
{
get { return(gamePads); }
}
#if !XBOX360
public MouseState MouseState
{
get { return(mouseState); }
}
public MouseState PreviousMouseState
{
136 CHAPTER 7 Sounds and Music
LISTING 7.1 Continued
get { return(prevMouseState); }
}
#endif
#endregion
}
public class ButtonHandler
{
private GamePadState[] prevGamePadsState = new GamePadState[4];
private GamePadState[] gamePadsState = new GamePadState[4];
public ButtonHandler()
{
prevGamePadsState[0] = GamePad.GetState(PlayerIndex.One);
prevGamePadsState[1] = GamePad.GetState(PlayerIndex.Two);
prevGamePadsState[2] = GamePad.GetState(PlayerIndex.Three);
prevGamePadsState[3] = GamePad.GetState(PlayerIndex.Four);
}
public void Update()
{
//set our previous state to our new state
prevGamePadsState[0] = gamePadsState[0];
prevGamePadsState[1] = gamePadsState[1];
prevGamePadsState[2] = gamePadsState[2];
prevGamePadsState[3] = gamePadsState[3];
//get our new state
//gamePadsState = GamePad.State .GetState();
gamePadsState[0] = GamePad.GetState(PlayerIndex.One);
gamePadsState[1] = GamePad.GetState(PlayerIndex.Two);
gamePadsState[2] = GamePad.GetState(PlayerIndex.Three);
gamePadsState[3] = GamePad.GetState(PlayerIndex.Four);
}
public bool WasButtonPressed(int playerIndex,
InputHandler.ButtonType button)
{
int pi = playerIndex;
switch(button)
{ //start switch
case InputHandler.ButtonType.A:
{
return(gamePadsState[pi].Buttons.A == ButtonState.Pressed &&
Updating Our Input Handler 137
7
LISTING 7.1 Continued
prevGamePadsState[pi].Buttons.A == ButtonState.Released);
}
case InputHandler.ButtonType.B:
{
return(gamePadsState[pi].Buttons.B == ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.B == ButtonState.Released);
}
case InputHandler.ButtonType.Back:
{
return(gamePadsState[pi].Buttons.Back == ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.Back == ButtonState.Released);
}
case InputHandler.ButtonType.LeftShoulder:
{
return(gamePadsState[pi].Buttons.LeftShoulder ==
ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.LeftShoulder ==
ButtonState.Released);
}
case InputHandler.ButtonType.LeftStick:
{
return(gamePadsState[pi].Buttons.LeftStick ==
ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.LeftStick ==
ButtonState.Released);
}
case InputHandler.ButtonType.RightShoulder:
{
return(gamePadsState[pi].Buttons.RightShoulder ==
ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.RightShoulder ==
ButtonState.Released);
}
case InputHandler.ButtonType.RightStick:
{
return(gamePadsState[pi].Buttons.RightStick ==
ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.RightStick ==
ButtonState.Released);
}
case InputHandler.ButtonType.Start:
{
return(gamePadsState[pi].Buttons.Start ==
ButtonState.Pressed &&
138 CHAPTER 7 Sounds and Music
LISTING 7.1 Continued
prevGamePadsState[pi].Buttons.Start ==
ButtonState.Released);
}
case InputHandler.ButtonType.X:
{
return(gamePadsState[pi].Buttons.X == ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.X == ButtonState.Released);
}
case InputHandler.ButtonType.Y:
{
return(gamePadsState[pi].Buttons.Y == ButtonState.Pressed &&
prevGamePadsState[pi].Buttons.Y == ButtonState.Released);
}
default:
throw (new ArgumentException());
} //end switch
}
}
public class KeyboardHandler
{
private KeyboardState prevKeyboardState;
private KeyboardState keyboardState;
public KeyboardHandler()
{
prevKeyboardState = Keyboard.GetState();
}
public bool IsKeyDown(Keys key)
{
return (keyboardState.IsKeyDown(key));
}
public bool IsHoldingKey(Keys key)
{
return(keyboardState.IsKeyDown(key) &&
prevKeyboardState.IsKeyDown(key));
}
public bool WasKeyPressed(Keys key)
{
return(keyboardState.IsKeyDown(key) &&
prevKeyboardState.IsKeyUp(key));
Updating Our Input Handler 139
7
LISTING 7.1 Continued
}
public bool HasReleasedKey(Keys key)
{
return(keyboardState.IsKeyUp(key) &&
prevKeyboardState.IsKeyDown(key));
}
public void Update()
{
//set our previous state to our new state
prevKeyboardState = keyboardState;
//get our new state
keyboardState = Keyboard.GetState();
}
}
}
The first thing to notice is that we added two more classes at the end of our file:
KeyboardHandler and ButtonHandler. These objects each have an Update method that
gets called by our main Update method inside of InputHandler. The Update method stores
the previous state and resets the new state. This is the key to it all. We simply check our
new state against our old state to see if keys or buttons have been pressed or released. We
have helper functions that our game code can call to check if the key was pressed or a
button was pressed. These helper functions just query the previous and new states of the
appropriate input device and return a boolean value. With this implemented we do not
run into the issue of getting multiple events kicked off because the gamer is holding the
button down. It also gives us a base from which to start working. We left our most current
state available, as we still need that for our triggers and Dpad. Dpad could also be put into
this handler because it is treated as a button, but that along with wrapping up the mouse
information is not in the code. This should be a good starting point if either of those is
needed, though.

Sounds and Music

2008-04-04T21:05:00.003-07:00

Stop and think for a moment what your favorite game
would be like if it did not have sound. Music sets the
atmosphere for our games and sound effects adds to the
realism of our games. In this chapter we discuss how to get
music and sounds into our demos and games.
To do this we will need to use the Microsoft Cross-Platform
Audio Creation Tool (XACT), which Microsoft provides for
us. The tool can be found in our Programs/Microsoft XNA
Game Studio Express/Tools menu. Once we have the tool
opened we will create wave banks and sound banks and
discuss global settings. We will then actually create a sound
manager that we can add to our library

Microsoft Cross-Platform Audio
Creation Tool (XACT)

Unlike textures and 3D models, we do not simply put our
raw wave files into the Content Pipeline directly. Instead
we use XACT to bundle them together and add effects to
the different sounds. The XACT tool allows us to associate
categories with our sounds. When we set a sound to have a
category of Music, it allows the Xbox 360 to ignore the
music if the gamer has a playlist playing on his or her
Xbox 360.
Before we open the actual tool we need to open up the
XACT Auditioning Utility, which is found in the same location
as XACT itself. We only need to do this if we actually
want to audition (listen to) the sounds we are making
inside of XACT. This can, of course, be beneficial, especially
when we want to add effects to the file. With that said,
XACT is not a sound editing software package. It takes
completed wave files and puts them in a format that XNA
can read and use. We can do simple effects like change the
124 CHAPTER 7 Sounds and Music
pitch and volume but the tool is not designed to be a wave file editor.
We first need to hook our XACT tool up to the Auditioning Utility we launched before.
The Auditioning Utility must be run before the XACT tool is run. To play our sounds we
need to tell XACT to connect to the Auditioning Utility by clicking the Audition menu
item and then clicking the Connect To (machine) item. After we have successfully
connected, the Auditioning Utility will say “XACT tool is now connected….”
When we open the tool we will see an empty project to which we can add .wav files.
After adding the files we can then set them up as sounds and create cue names for them
that we can kick off inside of our code. We can modify properties to get different effects
from the sounds.
Wave Banks
To get started we can create a new wave bank from inside XACT. To create a wave bank,
we can follow these steps:
1. Right-click Wave Banks and select New Wave Bank. This can be seen in Figure 7.1.
2. Inside of the Wave Bank empty pane, right-click and select Insert Wave File(s).
3. Find a wave file from the Spacewar project. We can use the Theme.wav file from
MySpacewarWin1\Content\Audio\Waves\Music.
FIGURE 7.1 The XACT tool allows us to add wave banks to utilize the sounds in our games.
4. Because we have our Auditioning Tool set up and XACT connected to it, we can
simply select the wave file and press the spacebar to hear it play. We could also
right-click and select Play, or click Play in the toolbar. As with most graphical user
interfaces (GUIs) there are many ways to accomplish the same task. This book only
lists one way in most cases.
We can go ahead and add in a few other wave files as well. Let’s follow the preceding
steps to enter all of the collision wave files from Spacewar. We can open them all up at
one time in the Open dialog box.
Sound Banks
Even though we have the wave file loaded inside our XACT project, we still could not use
it in our game. We have to create a sound bank first. To create a sound bank we can
follow these steps:
1. Right-click Sound Banks and select New Sound Bank. Just like the wave bank, we
could also accomplish this through the toolbar or the main menu items.
2. Our work pane just filled up with our Sound Bank window. We will need to work
with the Wave Bank window as well as the Sound Bank window so we will want to
position them so we can see them both. One way to do this is to click Tile
Horizontally inside of the Window menu item.
3. Now that we can see both windows we need to drag our wave file from the wave
bank into the sound bank, inside the top left pane (sounds frame).
4. A cue for the sound needs to be created in order for our code to utilize it. We can
create a cue by dragging the sound from the top left pane (sounds frame) into the
bottom left pane (cues frame).
This is the bare minimum we need to do to play sounds in our games. To hear the sound
we can select it and press the spacebar. We can press Escape to stop the sound. To get
sound effects and music into our games, these steps will work. In the next sections we
discuss more advanced ways to manipulate our sounds to get them ready for our game.
Understanding Variations
To accomplish something more than just playing sounds we need to understand variations.
With variations we can assign many waves to a track and we can create different
events for those tracks to create a sound. We can assign many sounds to a cue. We can
then set up how those sounds or waves are to be played. We will be utilizing XACT to
create different variations and then we are going to write a library component that a
demo can use to play these cues.
We can close out our existing XACT instance and open up a new one. We need to create a
wave bank and a sound bank to put our waves in. On this book’s CD, under this chapter’s
folder there is a subfolder entitled Sounds. We need to add all of these waves into our
Understanding Variations 125
7
wave bank. After adding in the waves we need to create some sounds. We are going to
add the different sounds and create different variations so we can learn how to use some
of the XACT features by example.
1. We can drag the Attention and Explosion sounds directly into our cues frame
(bottom left pane) because we are going to play these sounds as is.
2. We can drag the Axe_throw sound directly into our cues frame and rename the cue
to Bullet. We can do this by right-clicking the name in the cues frame and selecting
Rename. At this point, the screen should resemble Figure 7.2.
126 CHAPTER 7 Sounds and Music
FIGURE 7.2 Wave files can be dragged directly into the cues frame.
3. To start our more complicated tasks let’s drag our CoolLoop wave into our cues
frame.
4. In the top right pane (tracks frame) we can see that XACT created a track with a
play event that include our wave name. We want to make sure this sound loops so
we click the Play Wave tree node of the Track 1 root to select it.
5. In the properties window we can see LoopEvent under the PlayWave Properties. The
default value is No but we could either loop it a certain number of times by selecting
Finite and then entering the number of times to loop in the LoopCount property
or we can have it loop forever by selecting Infinite. We are going to let this
sound loop forever so we select Infinite. We can see this in Figure 7.3.
FIGURE 7.3 We can set our play event on a track to loop indefinitely.
6. Because this loop is going to be music we can click the CoolLoop’s sound icon and
drag it on top of the Music category on the left side of the window. When this is
successful we will see the Category change from Default to Music.
7. Next up we are going to add multiple sounds into one cue. We will use
Synth_beep_1 to start us off. Let’s drag that wave into our cues frame.
8. Now we want to make sure that the sound name is selected (in our sounds frame) so
the track frame is showing the play event for track 1.
9. We need to drag Synth_beep_2 and Synth_beep_3 waves and drop them on our play
event inside of track 1. We need to be careful to not drag over the cues frame as it
will make the tracks frame empty (it deselects the sound from the sound pane). We
drag the files by clicking on the icon (XACT does not allow us to drag by the name
of the wave). We can see where we need to release the cursor in Figure 7.4. The final
result after releasing the cursor and completing our drop operation can be seen in
Figure 7.5.
10. Rename this cue from Synth_beep_1 to Hit.
11. With Hit as our active cue, we can press the spacebar to hear it play (assuming we
are connected to the Auditioning Utility). Let’s hit the spacebar several times in a
row very fast. We can hear one sound being played every time we hit the spacebar
regardless if the previous sound was played. We see they are not played at the same
time by “pressing play” once. By putting our different waves directly into a play
event we are giving XACT a list of waves to play from when we call play. It does not
play them all at once (but we will see how to do that in a moment).
Understanding Variations 127
7
12. Because we do not want this particular cue to play more than one sound at a time
we can change the LimitInstances property in the Instance Limiting Properties
section of our properties window to True. We will need to have our cue name
selected to do this. Now when we press the spacebar multiple times it will not start
playing until the last sound has finished.
13. We can hear the sounds are random but we want them to play in the order we specified
in the play event of our track. To do this we need to select Ordered in the
PlayListType property in the Variation Playlist Properties section of the property
frame. We need to do this when we have the cue selected. Changing this value to
Ordered causes XACT to play the sounds in the order we specified. If we wanted it
to start with a random entry and then do them in order, we could have selected
Ordered From Random.
14. Now when we play the sounds, they play in order and only play one at a time.
However, we want the sounds to be queued up so that if we press the spacebar five
times, it will play all of the waves in the sound with each one starting as soon as the
previous one finishes. To do this we need to change the BehaviorAtMax property to
Queue instead of FailToPlay. This can be useful for queuing up things like voiceover
audio that we would never want to play simultaneously. This is shown in Figure 7.6.
Understanding Variations 129
7
15. Now we are going to make a crash cue. To start, let’s drag Ambulance_siren from our
waves into our cues and rename the cue to Crash.
16. Inside of our tracks frame, with our Ambulance_siren sound selected from the sound
frame, right-click and add a new track.
17. Now we can add a play event to the track we just added by right-clicking the track
and selecting Add Event > Play Wave.
18. We need to drag the Car_brake wave into the play event of the track we just created.
Remember not to drag across the cue frame, as the contents of the track frame will
disappear.
19. We need to repeat steps 16 through 18 with the wave files Bus_horn and Explosion.
When this step is completed we should have a total of four tracks, each with its
own play event that has a wave file associated with it. We have expanded the Sound
Banks window in Figure 7.7 so we can see the end result.
130 CHAPTER 7 Sounds and Music
FIGURE 7.7 We can create multiple tracks for a sound, each with one or more events in our
tracks frame.
20. Now if we play our Crash cue we will hear all four sounds at the same time. We
want them to be spaced out as to simulate an accident. We can delay the time at
which different tracks start to play by setting the TimeStamp property in the Timing
Properties section of our property frame when we have the play wave event selected.
Our Car_brake wave can be left alone as it is a little longer of a sound file. We
should modify the rest of the values as follows:
Bus_horn: 0.300
Explosion: 1.000
Ambulance_siren: 1.600
Now when we play the cue we can hear something that resembles a car colliding
with a bus, creating a large explosion and the fastest EMT response time ever!
21. Now we want to make a variant of our explosion sound. We are going to make a
gunshot sound without requiring an additional wave file to be used. To do this we
are going to drag our Explosion sound (top right pane) into the empty white space
inside of the same sound pane so it will create a copy of itself. It should have called
itself Explosion 2. Let’s drag that Explosion 2 from the sounds frame into our cues
frame and rename the cue to Gunshot.
22. When we play Gunshot, it does not sound any different than Explosion. Let’s
change that by adding a Pitch event to our only track for the Explosion 2 sound in
our tracks frame. We add this event just like we added the play event earlier, by
right-clicking the track and selecting Add Event > Pitch.
23. Now we need to actually modify the pitch to get the desired sound effect. To do this
we need to make sure our Pitch event is selected and then change the Constant
value. We can find this value in our properties frame under Pitch Properties/Setting
Type (Equation)/EquationType (Constant). Let’s change the pitch to 50.00 as shown
in Figure 7.8. Now if we play the cue we will hear something that resembles a
gunshot instead of an explosion. We did not have to add another large wave file to
accomplish this effect.
Understanding Variations 131
7
24. Next, we are going to create a cue with multiple sounds. We need to right-click
inside of our cues frame and select New Cue. We can name this cue Complex.
25. Drag the Explosion sound down on top of the Complex cue. Let’s do the same thing
with the Synth_beep_1 sound. Remember, this Synth_beep_1 sound has its own
sound variations already as it plays three different waves in order.
26. We need to change the PlayList type for this Complex cue to Random. This way it
will just play a sound randomly even if the one it picks was just played.
27. The final thing we will do is add a music playlist. Unfortunately, XACT does not
have a way to give us typical playlist functionality so we will have to put that into
our code. For now, though, we can at least add our songs to this playlist. We will
start by dragging our Song1, Song2, and Song3 waves into our sounds frame.
28. We will also drag those sounds to our music category.
29. Now we need to drag our Song1, Song2, and Song3 sounds from our sounds frame
into the cues frame.
30. We can now save our project, calling it Chapter7.
That was a lot of examples, but it was worth going through because at this point we have
good idea of how to do a lot of sound manipulation to prepare cues for our games. Our
games will always reference the cue value.
There are other actions XACT allows us to do, such as setting local and global variables,
setting up transitions through interactive audio settings, and setting up runtime parameter
controls (RPCs).
We can create RPCs when a simple pitch or volume change across the board will not do.
Perhaps we would like to add some reverb, or maybe we would like to modify the volume
as a cue plays up and down. Doing any of these things requires setting up an RPC, which
can be done by right-clicking the RPC tree node and selecting New RPC Preset as shown
in Figure 7.9.
Then we can drag that preset over to one of our sounds in the sounds frame. To test with,
we can make a copy of our CoolLoop sound and then add our preset to this new sound
by dragging the RPC on top of the new sound we just created. We can open the RPC
preset by double-clicking it. Because there is only one sound it is associated with, it will
play that one. At the top of the RPC dialog box we can select other sounds (if we have
added the RPC to multiple sounds). A default volume curve has been added for us. We
can move the points around and then the vertical horizontal bar that is the same color as
our curve can be moved left and right. The bar can be moved or we can modify the variable
above beside the curve declaration. This is the variable that we can change in our
code to cause the sound to react exactly how we want. We might want to do this, for
example, to dim the background music when dialogue is happening between characters.
We can pass a value to the global variable that will produce the sound identical to what
we are hearing as we audition the sound with our RPC added. We can add more curves
(pitch and reverb) by right-clicking the Volume item at the top of the dialog box and
selecting Add New Curve. We can add nodes to our curve by right-clicking inside of the
main white area and selecting Add. A screen shot of this dialog box is shown in Figure
7.10. Have fun coming up with a totally different CoolLoop 2 sound!
7
We can pause and resume all sounds in a category. This means that we could organize our
sounds in such a way that sounds that are used in our playing state can all be assigned to
a category we can define. Then through the code we can pause that category and it will
pause all sounds that are playing. This way we do not need to worry ourselves with
making sure all the sounds stop when someone pauses the game. When we associate a
sound with the Music category the Xbox 360 can mute that and replace it with the
playlist the gamer has his or her console playing at the time. This is a really nice feature
because no matter how good our soundtrack is, at some point gamers will most likely
want to play our games with their own music in the background.

Texturing 3D Models

2008-04-04T21:05:00.001-07:00

Now, let’s replace that texture with one we will load on the fly. We could just modify our
texture resource if we wanted to, but let’s assume that we want to keep that intact and as
we load different asteroids we want some to use that brownish texture and some to use
our newly created texture, on which we will simply remove the color. So let’s fire up our
favorite paint program and open up the .tga file and turn it into a grayscale image. If
needed, the image asteroid1-grey.tga can be taken from the CD in this chapter’s source
code. Let’s add our newly created image into our Solution Explorer (or we can just include
it into our project if we saved the new version in our /Textures/ subfolder from our paint
program).
Add the following code in our LoadGraphicsContent method:
originalAsteroid = content.Load(@”Content\Textures\asteroid1“);
greyAsteroid = content.Load(@”Content\Textures\asteroid1-grey”);
Just like adding our model, we can add our texture asset very easily. Of course, now we
have to actually declare our private member field:
private Texture2D originalAsteroid;
private Texture2D greyAsteroid;
Now we can make a couple of changes to our DrawModel method. We need to add in
another parameter of type Texture2D and call it texture. We also need to actually set our
effect to use that texture if it was passed in, which can be seen in the following code:
if (texture != null)
be.Texture = texture;
This code statement is inside of the inner foreach loop with the rest of the code that sets
the properties of our basic effect that is being used by our model. We are simply checking
to see if null is passed in; if not, we are setting the texture of the effect. As we saw earlier,
the effect is getting applied to the mesh of our model, so we only need to modify our call
to our DrawModel to pass in the new texture. We will go ahead and just create another
asteroid on our screen by replacing our current drawing code with the following:
world = Matrix.CreateTranslation(new Vector3(0, 0, -4000));
DrawModel(ref model, ref world, greyAsteroid);
world = Matrix.CreateTranslation(new Vector3(0, 0, 4000));
DrawModel(ref model, ref world, originalAsteroid);
The first line did not change, but it is added here for readability purposes. The second
statement we are actually passing in is our new texture. The last two statements are
placing another asteroid behind us and resetting the texture to the original one. We can
run this program and spin our camera to see both asteroids being drawn.
120 CHAPTER 6 Loading and Texturing 3D Objects
Now, let’s apply some transformations to our asteroids. We can add some rotation to get
them to do a little more than they are right now. To do this, we just need to replace our
Draw code with the following:
world = Matrix.CreateRotationY(MathHelper.ToRadians(
270.0f * (float)gameTime.TotalGameTime.TotalSeconds)) *
Matrix.CreateTranslation(new Vector3(0, 0, -4000));
DrawModel(ref model, ref world, greyAsteroid);
world = Matrix.CreateRotationY(MathHelper.ToRadians(
45.0f * (float)gameTime.TotalGameTime.TotalSeconds)) *
Matrix.CreateRotationZ(MathHelper.ToRadians(
45.0f * (float)gameTime.TotalGameTime.TotalSeconds)) *
Matrix.CreateTranslation(new Vector3(0, 0, 4000));
DrawModel(ref model, ref world, originalAsteroid);
Even with the code broken to fit on the page, we can still see that we only have four
statements, just like before. The only two that changed are our code that modified the
world matrix. This makes sense because we want to rotate our asteroids. We start by
looking at our first world transformation and can see that we are simply rotating it
around the y axis by 270 degrees * the number of seconds our game has been running.
This effectively makes it continuously render every frame. After rotating we still translate
it like we did before, moving it 4,000 units into our world. The second world transformation
is similar except we are only rotating by 45 degrees instead of 270 degrees. We are
also rotating around the x axis by the same amount. This should give us a decent wobble
effect. Finally we are translating 4,000 units behind us just like before. We can compile
and run our program and see our asteroids are moving (well, rotating in place).

Loading 3D Models

2008-04-04T21:04:00.002-07:00

The XNA Framework’s Content Pipeline handles loading .X and .FBX files automatically
when they are pasted into the Solution Explorer (or included in the project). This is when
the Content Pipeline goes through the process described in the previous section of
importing, processing, and compiling the data. We then can use our game class and the
Content Manager to read the model information.
We will start by creating a new project, which we can call Load3DObject. We can create
both the Windows and Xbox 360 game projects. After getting our solution set up, we can
then add an existing project to our solution—the XELibrary from last chapter. Once we
import both the Windows and the Xbox 360 XELibrary projects, we need to reference
them inside of the game projects we created. We reference the XELibrary in our Windows
project and the XELibrary_Xbox360 in our Xbox 360 game project.
After we have our initial setup of our solution file completed, we can jump right in and
add a using statement at the top of our Game1.cs class to access our library:
using XELibrary;
We can set up our private member fields to access the game components in our library:
private FPS fps;
private FirstPersonCamera camera;
private InputHandler input;
The following is our constructor, where we initialize the variables we just set:
public Game1()
{
graphics = new GraphicsDeviceManager(this);
content = new ContentManager(Services);
input = new InputHandler(this);
Components.Add(input);
camera = new FirstPersonCamera(this);
Components.Add(camera);
#if DEBUG
//draw 60 fps and update as often as possible
fps = new FPS(this, true, false);
#else
fps = new FPS(this, true, false);
#endif
Components.Add(fps);
}
With just that little bit of coding (and setup) we now have access to all of the code in our
library. We automatically have a first person camera now and we can handle input as well
as display our frame rate. Game components aren’t too shabby.
As we add content to our pipeline we could pretty easily clutter up our Solution Explorer
pane with all of the files. To help alleviate that problem, we are going to create a
Contents folder with subfolders under it. To start, we will add two subfolders—Models
and Textures—under the Content folder. This is not required, but it really helps keep the
clutter minimal. After doing this we will need to make sure we include that folder inside
Loading 3D Models 115
6
of our Xbox 360 solution, otherwise the content files won’t compile and won’t be
deployed and will cause the demo to not load.
Now with the preliminary work out of the way, we can actually get down to business and
load a 3D object. Find the Spacewar project that we extracted back in Chapter 1,
“Introducing the XNA Framework and XNA Game Studio Express,” and under the
Contents\Models\ folder we need to copy the asteroid1.x file and copy it into our
Solution Explorer’s Contents\Models\ folder. When we do this, XNA Game Studio
Express flags it as XNA Framework Content. Now we can compile the code, which will
also kick off the Content Pipeline. The Content Pipeline kicked off the Content Importer,
shoved the data into the DOM, and then called the Content Processor, which passed it to
the Content Compiler. So when we compile our game, it not only compiles our code, but
also the content.
The Content Compiler threw an error, “Missing asset … \Content\Textures\asteroid1.tga,”
because the .X file we loaded has a reference to a texture inside of it. It references a sibling
folder by the name of Textures. The following is a portion of the asteroid1.x file where it
references the texture in the texture’s sibling folder:
Material phong1SG {
1.0;1.0;1.0;1.000000;;
18.000000;
0.000000;0.000000;0.000000;;
0.000000;0.000000;0.000000;;
TextureFilename {
“..\\textures\\asteroid1.tga”;
}
}
We have that folder, but we did not grab the .tga texture from the Spacewar project. Let’s
do that now and paste it into our Textures folder. Once we do this we can compile again
and it should compile without issues. After it compiles successfully, we can browse to our
/bin/x86/content/models/ and /textures/ folders to see there are a couple of files that were
created at the time we compiled. The Content Compiler took the files and compiled them
into the .xnb files we see here. The compiler gave us an error when it could not find the
texture that was associated with the .X file. We have corrected that and our code (and
content) now compiles successfully.
We could run the code but nothing would be on our screen because we have not actually
told XNA to load and draw the object. We can get that ball rolling by creating a private
member field in our Game1.cs class as follows:
private Model model;
Now we can initialize this variable by actually loading our model in our code. We do this
inside of the LoadGraphicsContent method. The following code has the entire method:
116 CHAPTER 6 Loading and Texturing 3D Objects
protected override void LoadGraphicsContent(bool loadAllContent)
{
if (loadAllContent)
{
// TODO: Load any ResourceManagementMode.Automatic content
model = content.Load(@”Content\Models\asteroid1”);
}
// TODO: Load any ResourceManagementMode.Manual content
}
The only line we added was the statement inside of the condition, but it is important to
discuss this entire method, as we have just breezed over it in the past chapters. This
method is where we will load all of our graphics content. We have two options when we
load our content: We can let XNA handle the memory management of the resources automatically
by loading our content inside of the condition or we can maintain the memory
management ourselves. This method as well as its counterpart, UnloadGraphicsContent,
gets called at appropriate times. What are these appropriate times? This is a good time to
discuss the logic flow of XNA.
The XNA Framework’s logic flow works something like this:
1. The Main application calls the Game Constructor.
2. The Game Constructor will create any game components and call their constructors.
3. The XNA Framework calls the game’s Initialize method.
4. The XNA Framework calls each of the game component’s Initialize methods.
5. The XNA Framework calls each of the Drawable game component’s
LoadGraphicsContent methods.
6. The XNA Framework calls the game’s LoadGraphicsContent method.
7. The XNA Framework calls the game’s Update method.
8. The XNA Framework calls each of the game component’s Update methods.
9. The XNA Framework calls the game’s Draw method.
10. The XNA Framework calls each of the Drawable game component’s Draw methods.
11. Steps 7 through 10 are repeated many times each second.
12. If the device is lost (user moved the window to another monitor, screen resolution
is changed, window is minimized, etc.) then a call to UnloadGraphicsContent is
made.
13. If the device is reset then we start back at step 6 again.
14. The gamer exits the game.
15. The XNA Framework calls the game’s Dispose method.
Loading 3D Models 117
6
16. The game’s Dispose method calls the base object’s Dispose method, which causes …
17. The XNA Framework calls each of the game component’s Dispose methods.
18. The XNA Framework calls the game’s UnloadGraphicsContent method.
19. The game’s Dispose method gets focus back and the game exits.
Something to note about how the XNA Framework calls the game component’s
Initialize method (and LoadGraphicsContent for drawable game components) is this
only happens once when the game’s Initialize method is kicked off by the framework.
If game components are added later, their Initialize (and LoadGraphicsContent)
methods will not be called. This is important to understand when managing game
components.
At this point we have loaded our 3D content. We have created a private member field to
store the model we added. We actually loaded our model in our code and initialized our
variable. Now we just need to draw the model on the screen. We need to add the following
method to draw a model:
private void DrawModel(ref Model m, ref Matrix world)
{
Matrix[] transforms = new Matrix[m.Bones.Count];
m.CopyAbsoluteBoneTransformsTo(transforms);
foreach (ModelMesh mesh in m.Meshes)
{
foreach (BasicEffect be in mesh.Effects)
{
be.EnableDefaultLighting();
be.Projection = camera.Projection;
be.View = camera.View;
be.World = world * mesh.ParentBone.Transform;
}
mesh.Draw();
}
}
Our DrawModel method takes in a reference to our model as well as a reference to the world
matrix we need to apply to our model. The first two statements get the transforms of each
bone in the model. A model can have a parent bone with children bones associated with
it. This is mainly used in animations, but even if a model does not have animations it
might still have bones and so our code should include this unless we know for certain that
our model does not have any children. The transforms array will contain a transformation
matrix of each mesh of the model that contains its position relative to the parent. By
doing this, we can make sure that each ModelMesh of the parent Model will be drawn at the
right location. This actually happens in the last statement inside of our inner foreach loop.
118 CHAPTER 6 Loading and Texturing 3D Objects
We take the world matrix that the mesh is supposed to be transformed with and we multiply
that transformation with the ModelMesh’s parent’s transformation. This is to make sure
that that each ModelMesh is drawn correctly with the parent mesh.
We did not need to create our own BasicEffect object as XNA will apply one to a mesh
we load. We can override this and will see that in Part V of the book when we talk about
the High Level Shader Language and make our own effect files. For now, we just ensure
that the default lighting is enabled on the effect as well as setting our projection and view
matrices to what our Camera game component has updated it to be. When we did this in
the last chapter, we only moved where we are setting those values. Instead of having an
effect that we are explicitly calling, we are tying into the one that XNA applies to the
Model when it loads it. This is also happening inside of the inner foreach loop so we
could apply different effects to children meshes if we wanted to.
The other thing to notice is the fact that we did not reference our texture anywhere. Because
it was inside of the .X file and the Content Compiler stored that information, the Content
Manager knew where to look for the texture and load it automatically. We will see how to
override the texture through code a little later in this chapter. Let’s just get it to draw with
the normal texture for now! To do that, we need to actually call our DrawModel method
inside of our Draw method with the following code:
world = Matrix.CreateTranslation(new Vector3(0,0,-4000));
DrawModel(ref model, ref world);
The model we are loading is rather large and as such we are going to push it way back
into the world. In fact, we made a modification to our Camera class in our XELibrary. We
originally had our near and far planes set up as 0.0001 and 1000.0, respectively. The thing
about the plane values is that they are floating points, which means there is a finite
amount of precision we can have. We can either have the precision before the decimal
point or after the decimal point, but not both. A lot of times programmers will set the far
plane to a very high number but when that happens the depth buffer (also known as a z
buffer) could have a hard time knowing which objects to draw first. As a result during
game play the screen will almost flicker as different vertices are fighting to be drawn first
and the z buffer is confused because it cannot take into account the minor differences in
the locations of those vertices. Of course, the .0001 near plan we originally had set was
not exactly practical either. At this point having a near plane of 1 and a far plane of
10,000 should meet most of our needs without overly stressing our z buffer. We could
have our far plane even further without causing an adverse effect on the depth buffer.
Finally, we need to create our private member world field that we referenced:
private Matrix world;
Now we can compile and run our code and we should see our asteroid object sitting right
in front of us. This is not extremely exciting, but we have just successfully drawn a .X
model complete with a texture.

Understanding the Content Pipeline

2008-04-04T21:04:00.001-07:00

The Content Pipeline can be used to solve a very real
problem: The content we create for games is typically not
game ready. For example, 3D content is usually stored in a
proprietary format and there is a need to convert the data
before loading it into the game. This is where Content
Pipeline helps out. In general, it can take different files as
input, massage them to get them into a type that we can
work with, and then compile them into a format that can
easily be loaded when our game starts.
The XNA Framework Content Pipeline is made up of
several components. First is the Content Importer, which is
responsible for reading the data that is loaded into the
solution. If there is data in the file the Content Importer
does not know how to map to the content DOM, then the
data is not stored. It only keeps the data it cares about.
Once the importer is done reading in the data, it passes it
along to the Content DOM, which stores the strongly
typed data. It is then passed from the Content DOM to a
Content Processor, which then passes it to a Content
Compiler. If the compilation fails we get a nice message
inside of the IDE that tells us what happened: We do not
114 CHAPTER 6 Loading and Texturing 3D Objects
have to wait and see if it is going to load at runtime, and this is a huge improvement over
how things used to work. The compiler actually builds files that are read in at runtime.
These files typically have an .xnb file extension. Audio files actually create .xgs, .xwb, and
.xsb files for the actual sound project, wave bank, and sound bank content. We discuss
the sound and how it relates to the Content Pipeline in the next chapter. The Content
Pipeline is smart enough to not recompile any content that has not changed since the
last build. Finally, after all of the content is compiled into files, they are read in via the
Content Manager at runtime so our games can consume the content. We have been using
the Content Manager since our very first application in Chapter 2, “XNA and the Xbox
360.” We created an instance to the Content Manager in our game’s constructor like the
following:
content = new ContentManager(Services);
Fortunately, when we use the Content Manager we do not need to actually dispose of our
objects, as it handles disposing of our content itself. It does this in the following code,
which is always included in our new game projects:
protected override void UnloadGraphicsContent(bool unloadAllContent)
{
if (unloadAllContent == true)
{
content.Unload();
}
}
The code simply calls the Unload method on the instance of the content manager. This
then goes through each of the objects that have been loaded and disposes of them. We
discuss the counter part of this method in the next section. The LoadGraphicsContent
method does the actual loading of the data.
As we add content to our project that is recognizable as XNA Framework content, it goes
through the process just described. The Properties window inside of the Visual C# Express
IDE will show an asset name that we can modify. If we add content types that are not
recognized, we can change the XNA Framework Content boolean value to true. We would
then need to fill in the Content Importer and Content Processor properties, specifying
how to turn the unknown content type into a format that XNA can recognize. This
would require a custom importer and processor that we discuss building in Chapter 8,
“Extending the Content Pipeline,” where we will learn about extending the pipeline.

Creating a Split Screen

2008-04-04T21:03:00.000-07:00

Now that we know how to set up our camera and accept input, we can look into how our
code will need to change to handle multiple players in a split-screen game. To start, we
need to make a copy of the InputDemo project we just finished. We can rename the
project SplitScreen. After we have our solution and projects renamed (complete with our
assembly GUID and title) we can look at the code we will need to change to accomplish a
split-screen mode of play.
To create a split screen, we need to two different viewports. We have only been using one
up until now and we actually retrieved it in our camera’s Initialization method. We
simply grabbed the GraphicsDevice.Viewport property to get our camera’s viewport.
Because we want to display two screens in one we need to define our two new viewports
and then let the cameras (we will need two cameras) know about them so we can get the
desired effect. To start we will need to add the following private member fields to our
Game1.cs code:
private Viewport defaultViewport;
private Viewport topViewport;
private Viewport bottomViewport;
private separatorViewport;
private bool twoPlayers = true;
private FirstPersonCamera camera2;
Then at the end of our LoadGraphicsContent method we will need to define those viewports
and create our cameras and pass the new values. We do this in the following code:
if (twoPlayers)
{
defaultViewport = graphics.GraphicsDevice.Viewport;
topViewport = defaultViewport;
bottomViewport = defaultViewport;
topViewport.Height = topViewport.Height / 2;
separatorViewport.Y = topViewport.Height – 1;
separatorViewport.Height = 3;
bottomViewport.Y = topViewport.Height + 1;
bottomViewport.Height = (bottomViewport.Height / 2) - 1;
camera.Viewport = topViewport;
106 CHAPTER 5 Input Devices and Cameras
camera2 = new FirstPersonCamera(this);
camera2.Viewport = bottomViewport;
camera2.Position = new Vector3(0.0f, 0.0f, -3.0f);
camera2.Orientation = new Vector3(0.0f, 0.0f, 1.0f);
camera2.PlayerIndex = PlayerIndex.Two;
Components.Add(camera2);
}
We discussed briefly that we would need more than one camera to pull this off. This is
because we have our view and projection matrices associated with our camera class
(which we should). It makes sense that we will have two cameras because the camera is
showing what the player is seeing. Each player needs his or her own view into the game.
Our initial camera is still set up in our game’s constructor but our second camera will get
added here. Our first camera gets the default viewport associated with it. The first thing
the preceding code is doing is checking to see if we are in a two-player game. For a real
game, this should be determined by an options menu or something similar, but for now
we have just initialized the value to true when we initialized the twoPlayer variable.
Inside of the two-player condition the first thing we do is set our default viewport to what
we are currently using (the graphic device’s viewport). Then we set our top viewport to
the same value. We also initialize our bottomViewport to our defaultViewport value. The
final thing we do with our viewports is resize them to account for two players. We divide
the height in two (we are making two horizontal viewports) on both. We then set our
bottom viewport’s Y property to be one more than the height of our bottom. This effectively
puts the bottom viewport right underneath our top viewport.
While still in the two-player condition we change our first camera’s viewport to use the
top viewport. Then we set up our second camera by setting more properties. Not only
do we set the viewport for this camera to the bottom viewport we have, but we also
set a new camera position as well as the orientation of the camera. Finally, we set the
player index.
None of these properties is exposed from our camera object, so we need to open our
Camera.cs file and make some changes to account for this. First, we need to add a new
private member field to hold our player index. We just assumed it was player 1 before. We
can set up our protected (so our FirstPersonCamera class can access it) index as an
integer as follows:
protected int playerIndex = 0;
Now, we can actually modify our input code that controls our camera to use this index
instead of the hard-coded value 0 for our game pads. In the camera’s Update method we
can change any instance of input.GamePads[0] to input.GamePads[playerIndex]. We also
need to do the same for the FirstPersonCamera object. We did not update the keyboard
code and will not for the sake of time. However, to implement multiple users where both
can use the keyboard we should create a mapping for each player and check accordingly.
In general, it is a good practice to have a keyboard mapping so that if gamers do not like
Creating a Split Screen 107
5
the controls we have defined in our games then they have a way to change them so it
works more logically for them. The same can be said about creating a mapping for the
game pads but many games simply give a choice of a couple of layouts. Because the code
does not implement a keyboard mapping, the only way for us to control the separate
screens differently is by having two game pads hooked up to our PC or Xbox 360.
After we have changed our camera to take the player index into consideration before
reading values from our game pad, we can add the following properties to our code:
public PlayerIndex PlayerIndex
{
get { return ((PlayerIndex)playerIndex); }
set { playerIndex = (int)value; }
}
public Vector3 Position
{
get { return (cameraPosition); }
set { cameraPosition = value; }
}
public Vector3 Orientation
{
get { return (cameraReference); }
set { cameraReference = value; }
}
public Vector3 Target
{
get { return (cameraTarget); }
set { cameraTarget = value; }
}
public Viewport Viewport
{
get
{
if (viewport == null)
viewport = graphics.GraphicsDevice.Viewport;
return ((Viewport)viewport);
}
set
{
viewport = value;
InitializeCamera();
}
}
108 CHAPTER 5 Input Devices and Cameras
We are simply exposing the camera’s position, orientation (reference), and target variables.
For the player index property we are casting it to a PlayerIndex enumeration type.
The final property is the Viewport property. We first check to see if our viewport variable
is null and if so we set it to the graphics device’s viewport. When we set our Viewport
property, we also call our InitializeCamera method again so it can recalculate its view
and projection matrices. We need to set up a private member field for our viewport. We
will allow it to have a default null value so we can declare it as follows:
private Viewport? viewport;
Because we are utilizing the Viewport type we will need to add the following using statement
to our code:
using Microsoft.Xna.Framework.Graphics;
The only thing left for us to do now is to actually update our game’s drawing code to
draw our scene twice. Because we are going to have to draw our scene twice (once for
each camera) we will need to refactor our Draw code into a DrawScene method and pass in
a camera reference. Our new code for the new Draw method is as follows:
protected override void Draw(GameTime gameTime)
{
graphics.GraphicsDevice.Viewport = camera.Viewport;
DrawScene(gameTime, camera);
if (twoPlayers)
{
graphics.GraphicsDevice.Viewport = camera2.Viewport;
DrawScene(gameTime, camera2);
//now clear the thick horizontal line between the two screens
graphics.GraphicsDevice.Viewport = separatorViewport;
graphics.GraphicsDevice.Clear(Color.Black);
}
base.Draw(gameTime);
}
We took all of the code that was inside of this method and put it into a new method
DrawScene(GameTime gameTime, Camera camera). The code we put into the DrawScene
method did not change from how it looked when it resided inside of the Draw method.
The first thing we do with the preceding code is set our graphics device’s viewport to be
what our camera’s viewport is. We then draw the scene passing in our camera. Then we
check to see if we have two players; if so we set the viewport appropriately and finally
draw the scene for that camera. We can run our application and see that it is using a split
screen! The screen shot of this split screen demo can be seen in Figure 5.1.
Creating a Split Screen 109

Creating a First Person Camera

2008-04-04T21:02:00.000-07:00

We can build on our stationary camera by adding a first person camera. The main thing
we want to do is to add in a way to move back and forth and to each side. Before we
start, we should create a new camera class and inherit from the one we have. We can call
this new class FirstPersonCamera. The following is the Update method for this new class:
public override void Update(GameTime gameTime)
{
// TODO: Add your update code here
//reset movement vector
movement = Vector3.Zero;
if (input.KeyboardState.IsKeyDown(Keys.A) ||
(input.GamePads[0].ThumbSticks.Left.X < 0))
{
movement.X—;
Creating a First Person Camera 103
3
LISTING 5.1 Continued
}
if (input.KeyboardState.IsKeyDown(Keys.D) ||
(input.GamePads[0].ThumbSticks.Left.X > 0))
{
movement.X++;
}
if (input.KeyboardState.IsKeyDown(Keys.S) ||
(input.GamePads[0].ThumbSticks.Left.Y < 0))
{
movement.Z++;
}
if (input.KeyboardState.IsKeyDown(Keys.W) ||
(input.GamePads[0].ThumbSticks.Left.Y > 0))
{
movement.Z—;
}
//make sure we don’t increase speed if pushing up and over (diagonal)
if (movement.LengthSquared() != 0)
movement.Normalize();
base.Update(gameTime);
}
The conditional logic should look familiar. It is identical to our stationary camera, except
we changed where we were reading the input and what values it updated. We are reading
the A, S, W, D keys and the left thumb stick. We are not looking at the mouse for movement.
The value we are setting is a movement vector. We are only setting the X (left and
right) and Z (back and forth) values. At the end of the conditions we are normalizing our
vector as long as the length squared of the vector is not zero. This makes sure that we are
not allowing faster movement just because the user is moving diagonally. There is no
more code in the FirstPersonCamera object. The rest of the changes were made back on
our original camera object.
We declared the movement as a protected member field of type Vector3 called movement
inside of our original Camera object. We also declared a constant value for our movement
speed. Both of these are listed here:
protected Vector3 movement = Vector3.Zero;
private const float moveRate = 120.0f;
We also set the access modifier of our input field to protected so our FirstPersonCamera
could access it:
protected IInputHandler input;
104 CHAPTER 5 Input Devices and Cameras
Finally we updated the last part of our Update method to take the movement into
account when transforming our camera:
//update movement (none for this base class)
movement *= (moveRate * timeDelta);
Matrix rotationMatrix;
Vector3 transformedReference;
Matrix.CreateRotationY(MathHelper.ToRadians(cameraYaw), out rotationMatrix);
if (movement != Vector3.Zero)
{
Vector3.Transform(ref movement, ref rotationMatrix, out movement);
cameraPosition += movement;
}
//add in pitch to the rotation
rotationMatrix = Matrix.CreateRotationX(MathHelper.ToRadians(cameraPitch)) *
rotationMatrix;
// Create a vector pointing the direction the camera is facing.
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
Vector3.Add(ref cameraPosition, ref transformedReference, out cameraTarget);
Matrix.CreateLookAt(ref cameraPosition, ref cameraTarget, ref cameraUpVector,
out view);
Besides just moving our local variables closer together, the only things that changed are
the items in bold type. We take our movement vector and apply our move rate to it
(taking into account our time delta, of course). The second portion is the key. We transformed
our movement vector by our rotation matrix. This keeps us from just looking in a
direction but continuing to move straight ahead. By transforming our movement vector
by our rotation matrix we actually move in the direction we are looking! Well, the movement
actually happens in the next statement when we add this movement vector to our
current camera position. We wrapped all of this in a condition to see if any movement
happened because we do not want to take a performance hit to do the math if we did not
move.
Another thing to note is that because we were creating a first person camera we only
transformed our movement vector by the yaw portion of our rotation matrix. We did
not include the pitch, as that would have allowed us to “fly.” If we did want to create a
flying camera instead, we could simply move this following statement before the code
that is bold:
105
5
//add in pitch to the rotation
rotationMatrix = Matrix.CreateRotationX(MathHelper.ToRadians(cameraPitch)) *
rotationMatrix;

Creating a Stationary Camera

2008-04-03T21:42:00.001-07:00

Now that we know how to utilize our input, we can get working on implementing our
stationary camera. We actually have most of this done, but we need to add pitching as
well as the yaw we already have. One use for a stationary camera is to look at an object
and follow it by rotating as needed. This is commonly used in racing game replay mode.
Before we dig into the camera changes, though, let’s add a few more rectangles to our
world. We can do this by adding the following code to the end of our demo’s Update
method:
world = Matrix.CreateTranslation(new Vector3(8.0f, 0, -10.0f));
DrawRectangle(ref world);
world = Matrix.CreateTranslation(new Vector3(8.0f, 0, -6.0f));
DrawRectangle(ref world);
world = Matrix.CreateRotationY(Matrix.CreateTranslation(new Vector3(3.0f, 0, 10.0f));
DrawRectangle(ref world);
We should also change our cull mode to None so that as we rotate around that we will
always see our rectangles. We can do that by calling the following code at the top of our
game’s Draw method:
graphics.GraphicsDevice.RenderState.CullMode = CullMode.None;
To get our camera updated we need to modify our camera class a little bit. First we need
to declare a private member field as follows:
private float cameraPitch = 0.0f;
Now we can modify the Update method to set our camera pitch. Remember, pitching
refers to rotating around the x axis. To calculate this we simply take the code we did for
calculating the yaw and replace our reference to the y axis with the x axis. The following
is the code to check our keyboard and game pad:
if (input.KeyboardState.IsKeyDown(Keys.Down) ||
(input.GamePads[0].ThumbSticks.Right.Y < 0))
{
cameraPitch -= (spinRate * timeDelta);
}
if (input.KeyboardState.IsKeyDown(Keys.Up) ||
(input.GamePads[0].ThumbSticks.Right.Y > 0))
{
cameraPitch += (spinRate * timeDelta);
}
100 CHAPTER 5 Input Devices and Cameras
No surprises there, and we need to do the same thing with our mouse code. Inside of the
#if !XBOX360 compilation directive we already have we can add the following code:
if ((input.PreviousMouseState.Y > input.MouseState.Y) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraPitch += (spinRate * timeDelta);
}
else if ((input.PreviousMouseState.Y < input.MouseState.Y) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraPitch -= (spinRate * timeDelta);
}
We want to clamp our values so we do not rotate over 90 degrees in either direction:
if (cameraPitch > 89)
cameraPitch = 89;
if (cameraPitch < -89)
cameraPitch = -89;
Finally, we need to update our rotation matrix to include our pitch value. Here is the
updated calculation:
Matrix rotationMatrix;
Matrix.CreateRotationY(MathHelper.ToRadians(cameraYaw), out rotationMatrix);
//add in pitch to the rotation
rotationMatrix = Matrix.CreateRotationX(MathHelper.ToRadians(cameraPitch)) *
rotationMatrix;
The last statement is the only thing we added. We just added our pitch to the rotation
matrix that was already being used to transform our camera. The full Update listing can
be found in Listing 5.1.
LISTING 5.1 Our stationary camera’ s Update method
public override void Update(GameTime gameTime)
{
float timeDelta = (float)gameTime.ElapsedGameTime.TotalSeconds;
if (input.KeyboardState.IsKeyDown(Keys.Left) ||
(input.GamePads[0].ThumbSticks.Right.X < 0))
{
cameraYaw += (spinRate * timeDelta);
}
if (input.KeyboardState.IsKeyDown(Keys.Right) ||
(input.GamePads[0].ThumbSticks.Right.X > 0))
Creating a Stationary Camera 101
5
{
cameraYaw -= (spinRate * timeDelta);
}
if (input.KeyboardState.IsKeyDown(Keys.Down) ||
(input.GamePads[0].ThumbSticks.Right.Y < 0))
{
cameraPitch -= (spinRate * timeDelta);
}
if (input.KeyboardState.IsKeyDown(Keys.Up) ||
(input.GamePads[0].ThumbSticks.Right.Y > 0))
{
cameraPitch += (spinRate * timeDelta);
}
#if !XBOX360
if ((input.PreviousMouseState.X > input.MouseState.X) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraYaw += (spinRate * timeDelta);
}
else if ((input.PreviousMouseState.X < input.MouseState.X) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraYaw -= (spinRate * timeDelta);
}
if ((input.PreviousMouseState.Y > input.MouseState.Y) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraPitch += (spinRate * timeDelta);
}
else if ((input.PreviousMouseState.Y < input.MouseState.Y) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraPitch -= (spinRate * timeDelta);
}
#endif
//reset camera angle if needed
if (cameraYaw > 360)
cameraYaw -= 360;
else if (cameraYaw < 0)
102 CHAPTER 5 Input Devices and Cameras
LISTING 5.1 Continued
cameraYaw += 360;
//keep camera from rotating a full 90 degrees in either direction
if (cameraPitch > 89)
cameraPitch = 89;
if (cameraPitch < -89)
cameraPitch = -89;
Matrix rotationMatrix;
Matrix.CreateRotationY(MathHelper.ToRadians(cameraYaw),
out rotationMatrix);
//add in pitch to the rotation
rotationMatrix = Matrix.CreateRotationX(MathHelper.ToRadians(cameraPitch))
* rotationMatrix;
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference;
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
Vector3.Add(ref cameraPosition, ref transformedReference, out cameraTarget);
Matrix.CreateLookAt(ref cameraPosition, ref cameraTarget, ref cameraUpVector,
out view);
base.Update(gameTime);
}

Working with mouse Devices

2008-04-03T21:41:00.001-07:00

This input device is only available for Windows, so if we are deploying our game for the
Xbox 360 we will need to put the XBOX360 compilation directive check we learned about
in Chapter 2 around any code that references the mouse as an input device. So we will
create a private member field with this preprocessor check inside of our InputHandler
class. We need to set up a private member field to hold our previous mouse state and
another one to hold our current mouse state:
#if !XBOX360
private MouseState mouseState;
private MouseState prevMouseState;
#endif
Then in our constructor we tell XNA that we want the mouse icon visible in our window
and we store our current mouse state:
#if !XBOX360
Game.IsMouseVisible = true;
prevMouseState = Mouse.GetState();
#endif
In our Update method of the input handler game component we need to set the previous
state to what our current state is and then reset our current state as follows:
#if !XBOX360
prevMouseState = mouseState;
mouseState = Mouse.GetState();
#endif
98 CHAPTER 5 Input Devices and Cameras
Now we need to expose these internal fields so our camera (and any other) object can get
their values. First we need to add the properties to our interface as follows:
#if !XBOX360
MouseState MouseState { get; }
MouseState PreviousMouseState { get; }
#endif
Now we can implement those properties in our class:
#if !XBOX360
public MouseState MouseState
{
get { return(mouseState); }
}
public MouseState PreviousMouseState
{
get { return(prevMouseState); }
}
#endif
In our camera’s Update method we want to get the latest state of our mouse and compare
the current X value to the previous X value to determine if we moved the mouse left or
right. We also want to check if the left mouse button is pushed before updating our
cameraYaw variable. Of course, all of this is wrapped in our compilation preprocessor
condition as follows:
#if !XBOX360
if ((input.PreviousMouseState.X > input.MouseState.X) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraYaw += (spinRate * timeDelta);
}
else if ((input.PreviousMouseState.X < input.MouseState.X) &&
(input.MouseState.LeftButton == ButtonState.Pressed))
{
cameraYaw -= (spinRate * timeDelta);
}
#endif
We can compile and run the code and test the latest functionality on Windows. If the
preprocessor checks are in place correctly, we should be able to deploy this demo to the
Xbox 360 as well, although it will not do anything different than it did before we added
the mouse support.

Working with gamepad Devices

2008-04-03T21:40:00.002-07:00

The Microsoft Xbox 360 wired controller works on the PC. XNA provides us with helper
classes that make it very easy to determine the state of our game pad. The template
already provided one call to the game pad helper class. This call is also in the Update
method. Let’s take a look at what is provided for us already.
if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
this.Exit();
The template is calling the built-in XNA class GamePad and calling its GetState method
passing in which player’s controller they want to check. The template then checks the
Back button on that controller to see if it has been pressed. If the controller’s Back button
has been pressed, the game exits. Now, that was pretty straightforward. To be consistent
we can use our input class to check for the condition.
Before we can do that, we need to update our interface and add the appropriate property
as well as actually getting the game pad state just like we did for our keyboard. Let’s jump
to our input handler code and do some of these things. We can start by adding a property
to get to our list of game pads in our interface:
GamePadState[] GamePads { get; }
Now we can create the member field and property to get that field like the following code:
private GamePadState[] gamePads = new GamePadState[4];
public GamePadState[] GamePads
{
get { return(gamePads); }
}
Working with Input Devices 95
5
We need to initialize each game pad state and can do that in the Update method of the
input handler object:
gamePads[0] = GamePad.GetState(PlayerIndex.One);
gamePads[1] = GamePad.GetState(PlayerIndex.Two);
gamePads[2] = GamePad.GetState(PlayerIndex.Three);
gamePads[3] = GamePad.GetState(PlayerIndex.Four);
Now, let’s remove the code that checks to see if the Back button is pressed on player one’s
game pad from our demo. We can add this code in the Update method of our
InputHandler game component to get the same effect:
if (gamePads[0].Buttons.Back == ButtonState.Pressed)
Game.Exit();
Let’s update our yaw rotation code inside of the camera game component so that we can
get the same result with our controller. We can modify our existing code that checks for
left and right to also handle input from our controller. So we modify our two conditional
statements that set the cameraYaw to also check the right thumb stick state of the game
pad we are examining:
if (input.KeyboardState.IsKeyDown(Keys.Left) ||
(input.GamePads[0].ThumbSticks.Right.X < 0))
{
cameraYaw += (spinRate * timeDelta);
}
if (input.KeyboardState.IsKeyDown(Keys.Right) ||
(input.GamePads[0].ThumbSticks.Right.X > 0))
{
cameraYaw -= (spinRate * timeDelta);
}
The thumb stick x and y axis provide a float value between -1 and 1. A value of 0 means
there is no movement. A value of -0.5 means the stick is pushed to the left halfway. A
value of 0.9 would be the stick is pushed to the right 90 percent of the way.
We did not change the keyboard code, we simply added another “or” condition to handle
our controller. We can see it is very simple, as we only needed to check the
ThumbSticks.Left property. We check the x axis of that joystick and if it is less than zero
the user is pushing the stick to the left. We check to see if it is positive (user pushing to
the right) in the second condition. We leave our cameraYaw variable to be set by our spin
rate (taking into account our time delta). At this point, regardless if players are using the
keyboard or the game pad they will get the same result from the game: The camera will
rotate around the y axis. Compile and run the program to try it out. We can also try the
game on the Xbox 360 because we have hooked up our game pad code.
At this point we know how to get access to any of the buttons (they are treated the same
way as the Back button) and either thumb stick but we have not discussed the D-pad yet.
96 CHAPTER 5 Input Devices and Cameras
The D-pad is actually treated like buttons. If we also wanted to allow the player to rotate
the camera left or right by using the D-pad, we simply need to add the following as part
of our condition:
gamePadState.DPad.Left == ButtonState.Pressed
Add that condition along with a check for the right D-Pad being pressed to our code.
Compile and run the code again and make sure that the demo allows us to look left or
right by using the keyboard, thumb stick, and D-pad. The code should now look like the
following:
if (keyboardState.IsKeyDown(Keys.Left) ||
(gamePadState.ThumbSticks.Right.X < 0) ||
(gamePadState.DPad.Left == ButtonState.Pressed))
{
cameraYaw += spinRate;
}
if (keyboardState.IsKeyDown(Keys.Right) ||
(gamePadState.ThumbSticks.Right.X > 0) ||
(gamePadState.DPad.Right == ButtonState.Pressed))
{
cameraYaw -= spinRate;
}
The shoulder buttons are just that—buttons—and we know how to handle those already.
We can determine when we press down on the left or right thumb stick because those are
also considered buttons. However, the final item we discuss regarding our game pad
controller is the triggers. Now, a good use of our triggers for this demo would be to turn
on vibration!
Before we actually determine how to use the triggers, we can look at another property of
the game pad state we have access to and that is if the controller is actually connected or
not. We can check this by getting the value of the IsConnected property.
The trigger values return a float between 0 and 1 to signify how much the trigger is
pressed (0 = not pressed; 1 = fully pressed). The Xbox 360 controller has two motors that
create its vibration. The motor on the left is a low-frequency motor whereas the motor on
the right is a high-frequency motor. We can set the values on both motors in the same
method call. We do this by calling the GamePad.SetVibration method. Because this is just
something we are doing for our demo and not really a part of the library, we will put this
code in our Game1.cs file inside the Update method:
if (input.GamePads[0].IsConnected)
{
GamePad.SetVibration(PlayerIndex.One, input.GamePads[0].Triggers.Left,
input.GamePads[0].Triggers.Right);
}
Working with Input Devices 97
5
The first thing we are doing with this new code is checking to see if the game pad is actually
connected. If it is connected then we set the vibration of both the left and right
motors based on how much the left and right triggers are being pressed. We are calling
the GamePad’s static SetVibration method. There is currently no benefit in wrapping
that into a method inside of our input handler.
We can also change the information being displayed in our window title bar to include
the left and right motor values. This can help you determine what values you should use
as you implement vibration in your games! The following is the code to accomplish that
task:
this.Window.Title = “left: “ +
input.GamePads[0].Triggers.Left.ToString() + “; right: “ +
input.GamePads[0].Triggers.Right.ToString();
Go ahead and add this debug line inside of the IsConnected condition and compile and
run the code to check the progress. We will no longer be able to see our frame rate with
this code so we could just comment out the fps object until we are ready to actually
check on our performance.

Working with keyboard Devices

2008-04-03T21:40:00.001-07:00

We will be populating the stub we created for handling our input. We are going to create
a stationary camera and a first person. Both of these cameras will need to respond to user
input. We need to learn how to handle input devices and utilize them to move our
camera and fully see the worlds we create.
Keyboard
The first input device we will talk about is the keyboard. XNA provides us with helper
classes that allow us to easily determine the state of our input devices. We determine the
state of our keyboard by declaring a variable to store our keyboard state and then calling
the GetState method on the Keyboard helper object. We can then query that variable to
determine which key (or keys) is being pressed or released. We can start by adding a
private member field to store our keyboard state. We do this via the following code inside
of our InputHandler game component:
private KeyboardState keyboardState;
Then we can find the Update method that was stubbed out for us when the InputHandler
game component was created.
keyboardState = Keyboard.GetState();
if (keyboardState.IsKeyDown(Keys.Escape))
Game.Exit();
We can put this at the very beginning of the Update method. We are simply storing the
state of the keyboard and then checking to see if the Escape key was pressed. If so, we
simply exit the program. It doesn’t get much simpler than that! So now when we run the
program we can exit by pressing the Escape key (instead of having to close the window
with our mouse).
Although being able to exit our game easily is important, we still haven’t done anything
exciting. Let’s set up our camera so we swivel back and forth if the left or right keys are
pressed. To do this we need to add and initialize a new private member field called
cameraReference inside of our Camera game component:
private Vector3 cameraReference = new Vector3(0.0f, 0.0f, -1.0f);
This camera reference direction will not change throughout the game, but we will be
passing it in as a reference so we cannot declare it as a readonly variable. Typically this
value will either be (0,0,1) or (0,0,-1). We chose to have a negative z value so we can
continue to have our camera face the same way.
Now that we have our camera reference direction set up, we need to apply any movement
and rotation to our view of the world. So if the player wants to look left and right we can
adjust our view matrix accordingly so that our view of the world is from a certain angle.
To look left and right we need to rotate around our y axis. We can add the following code
to our Update method right before our call out to the base object’s Update method (we are
still in our Camera class):
Working with Input Devices 91
5
Matrix rotationMatrix;
Matrix.CreateRotationY(MathHelper.ToRadians(cameraYaw), out rotationMatrix);
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference;
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
Vector3.Add(ref cameraPosition, ref transformedReference, out cameraTarget);
Matrix.CreateLookAt(ref cameraPosition, ref cameraTarget, ref cameraUpVector,
out view);
Because we know we will be rotating, we will create a matrix to hold our rotation. With a
helper function from XNA we will create a matrix with the appropriate values to rotate
our camera on the y axis by a certain number of degrees. We are storing that value in a
variable that we will set with our input devices. We will see how we set that value with
our keyboard soon. Once we have our matrix with all of the translations, scaling, and
rotations that we need (in this case we are only rotating) we can create a transform vector
that will allow us to change the target of the camera. We get this transformed vector by
using another XNA helper method, Vector3.Transform. We then add the transformed
camera reference to our camera position, which will give us our new camera target. To do
this, we could have used the plus (+) operator like the following code:
cameraTarget = cameraPosition + transformedReference;
However, it is much more efficient to use the built-in static Add method of the Vector3
struct because it allows us to pass our vectors by reference instead of having to copy the
values to memory. Finally, we reset our view with our new camera target. We also need to
set the following private member field that we used in the code:
private float cameraYaw = 0.0f;
Now we are to the point where we can compile the code, but our newly added code does
not do anything for us. This is because we are never changing our rotation angle. It stays
at 0 on every frame. Let’s change that now with our keyboard. Inside of our InputHandler
class, we need to update our IInputHandler interface to expose the keyboard state we
retrieved earlier. Let’s add the following code inside of our interface:
KeyboardState KeyboardState { get; }
Now, we need to implement that property inside of the class. An easy way to do this is to
right-click IInputHandler where we derived from it and select Implement Interface. We
will be doing this a couple of times and each time it will create a region so we will have
to clean up the code and remove the extra regions the IDE provides for us. Now we need
to change the get value to retrieve our internal keyboardState value as follows:
92 CHAPTER 5 Input Devices and Cameras
public KeyboardState KeyboardState
{
get { return(keyboardState); }
}
Now that we have exposed our keyboard state we can utilize it inside of our Camera
object. We need to add the following code to our Update method right above the previous
code inside of our camera object:
if (input.KeyboardState.IsKeyDown(Keys.Left))
cameraYaw += spinRate;
if (input.KeyboardState.IsKeyDown(Keys.Right))
cameraYaw -= spinRate;
if (cameraYaw > 360)
cameraYaw -= 360;
else if (cameraYaw < 0)
cameraYaw += 360;
We also need to make sure camera is using the XNA Framework’s Input namespace
because we are accessing the Keys enumeration:
using Microsoft.Xna.Framework.Input;
Finally, we add this constant to the top of our camera class:
private const float spinRate = 2.0f;
In our update code we utilized the current keyboard state we already captured and
checked to see if either the left arrow or right arrow on the keyboard was pressed. If the
player wants to rotate to the left then we add our spin rate constant to our current
camera yaw angle. (Yaw, pitch, and roll are terms borrowed from flight dynamics. Because
we are using a right-handed coordinate system, this means that yaw is rotation around
the y axis, pitch is rotation around the x axis, and roll is rotation around the z axis.) If
the player wants to rotate to the right then we subtract our spin rate constant from our
current camera yaw angle. Finally we just check to make sure that we do not have an
invalid rotation angle.
There is one last thing we need to do before we can run our code again. We need to actually
add our input handler game component to our game’s collection of components. We
can declare our member field as follows:
private InputHandler input;
Now we can actually initialize that variable and add it to the collection inside of our
constructor with this code:
input = new InputHandler(this);
Components.Add(input);
Working with Input Devices 93
5
We can compile and run the code and move knowing that our left and right arrows rotate
the camera. When running we can see that our objects are just flying by. It almost seems
they are blinking we are turning so fast. This is because we are calling our Update statement
as fast as possible. We can modify the game code where we are initializing our fps
variable to use a fixed time step:
fps = new FPS(this, false, true);
For the preceding code to work we need to add another constructor to our FPS code. We
are doing this is so we don’t need to actually pass in our target elapsed time value if we
want it to be the default.
public FPS(Game game, bool synchWithVerticalRetrace, bool isFixedTimeStep)
: this(game, synchWithVerticalRetrace, isFixedTimeStep,
game.TargetElapsedTime) { }
Now when we run the code we can see the objects move by at a consistent and slower
rate. This is because the Update method is now only getting called 60 times a second
instead of whatever rate our machine was running at.
We will notice, however, that as it renders the rectangles that our screen is “choppy.” The
reason is that we are not letting XNA only draw during our monitor’s vertical refresh. We
could do this by setting our second parameter to true and we would see the screen rotate
at a nice even pace with the screen drawing nicely. However, a better way to handle this
is by utilizing the elapsed time between calls to our methods. We need to retrieve the
elapsed time since the last time our Update method was called and then multiply our
spinRate by this delta of the time between calls. We will change the camera code snippet
to match the following:
float timeDelta = (float)gameTime.ElapsedGameTime.TotalSeconds;
if (input.KeyboardState.IsKeyDown(Keys.Left))
cameraYaw += (spinRate * timeDelta);
if (input.KeyboardState.IsKeyDown(Keys.Right))
cameraYaw -= (spinRate * timeDelta);
We can modify our game code to call the default constructor again:
fps = new FPS(this);
Now we are just creeping along. This is because our spin rate is so low. We had it low
because we were relying on the update method to be called 60 times per frame, so we
were basically rotating our camera 120 degrees per second. To get the same effect we
simply set our spinRate to 120. The reason is we are now multiplying it by the time
difference between calls. At this point we can safely set our units and know they will be
used on a per-second basis. Now that we have our spinRate utilizing the delta of the time
between calls we are safe to run at any frame rate and have our objects drawn correctly
based on the amount of time that has elapsed.
94 CHAPTER 5 Input Devices and Cameras
We can have it always run at 60 fps in release mode and run as fast as possible in debug
mode by modifying our game code as follows:
#if DEBUG
fps = new FPS(this);
#else
fps = new FPS(this, true, false);
#endif
This allows us to run as fast as we can in debug mode while consistently moving our
objects no matter the frame rate. It allows us to force XNA to only update the screen
during the monitor’s vertical retrace, which would drop us to 60 fps or whatever rate the
monitor is refreshing at.
Making a game update itself consistently regardless of the frame rate can make the game
more complex. We need to calculate the elapsed time (time delta) since the last frame and
use that value in all of our calculations. With the fixed step mode that XNA provides we
could cut down on development time and rely on the fact that the update code will be
called 60 times a second. This is not sufficient if we are writing a library that can be
plugged into games, as those games might not run at a consistent frame rate.

Textures

2008-04-03T21:35:00.000-07:00

We have a triangle finally drawn on the screen, but it does not look particularly
good. We can fix that by adding a texture. Copy the texture from the
Chapter4\XNADemo\XNADemo folder (texture.jpg) and paste that into our project.
This invokes the XNA Content Pipeline, which we discuss in Part III, “Content Pipeline”.
For now, we just need to know that it makes it available as loadable content complete
with a name by which we can access it. The asset will get the name “texture” (because that
is the name of the file). We need to declare a private member field to store our texture:
68 CHAPTER 4 Creating 3D Objects
private Texture2D texture;
We define our texture as a Texture2D object. This is another class that XNA provides for
us. Texture2D inherits from the Texture class, which allows us to manipulate a texture
resource. Now we need to actually load our texture into that variable. We do this in the
LoadGraphicsContent method. Inside of the loadAllContent condition, add this line of
code:
texture = content.Load(“texture”);
Now we have our texture added to our project and loaded into a variable (with very little
code), but we have yet to associate that texture to the effect that we used to draw the
triangle. We will do that now by adding the following two lines of code right before our
call to effect.Begin inside of our Draw method:
effect.TextureEnabled = true;
effect.Texture = texture;
This simply tells the effect we are using that we want to use textures, and then we actually
assign the texture to our effect. It is really that simple. Go ahead and compile and run
the code to see our nicely textured triangle!

Index Buffers

We have covered a lot of ground so far, but we aren’t done yet. We want to create a
rectangle on the screen and to do this we need another triangle. So that means we need
three more vertices, or do we? Actually, we only need one more vertex to create our
square because the second triangle we need to complete the square shares two of our existing
points already. Feel free to review a couple of sections earlier where we talked about
vertex buffers. We set up three points to make the triangle we just saw. To use the code as
is we would need to create another three points, but two of those points are redundant
and the amount of data it takes to represent the VertexPositionNormalTexture struct is
not minimal, so we do not want to duplicate all of that data if we do not need to.
Fortunately, we do not. XNA provides us with index buffers. Index buffers simply store
indices that correspond to our vertex buffer. So to resolve our current dilemma of not
wanting to duplicate our heavy vertex data we will instead duplicate our index data, which
is much smaller. Our vertex buffer will only store four points (instead of six) and our index
buffer will store six indices that will correspond to our vertices in the order we want them
to be drawn. We need to increase our vertex array to hold four values instead of three.
Make the following change:
vertices = new VertexPositionNormalTexture[4];
An index buffer simply describes the order in which we want the vertices in our vertex
buffer to be drawn in our scene.
Find the InitializeVertices method in our code and add the last point we need for our
rectangle. Try to do this before looking at the following code.
Index Buffers 69
4
//top right
position = new Vector3(1, 1, 0);
textureCoordinates = new Vector2(1, 0);
vertices[3] = new VertexPositionNormalTexture(position, Vector3.Forward,
textureCoordinates);
As you were writing the code, I imagine you were wondering about the texture coordinates
for the points. We finally talked about textures, but not really how we mapped the
texture to the vertices we created. We will take a moment and do that now before we
continue our understanding of index buffers.
Texture coordinates start at the top left at (0,0) and end at the bottom right at (1,1). The
bottom left texture coordinate is (0,1) and the top right is (1,0). Take a look at Figure 4.4
to see an example.

If we wanted to map a vertex to the bottom center pixel of a texture, what should the
values be? The horizontal axis is our x axis and the vertical axis is our y axis. We know we
need a 1 in our y coordinate to get to the very bottom of the texture. To get to the middle
of that bottom row, we would need to take the value in between 0 and 1, which is 0.5. So
if we wanted to map a vertex to the bottom center pixel of a texture, we would map it at
(0.5, 1). Back to our demo: Because the vertex we just added was the top right point of
the rectangle, the texture coordinate we assigned to it was (1,0).
Now that we have a better understanding of why our texture mapped to our triangle
correctly, we can get back to our index buffer. We have added a vertex to our code and
now we need to create an index buffer to reference these four points. We need to create
another private member field called indices:
private short[] indices;
Notice that we declared this as an array of short. We could have used int, but short takes
up less room and we aren’t going to have more than 65,535 indices in this demo. The
next thing we need to do is actually create our method that will initialize our indices.
We will name this InitializeIndices and we will call this method from inside our
LoadGraphicsContent method right after we make the call to InitializeVertices. Make
sure that the vertex was added right before we initialize our vertex buffer and after we
created all of the other vertices. This way the code for InitializeIndices shown next
will work for us. It assumes the latest addition to our list of vertices is at the bottom of
the list.
private void InitializeIndices()
{
//6 vertices make up 2 triangles which make up our rectangle
indices = new short[6];
//triangle 1 (bottom portion)
indices[0] = 0; // top left
indices[1] = 1; // bottom right
indices[2] = 2; // bottom left
//triangle 2 (top portion)
indices[3] = 0; // top left
indices[4] = 3; // top right
indices[5] = 1; // bottom right
}
In this method we know we are going to create two triangles (with three points each) so
we create enough space to hold all six indices. We then populate our indices. We took
care to add our vertices in a clockwise order when adding them to the vertex list, so we
can simply set our first three indices to 0, 1, and 2. The second triangle, however, needs a
little more thought. We know we have to add these in clockwise order, so we can start
with any vertex and work our way around. Let us start with the top left vertex (the first
vertex we added to our list—index of 0). That means we need to set our next index to be
the top right vertex, which is the one we just added to the end of the list. We set that
index to 3. Finally, we set the last point to the bottom right vertex, which was added to
the vertex buffer second and has the index of 1.
Now we have our vertices created, complete with textured coordinates and position and
even normals. We have our indices set up to use the vertex buffer in a way where we did
not have to duplicate any of the complex vertex data. We further saved memory by using
short instead of int because we will only have a few indices we need to store to represent
our 3D object (our rectangle). Also, some older graphic cards do not support 32-bit (int)
index buffers. The only thing left for us to do is to actually modify our code that draws
the primitive to tell it we are now using an index buffer. To do that, find the Draw method
and locate the call to DrawUserPrimitives. We will want to replace that line with the
following line:
graphics.GraphicsDevice.DrawUserIndexedPrimitives(
PrimitiveType.TriangleList, vertices, 0, vertices.Length,
indices, 0, indices.Length / 3);
Index Buffers 71
4
Notice that we changed the method we are calling on the graphics device. We are now
passing in both vertex and index data. Let’s break down the parameters we are passing in.
We still pass in a triangle array as the first parameter and our array of vertices as the
second parameter and we are leaving our vertex offset at 0. The next parameter is new
and simply needs the number of vertices that is in our vertex array. The fifth parameter is
our array of indices (this method has an override that accepts an array of int as well). The
sixth parameter is the offset we want for our index buffer. We want to use all of the
indices so we passed in 0. The final parameter, primitive count, is the same as the final
parameter in the method we just replaced. Because we only have four vertices we needed
to change that to our index array. Our indices array has six references to vertices in it and
we take that value and divide it by three to get the number of triangles that are in our
triangle list. When we compile and run the code we should see a rectangle that was
created with our modified vertex buffer and our new index buffer!
As an exercise, modify the points in our vertex to have the rectangle slanted into the
screen. This will require modifying a couple of our z values from 0 to something else.
Give it a try!

Effects

2008-04-03T21:34:00.000-07:00

Effects are used to get anything in our XNA 3D game to actually show up on the screen.
They handle things like lights, textures, and even position of the points. We will talk
about effects extensively in Part V, “High Level Shading Language (HLSL).” For now, we
can utilize the BasicEffect class that XNA provides. This keeps us from having to actually
create an effect file so we can get started quickly.
The first thing to notice is that we create a new variable to hold our effect. We do this by
passing in the graphics device as our first parameter and we are passing in null as the
effect pool because we are only using one effect and don’t need a pool to share among
66 CHAPTER 4 Creating 3D Objects
multiple effects. After creating our effect, we want to set some of the properties so we can
use it. Notice we set the world, view, and projection matrices for the effect as well as
telling the effect to turn on the default lighting. We discuss lighting in detail in the HLSL
part of our book, but for now, this will light up the 3D scene so we can see our objects.
TIP
It is a good idea to leave the background color set to Color.CornflowerBlue or some
other nonblack color. The reason for this is if the lights are not set up correctly, the
object will render in black (no light is shining on it). So if the background color is
black, we might think that the object didn’t render at all.
Now back to our code. Notice that we call the Begin method on our effect and we also
call the End method. Anything we draw on the screen in between these two calls will
have that effect applied to them. The next section of code is our foreach loop. This loop
iterates through all of the passes of our effect. Effects will have one or more techniques. A
technique will have one or more passes. For this basic effect, we have only one technique
and one pass. We will learn about techniques and passes in more detail in Part V. At this
point we have another begin and end pair, but this time it is for the pass of the current
(only) technique in our effect. Inside of this pass is where we finally get to draw our triangle
onto the screen. This is done using the DrawUserPrimitives method in the graphics
device object:
graphics.GraphicsDevice.DrawUserPrimitives(
PrimitiveType.TriangleList, vertices, 0, vertices.Length / 3);
We are passing in the type of primitive we will be rendering. The primitives we are
drawing are triangles so we are going to pass in a triangle list. This is the most common
primitive type used in modern games. Refer to Table 4.1 for a list of different primitive
types and how they can be used. The second parameter we pass in is the actual vertex
data we created in our InitializeVertices method. The third parameter is the offset of
the point data where we want to start drawing—in our case we want to start with the first
point, so that is 0. Finally, we need to pass in the number of triangles we are drawing on
the screen. We can calculate this by taking the number of points we have stored and
dividing it by 3 (as there are 3 points in a triangle). For our example, this will return one
triangle. If we compile and run the code at this point we should see a triangle drawn on
our screen. It is not very pretty, as it is a dull shade of gray, but it is a triangle nonetheless.
To see a screen shot, refer to Figure 4.3.
Effects 67
4
Member Name Description
LineList Renders the vertices as a list of isolated straight-line segments.
LineStrip Renders the vertices as a single polyline.
PointList Renders the vertices as a collection of isolated points. This value is
unsupported for indexed primitives.
TriangleFan Renders the vertices as a triangle fan.
TriangleList Renders the specified vertices as a sequence of isolated triangles. Each
group of three vertices defines a separate triangle. Back-face culling is
affected by the current winding-order render state.
TriangleStrip Renders the vertices as a triangle strip. The back-face culling flag is
flipped automatically on even-numbered triangles.

Creating a Camera

2008-04-03T21:33:00.000-07:00

That is enough theory for a bit. We are going to create a camera so we can view our
world. Now we can create a new Windows game project to get started with this section.
We can call this project XNADemo. To begin, we will need to create the following private
member fields:
private Matrix projection;
private Matrix view;
private Matrix world;
We will then need to add a call to InitializeCamera in the beginning of our
LoadGraphicsContent method. The InitializeCamera method will have no return
value. We will begin to populate the method, which can be marked as private, in the next
three points.
Projection
The Matrix struct has a lot of helper functions built in that we can utilize. The
Matrix.CreatePerspectiveFieldOfView is the method we want to look at now.
float aspectRatio = (float)graphics.GraphicsDevice.Viewport.Width /
(float)graphics.GraphicsDevice.Viewport.Height;
Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, aspectRatio,
0.0001f, 1000.0f, out projection);
First we set up a local variable aspectRatio. This is to store, you guessed it, the aspect
ratio of our screen. For the Xbox 360 the aspect ratio of the back buffer will determine
how the game is displayed on the gamer’s TV. If we develop with a widescreen aspect ratio
and the user has a standard TV, the game will have a letterbox look to it. Conversely, if we
develop with a standard aspect ratio and the user has a wide screen, the Xbox 360 will
stretch the display. To avoid this we should account for both situations and then adjust
the value of our aspect ratio variable to the default values of the viewport of the graphics
device like in the preceding code. If we needed to query the default value to which the
gamer had his or her Xbox 360 set, we can gather that information by querying the
DisplayMode property of the graphics device during or after the Initialization method
is called by the framework.
Creating a Camera 61
4
However, if we want to force a widescreen aspect ratio on the Xbox 360 we could set the
PreferredBackBufferWidth and PreferredBackBufferHeight properties on the graphics
object right after creating it. Many gamers do not care for the black bars, so we should use
this with caution. To force a widescreen aspect ratio on Windows is a little more complicated,
but the XNA Game Studio Express documentation has a great “How to” page
explaining how to do it. Once in the documentation, you can find “How to: Restrict
Graphics Devices to Widescreen Aspect Ratios in Full Screen” under the Application
Model in the Programming Guide.
Second, we create our field of view. The first parameter we pass in is 45 degrees. We could
have used MathHelper.ToRadians(45.0f) but there is no need to do the math because the
MathHelper class already has the value as a constant. The second parameter is the aspect
ratio, which we already calculated. The third and fourth parameters are our near and far
clipping planes, respectively. The plane values represent how far the plane is from our
camera. It means anything past the far clipping plane will not be drawn onto the screen.
It also means anything closer to us than the near clipping plane will not be drawn either.
Only the points that fall in between those two planes and are within a 45-degree angle of
where we are looking will be drawn on the screen. The last parameter is where we populate
our projection matrix. This is an overloaded method. (One version actually returns
the projection, but we will utilize the overload that has reference and out parameters, as
they are faster because it doesn’t have to copy the value of the data.)
View
Now that we have our projection matrix set, we can set up our view matrix. To do this we
are going to use another XNA matrix helper method. The Matrix.CreateLookAt method
takes three parameters. Let’s create and initialize these private member fields now.
private Vector3 cameraPosition = new Vector3(0.0f, 0.0f, 3.0f);
private Vector3 cameraTarget = Vector3.Zero;
private Vector3 cameraUpVector = Vector3.Up;
Now we can actually call the CreateLookAt method inside of our InitializeCamera
method. We should add the following code at the end of the method:
Matrix.CreateLookAt(ref cameraPosition, ref cameraTarget,
ref cameraUpVector, out view);
The first parameter we pass in is our camera position. We are passing in the coordinates
(0,0,3) for our camera position to start with, so our camera position will remain at the
origin of the x and y axis, but it will move backward from the origin 3 units. The second
parameter of the CreateLookAt method is the target of where we are aiming the camera.
In this example, we are aiming the camera at the origin of the world Vector3.Zero
(0,0,0). Finally, we pass in the camera’s up vector. For this we use the Up property on
Vector3, which means (0,1,0). Notice we actually created a variable for this so we can pass
it in by reference. This is also an overloaded method, and because we want this to be fast
we will pass the variables in by reference instead of by value. Fortunately, we do not lose
much readability with this performance gain.
62 CHAPTER 4 Creating 3D Objects
World
At this point if we compiled and ran the demo we would still see the lovely blank cornflower
blue screen because we have not set up our world matrix or put anything in the
world to actually look at. Let’s fix that now.
As we saw, the templates provide a lot of methods stubbed out for us. One of these very
important methods is the Draw method. Find this method and add this line of code right
below the TODO: Add your drawing code here comment:
world = Matrix.Identity;
This simply sets our world matrix to an identity matrix, which means that there is no
scaling, no rotating, and no translating (movement). The identity matrix has a translation
of (0,0,0) so this will effectively set our world matrix to the origin of the world.
At this point we have our camera successfully set up but we have not actually drawn
anything. We are going to correct that starting with the next section.
Vertex Buffers

3D objects are made up of triangles. Every object is one triangle or more. For example, a
sphere is just made up of triangles; the more triangles, the more rounded the sphere is.
Take a look at Figure 4.1 to see how this works. Now that we know that every 3D object
we render is made up of triangles and that a triangle is simply three vertices in 3D space,
we can use vertex buffers to store a list of 3D points. As the name implies, a vertex buffer
is simply memory (a buffer) that holds a list of vertices.
Vertex Buffers 63
4
FIGURE 4.1 All 3D objects are made up of triangles.
XNA uses a right-handed coordinate system. This means that the x axis goes from left to
right (left being negative and right being positive), the y axis goes up and down (down
being negative and up being positive), and z goes forward and backward (forward being
negative and backward being positive). We can visualize this by extending our right arm
out to our right and positioning our hand like we are holding a gun. Now rotate our wrist
so our palm is facing the sky. At this point our pointer finger should be pointing to the
right (this is our x axis going in a positive direction to the right). Our thumb should be
pointing behind us (this is our z axis going in a positive direction backward). Now, we
uncurl our three fingers so they are pointing to the sky (this represents the y axis with a
positive direction upward). Take a look at Figure 4.2 to help solidify how the right-handed
coordinate system works.

Now that we know what the positive direction is for each axis we are ready to start plotting
our points. XNA uses counterclockwise culling. Culling is a performance measure
graphic cards take to keep from rendering objects that are not facing the camera. XNA has
three options for culling: CullClockwiseFace, CullCounterClockwiseFace, and None. The
default culling mode for XNA is CullCounterClockwiseFace, so to see our objects we have
to set up our points in the opposite order—clockwise.
TIP
It is helpful to use some graph paper (or regular notebook paper for that matter) to
plot out points. Simply put points where we want them and make sure when we put
them into the code, we do it in a clockwise order.
Let’s plot some points. Ultimately, we want to make a square. We know that all 3D
objects can be made with triangles and we can see that a square is made up of two triangles.
We will position the first triangle at (-1,1,0); (1,-1,0); (-1,-1,0). That means the first
point (-1,1,0) will be positioned on the x axis 1 unit to the left and it will be 1 unit up the
y axis and will stay at the origin on the z axis. The code needed to set up these points is
as follows:
private void InitializeVertices()
{
Vector3 position;
Vector2 textureCoordinates;
vertices = new VertexPositionNormalTexture[3];
//top left
position = new Vector3(-1, 1, 0);
textureCoordinates = new Vector2(0, 0);
vertices[0] = new VertexPositionNormalTexture(position, Vector3.Forward,
textureCoordinates);
//bottom right
position = new Vector3(1, -1, 0);
textureCoordinates = new Vector2(1, 1);
vertices[1] = new VertexPositionNormalTexture(position, Vector3.Forward,
textureCoordinates);
//bottom left
position = new Vector3(-1, -1, 0);
textureCoordinates = new Vector2(0, 1);
vertices[2] = new VertexPositionNormalTexture(position, Vector3.Forward,
textureCoordinates);
}
As we look at this function we can see three variables that have been created: vertex,
position, and textureCoordinates. The vertex variable will store our vertex (point) data.
XNA has different structs that describe the type of data a vertex will hold. In most cases
for 3D games we will need to store the position, normal, and texture coordinates. We
discuss normals later, but for now it is sufficient to know they let the graphics device
know how to reflect light off of the face (triangle). The most important part of the vertex
variable is the position of the point in 3D space. We saw earlier that XNA allows us to
store that information in a Vector3 struct. We can either set the data in the constructor as
we did in this code, or we can explicitly set its X, Y, and Z properties.
We skip over explaining the texture coordinates momentarily, but notice it uses the
Vector2 struct that XNA provides for us.We need to add the following private member
field to our class that we have been using to store our vertices:
private VertexPositionNormalTexture[] vertices;
We need to call this method in our application. The appropriate place to call the
InitializeVertices method is inside of the LoadGraphicsContent method.
Vertex Buffers 65
4
If we compile and run our application now we still do not see anything on the screen.
This is because we have not actually told the program to draw our triangle! We will want
to find our Draw method and before the last call to the base class base.Draw(gameTime),
we need to add the following code:
graphics.GraphicsDevice.VertexDeclaration = new
VertexDeclaration(graphics.GraphicsDevice,
VertexPositionNormalTexture.VertexElements);
BasicEffect effect = new BasicEffect(graphics.GraphicsDevice, null);
world = Matrix.Identity;
effect.World = world;
effect.Projection = projection;
effect.View = view;
effect.EnableDefaultLighting();
effect.Begin();
foreach (EffectPass pass in effect.CurrentTechnique.Passes)
{
pass.Begin();
graphics.GraphicsDevice.DrawUserPrimitives(
PrimitiveType.TriangleList, vertices, 0,
vertices.Length / 3);
pass.End();
}
effect.End();
You might think there is a lot of code here just to draw the points we have created on the
screen. Well, there is, but it is all very straightforward and we can plow on through.
Before we do, though, let’s take a minute and talk about effects.

Transformations Reloaded

2008-04-03T21:31:00.000-07:00

An object can have one transformation applied to it or it can have many transformations
applied to it. We might only want to translate (move) an object, so we can update the
object’s world matrix to move it around in the world. We might just want the object to
spin around, so we apply a rotation transformation to the object over and over so it will
rotate. We might need an object we created from a 3D editor to be smaller to fit better in
our world. In that case we can apply a scaling transformation to the object. Of course, we
might need to take this object we loaded in from the 3D editor and scale it down and
rotate it 30 degrees to the left so it will face some object and we need to move it closer to
the object it is facing. In this case we would actually do all three types of transformations
to get the desired results. We might even need to rotate it downward 5 degrees as well,
and that is perfectly acceptable.
We can have many different transformations applied to an object. However, there is a
catch—there is always a catch, right? The catch is that because we are doing these transformations
using matrix math we need to be aware of something very important. We are
multiplying our transformation matrices together to get the results we want. Unlike
multiplying normal integers, multiplying matrices is not commutative. This means that
Matrix A * Matrix B != Matrix B * Matrix A. So in our earlier example where we want to
scale our object and rotate it (two different times) and then move it, we will need to be
careful in which order we perform those operations. We will see how to do this a little
later in the chapter.

Creating a Benchmark

2008-04-03T21:30:00.000-07:00

To get a baseline for our game loop we will start with a new Windows game project. We
can call this project PerformanceBenchmark. We will add a frame rate counter and
update our window title to show just how many frames per second we are getting “out
of the box.”
Now we can set the following properties inside of the constructor:
//Do not synch our Draw method with the Vertical Retrace of our monitor
graphics.SynchronizeWithVerticalRetrace = false;
//Call our Update method at the default rate of 1/60 of a second.
IsFixedTimeStep = true;
The template creates the GraphicsDeviceManager for us. We set the
SynchronizeWithVerticalRetrace property of the manager to false. The default of this
property is true. As the name suggests, this property synchronizes the call to the Draw
method from inside of the XNA Framework’s game loop to coincide with the monitor’s
refresh rate. If the monitor has a refresh rate of 60 Hz, it refreshes every 1/60 seconds or
60 times every second. By default XNA draws to the screen at the same time the monitor
refreshes to keep the scene from appearing jerky. This is typically what we want. However,
Measure, Measure, Measure 37
3
when measuring the change a piece of code has on our frame rate it is difficult to determine
how we are affecting it if we are always drawing 60 fps. We would not know
anything was wrong until we did something that dropped us below that margin keeping
XNA from calling the Draw method fast enough.
We also set the fixed time step property (IsFixedTimeStep) to true. This is the default
value of this property. This property lets XNA know if it should call the Update method
immediately after drawing to the screen (false) or only after a fixed amount of time has
passed (true). This fixed amount of time is 1/60 second and is stored in the property
TargetElapsedTime, which we can change. At this point we do not need the framework
to call Update as often as possible. For this application it does not really matter because
we are not doing anything inside of our Update method.
Let’s add the following private member fields to our Game1.cs file:
private float fps;
private float updateInterval = 1.0f;
private float timeSinceLastUpdate = 0.0f;
private float framecount = 0;
Finally, let’s add the frame rate calculation inside of our Draw method.
float elapsed = (float)gameTime.ElapsedRealTime.TotalSeconds;
framecount++;
timeSinceLastUpdate += elapsed;
if (timeSinceLastUpdate > updateInterval)
{
fps = framecount / timeSinceLastUpdate; //mean fps over updateIntrval
Window.Title = “FPS: “ + fps.ToString() + “ - RT: “ +
gameTime.ElapsedRealTime.TotalSeconds.ToString() + “ - GT: “ +
gameTime.ElapsedGameTime.TotalSeconds.ToString();
framecount = 0;
timeSinceLastUpdate -= updateInterval;
}
The first thing we are doing with the code is storing the elapsed time since the last time
the Draw method was executed. We then increment our frame count along with the variable
that is keeping a running total of the time. We check to see if enough time has passed,
at which point we update our frame rate. We have the updateInterval set at 1 second, but
we can tweak that number if we would like. Once enough time has passed for us to recalculate
our frame rate, we do just that by taking the number of frames and dividing it by
the time it took us to get inside of this condition. We then update the title of the window
with our fps. We also write out the ElapsedRealTime along with the ElapsedGameTime. To
calculate our fps we used the real time. Play with the first two properties we set to see the
effect it has on the time. Remember the SynchronizeWithVerticalRetrace property determines
how often the Draw method gets called and the IsFixedTimeStep property determines
how often the Update method gets called. We can see that the ElapsedRealTime is
associated to the time it took to call our Draw method while the ElapsedGameTime is associated
with the time it took to call our Update method.
CHAPTER 3 38 Performance Considerations
Finally, we reset our frame count along with the timeSinceLastUpdate variable. Let’s run
the application so we can get our baseline for how our machine is performing.
Now that we have our base number we want to make a note of it. This could be done in
an Excel spreadsheet where we can easily track the changes in our performance. We
should always try to run our performance tests under the same conditions. Ideally,
nothing except the game should be run during all of the benchmark testing.
As an example, let’s add the following code inside of the Draw method:
//bad code that shoud not be replicated
Matrix m = Matrix.Identity;
Vector3 v2;
for (int i = 0; i < 1; i++)
{
m = Matrix.CreateRotationX(MathHelper.PiOver4);
m *= Matrix.CreateTranslation(new Vector3(5.0f));
Vector3 v = m.Translation - Vector3.One;
v2 = v + Vector3.One;
}
It does not do anything other than some 3D math that has absolutely no purpose. The
reason we are going through this exercise is to see how our frame rate will drop as we
increment the upper limit of our for loop. The point is that when we start writing real
functionality inside of the Draw method we can measure how our frame rate is handling
the addition of code. On the included CD, this example is called PerformanceTest1.

Creating 3D Objects

2008-04-03T21:08:00.002-07:00

In this chapter we examine 3D concepts and how the
XNA Framework exposes different types and objects that
allow us to easily create 3D worlds. We will create a couple
of 3D demos that explain the basics. We will also create 3D
objects directly inside of our code. Finally, we will move
these objects on the screen.
Vertices
Everything in a 3D game is represented by 3D points. There
are a couple of ways to get 3D objects on the screen. We
can plot the points ourselves or we can load them from a
3D file (which has all of the points stored already). Later, in
Chapter 6, “Loading and Texturing 3D Objects,” we will
learn how to load 3D files to use in our games. For now,
we are going to create the points ourselves.
We defined these points with an x, y, and z coordinate (x,
y, z). In XNA we represent a vertex with a vector, which
leads us to the next section.
Vectors
XNA provides three different vector structs for us—
Vector2, Vector3, and Vector4. Vector2 only has an x
and y component. We typically use this 2D vector in 2D
games and when using a texture. Vector3 adds in the z
component. Not only do we store vertices as a vector, but
we also store velocity as a vector. We discuss velocity in
Chapter 19, “Physics Basics.” The last vector struct that
XNA provides for us is a 4D struct appropriately called
Vector4. Later examples in this book will use this struct to
pass color information around as it has four components.
We can perform different math operations on vectors,
which prove to be very helpful. We do not discuss 3D math
in detail in this book as there are many texts out there that
60 CHAPTER 4 Creating 3D Objects
cover it. Fortunately, XNA allows us to use the built-in helper functions without having to
have a deep understanding of the inner workings of the code. With that said, it is
extremely beneficial to understand the math behind the different functions.
Matrices
In XNA a matrix is a 4x 4 table of data. It is a two-dimensional array. An identity matrix,
also referred to as a unit matrix, is similar to the number 1 in that if we multiply any
other number by 1 we always end up with the number we started out with (5 * 1 = 5 ).
Multiplying a matrix by an identity matrix will produce a matrix with the same value as
the original matrix. XNA provides a struct to hold matrix data—not surprisingly, it is
called Matrix.
Transformations
The data a matrix contains are called transformations. There are three common transformations:
translation, scaling, and rotating. These transformations do just that: They transform
our 3D objects.
Translation
Translating an object simply means we are moving an object. We translate an object from
one point to another point by moving each point inside of the object correctly.
Scaling
Scaling an object will make the object larger or smaller. This is done by actually moving
the points in the object closer together or further apart depending on if we are scaling
down or scaling up.
Rotation
Rotating an object will turn the object on one or more axes. By moving the points in 3D
space we can make our object spin.

Transformations Reloaded

tag: transformation,reloaded,xna

An object can have one transformation applied to it or it can have many transformations
applied to it. We might only want to translate (move) an object, so we can update the
object’s world matrix to move it around in the world. We might just want the object to
spin around, so we apply a rotation transformation to the object over and over so it will
rotate. We might need an object we created from a 3D editor to be smaller to fit better in
our world. In that case we can apply a scaling transformation to the object. Of course, we
might need to take this object we loaded in from the 3D editor and scale it down and
rotate it 30 degrees to the left so it will face some object and we need to move it closer to
the object it is facing. In this case we would actually do all three types of transformations
to get the desired results. We might even need to rotate it downward 5 degrees as well,
and that is perfectly acceptable.
We can have many different transformations applied to an object. However, there is a
catch—there is always a catch, right? The catch is that because we are doing these transformations
using matrix math we need to be aware of something very important. We are
multiplying our transformation matrices together to get the results we want. Unlike
multiplying normal integers, multiplying matrices is not commutative. This means that
Matrix A * Matrix B != Matrix B * Matrix A. So in our earlier example where we want to
scale our object and rotate it (two different times) and then move it, we will need to be
careful in which order we perform those operations. We will see how to do this a little
later in the chapter.

Creating a Micro-Benchmark Framework

2008-04-03T21:08:00.001-07:00

When we are trying to make a particular piece of code run faster because we see that it is
taking more time compared to everything else in our application, we will need to
compare different implementations of completing the same task. This is where microbenchmark
testing can help.
Micro-benchmark testing allows us to take a close look at how fast small bits of code are
performing. There are a couple of items to keep in mind as we use micro-benchmark
testing, though. The first is that we cannot exactly determine best practices from a microbenchmark
test because it is such an isolated case. The second is that although a piece of
code might perform faster in a micro-benchmark test, it might very well take up a lot
more memory and therefore cause the garbage collector to collect its garbage more often.
Optimization Suggestions 43
3
The point here is that although micro-benchmark testing is good and we should do it
(which is why we are going to build a framework for it) we need to be careful of any
assumptions we make solely on what we find out from our micro-benchmark tests.
XNA Game Studio Express not only lets us create game projects, but also allows us to
create library projects. When the library projects are compiled they can be used by other
applications—a game, a Windows form, or even a console application.
We are going to create another application, but this time it is going to be a normal
Windows Game Library project. This class should be called CheckPerformance. We will be
utilizing this library from a console application. The code for the CheckPerformance can
be found in Listing 3.1. The purpose of this class is to create methods that perform the
same tasks different ways. We will then create a console application that calls the different
methods and measure the amount of time it takes to process each method.
LISTING 3.1 The CheckPerformance class has methods that produce the same results
through different means.
public class CheckPerformance
{
private Vector3 cameraReference = new Vector3(0, 0, -1.0f);
private Vector3 cameraPosition = new Vector3(0, 0, 3.0f);
private Vector3 cameraTarget = Vector3.Zero;
private Vector3 vectorUp = Vector3.Up;
private Matrix projection;
private Matrix view;
private float cameraYaw = 0.0f;
public CheckPerformance() { }
public void TransformVectorByValue()
{
Matrix rotationMatrix = Matrix.CreateRotationY(
MathHelper.ToRadians(45.0f));
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference = Vector3.Transform(cameraReference,
rotationMatrix);
// Calculate the position the camera is looking at.
cameraTarget = cameraPosition + transformedReference;
}
public void TransformVectorByReference()
{
Matrix rotationMatrix = Matrix.CreateRotationY(
MathHelper.ToRadians(45.0f));
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference;
CHAPTER 3 44 Performance Considerations
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
Vector3.Add(ref cameraPosition, ref transformedReference,
out cameraTarget);
}
public void TransformVectorByReferenceAndOut()
{
Matrix rotationMatrix = Matrix.CreateRotationY(
MathHelper.ToRadians(45.0f));
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference;
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
Vector3.Add(ref cameraPosition, ref transformedReference,
out cameraTarget);
}
public void TransformVectorByReferenceAndOutVectorAdd()
{
Matrix rotationMatrix;
Matrix.CreateRotationY(MathHelper.ToRadians(45.0f),
out rotationMatrix);
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference;
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
Vector3.Add(ref cameraPosition, ref transformedReference,
out cameraTarget);
}
public void InitializeTransformWithCalculation()
{
float aspectRatio = (float)640 / (float)480;
projection = Matrix.CreatePerspectiveFieldOfView(
MathHelper.ToRadians(45.0f), aspectRatio, 0.0001f, 1000.0f);
view = Matrix.CreateLookAt(cameraPosition, cameraTarget, Vector3.Up);
}
public void InitializeTransformWithConstant()
{
Optimization Suggestions 45
3
LISTING 3.1 Continued
float aspectRatio = (float)640 / (float)480;
projection = Matrix.CreatePerspectiveFieldOfView(
MathHelper.PiOver4, aspectRatio, 0.0001f, 1000.0f);
view = Matrix.CreateLookAt(cameraPosition, cameraTarget, Vector3.Up);
}
public void InitializeTransformWithDivision()
{
float aspectRatio = (float)640 / (float)480;
projection = Matrix.CreatePerspectiveFieldOfView(
MathHelper.Pi / 4, aspectRatio, 0.0001f, 1000.0f);
view = Matrix.CreateLookAt(cameraPosition, cameraTarget, Vector3.Up);
}
public void InitializeTransformWithConstantReferenceOut()
{
float aspectRatio = (float)640 / (float)480;
Matrix.CreatePerspectiveFieldOfView(
MathHelper.ToRadians(45.0f), aspectRatio, 0.0001f, 1000.0f,
out projection);
Matrix.CreateLookAt(
ref cameraPosition, ref cameraTarget, ref vectorUp, out view);
}
public void InitializeTransformWithPreDeterminedAspectRatio()
{
Matrix.CreatePerspectiveFieldOfView(
MathHelper.ToRadians(45.0f), 1.33333f, 0.0001f, 1000.0f,
out projection);
Matrix.CreateLookAt(
ref cameraPosition, ref cameraTarget, ref vectorUp, out view);
}
public void CreateCameraReferenceWithProperty()
{
Vector3 cameraReference = Vector3.Forward;
Matrix rotationMatrix;
Matrix.CreateRotationY(
MathHelper.ToRadians(45.0f), out rotationMatrix);
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference;
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
CHAPTER 3 46 Performance Considerations
LISTING 3.1 Continued
cameraTarget = cameraPosition + transformedReference;
}
public void CreateCameraReferenceWithValue()
{
Vector3 cameraReference = new Vector3(0, 0, -1.0f);
Matrix rotationMatrix;
Matrix.CreateRotationY(
MathHelper.ToRadians(45.0f), out rotationMatrix);
// Create a vector pointing the direction the camera is facing.
Vector3 transformedReference;
Vector3.Transform(ref cameraReference, ref rotationMatrix,
out transformedReference);
// Calculate the position the camera is looking at.
cameraTarget = cameraPosition + transformedReference;
}
public void RotateWithoutMod()
{
cameraYaw += 2.0f;
if (cameraYaw > 360)
cameraYaw -= 360;
if (cameraYaw < 0)
cameraYaw += 360;
float tmp = cameraYaw;
}
public void RotateWithMod()
{
cameraYaw += 2.0f;
cameraYaw %= 30;
float tmp = cameraYaw;
}
public void RotateElseIf()
{
cameraYaw += 2.0f;
if (cameraYaw > 360)
cameraYaw -= 360;
Optimization Suggestions 47
3
LISTING 3.1 Continued
else if (cameraYaw < 0)
cameraYaw += 360;
float tmp = cameraYaw;
}
}
We do not need to be concerned with the actual contents of the different methods. The
main concept we need to understand at this point is we have different groups of methods
that do the same task but are executed in different ways. We discuss the details of the
Matrix in Chapter 4, “Creating 3D Objects.” For now we can take a look at the last three
methods in the listing and see they are all doing the same thing. All three methods are
adding 2 to a variable cameraYaw and then making sure that the value is between 0 and
360. The idea is that this code would be inside of the game loop reading input from a
device and updating the cameraYaw variable appropriately.
Now we can create the console application that will actually call that class. We need to
add a new Console Application project to the solution and can call this project
XNAPerfStarter. We can name this project XNAPerformanceChecker. The code for
Program.cs is given in Listing 3.2.
LISTING 3.2 The program measures the amount of time it takes to execute the different
CheckPerformance methods.
class Program
{
static int timesToLoop = 10000;
static void Main(string[] args)
{
while (true)
{
XNAPerformanceChecker.CheckPerformance cp =
new XNAPerformanceChecker.CheckPerformance();
Stopwatch sw = new Stopwatch();
//Call all methods once for any JIT-ing that needs to be done
sw.Start();
cp.InitializeTransformWithCalculation();
cp.InitializeTransformWithConstant();
cp.InitializeTransformWithDivision();
cp.InitializeTransformWithConstantReferenceOut();
cp.TransformVectorByReference();
cp.TransformVectorByValue();
CHAPTER 3 48 Performance Considerations
LISTING 3.1 Continued
cp.TransformVectorByReferenceAndOut();
cp.TransformVectorByReferenceAndOutVectorAdd();
cp.CreateCameraReferenceWithProperty();
cp.CreateCameraReferenceWithValue();
sw.Stop();
sw.Reset();
int i;
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.InitializeTransformWithCalculation();
sw.Stop();
PrintPerformance(“ Calculation”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.InitializeTransformWithConstant();
sw.Stop();
PrintPerformance(“ Constant”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.InitializeTransformWithDivision();
sw.Stop();
PrintPerformance(“ Division”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.InitializeTransformWithConstantReferenceOut();
sw.Stop();
PrintPerformance(“ConstantReferenceOut”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.InitializeTransformWithPreDeterminedAspectRatio();
sw.Stop();
Optimization Suggestions 49
3
LISTING 3.2 Continued
PrintPerformance(“ AspectRatio”, ref sw);
sw.Reset();
Console.WriteLine();
Console.WriteLine(“——————————————————————-”);
Console.WriteLine();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.TransformVectorByReference();
sw.Stop();
PrintPerformance(“ Reference”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.TransformVectorByValue();
sw.Stop();
PrintPerformance(“ Value”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.TransformVectorByReferenceAndOut();
sw.Stop();
PrintPerformance(“ReferenceAndOut”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.TransformVectorByReferenceAndOutVectorAdd();
sw.Stop();
PrintPerformance(“RefOutVectorAdd”, ref sw);
sw.Reset();
Console.WriteLine();
Console.WriteLine(“——————————————————————-”);
Console.WriteLine();
sw.Start();
CHAPTER 3 50 Performance Considerations
LISTING 3.2 Continued
for (i = 0; i < timesToLoop; i++)
cp.CreateCameraReferenceWithProperty();
sw.Stop();
PrintPerformance(“Property”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.CreateCameraReferenceWithValue();
sw.Stop();
PrintPerformance(“ Value”, ref sw);
sw.Reset();
Console.WriteLine();
Console.WriteLine(“——————————————————————-”);
Console.WriteLine();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.RotateWithMod();
sw.Stop();
PrintPerformance(“ RotateWithMod”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.RotateWithoutMod();
sw.Stop();
PrintPerformance(“RotateWithoutMod”, ref sw);
sw.Reset();
sw.Start();
for (i = 0; i < timesToLoop; i++)
cp.RotateElseIf();
sw.Stop();
PrintPerformance(“ RotateElseIf”, ref sw);
sw.Reset();
string command = Console.ReadLine();
Optimization Suggestions 51
3
LISTING 3.2 Continued
if (command.ToUpper().StartsWith(“E”) ||
command.ToUpper().StartsWith(“Q”))
break;
}
}
static void PrintPerformance(string label, ref Stopwatch sw)
{
Console.WriteLine(label + “ – Avg: “ +
((float)((float)(sw.Elapsed.Ticks * 100) /
(float)timesToLoop)).ToString(“F”) +
“ Total: “ + sw.Elapsed.TotalMilliseconds.ToString());
}
}
We need to also add the following using clause to the top of our Program.cs file:
using System.Diagnostics;
The System.Diagnostics class gives us access to the Stopwatch we are using to keep track
of the time it takes to process the different methods. After starting the timer we then loop
100,000 times and call a method in the CheckPerformance class we created earlier. Once
the loop finishes executing the method the specified number of times, we stop the stopwatch
and print out our results to the console. When using the Stopwatch object we need
to make sure that if we want to start another test that we first call the Reset method. This
isn’t built into the Stop method in case we just want to pause the timer and start it back
up for some reason. We could also use the static StartNew method instead of the instance
Start method. The StartNew method effectively resets the timer as it returns a new
instance of the Stopwatch.
When we are trying to measure performance on pieces of code that perform very fast
(even inside of a large loop) it is important to be able to track exactly how much time it
took, even down to the nanosecond level.
Typically timing things in seconds does not give us the granularity we need to see how
long something is really taking, so the next unit of time we can measure against is
milliseconds. There are 1,000 milliseconds in a second. Next comes the microsecond, and
there are 1,000 microseconds in a millisecond. Next is the tick, which is what the
TimeSpan object uses. There are 10 ticks in a microsecond. Finally, we come to the
nanosecond. There are 100 nanoseconds in each tick. A nanosecond is 1/1,000,000,000
(one billionth) of a second. Table 3.1 shows the relationships between the different
measurements of time.
CHAPTER 3 52 Performance Considerations
LISTING 3.2 Continued
TABLE 3.1 Time Measurement Relationships
Nanoseconds Ticks Microseconds Milliseconds Seconds
100 1 0.1 0.0001 0.0000001
10,000 100 10.0 0.0100 0.0000100
100,000 1,000 100.0 0.1000 0.0001000
1,000,000 10,000 1,000.0 1.0000 0.0010000
10,000,000 100,000 10,000.0 10.0000 0.0100000
100,000,000 1,000,000 100,000.0 100.0000 0.1000000
1,000,000,000 10,000,000 1,000,000.0 1,000.0000 1.0000000
PrintPerformance, our method to print out the performance measurements, takes in the
label that describes what we are measuring along with a reference to Stopwatch object.
TimeSpan is the type the .NET Framework uses to measure time. The smallest unit of time
measurement this type allows is a tick.
Because we want to measure our time in nanoseconds, we multiply the number of elapsed
ticks by 100. Then we take the total number of nanoseconds and divide by the number of
times we executed the method. Finally, we display the average number of nanoseconds
along with total number of milliseconds the task took to execute.
When we print out our measurements we want the average time it took to execute a
method for the number of iterations we told it to loop. The reason we do this instead of
just running it once is so that we can easily determine a more accurate number. In fact,
we even run an outer loop (that we exit out of by entering text that starts with “E” or
“Q”) to account for anomalies in performance on the machine in general.
An additional item to note about this code is that we call each method of the
CheckPerformance object once before we start measuring execution times. The reason we
do this is so the compiler can do any just-in-time compiling for the methods we will be
calling so we are not taking that time into account.

Understanding the Garbage Collector

2008-04-03T21:07:00.002-07:00

A big plus of writing managed code is the fact that we do not need to worry about
memory leaks from the sense of losing pointers to referenced memory. We still have
“memory leaks” in managed code, but whenever the term is used it is referring to not
decommissioning variables in a timely fashion. We would have a memory leak if we kept
a handle on a pointer that we should have set to null. It would remain in memory until
the game exits.
We should use the using statement. An example of the using statement can be found in
the program.cs file that is generated for us by the game template. The entry point of the
program uses this using statement to create our game object and then to call its Run
method. The using statement effectively puts a try/finally block around the code while
putting a call to the object’s Dispose method inside of the finally block.
Garbage collection concerns on Windows are not as large as those on the Xbox 360.
However, if we optimize our code to run well on the Xbox 360 in regard to garbage
collection, the game will also perform well on Windows.

Managing Memory

2008-04-03T21:07:00.001-07:00

There are two types of objects in the .NET Framework: reference and value. Examples of
value types are enums, integral types (byte, short, int, long), floating types (single, double,
float), primitive types (bool, char), and structs. Examples of objects that are reference
types are arrays, exceptions, attributes, delegates, and classes. Value types have their data
stored on the current thread’s stack and the managed heap is where reference types find
themselves.
By default, when we pass variables into methods we pass them by value. This means for
value types we are actually passing a copy of the data on the stack, so anything we do to
that variable inside of the method does not affect the original memory. When we pass in
a reference type we are actually passing a copy of the reference to the data. The actual
data is not copied, just the address of the memory. Because of this, we should pass large
CHAPTER 3 40 Performance Considerations
value types by reference instead of by value when appropriate. It is much faster to copy
an address of a large value type than its actual data.
We use the ref keyword to pass the objects as reference to our methods. We should not
use this keyword on reference types as it will actually slow things down. We should use
the keyword on value types (like structs) that have a large amount of data it would need
to copy if passed by value.
The other thing to note is that even if we have a reference type and we pass it into a
method that takes an object type and we box (implicitly or explicitly), then a copy of the
data is actually created as well—not just the address to the original memory. For example,
consider a class that takes a general object type (like an ArrayList’s Add method). We pass
in a reference type, but instead of just the reference being passed across, a copy of the
data is created and then a reference to that copy of the data is passed across. This eats up
memory and causes the garbage collector to run more often. To avoid this we need to use
generics whenever possible.

Installing Visual C# Express

2008-04-03T21:05:00.000-07:00

To get started, we must have the software installed. Let’s start by installing Visual C#
Express. Visual C# Express is the IDE that is required to run XNA Game Studio Express.
XNA requires C# due to how the Content Pipeline is used. There are some people who
have successfully created demos using other languages such as VB.NET and even F#.
However, this is not supported by Microsoft currently and won’t be discussed in this
book. This book assumes you have a good understanding of C#. If you know C++, Java, or
VB.NET, you should be able to pick up C# pretty quickly.
I am going to be detailed in the steps to make sure that anyone who has not worked with
Visual C# Express will be able to get it installed with no issues. Feel free to skip this
section if you already have Visual C# Express installed.
To install Visual C# Express, follow these steps:
1. You will need to be connected to the Internet to install the application. The application
can be downloaded by browsing to
http://msdn.microsoft.com/vstudio/express/downloads/ and clicking the Visual C#
Express Go button to download the vcssetup.exe setup program.
2. Optional. On the Welcome to Setup screen select the check box to send data about
your setup experience to Microsoft. This way if something goes awry, Microsoft can
get the data and try to make the experience better the next time around. This
screen is shown in Figure 1.1.
11
1
Installing Visual C# Express
FIGURE 1.1 Select the check box if you want the system to provide feedback to Microsoft
about your installation experience.
3. Click Next to continue.
4. The next screen is the End-User License Agreement. If you accept the terms, select
the check box and click Next.
5. The following screen, shown in Figure 1.2, has two installation options you can
check. Neither of these options is required to utilize XNA.
FIGURE 1.2 Neither of these options is required to utilize XNA.
CHAPTER 1 Introducing the XNA Framewor12 k
6. Click Next to continue.
7. The next screen, shown in Figure 1.3, asks where we would like to install Visual C#
Express. It is going to install other required applications including Microsoft .NET
Framework 2.0. This is required, as C# runs on the .NET Framework. You will also
notice it requires more than 300MB of space.
8. Click Next to continue.
FIGURE 1.3 Specify which directory you want Visual C# Express to be installed in.
9. Now we are looking at the Installation Progress screen where we will be able to
monitor the progress of the installation.
10. Finally, on the Setup Complete screen we can see the Windows Update link we can
click on to get any of the latest service packs for Visual C# Express.
11. Click Exit to complete the installation.
We have successfully installed the first piece of the pie to start creating excellent games
with XNA! Before we continue to the next piece of software, we need to open up Visual
C# Express. It might take a couple of minutes to launch the first time the application is
loaded. Once the Visual C# Express is loaded we should see the Start Page as shown in
Figure 1.4.
Installing Visual C# Express 13
1
FIGURE 1.4 This is the Start Page inside of Visual C# Express.
The following procedure is optional, but it does ensure that everything is working
correctly on our machine.
1. In the Recent Projects section, find Create Project and click the link. You can also
create a new project under the File menu.
2. Visual C# Express installed several default templates that we can choose from. Select
the Windows Application template as displayed in Figure 1.5.
3. You can leave the name set to WindowsApplication1 as we will just be discarding
this project when we are done.
FIGURE 1.5 The New Project dialog box allows you to choose from the default templates to
create an application.
CHAPTER 1 Introducing the XNA Framewor14 k
4. Click OK to create the application.
At this point a new project should have been created and we should be looking at a blank
Windows Form called Form1.
5. Press Ctrl+F5 or click Start Without Debugging on the Debug menu.
If everything compiled correctly, the form we just saw in design mode should actually
be running. Granted, it doesn’t do anything, but it does prove that we can compile and
run C# through Visual C# Express. The end result can be seen in Figure 1.6. Let’s close
down the application we just created as well as Visual C# Express. Feel free to discard
the application.
FIGURE 1.6 This is a C# Windows Form application after compiling and running the default
template.
Installing the DirectX Runtime
We also need the DirectX 9 runtime if it isn’t already on the machine. To get started,
follow these steps:
1. Run the dxwebsetup.exe file from Microsoft’s website. This can be found by clicking
on the DirectX Runtime Web Installer link at the bottom of the Creator’s Club
Resources—Essentials web page http://creators.xna.com/Resources/Essentials.aspx.
This file contains the redistribution package of the February 2007 DirectX 9.
You will need to be connected to the Internet so it can completely install the
application.
2. We are greeted with the End-User License Agreement. Handle with care.
3. The next screen is a dialog box asking where we would like the installation files to
be stored. We can pick any directory we want as long as we remember it so we can
actually install the runtime—we are simply extracting the files needed to install the
runtime.
4. Click OK to continue.
5. We will be prompted to create that directory if the directory entered doesn’t exist.
Click Yes to continue.
6. Wait for the dialog box with the progress bar to finish unpacking the files.
Now we can actually install the runtime by following these steps:
1. Browse to the folder where we installed the files and run the dxsetup.exe file to
actually install DirectX 9 onto the machine.
2. The welcome screen we see includes the End-User License Agreement. Select the
appropriate radio button to continue.
3. Following the agreement is a screen stating that it will install DirectX—click Next.
4. Once it finishes installing (a progress bar will be visible while it is installing the
files) we will be presented with the Installation Complete screen.
5. Simply click Finish to exit the setup.
Now, we can move on to installing XNA Game Studio Express.
Installing XNA Game Studio Express
To use XNA Game Studio Express we must use Visual C# Express. We cannot use Visual
Studio .NET Professional nor can we use any other IDE. Although there are people who
have successfully been able to run XNA and even get the Content Pipeline (which we talk
about in Part III of the book) to work in Visual Studio .NET Professional, it is not officially
supported by Microsoft and is not covered in this book.
WARNING
You must run the Visual C# Express IDE at least one time before installing XNA Game
Studio Express. If this is not done, not all of the functionality will be installed. If XNA
Game Studio Express was installed prematurely, you will need to uninstall XNA Game
Studio Express and run Visual C# Express and then exit the IDE. Then you will be able
to reinstall XNA Game Studio Express.
To get started complete the following steps:
1. Run the xnagse_setup.msi file from Microsoft’s website. The file can be downloaded
by clicking on the top link of the Creator’s Club Resources—Essentials web site
http://creators.xna.com/Resources/Essentials.aspx.
2. Click Next to get past the setup welcome screen.
3. The next screen is the End-User License Agreement. If you accept the terms, select
the check box and click Next.
4. This will open up a notification dialog box that explains that the Windows Firewall
will have a rule added to it to allow communication between the computer and the
Xbox 360. This can be seen in Figure 1.7.
Installing XNA Game Studio Express 15
1
FIGURE 1.7 XNA Game Studio Express modifies the Windows Firewall so an Xbox 360 and
the PC can talk to each other.
5. Click Install to continue. The next screen shows the progress of the installation.
6. Once it has completed installing all of the required files we will be presented with
the completion dialog box. Simply click Finish to exit the setup.
After we have installed XNA Game Studio Express, we can go to the Start menu and see it
added a few more items than those contained in the IDE. Make sure to take time and read
through some of the XNA Game Studio Express documentation. There is also a Tools
folder that contains a couple of tools we will be looking at later. We will be discussing the
XACT tool in Chapter 6, “Loading and Texturing 3D Objects,” and the XNA Framework
Remote Performance Monitor for Xbox 360 application in Chapter 3, “Performance
Considerations.” Go ahead and open the IDE by clicking XNA Game Studio Express on
the Start menu.
Hmm, this looks identical to the Visual C# Express IDE. There is a good reason for this—it
is the same application! When we installed XNA Game Studio Express it added properties
to Visual C# Express to allow it to behave differently under certain circumstances. Mainly
it added some templates, which we will look at shortly, and it added the ability for Visual
C# Express to handle content via the XNA Content Pipeline. It also added a way for us to
send data to our Xbox 360, as we will see in the next chapter.

Introducing the XNA Framework and XNA Game Studio Express

2008-04-03T21:04:00.002-07:00

Most developers I know decided to enter the computer
field and specifically programming because of computer
games. Game development can be one of the most challenging
disciplines of software engineering—it can also be
the most rewarding!
Never before has it been possible for the masses to create
games for a game console, much less a next generation
game console. We are coming in on the ground floor of a
technology that is going to experience tremendous growth.
Microsoft is leading the way into how content will be
created for game consoles. Soon other game console manufacturers
will be jumping at a way to allow the public to
create content for their machines. The great news for the
Xbox 360 is that Microsoft has spent so much time over
the years creating productive and stable development environments
for programmers. We will be installing one of
Microsoft’s latest integrated development environments
(IDEs) in this chapter. Before we get to that, let’s take a look
at the technology we discuss in this site—XNA.

What Is the XNA Framework?
You have probably heard the statement, “To know where
you are going, you need to know where you have been.”
I am uncertain if that is entirely true, but I do believe it
applies here. Before we dig into exactly what XNA is and
what it can do for us, let’s take a moment to look at
DirectX because that is what the XNA Framework is
built on.

The Foundation of the XNA Framework
Let’s take a journey back to the days of DOS on the PC. When programming games,
graphic demos, and the like in DOS, programmers typically had to write low-level code to
talk directly to the sound card, graphics cards, and input devices. This was tedious and
the resulting code was error prone because different manufacturers would handle different
BIOS interrupts, IO ports, and memory banks—well, differently, so the code would work
on one system and not another.
Later, Microsoft released the Windows 95 operating system. Many game programmers
were skeptical at writing games for Windows—and rightly so—because there was no way
to get down to hardware level to do things that required a lot of speed. Windows 95 had
a protected memory model that kept developers from directly accessing the low-level
interrupts of the hardware.
To solve this problem, Microsoft created a technology called DirectX. It was actually
called Windows Game SDK to begin with, but quickly switched names after a reporter
poked fun at the API names DirectDraw, DirectSound, and DirectPlay, calling the SDK
Direct “X.” Microsoft ran with the name and DirectX 1.0 was born a few months after
Windows 95 was released. I remember working with DirectDraw for a couple of demos
back when this technology first came out.
Because of DirectX, developers had a way to write games with one source that would work
on all PCs regardless of their hardware. Hardware vendors were eager to work with
Microsoft on standardizing an interface to access their hardware. They created device
drivers to which DirectX would map its API, so all of the work that previously had to be
done by game programmers was taken care of, and programmers could then spend their
time doing what they wanted to—write games! Vendors called this a Hardware
Abstraction Layer (HAL). They also developed a Hardware Emulation Layer (HEL), which
emulates hardware through software in case hardware isn’t present. Of course, this is
slower but it allowed certain games to be run on machines with no special hardware.
After a couple of years Microsoft released DirectX 3.0, which ran on Windows NT 4 as
well as Windows 95. As part of those upgrades, they introduced Direct3D. This allowed
developers to create 3D objects inside of 3D worlds. DirectX 4 was never released, but
DirectX 5 was released in 1997 and later had some upgrades to work under Windows 98.
When DirectX 8 came on the scene in 2000, some of the newly available graphics hardware
had vertex and pixel shaders. As a result, Microsoft added in a way to pass custom
program code to the hardware. Through assembly code, the game developer could manipulate
the data the main game passed to the graphics card. This assembly code was
consumed directly by the graphics hardware.
When there was no graphics hardware, games were slow, but they were very flexible.
Later, as hardware rendering became prominent, the games were faster, but they were not
very flexible in that all of the games really started to look the same. Now with shaders,
the speed of the hardware is combined with the flexibility for each game to render and
light its 3D content differently.

This brings us to present-day DirectX: We are up to DirectX 9 and 10. Before I talk about
DirectX 9, I spend some time talking about DirectX 10. DirectX 10 was released at the
same time as Microsoft Windows Vista. In fact, DirectX 10 only works on Vista. This is
largely due to the fact that Microsoft has made major changes in the driver model for this
operating system. DirectX 10 also requires Shader Model 4.0 hardware.
The Xbox 360 runs on DirectX 9 plus some additional partial support for Shader Model
3.0 functionality. DirectX 9 is the foundation for Managed DirectX, an API that exposed
the core DirectX functionality to .NET Framework developers. There was a lot of concern
about whether this “wrapper” could be as fast as the C++ counterparts. Fortunately, it was
almost as fast—about 98 percent was the benchmark touted. I experienced these benchmark
speeds firsthand while on the beta team for this technology. I fell in love with
Managed DirectX.
The XNA Framework used the lessons learned from Managed DirectX and used that foundation
as a launching pad. To be clear, XNA was built from the ground up and was not
built on top of Managed DirectX. It didn’t use the same namespaces as Managed DirectX
and is not simply pointing to the Managed DirectX methods in the background.
Although XNA utilizes DirectX 9 in the background, there are no references to DirectX’s
API like there were in Managed DirectX.
XNA Today
XNA is actually a generic term much like the term .NET. XNA really refers to anything
that Microsoft produces that relates to game developers. The XNA Framework is the API
we are discussing. The final piece to XNA is the XNA Game Studio Express application,
which we discuss in detail later. This is the IDE we use to develop our XNA games.
TIP
In this book, whenever we use the term XNA, we are really referring to the XNA
Framework unless otherwise noted.
XNA allows us to do a lot of things. We have easy access to the input devices (keyboard,
game pad or controller, mouse). XNA gives us easy access to the graphics hardware. We
are able to easily control audio through XNA. XNA provides the ability for us to store
information like high scores and even saved games. XNA does not currently have any
networking capability. Microsoft wants to use the Xbox Live technology for adding
network support to XNA. However, there is more work to be done to make sure Microsoft
can provide multiplayer functionality in a secure manner.
To get started using XNA we have to install some software. We need to install the latest
version of DirectX 9 as well as have a graphics card that supports DirectX 9.0c and Shader
Model 1.1. (You should get a card that supports Shader Model 2.0 as some of the examples,
including the starter kit we use in this chapter and the next one, will not run
without it.) We also need to install Visual C# Express, the DirectX 9 runtime, and finally
XNA Game Studio Express. Fortunately, all of the software is free! If you don’t have
10 CHAPTER 1 Introducing the XNA Framework and XNA Game Studio Express
graphics hardware that can support Shader Model 2.0 you can pick up a card relatively
inexpensively for about $35 USD. If possible, you should purchase a graphics card that
can support Shader Model 3.0, as a couple of examples at the end of the book require it.
At this point, games cannot be created for commercial use on the Xbox 360 but Microsoft
has mentioned they are interested in supporting commercial games in future versions.
Fortunately, we can create community games for the Xbox 360 with the Express versions.
XNA Game Studio Express is great for the game hobbyist, a student, or someone just
getting started because you do not have to shell out a lot of (any!) money to get up and
running. One exception to this is if you actually want to deploy your games on your
Xbox 360. To do that, you will need to subscribe to the XNA Creators Club for $99 USD a
year (or $49 USD for four months). Remember, writing games for the PC using XNA is
totally free!
Oh, in case you are wondering what XNA stands for, XNA’s Not Acronymed (or so
Microsoft says in the XNA FAQ).