The most basic operations we can do with vectors are arithmetic operations. Adding, subtracting, multiplying, and dividing vectors with each other is as simple as performing the operation on each member in one vector to the corresponding member in a second vector. An example of this can be seen with performing various operations to a 2D vector:

Vector2D a, b, result;

// Adding
result.x = a.x + b.x;
result.y = a.y + b.y;

// Subtracting
result.x = a.x - b.x;
result.y = a.y - b.y;

// Multiplying
result.x = a.x * b.x;
result.y = a.y * b.y;

// Dividing
result.x = a.x / b.x;
result.y = a.y / b.y;

It is also common to perform these operations between a vector and a scalar (floating-point value), as well as using overloaded operators. Although overloaded operators are convenient to look at in code, they are often less optimal since they often require multiple functions to be executed (one for the equals, one for the operator, constructors for the vector parameters to the overloaded function, etc.) and multiple load/store operations. An example of adding a scalar to a vector or using an overloaded operation can be seen as follows:

Vector2D a, result;
float value = 100.0f;

// Adding a float
result.x = a.x + value;
result.y = a.y + value;

// Adding as an overloaded operator
result = a + value;

In XNA Math we have XMVectorAdd, XMVectorSubtract, XMVectorDivide, and XMVectorMultiply as a means of performing each of these operations between XMVECTOR objects. Their prototypes are as follows, and they use optimized instruction sets:

XMVECTOR XMVectorAdd( XMVECTOR V1, XMVECTOR V2 );

XMVECTOR XMVectorSubtract( XMVECTOR V1, XMVECTOR V2 );

XMVECTOR XMVectorDivide( XMVECTOR V1, XMVECTOR V2 );

XMVECTOR XMVectorMultiply( XMVECTOR V1, XMVECTOR V2 );

Occasionally you will need to determine the distance between two points. These points can be either the origin and a fixed location or two completely arbitrary points.

For example, imagine you’re creating a real-time strategy game. Each of the monsters of the opposing army has the opportunity to move toward a common goal. During the turn of the AI, it can choose to move one of these monsters toward the goal, but which one? This is where the ability to figure out distance comes in handy. By calculating the relative distance between each monster and the common goal, the AI can choose which one of the creatures is more advantageous to move.

Whether you are determining the distance within a 2D or 3D space, the calculation is essentially the same. An example can be seen in the following pseudo code:

Vector2D x1, x2;

float xDistance = x2.x - x1.x;
float yDistance = y2.x - y1.x;

float distance = square_root( xDistance * xDistance + yDistance * yDistance );

In this example x2 is the X axis value of the second vector and x1 is the X axis of the first vector. The result of the distance calculation will be a single value that represents the distance between the two points. When determining the distance between two points in 3D space, make sure to take the Z value into account as well.

To put it another way, the distance between one vector and another is the square root of the dot product of the vector between the points. We’ll cover dot products in the upcoming subsection titled “Dot Product.” The square root of the vector between the points is also known as the vector’s length. In this case the length can be used to give us the distance between vectors.

Occasionally it is useful to know the length of a vector, since the length or magnitude of the vector can be used as acceleration or velocity when applied to a game object. The length is also used as an input when normalizing the vector.

To calculate the length of a vector, each of the components must be first squared and then added together. This is known as the dot product. Finally, the square root of the dot product is taken to give the output length.

sqrt(vectorX * vectorX + vectorY * vectorY + vectorZ * vectorZ);

Direct3D provides several functions to calculate the length of a vector. The length of a 2D vector is obtained with a call to XMVector2Length, the length of a 3D vector via XMVector3Length, and a 4D vector via XMVector4Length. Additional functions also exist to estimate the length of a vector as well as to square the length. The squared-length functions end with Sq and will essentially perform length × length, while the estimation functions that end with Est are used to increase performance at the expense of accuracy. All of the length functions in XNA Math can be seen as follows:

XMVECTOR XMVector2Length( XMVECTOR V );
XMVECTOR XMVector3Length( XMVECTOR V );
XMVECTOR XMVector4Length( XMVECTOR V );

XMVECTOR XMVector2LengthEst( XMVECTOR V );
XMVECTOR XMVector3LengthEst( XMVECTOR V );
XMVECTOR XMVector4LengthEst( XMVECTOR V );

XMVECTOR XMVector2LengthSq( XMVECTOR V );
XMVECTOR XMVector3LengthSq( XMVECTOR V );
XMVECTOR XMVector4LengthSq( XMVECTOR V );

Normalizing a vector is the process of reducing any vector into a unit vector, which as you should remember is a vector with a length equal to 1. This is best done when only the direction of a vector is needed and the length is unimportant. Vectors can be normalized simply by dividing each of the components by the vector’s length— an example of which can be seen in the following:

Vector3 vec;

float length = Length( vec );

vec.X = vec.X / length;
vec.Y = vec.Y / length;
vec.Z = vec.Z / length;

The final vector will still point in the same direction, but the length of the vector is reduced to 1. In XNA Math we have XMVector2Normalize to normalize a 2D vector, XMVector2NormalizeEst to calculate an estimated normal vector (which can lead to a increase of performance at the expense of accuracy), and versions of each for 3D and 4D vectors. The function prototypes are as follows:

XMVECTOR XMVector2Normalize( XMVECTOR V );
XMVECTOR XMVector3Normalize( XMVECTOR V );
XMVECTOR XMVector4Normalize( XMVECTOR V );

XMVECTOR XMVector2NormalizeEst( XMVECTOR V );
XMVECTOR XMVector3NormalizeEst( XMVECTOR V );
XMVECTOR XMVector4NormalizeEst( XMVECTOR V );

A cross product of a vector is used to calculate a vector that is perpendicular to two other vectors. One common use for this is to calculate the normal of a triangle. In this situation you can use the cross product of each edge vector to obtain the triangle’s normal. An edge vector is essentially point A of the triangle — point B for edge 1, and point B — point C for the second edge. The cross product is also known as the vector product.

An example of calculating the cross product can be seen in the following, where a new vector is created by multiplying the components of the two input vectors:

newVectorX = (vector1Y * vector2Z) –(vector1Z * vector2Y);
newVectorY = (vector1Z * vector2X) –(vector1X * vector2Z);
newVectorZ = (vector1X * vector2Y) –(vector1Y * vector2X);

In XNA Math we have XMVector2Cross , XMVector3Cross , and XMVector4Cross for calculating the cross product of 2D, 3D, and 4D vectors. Their function prototypes are as follows:

XMVECTOR XMVector2Cross( XMVECTOR V1, XMVECTOR V2 );
XMVECTOR XMVector3Cross( XMVECTOR V1, XMVECTOR V2 );
XMVECTOR XMVector4Cross( XMVECTOR V1, XMVECTOR V2 );

The final vector calculation we’ll go over is the dot product. The dot product, also known as the scalar product, is used to determine the angle between two vectors and is commonly used for many calculations in computer graphics such as back-face culling, lighting, and more.

Back-face culling is the process by which polygons that are not visible are removed to reduce the number of polygons being drawn. If two vectors have an angle less than 90 degrees, then the dot product is a positive value; otherwise, the dot product is negative. The sign of the dot product is what’s used to determine whether a polygon is front or back facing. If we use the view vector as one vector, the dot product between the view vector and the polygon’s normal tells us which direction it is facing, and thus which polygons we should draw or not. This is usually handled internally by the graphics hardware and is not anything we would do manually when using Direct3D.

We could also use this for lighting, which we’ll discuss in more detail in Chapter 7 in the section titled “Lighting.” One way we can use the dot product for lighting is to use the value to see how much diffuse light is reaching the surface. Light sources directly above a surface will be fully lit, surfaces at an angle will be partially lit, and surfaces where the light is behind it will receive no light. The vector used for the dot product is usually the surface normal and the light vector, where the light vector is calculated as the light’s position — the vertex position (or the pixel’s position when doing per-pixel lighting).

The dot product is calculated by squaring each axis of the vector and adding together their results to form a single scalar value. An example of this can be seen in the following:

float dotProduct = vecl.X * vec2.X + vecl.Y * vec2.Y + vecl.Z * vec2.Z;

XNA Math has XMVector2Dot for the dot product between 2D vectors, XMVector3Dot for 3D vectors, and XMVector4Dot for 4D vectors. Their prototypes are shown as follows:

XMVECTOR XMVector2Dot( XMVECTOR V1, XMVECTOR V2 );
XMVECTOR XMVector3Dot( XMVECTOR V1, XMVECTOR V2 );
XMVECTOR XMVector4Dot( XMVECTOR V1, XMVECTOR V2 );

Although the dot product returns a scalar, in XNA Math it seems to be returning a vector of XMVECTOR. This is because the result is copied into all components of XMVECTOR. Since the optimized instruction set used in XNA Math uses vectors for stream parallel processing, technically that is what we are using even if we ultimately only really use one component. SIMD instructions work on four floating-point values at a time with a single instruction, so in a case such as this we only need to access one of them to get our scalar result.

A point of reference is a location that both you and the other person understand. For instance, if the point of reference was a doorway, you could then explain that the desk was located about 10 feet from the door on the left side. When you’re building a 3D world, a point of reference is crucial.

You need to be able to place objects in relation to a point of reference that both you and the computer understand. When working with 3D graphics, this point of reference is the coordinate system. A coordinate system is a series of imaginary lines that run through space and are used to describe locations within it. The center of this coordinate system is called the origin; this is the core of your point of reference. Any location within this space can be described precisely in relation to the origin.

For example, you can describe the location of an object by saying it is four units up from the origin and two units to the left. By using the origin as the point of reference, any point within the defined space can be described.

If you remember from working with sprites, any point on the screen can be explained using X and Y coordinates. The X and Y coordinates determine the sprite’s position in a coordinate system consisting of two perpendicular axes, a horizontal and a vertical. Figure 6.1 shows an example of a 2D coordinate system.

When working with three dimensions, a third axis will be needed: the Z axis. The Z axis extends away from the viewer, giving the coordinate system a way to describe depth. So now you have three dimensions, width, height, and depth, as well as three axes.

Figure 6.1. A 2D coordinate system.

When dealing with 3D coordinate systems, you have to be aware that they come in two flavors: left-handed and right-handed. The handedness of the system determines the direction the axes face in relation to the viewer.

Left-Handed Coordinate Systems

A left-handed coordinate system extends the positive X axis to the left and the positive Y axis upward. The Z axis in a left-handed system is positive in the direction away from the viewer, with the negative portion extending toward them. Figure 6.2 shows how a left-handed coordinate system is set up.

Figure 6.2. A left-handed coordinate system.

Figure 6.3. A right-handed coordinate system.

3D models are for the most part created outside of your game code. For instance, if you’re creating a racing game, you’ll probably create the car models in a 3D art package. During the creation process, these models will be working off of the coordinate system provided to them in the modeler. This causes the objects to be created with a set of vertices that aren’t necessarily going to place where the model will end up in the game and how you want it oriented in your game environment. Because of this, you will need to move and rotate the model yourself. You can do this by using the geometry pipeline. The geometry pipeline is a process that allows you to transform an object from one coordinate system into another. Figure 6.4 shows the transformations a vertex goes through.

Figure 6.4. Geometry pipeline.

When a model starts out, it is centered on the origin. This causes the model to be centered in the environment with a default orientation. Not every model you load needs to be at the origin, so how do you get models where they need to be? The answer to that is through transformations.

Transformations refer to the actions of translating (moving), rotating, and scaling an object. By applying these actions, you can make an object appear to move around. These actions are handled as your objects progress through the stages of the geometry pipeline.

When you load a model, its vertices are in a local coordinate system called model space. Model space refers to a coordinate system where the parts of an object are relative to a local origin. For instance, upon creation, a model’s vertices are in reference to the origin point around which they were created. A cube that is two units in size centered on the origin would have its vertices one unit on either side of the origin. If you then wanted to place this cube somewhere within your game, you would need to transform its vertices from model space into the global system used by all the objects in your world. This global coordinate system is called world space, where all objects are relative to a single fixed origin. The process of transforming an object from model space into world space is called the world transformation.

The world transformation stage of the geometry pipeline takes an existing object with its own local coordinate system and transforms that object into the world coordinate system. The world coordinate system is the system that contains the position and orientation of all objects within the 3D world. The world system has a single origin point that all models transformed into this system become relative to.

The transformation from model space to world space usually occurs within the vertex shader when it comes to rendering geometry. You could transform the geometry yourself outside of shaders, but that will require repopulating vertex buffers with dynamic information, which would not always be the best course of action (especially for static geometry).

The next stage of the geometry pipeline is the view transformation. Because all objects at this point are relative to a single origin, you can only view them from this point. To allow you to view the scene from any arbitrary point, the objects must go through a view transformation.

The view transformation transforms the coordinates from world space into view space. View space refers to the coordinate system that is relative to the position of a virtual camera. In other words, the view transformation is used to simulate a camera that is applied to all objects in the game world with the exception of the graphical user interface (e.g., screen elements for the health bar, timers, ammo counter, etc.). When you choose a point of view for your virtual camera, the coordinates in world space get reoriented in respect to the camera. For instance, the camera remains at the origin, while the world itself is moved into the camera’s view.

At this point, you have the camera angle and view for your scene, and you’re ready to display it to the screen.

The next stage in the geometry pipeline is the projection transformation. The projection transformation is the stage of the pipeline where depth is applied. When you cause objects that are closer to the camera to appear larger than those farther away, you create an illusion of depth. This type of projection is known as perspective projection and is used for 3D games. Another type of projection will keep all rendered objects looking like they are the same distance apart from each other even when they are not. This is done through orthographic projection. A final type of projection is isometric projection, which is a projection used to display 3D objects in 2D technical drawings. This type of projection is simulated and not actually done in graphics APIs, where we usually just have either perspective projection or orthographic projection.

Finally, the vertices are scaled to the viewport and projected into 2D space. The resulting 2D image appears on your monitor with the illusion of being a 3D scene.

Now that you’re aware of the transformations, what are they really used for? As an example, say you were modeling a city. This city is made up of houses, office buildings, and a few cars here and there. Now, you load in a model of a new car and need to add it to your existing scene. When the model comes in, though, it’s centered on the origin and facing the wrong way. To get the car to the correct spot and orientation in the scene, the car model will have to be rotated properly and then translated to its world space location.

When putting an object through the transformation pipeline, you’re really transforming each vertex individually. In the case of the car, every vertex that makes up the car will be moved individually by a certain amount and then rotated. After each vertex is complete, the object appears in the new position. These transformations take place by multiplying each vertex in the model by a transformation matrix.

The world matrix used for the world transformation is created by combining the scale, rotation, and translation (positioning) matrices for that specific game object. Although we usually use these three matrices to create the world matrix, if the object doesn’t use one or more of these properties, you could just leave it out, since combining one matrix with an identity matrix is similar to multiplying a number by 1; it doesn’t change its value. An identity matrix is similar to a matrix with nothing applied to it.

Combining the world matrix and the view matrix will create a new matrix called the world-view matrix. Combining the world-view and projection matrices will create another matrix called the world-view-projection matrix. This matrix is often used by the vertex shader and is the one we’ve been working with throughout this book.

Transforming a vector by a transformation matrix is done by multiplying the vector by the matrix. This is an operation we’ve done in the large majority of demos in the vertex shader where we used the HLSL keyword mul to perform the multiplication. In XNA Math we can call, using 2D vectors as an example, the function XMVector2Transform to transform a vector by a matrix. There is also a version of this called XMVector2TransformCoord, which is used to transform a vector and then project it onto w = 1. The third type of transformation function, called XMVector2TransformNormal, is used to transform a vector by all parts of the matrix with the exception of its translational part. Each of these types of functions for 2D, 3D, and 4D vectors can be seen as follows:

XMVECTOR XMVector2Transform( XMVECTOR V, XMMATRIX M );
XMVECTOR XMVector3Transform( XMVECTOR V, XMMATRIX M );
XMVECTOR XMVector4Transform( XMVECTOR V, XMMATRIX M );

XMVECTOR XMVector2TransformCoord( XMVECTOR V, XMMATRIX M );
XMVECTOR XMVector3TransformCoord( XMVECTOR V, XMMATRIX M );
XMVECTOR XMVector4TransformCoord( XMVECTOR V, XMMATRIX M );

XMVECTOR XMVector2TransformNormal( XMVECTOR V, XMMATRIX M );
XMVECTOR XMVector3TransformNormal( XMVECTOR V, XMMATRIX M );
XMVECTOR XMVector4TransformNormal( XMVECTOR V, XMMATRIX M );

There is also a stream version of each of these functions. Using the 2D vector version of this function as an example, the parameters include the address to the output array the data will be saved, the size in bytes between each output vector, the input array of vectors you are supplying to be transformed, the size in bytes between each input vector, the total number of vectors being transformed, and the matrix by which these vectors will be transformed. The function prototype for the XMVector2TransformStream function can be seen as follows:

XMFLOAT4* XMVector2TransformStream(
    XMFLOAT4 *pOutputStream,
    UINT OutputStride,
    CONST XMFLOAT2 *pInputStream,
    UINT InputStride,
    UINT VectorCount,
    XMMATRIX M
);

An alternative to XMVector2Transform is XMVector2TransformNC, where NC refers to non-cached memory.

There is a special matrix that you should be aware of called the identity matrix. This is the default matrix. It contains values that reset scaling to 1, with no rotations and no translation taking place. The identity matrix is created by zeroing out all 16 values in the matrix and then applying ones along the diagonal. The identity matrix can be used as a starting point for all matrix operations. Multiplying a matrix with an identity matrix has no affect, and transforming an object by an identity matrix does nothing, since the matrix has no translation, no scaling, and no rotation.

Following is an identity matrix:

float matrix [4][4] =
{
    1.0f, 0.0f, 0.0f, 0.0f,
    0.0f, 1.0f, 0.0f, 0.0f,
    0.0f, 0.0f, 1.0f, 0.0f,
    0.0f, 0.0f, 0.0f, 1.0f
};

Creating an identity matrix in XNA Math is as simple as calling the XMMatrixIdentity function. This function takes no parameters and returns an XMMATRIX object loaded as an identity matrix. The function prototype for this function is:

XMMATRIX XMMatrixIdentity( );

One of the transformations you can apply to an object is scaling. Scaling is the ability to shrink or enlarge an object by a certain factor. For instance, if you have a square centered on the origin that was two units wide and two units tall and you scaled it twice in size, you would have a square that now went four units in each direction (i.e., twice its original size).

Remember the ones that were placed into the identity matrix? Those ones control the scaling on each of the three axes. When vertices are transformed using this matrix, their X, Y, and Z values are altered based on the scaling values. By changing the X axis value to 2 and the Y axis to 3, the objects will be scaled twice their size in the X direction and three times their size in the Y. An example ScaleMatrix array is shown next. The variables scaleX, scaleY, and scaleZ show where the appropriate scaling values would go.

float ScaleMatrix [4][4] =
{
    scaleX, 0.0f, 0.0f, 0.0f,
    0.0f, scaleY, 0.0f, 0.0f,
    0.0f, 0.0f, scaleZ, 0.0f,
    0.0f, 0.0f, 0.0f, 1.0f
};

In XNA Math we can use the function XMMatrixScaling to create a scaling matrix. This function takes as parameters the X, Y, and Z scaling factors and returns an XMMATRIX that represents this scale in matrix form. The function prototype can be seen as follows:

XMMATRIX XMMatrixScaling( FLOAT ScaleX, FLOAT ScaleY, FLOAT ScaleZ);

The act of moving an object is called translation. Translation allows for an object to be moved along any of the three axes by specifying the amount of movement needed. For example, if you want to move an object right along the X axis, you would need to translate that object an appropriate number of units in the positive X direction. To do so, you would need to create a translation matrix.

Again, we’ll start with the identity matrix and change it to add in the variables that affect translation. Take a look at the following translation matrix; the variables moveX, moveY, and moveZ show you where the translation values would go. If you wanted to translate an object four units to the right, you would replace moveX with the value 4.

float matrix [4][4] =
{
    1.0f, 0.0f, 0.0f, 0.0f,
    0.0f, 1.0f, 0.0f, 0.0f,
    0.0f, 0.0f, 1.0f, 0.0f,
    moveX, moveY, moveZ, 1.0f
};

In XNAMath we create a translation matrix by calling XMMatrixTranslation , which takes as parameters the X, Y, and Z translation values and has the following function prototype:

XMMATRIX XMMatrixTranslation( FLOAT OffsetX, FLOAT OffsetY, FLOAT OffsetZ );

The final effect we’ll describe is rotation. Rotation is the act of turning an object around a certain axis. This allows objects to change their orientation within space. For instance, if you wanted to rotate a planet, you would create a rotation matrix and apply it to the planet.

Rotation matrices take a little more explanation because the matrix needs to change based on the axis you’re trying to rotate around.

When rotating around any axis, it will require you to convert the angle of rotation into both a sine and a cosine value. These values are then plugged into the matrix to cause the proper amount of rotation. When rotating around the X axis, the sine and cosine values are placed into the matrix in the following manner.

float rotateXMatrix[4][4] =
{
    1.0f, 0.0f, 0.0f, 0.0f
    0.0f, cosAngle, sinAngle, 0.0f,
    0.0f, -sinAngle, cosAngle, 0.0f,
    0.0f, 0.0f, 0.0f, 1.0f
};

Rotating around the Y axis requires only that the sine and cosine values be moved to different positions within the matrix. In this instance, the values are moved to affect the X and Z axes as shown in the following manner.

float rotateYMatrix[4][4] =
{
    cosAngle, 0.0f, -sinAngle, 0.0f,
    0.0f, 1.0f, 0.0f, 0.0f,
    sinAngle, 0.0f, cosAngle, 0.0f,
    0.0f, 0.0f, 0.0f, 1.0f
};

The final rotation matrix allows for rotation around the Z axis. In this instance, the sine and cosine values affect the X and Y axes.

float rotateZMatrix[4][4] =
{
    cosAngle, sinAngle, 0.0f, 0.0f,
    -sinAngle, cosAngle, 0.0f, 0.0f,
    0.0f, 0.0f, 1.0f, 0.0f,
    0.0f, 0.0f, 0.0f, 1.0f
};

In XNA Math we have quite a few different options for creating a rotation matrix. We can rotate along a single axis as we’ve already discussed to create three separate rotation matrices, which we can then combine into one with the following functions:

XMMATRIX XMMatrixRotationX( FLOAT Angle );
XMMATRIX XMMatrixRotationY( FLOAT Angle );
XMMATRIX XMMatrixRotationZ( FLOAT Angle );

We can also rotate using Yaw, Pitch, and Roll values by using the following XNA Math functions:

XMMATRIX XMMatrixRotationRollPitchYaw(
    FLOAT Pitch,
    FLOAT Yaw,
    FLOAT Roll
);


XMMATRIX XMMatrixRotationRollPitchYawFromVector(
    XMVECTOR Angles
);

Pitch is the rotation in radians (not degrees) for the X axis, Yaw is the rotation in radians for the Y axis, and Roll is the rotation in radians for the Z axis. By specifying all three of these angles in radians we can use the XMMatrixRota-tionRollPitchYaw function to build one rotation matrix that combines all three axis rotations instead of creating three separate rotation matrices using XMMa-trixRotationX etc. and combining the three together into one final rotation matrix.

Other options of rotation include rotating around an axis where we provide an axis to rotate about and an angle in radians that describes by how much to rotate. This is done using XMMatrixRotationAxis:

XMMATRIX XMMatrixRotationAxis( XMVECTOR Axis, FLOAT Angle );

We can also rotate around a normal vector by using XMMatrixRotationNormal:

XMMATRIX XMMatrixRotationNormal( XMVECTORNormalAxis, FLOAT Angle );

And we can also rotate around a quaternion using XMMatrixRotationQuaternion:

XMMATRIX XMMatrixRotationQuaternion( XMVECTOR Quaternion );

A quaternion is another mathematical object we can use to represent rotation in graphics programming. The topic of quaternions is more advanced than matrices and is definitely something you will encounter when you touch upon advanced character animation techniques, such as skinned animation using bones (skeleton).

The last thing you need to learn about matrices is how to combine them. Most of the time, you won’t need to only translate an object, you’ll need to scale it or maybe rotate it all in one go. Multiple matrices can be multiplied, or concatenated, together to create a single matrix that is capable of containing the previously single calculations. This means that instead of needing a matrix for rotation as well as one for translation, these two can be combined into one.

Depending on the platform and intrinsic used, in XNA Math we could use the overloaded multiplication operator. The following single line of code demonstrates this.

XMMATRIX finalMatrix = rotationMatrix * translationMatrix;

A new matrix called finalMatrix is created, which now contains both the rotation and translation. This new matrix can then be applied to any object going through the pipeline. One thing to mention though is to watch out for the order in which you multiply matrices. Using the previous line of code, objects will be rotated first and then translated away from that position. For example, rotating the object 90 degrees around the Y axis and then translating it four units along the X axis would cause the object to be rotated in place at the origin and then moved four units to the right. When creating a world matrix, you should combine the various matrices as scaling × rotation × translation.

If the translation appeared first, the object would be translated four units to the right of the origin first and then rotated 90 degrees. Think what would happen if you extended your hand to your right and then turned your body 90 degrees— where would your hand end up? Not exactly in the same place as before; you need to make sure that the order in which you multiply the matrices is the order you really want them applied.

In XNA Math we can also multiply matrices using the function XMMatrixMul-tiply, which takes as parameters two matrices to multiply together and returns the resulting matrix. Its prototype can be seen as follows:

XMMATRIX XMMatrixMultiply( XMMATRIX M1, XMMATRIX M2 );

Matrix concatenation is another term for matrix multiplication.

XNA Math has a list of compiler directives used to tune how XNA Math is compiled and used within an application. These compiler directives give developers the ability to specify their applications’ functionality and include the following:

_XM_NO_INTRINSICS_ defines that no intrinsic types are to be used and that the XNA Math library will only use standard floating-point precision when performing its operations. This can be seen as the behavior that will allow an application to use XNA Math with no special optimizations or functionality.

_XM_SSE_INTRINSICS_ is used to enable the use of SSE and SSE2 intrinsic types on platforms that support it. This define has no effect on platforms that do not support SSE and SSE2. SSE and SSE2 are types of SIMD (single-instruction multiple data) operations that aim to boost performance by providing instruction-level parallelism, or in other words allow multiple operations to be done on multiple pieces ofdata at the same time. SIMD is discussed in more detail later in this chapter under the subsection “SIMD.” SSE stands for Streaming SIMD Extension.

_XM_VMX128_INTRINSICS_ is used to define that the Xbox 360 target use the VMX128 intrinsic but has no effect on other platforms. VMX is another SIMD set of instructions. VMX128 is an extension of the VMX set for use in Xenon processors, which is found inside the Xbox 360. Using this intrinsic should be done if the game is being targeted toward the Xbox 360.

XM_NO_ALIGNMENT is used to define that no alignment should be made to the data. For example, the XMMATRIX type structure will not be aligned to 16 bytes using this directive. This is not defined by default since by default alignment takes places.

XM_NO_MISALIGNED_VECTOR_ACCESS is used to improve the performance of the VMX128 intrinsic when operating on write-combined memory. This affects the Xbox 360’s Xenon processor.

XM_NO_OPERATOR_OVERLOADS is used to disable the use of C++ style operator overloads. By default this is not defined, but it can be used to force the omission of overloaded operators.

XM_STRICT_VECTOR4 is used to determine if the X, Y, Z, and W components of the XMVECTOR and XMVECTORI types can be directly accessed (e.g., float × Val = vec.x). This only affects Xbox 360 targets that are defined using the __vector4 intrinsic type and has no effect on Windows targets using the __m128 type. Accessor functions can be used to access members of these structures when this strict directive is used.

Compiler constants provide useful information to developers using the XNA Math library. The list of constants and what each one represents can be seen in the following:

Macros are available in XNA Math to provide extra functionality for common operations such as comparison operations, min and max determination, asserts, and the ability to mark objects as global. The complete list ofXNA Math macros is seen in the following:

XMASSERT provides debugging information by using assertions that are raised when a condition is false. This macro takes the expression to test and will include the file and line information for you.

XMGLOBALCONST is used to specify an object as a “pick-any” global constant and is used to reduce the size of the data segment and avoid reloads of global constants that are used and declared in multiple places within the XNA Math library.

XMComparisonAllFalse is used to compare all components and to return true if they all evaluate to false.

XMComparisonAllTrue is used to compare all components and to return true if they all evaluate to true.

XMComparisonAllInBounds is used to test if all components are within the allowed bounds. True is returned if they are all within the bounds.

XMComparisonAnyFalse returns true if any, not necessarily all, of the components evaluate to false.

XMComparisonAnyOutOfBounds returns true if any, not necessarily all, of the components are out of bounds.

XMComparisonAnyTrue returns true if any component, not necessarily all, evaluates to true.

XMComparisonMixed returns true if some of the components evaluated to true while others evaluated to false.

XMMax compares two types and returns the one determined to be larger using the operator <.

XMMin compares two types and returns the one determined to be smaller using the operator <.

The goal of these various structures and types is to encapsulate their functionality to make them easier to code with, easier to obtain portability, and allows for data optimizations. All of these structures and types are exposed via the header file xnamath.h. So far we’ve briefly touched upon a few vector and matrix structures, but in this section we will look at all of them.

The first sets of structures we will look at are the following:

The XMBYTE4 structure is used to create a four-component vector where each component is 1 byte (using the char data type). The XMBYTEN4 is similar to the XMBYTE4 structure with the exception that XMBYTEN4 is used to store normalized input. When XMBYTEN4 is initialized, its inputs are multiplied by 127.0f and scaled to fit the range 0.0 - 1.0f. Input data are to be in the range of -127.0f and 127.0f when using XMBYTEN4.

XMCOLOR is a 32-bit color structure that stores red, blue, green, and alpha color channels. Each channel is an unsigned 8-bit value, where all four 8-bit channels total 32 bits for the entire structure. This is the same as XMBYTE4.

The XMDEC4 structure uses 10 bits for the X, Y, and Z components and uses 2 bits for the W. This totals 32 bits for the structure. XMDECN4 stores normalized values. On the other hand, XMDHEN3 stores 10 bits for the X component and stores 11 bits for the Y and Z components. XMDHENN3 stores the normalized values of a XMDHEN3. These can be used if you need structures that provide more bits per component while totaling 32 bits in all.

The next set of structures deals with 2D components:

XMFLOAT2 was mentioned earlier in this chapter and is used to represent a 2D floating-point vector. XMFLOAT2A represents a 16-byte boundary aligned XMFLOAT2.

XMHALF2 is a 2D vector used to store half-precision 16-bit floating-point components (instead of 32 bits per component), whereas XMSHORT2 is a 2D vector storing half-precision 16-bit integer components. The U after XM for these structures are used to specify that they are unsigned, and the N that follows the number of components at the end of the names represents that they store normalized values. Therefore the appearance ofa U and N represents an unsigned normalized structure.

The next list displays all structures that are based on three components:

XMFLOAT3, which was mentioned in the “Vectors” section earlier in this chapter, is a three-component structure of floating-point values. XMFLOAT3A is used for 16-byte aligned three-component vectors. XMFLOAT3PK is used for three-component vectors, where the X and Y components are 10 bits each, and the Z is 11 bits, whereas XMFLOAT3SE is a vector where the components use nine bits for the mantissa and five bits for the exponent.

XMDHEN3 (and its normalized form XMDHENN3) are 3D integer vectors with 10 bits for the X components and 11 bits for the Y and Z. The XMHEND3 and XMHENDN3 are used to store 11 bits for the X and Y and 10 bits for the Z components. The unsigned versions of these are XMUDHEN3 and XMUDHENN3.

The XMU555 is used to create a three-component vector that uses five bits for each component. The XMU565 creates a three-component vector that uses five bits for the X and Z components but uses six bits for the Y.

The next list displays the 4D vector structures in the XNA Math library:

XMFLOAT4 is a four-component floating-point vector that was mentioned in the “Vectors” section of this chapter. XMHALF4 is a half-precision 4D vector, and XMSHORT4 is half-precision using short integers. Again, the A that follows the structure names is for byte-aligned structures, while N is for normalized versions of them.

XMUBYTE4 is for a four-component unsigned byte (char) structure, and XMUNIB-BLE4 uses four 4-bit integer components. The structures with ICO in their names use 20 bits for the X, Y, and Z components while using four bits for the W, which totals 64 bits for the ICO structures. The structures with DEC in their names use 10 bits for the X, Y, and Z components and two bits for the W, which totals 32 bits for the DEC structures. The XICO and XDEC structures use signed values, whereas UICO and UDEC use unsigned values.

The next list of structures is related to matrices:

XMFLOAT3x3 represents a 3 × 3 matrix of floating-point values (9 in total) and is usually used to represent rotation matrices. XMFLOAT4x3 represents 4 × 3 matrices (12 elements in total), and XMFLOAT4x4 represents 4 × 4 matrices (16 elements in total). The A that follows the structure names indicates that they are aligned structures. XMMATRIX is a row-major 4 × 4 byte-aligned matrix that maps to four vector hardware registers.

The final list that we’ll look at includes the additional types available using XNA Math. These additional types are listed as follows:

The HALF data type, which is aliased by USHORT, is a 16-bit floating-point number. It uses five bits for the exponent and 10 for the mantissa and has a sign bit.

The XMVECTOR structure is a four-component structure where each component is represented by 32 bits. This structure can use floating-point numbers or integers and is also optimally aligned and mapped to a hardware vector register. XMVECTOR was discussed in the “Vectors” section of this chapter.

The XMVECTORF32 is a portable 32-bit floating-point structure used by C++ initializer syntax to initialize a XMVECTOR structure to use floating-point values.

The XMVECTORI32 is a portable 32-bit integer structure used by C++ initializer syntax to initialize a XMVECTOR structure to use integer values.

The XMVECTORU32 is a portable structure used by C++ initializer syntax to initialize a XMVECTOR structure to use unsigned integer values (UINT).

The XMVECTORI32 is a portable 8-bit structure used by C++ initializer syntax to initialize a XMVECTOR structure to use byte values (char ).

In this section we will briefly discuss the additional functions available through XNA Math that we have yet to touch upon. These functions deal with colors, conversions, and scalars. The first type we’ll discuss is the color functions.

XMVECTORXMColorAdjustContrast( XMVECTOR C, FLOAT Contrast );

XMVECTORXMColorAdjustSaturation( XMVECTOR C, FLOAT Saturation );

BOOL XMColorEqual( XMVECTOR C1, XMVECTOR C2 );
BOOL XMColorNotEqual( XMVECTOR C1, XMVECTOR C2 );

BOOL XMColorGreater( XMVECTOR C1, XMVECTOR C2 );
BOOL XMColorGreaterOrEqual( XMVECTOR C1, XMVECTOR C2 );

BOOL XMColorLess( XMVECTOR C1, XMVECTOR C2 );
BOOL XMColorLessOrEqual( XMVECTOR C1, XMVECTOR C2 );

BOOL XMColorIsInfinite( XMVECTOR C );
BOOL XMColorIsNaN( XMVECTOR C );

XMVECTOR XMColorModulate( XMVECTOR C1, XMVECTOR C2 );
XMVECTOR XMColorNegative( XMVECTOR C );

XMVECTOR col, result;

result.x = 1.0f - col.x;
result.y = 1.0f - col.y;
result.z = 1.0f - col.z;
result.w = 1.0f - col.w;

HALF XMConvertFloatToHalf FLOAT Value );

FLOAT XMConvertHalfToFloat( HALF Value );

HALF* XMConvertFloatToHalfStream( HALF* pOutputStream, UINT OutputStride,
    CONST FLOAT* pInputStream, UINT InputStride, UINT FloatCount );

FLOAT* XMConvertHalfToFloatStream( FLOAT *pOutputStream, UINT OutputStride,
    CONST HALF* pInputStream, UINT InputStride, UINT HalfCount );

FLOAT XMConvertToDegrees( FLOAT fRadians );
FLOAT XMConvertToRadians( FLOAT fDegrees );

XMVECTOR XMConvertVectorFloatToInt( XMVECTOR VFloat, UINT MulExponent );
XMVECTOR XMConvertVectorFloatToUInt( XMVECTOR VFloat, UINT MulExponent );

XMVECTOR XMConvertVectorIntToFloat( XMVECTOR VInt, UINT DivExponent );
XMVECTOR XMConvertVectorUIntToFloat( XMVECTOR VUInt, UINT DivExponent );

FLOAT XMScalarCos( FLOAT Value );
FLOAT XMScalarCosEst( FLOAT Value );

FLOAT XMScalarSin( FLOAT Value );
FLOAT XMScalarSinEst( FLOAT Value );

FLOAT XMScalarACos( FLOAT Value );
FLOAT XMScalarACosEst( FLOAT Value );

FLOAT XMScalarASin( FLOAT Value );
FLOAT XMScalarASinEst( FLOAT Value );

FLOAT XMScalarSinCos( FLOAT Value );
FLOAT XMScalarSinCosEst( FLOAT Value );

FLOAT XMScalarModAngle( FLOAT Value );
BOOL XMScalarNearEqual( FLOAT S1, FLOAT S2, FLOAT Epsilon )

Everything in this chapter is related not only to graphics but also to game physics. Physics is a huge part of 3D game development and cannot be avoided when creating realistic simulations. Physics in games usually deals with point masses, rigid bodies, and soft bodies.

Point masses are physics objects that have their linear velocities and positions updated but have no applied rotations. These are often the easiest to start with for beginners and are common for many simulations in games, including particle systems.

Rigid bodies are often used for objects in the scene that can have forces acting upon them that causes them to not only have forces applied to their position and velocity but also their angular movements. This is used for things like crates and other objects as they react to explosions and other forces that cause them to realistically move throughout the scene by moving and rotating as they interact with the world. Another example can be seen with rag-doll bodies, where enemies can fall down a flight of stairs realistically as they collide with the environment. Rigid bodies do not deform in shape.

Soft bodies are not used as often as the other two but are used to simulate objects that can deform in shape. Epic’s Unreal game engine has support for soft bodies.

Collision detection and response is the act of detecting when one or more objects collide and resolving those collisions by applying forces on them or restricting their movements. This is done so that objects never penetrate one another and so that they react as you would expect them to when they touch. Physics in games is applying forces on objects so that they behave as designed within the environment. Collision detection allows us to catch objects that start to penetrate each other as a result of these forces acting upon them, and the response to collision allows us to deal with that collision realistically to add further to the simulation. Although they can go hand in hand, physics and collision detection are separate subjects that meet to create the complete simulation the designers intended.