Direct3D Mobile Application Operation (Windows Embedded CE 6.0)
After your application has created and initialized the appropriate resources you can have it enter its rendering loop to animate your application's scene. This loop is also sometimes called the main loop. You can drive your application's rendering loop by taking user input, watching an external clock, listening for windows messages, or by simply letting your application draw its scenes as quickly as possible.
The following list shows the typical sequence of operations for an application's rendering loop.
Change the appropriate render states, see IDirect3DMobileDevice::SetRenderState.
Clear the render target, the depth buffer, and the stencil buffer to a known initial value, see IDirect3DMobileDevice::Clear.
Begin the scene, see IDirect3DMobileDevice::BeginScene.
Draw the primitives, see IDirect3DMobileDevice::DrawPrimitive and IDirect3DMobileDevice::DrawIndexedPrimitive.
End the scene, see IDirect3DMobileDevice::EndScene method.
Present the scene see IDirect3DMobileDevice::Present.
This typical sequence of operations is not the only possible sequence. The following sections provide greater detail on the operations listed in the typical sequence. You can draw on this information to help you implement any of a number of variations of this typical sequence to best serve the design goals for you application.
Clearing is the process of setting pixels values of surfaces in the swap chain to a known value. You can clear an entire surface or just an array of sub rectangles. You can clear any combination of the render target color buffer, stencil buffer, or depth buffer.
You can clear the current swap chain by calling the IDirect3DMobileDevice::Clear method. This method lets you identify the buffers you want to clear, any sub rectangles, and the values that you want to clear the color, depth and stencil buffers to.
You clear the color buffer with a 32 bit ARGB value of type D3DMCOLOR. You clear the depth buffer with an IEEE 32 bit floating point value where 0.0 represents the nearest distance to the viewer and 1.0 represents the farthest. Values outside of the range 0.0 to 1.0 cause the IDirect3DMobileDevice::Clear method to fail in debug D3DM middleware builds. The behavior in release builds is undefined. You clear the stencil buffer with an unsigned integer value between 0 and 2^n - 1 where n is the number of bits in the stencil channel.
You can command the IDirect3DMobileDevice::Clear method to clear the entire area of the various surfaces. It may also take an optional array of RECT structures that describe sub-rectangles of the surface to clear. The size of the Microsoft® Direct3D Mobile® command buffer limits the number of rectangles that can be cleared by a single call to this method 1024.
Using the IDirect3DMobileDevice::DrawPrimitive method requires you to specify the primitive type, the number of vertices of offset in the vertex buffer, and the number of primitives to draw. The middleware automatically reads successive groups of vertices appropriate for the primitive type from the vertex buffer.
Using the IDirect3DMobileDevice::DrawIndexedPrimitive method is slightly more complicated. You must also specify the primitive type, however instead of reading vertices sequentially from the vertex buffer, this method reads indices sequentially from the index buffer. The index is the offset, counted in vertices, of the vertex. Using an index buffer allows vertices to be shared among primitives without replicating the vertex data in the vertex buffer.
As part of the design of Direct3D Mobile, both of these drawing methods actually result in Direct3D Mobile cause the middleware to write command tokens into the command buffer. The middleware does not send these commands to the driver until you flush the command buffer.
Direct3D Mobile uses the concept of a scene. A scene is a block of drawing commands made between a call to the IDirect3DMobileDevice::BeginScene method and a call to the IDirect3DMobileDevice::EndScene method. Explicitly marking when drawing commands will occur by containing them within a scene allows the driver optimize its setup and internal state. A side effect of this optimization is that changing driver states within a scene may result in a higher performance penalty than changing them outside of the scene.