Graphics Reference
In-Depth Information
In addition to the render target, we also need to create a depth stencil buffer and a
corresponding depth stencil view for binding it to the pipeline. The code required to do this
is shown in Listing 1.9. Once again, this creation process is covered in detail in Chapter 2.
D3D11_TEXTURE2D_DESC desc;
desc.Width = width;
desc.Height = height;
desc.MipLevels = 1;
desc.ArraySize = 1;
desc.Format = DXGI_FORMAT_D32_FLOAT;
desc.SampleDesc.Count = 1;
desc.SampleDesc.Quality = 0;
desc.Usage = D3D11_USAGE_DEFAULT;
desc.BindFlags = D3D11_BIND_DEPTH_STENCIL;
desc.CPUAccessFlags = 0;
desc.MiscFlags = 0;
ID3DllTexture2D* pDepthStencilBuffer = 0;
HRESULT hr = m_pDevice->CreateTexture2D( &desc,
0, &pDepthStencilBuffer );
ID3DllDepthStencilView* pDepthview = 0;
HRESULT hr = m_pDevice->CreateDepthStencilView( pDepthStencilBuffer,
pDesc, &pDepthView );
Listing 1.9. The process of creating a depth stencil buffer, and a depth stencil view for using it.
Even though we won't be creating additional resources or objects in this sample, we can
still consider the types of items that should be created in this initialization routine. Essentially,
all Direct3D resources should be created in the initialization phase, unless a particular use
case absolutely requires that a resource be created and destroyed during runtime. For ex-
ample, if a particular texture is procedurally generated, and its size is dependent on some run-
time parameter, it would not be easy to create the texture during startup. However, it may be
worth considering changing the algorithm to allow early creation. In our example, this could
include just declaring one large resource that is shared by all objects that need such a proce-
dural texture. It is also acceptable to create a resource at startup and then modify its contents
during runtime, especially if the multithreading capabilities of Direct3D 11 are put to use.
In addition, all pipeline configurations should be pre-created. This includes any state
objects that would be used by fixed function stages, as well as the shader program objects
that would be used for the programmable shader stages. Since these items are typically
planned for well in advance, there shouldn't be any reason that they couldn't be created
at startup, instead of by using a dynamic loading scheme. Unless an application uses an
enormous number of these objects, they should not cause any issues with memory con-
sumption. In particular, the shader programs would need to read from the hard disk during
Search WWH ::




Custom Search