Chapter 1. Introducing DirectX

DirectX is a set of APIs for developing game-or graphics-related applications on Microsoft platforms, including Windows, Windows Phone, Xbox 360, and the new Xbox One. DirectX has been evolving since the mid-1990s and is at the leading edge of modern graphics development. Direct3D is the 3D graphics API within DirectX, and this book focuses its attention there. DirectX also includes systems for 2D graphics, input, audio, text rendering, and general-purpose GPU programming. This chapter provides an overview of DirectX and the DirectX 11 graphics pipeline.

During this same period, 3D graphics hardware was in a similar state of rapid advancement. Consider that, before the mid-1990s, low-cost, consumer-oriented 3D graphics hardware simply didn’t exist. Early 3D graphics cards offered fixed-function APIs—feature sets that were specific to the graphics card and could not be modified or extended by a graphics developer. With the 2001 release of the Xbox, the nVidia GeForce 3, and DirectX 8, developers were first widely introduced to programmable shaders. Programmable shaders enable developers to manipulate a 3D object as it passes through the graphics processing unit (GPU), also known as a graphics card, and define its output pixel by pixel. Under DirectX 8, shaders were written in assembly language, but in 2002, with the release of DirectX 9, Microsoft introduced the High-Level Shading Language (HLSL), a C-styled programming language for writing shaders.

In November 2005, Microsoft launched the Xbox 360 and a console cycle that lasted until November 2013 (the longest such cycle since the introduction of game consoles). The Xbox 360 employed a flavor of DirectX 9. A year later, in November 2006, Microsoft released Windows Vista and, with it, DirectX 10. However, during this time, consoles dominated the video game market, and the Xbox 360 supported DirectX 9 only. Thus, few developers embraced DirectX 10, and those who did were limited to the PC platform for DirectX 10 features. Additional factors that likely suppressed large-scale adoption of DirectX 10 were the major changes between DirectX 9 and DirectX 10 and the poor adoption of Windows Vista.

Windows 7 launched in July 2009, followed shortly by DirectX 11. This latest release represented relatively minor changes from DirectX 10 (compared with those of the earlier iteration). DirectX 11 introduced DirectCompute, Microsoft’s API for general-purpose GPU (GPGPU) programming, tessellation support, and improved multithreading. Around this time, the PC game market began a resurgence in popularity, due in part to digital distribution platforms like Valve’s Steam, as well as aging consoles. These factors almost certainly contributed to the increasing number of developers who began adopting the updated libraries. Then in fall 2012, Microsoft released Windows 8 and Windows Phone 8, along with DirectX 11.1. This is the version this book focuses on, and all of Microsoft’s most recent platforms, including the new Xbox One, support it.

Although this is a book about DirectX, I would be remiss if I didn’t mention OpenGL, a competing graphics library that evolved during this same time period. OpenGL is a cross-platform rendering API that Silicon Graphics Inc. first released in 1991. As of this writing, the latest version of OpenGL is the 4.4 specification (released in July 2013), and the Kronos Group manages the API. Although they have significant differences in design, modern OpenGL and DirectX generally support the same rendering capability. Thus, the choice of DirectX or OpenGL is largely a question of platform. DirectX is specific to Microsoft platforms, and graphics vendors widely support it, given the dominance of the Microsoft Windows operating system on desktop computers. OpenGL, on the other hand, is not specific to a particular platform and has gained wide adoption in the mobile development space.

And so, with a bit of history under our belt, we begin.

Direct3D is the API within DirectX that we’re primarily concerned with. Put simply, Direct3D is the system you use to draw 3D graphics, and it defines a sequence of steps you use to present graphics to the screen. These steps are known as the Direct3D graphics pipeline (see Figure 1.1). In this figure, the arrows depict the flow of data from one stage to the next. The large rectangle spanning the right of the figure designates resources within GPU memory, and bi-directional arrows indicate read/write capability between a stage and these resources. Stages that are programmable (using HLSL) are shown as rounded rectangles. The following sections describe each stage in the pipeline.

Figure 1.1 The Direct3D 11 graphics pipeline.

Figure 1.2 3D primitives: point (left), line (middle), triangle (right).

Figure 1.3 Vertices and indices for a 3D quadrilateral.

Now, you might be thinking, “How does adding an index buffer decrease the total size of the data I’m using?” Well, if your vertex data is composed of just a 3D position (x, y, z), where each component is a 32-bit floating point number (4 bytes per component), then each vertex is 12 bytes. Without an index buffer, your vertex buffer will be filled with 72 bytes of data (6 vertices × 12 bytes/vertex = 72 bytes). With an index buffer, your vertex buffer becomes 48 bytes (4 vertices × 12 bytes/vertex). If you use 16-bit integers for your indices, then your index buffer is a total of 12 bytes (6 indices × 2 bytes/index = 12 bytes). Combined, the total size of the vertex and index buffers is 60 bytes (48-byte vertex buffer + 12-byte index buffer). You see hardly any savings at all. But consider passing additional vertex data—perhaps a 16-byte color, a 12-byte normal, and 8 bytes of texture coordinates. That’s an additional 36 bytes per vertex saved for each vertex shared between two triangles. This really adds up when loading meshes with hundreds or thousands of vertices. Furthermore, you’re not concerned with just memory—you also need to consider the bus between the CPU and the GPU. Every bit of data that you employ must be transferred from the application to the video card over the graphics bus (such as PCI Express). This bus is slow (compared to CPU to RAM or GPU to VRAM), so reducing the amount of data you transmit is vital.

Point list

Line list

Line strip

Triangle list

Triangle strip

A point list is a collection of vertices that are rendered as individual, unconnected points. A line list, by contrast, connects pairs of points into line segments. However, these line segments are not connected as they are in a line strip. Furthermore, a line strip specifies its vertices not in pairs, but as a connect-the-dots-style sequence of points. Figure 1.4 illustrates these topologies.

Figure 1.4 Point list (left), line list (middle), and line strip (right).

A triangle list is the most common topology we’ll be working with. In a triangle list, each set of three vertices is interpreted as an isolated triangle. Any shared vertices are repeated (not withstanding our discussion of index buffers). By contrast, a triangle strip interprets vertices as a series of connected triangles in which shared vertices are not repeated. Figure 1.5 depicts both topologies.

Figure 1.5 Triangle list (top) and triangle strip (bottom).

Figure 1.6 Triangle list with adjacency.

A shader is a small program—a function, if you’d like—that you write and the GPU executes. A vertex shader operates on every vertex passing through the pipeline (the input to the shader), performing a series of instructions and passing output to the next active stage. As mentioned before, the input to the vertex shader is at least the position of the vertex. Generally, the vertex shader transforms the vertex in some way and outputs the modified or newly computed data. Listing 1.1 shows perhaps the simplest vertex shader we can create.

Listing 1.1 Your First Vertex Shader

Click here to view code image

float4 vertex_shader(float3 objectPosition : POSITION) : SV_Position
{
    return mul(float4(objectPosition, 1), WorldViewProjection);
}

Figure 1.7 A 3D model with low, medium, and high levels of detail. (3D Model by Nick Zuccarello, Florida Interactive Entertainment Academy.)

This image shows a 3D model with low, medium, and high levels of detail (LODs). Traditionally, LODs are authored by an artist, and a particular LOD is rendered based on the distance of the object from the camera.

With a traditional LOD system, you have a fixed amount of detail (polygon count) in your models. Hardware tessellation enables you to subdivide an object dynamically and without the cost of additional geometry passed to the input-assembler stage. This allows for a dynamic LOD system and less utilization of the graphics bus (both good things). In Direct3D 11, these three stages correspond to tessellation:

The hull shader stage (HS)

The tessellator stage

The domain shader stage (DS)

The hull and domain shader stages are programmable; the tessellator stage is not. We cover the topic of tessellation in more detail in Chapter 21.

Connected to the GS stage is the stream-output stage (SO). This stage streams in the vertices output from the geometry shader and stores them in memory. For multipass rendering, this data can be read back into the pipeline in a subsequent pass, or the CPU can read the data. As with the tessellation stages, the geometry shader stage is optional. We discuss geometry shaders and multipass rendering in more detail in Part IV, “Intermediate-Level Rendering Topics.”

The rasterizer stage determines what, if any, pixels should be rendered and passes those pixels to the pixel shader stage. Along with the pixels to render, the rasterizer passes per-vertex values interpolated across each primitive. For example, a triangle primitive has three vertices, each of which contains at least a position and potentially additional data such as color, normal, and texture coordinates. This vertex data is interpolated for the in-between pixels the rasterizer computes. Figure 1.8 illustrates this concept for vertex colors. In this image, the three points of the triangle are supplied with a red, green, and blue vertex color, respectively. Notice how the pixels within the triangle change color relative to their proximity to the three vertices. The rasterizer stage produces those interpolated colors.

Figure 1.8 Rasterizer interpolation for a triangle with red, green, and blue colors specified for the three vertices.

Listing 1.2 Your First Pixel Shader

Click here to view code image

float4 pixel_shader() : SV_Target
{
    return float4(1, 0, 0, 1);
}

The OM stage also determines which pixels are visible in the final render through processes known as depth testing and stencil testing. Depth testing uses data that has previously been written to the render target to determine whether a pixel should be drawn. Consider the scenario in Figure 1.9. In this figure, a number of objects are closer to the camera than others, but they otherwise represent the same screen space. These objects occlude the ones behind them either entirely or in part. Depth testing makes use of the distance between the object and the camera for each corresponding pixel written to the render target. Most commonly, if the pixel already in the render target is closer to the camera than the pixel being considered, the new pixel is discarded.

Figure 1.9 A scene illustrating depth testing, with some objects occluding others.

Stencil testing uses a mask to determine which pixels to update. This is conceptually similar to a cardboard or plastic stencil you might use to paint or print a design on a physical surface. We discuss depth and stencil testing in more detail in Part III, “Rendering with DirectX.”

This is just the beginning—the coming chapters expand upon all these topics and much more.