Complete the basic steps of drawing an entity __directx

1.d3d steps to draw from 0 to one entity
(1). Initialize D3D (LPDIRECT3D9) and device (Lpdirect3ddevice9) objects.
The main role here is: Set the number of back buffer, format, as well as the buffer after the Swapbuffer processing methods, such as the contents of the back buffer is deleted or back to the contents of the buffer changes; whether to enable Z-buffer or template caching And the two cached formats, full screen rendering and anti-aliasing, and so on.
(2). Prepare vertex data: Let VB (vertex buffer) and device associated, and write a set of known data into VB
(3). Clear back buffer current buffer (also can have depth buffer, template buffer), set the world matrix, projection matrix and viewpoint
(4). Set device current VB, and set this VB format, and then draw the entity
(5). End of program, release resources.

The contents of (1), (3), (5) can be found in << from 0 to the first D3D program >>

2. Description of preparation of data for step (2)
(1) The concept of vertex caching and the method of creation
Vertex caching is a contiguous memory space that is allocated and managed by D3D and is used to store vertex data.
The contents of vertex data can include vertex (x,y,z) coordinate data, vertex color data (diffuse), texture coordinate data, and so on.

Vertex buffering, like the D3d object, is also an object: Lpdirect3dvertexbuffer9, which is also managed by D3D.

The way to assign memory to a VB object and set the properties of this VB object in device is:
HRESULT Idirect3ddevice9::createvertexbuffer (
UINT Length,
DWORD Usage,
DWORD FVF,
D3dpool Pool,
idirect3dvertexbuffer9** Ppvertexbuffer,
handle* Psharedhandle
);

length--the byte size assigned to the cache. If you want a vertex cache that can store 8 vertices, then we'll set this parameter to 8 * sizeof (VERTEX) in the vertex structure.
usage--Specifies additional information about how to use the cache. This value can be 0, no tag, or one or more combinations marked below:
d3dusage_dynamic--Setting this parameter allows the cache to be dynamic.
d3dusage_points--This parameter specifies the cache storage raw point. This parameter is used only in vertex buffering.
d3dusage_softwareprocessing--using software vertex processing
d3dusage_writeonly--specifies that the application can write caching only. It allows the driver to allocate the most appropriate memory address as a write cache. Note If you read data from this created cache, you will return an error message.
fvf--the vertex format stored in the cache.
The corresponding relationship between the data format of vertex buffers and the type of their values see: http://www.cnblogs.com/xmzyl/articles/1604096.html
The pool--cache is placed in which memory pool. We are using d3dpool_default, which means that the vertex buffer is in the video memory as much as possible.
ppvertexbuffer--returns a pointer to the created good vertex cache.
psharedhandle--is not used; set to 0.

Note: A cache created without using the d3dusage_dynamic parameter is called a static cache. Static caching is usually placed in memory, where the data can be handled very efficiently. However, for static caching, reading and writing data is slow because access to memory is slow. For this reason, we use static caching to store static data (no data that is constantly changed). Terrain and buildings are good candidates because they usually don't need to be changed in the application. Static caching should be populated when the application is initialized, rather than at run time.

Note: Caching created using the D3dusage_dynamic parameter is called dynamic caching. Dynamic caching is typically placed in AGP memory, which can be quickly updated. Processing data in dynamic caching is not faster than processing data in a static cache, because the data must be transferred to memory before rendering, and the benefit of dynamic caching is that they can be updated slightly faster (faster than the CPU). Therefore, if you need to update the data in the cache frequently, you should use dynamic caching. Particle systems are a good application because they are dynamic, and they are usually updated every frame.

Note: Reading video memory and AGP memory in a program is very slow. So, if you need to read your geometry at run time, the best solution is to specify a piece of system memory to copy and read the data.

(2) Vertex cache read and write
We read and write the data in the cache by getting a memory pointer to a vertex cache, using lock:
HRESULT Idirect3dvertexbuffer9::lock (
UINT Offsettolock,
UINT Sizetolock,
byte** Ppbdata,
DWORD Flags
);

The offsettolock--offset, in bytes, from the beginning of the cache to the distance from the start position of the lock.
sizetolock--the number of bytes locked.
ppbdata--a pointer to the starting position of the locked memory.
The flags--tag describes how to lock memory. It may be 0 or a combination of 1 or more of the following parameters:
d3dlock_discard--This parameter is only used in dynamic caching. It instructs the hardware to discard the cache and return a pointer to the newly allocated cache. This is useful because when we access a newly allocated cache it allows the hardware to continue rendering from the discarded cache. This prevents hardware latency.
d3dlock_nooverwrite--This parameter is only used in dynamic caching. It declares that you will add data to the cache. That is, you cannot write data to an already rendered memory. It's good because he lets you add new data to the cache while the hardware continues to render.
d3dlock_readonly--This parameter declares that the cache you are locking can only read data from and not write data. This allows for some intrinsic optimizations.
Use parameter D3dlock_discard and d3dlock_nooverwrite to indicate that a portion of the cache is locked and can continue to be used. If the hardware configuration allows these tags to be used, other display operations will not be interrupted when the cache is locked.

The example below shows how the lock method is usually used. Note that the Unlock method is invoked when we have finished using it.

vertex* vertices;
_vb->lock (0, 0, (void**) &vertices, 0); Lock entire Cache
Vertices[0] = Vertex ( -1.0f, 0.0f, 2.0f); Write vertices to cache
VERTICES[1] = Vertex (0.0f, 1.0f, 2.0f);
VERTICES[2] = Vertex (1.0f, 0.0f, 2.0f);
_vb->unlock (); When you are done accessing the cache, unlock the cache

3. Note to step (4)
Set the current VB for device, and set the format of this VB, and then draw an entity.
Steps:
M_pdevice->setstreamsource (0,m_pvb,0,sizeof CustomVertex);
M_PDEVICE-&GT;SETFVF (D3dfvf_customvertex);
M_pdevice->drawprimitive (d3dpt_linelist,0,3); The primitive type here is d3dpt_linelist, which is some segment.
Entity related can see: http://blog.csdn.net/niyongfu14/article/details/6617977

HRESULT SetStreamSource (
UINT Streamnumber,//render data stream serial number, the concept of data flow will be encountered in texture-related processing, now 0
Idirect3dvertexbuffer9 *pstreamdata,//bind vertex buffer pointer
UINT offsetinbytes,//The starting position of the render data stream for the bound connection
UINT Stride//render the memory size of a vertex in the data stream
);