Main Page   Modules   Alphabetical List   Data Structures   Data Fields  

Device Cache
[D3D9]

D3D9 RenderWare Graphics provides a variety of utility functions that should be used instead of the equivalent D3D9 API functions. These RenderWare functions are preferred in user applications since RenderWare Graphics maintains an internal cache that is used to optimize performance. This cache is only maintained when RenderWare functions are used.

The cache covers areas of D3D9 that control:

For details on the utility functions available in D3D9 RenderWare Graphics, refer to Platform Specific Functions.
Lazy State Updates
It should be appreciated that making renderstate and/or texturestate changes always incur a run-time cost. This cost is amplified when calls are made to change the state when it is already set in the required state. Hence in RenderWare Graphics, renderstate and texturestate changes are buffered until a "draw primitive" call is made, and then only the necessary state changes are made. This means that if muliple calls to set a particular render/texturestate have occurred since the last primitive was rendered, only the last instance is processed. This can considerably improve efficiency.

Note that in order to use the lazy updating of renderstates, the only functions that can be used to change the renderstates are RwRenderStateSet and RwD3D9SetRenderState.

Similarly, for texturestate lazy updates, the only function that can be explicitly used is RwD3D9SetTextureStageState.

Dynamic Vertex Buffer Managers
There are two management systems for dynamic vertex buffers in D3D9 RenderWare Graphics:

  1. for dynamic vertex buffers created by the application using RwD3D9DynamicVertexBufferCreate.
  2. for internally managed dynamic vertex buffers that can be accessed by applying for a lock on the next free buffer using RwD3D9DynamicVertexBufferLock.
The first manager will create dynamic vertex buffers as requested by the application and will reuse them as necessary, reducing both spatial and temporal overheads of unnecessarily deallocating and reallocating storage. The application is then free to do with that vertex buffer as they will, except destroying it using the D3D9 API functions. It is up to the application to determine when the vertex data can be overwritten. Hence these vertex buffers may be used for static vertex data. Once finished with, the vertex buffer should be made available for reuse by calling RwD3D9DynamicVertexBufferDestroy.

The second manager creates a number of dynamic vertex buffers of a predefined size when RwEngineStart is called. If the video card driver supports hardware TnL then four vertex buffers, each of 256 KB are created, otherwise only one 256 KB buffer is created. Hence there is an initial memory overhead of at most 1 MB. Subsequently the application may request a section of a vertex buffer to be locked with RwD3D9DynamicVertexBufferLock , and the manager determines the next free vertex buffer to use (this follows a cyclic path). A pointer to the vertex data is then provided and the section of storage requested is guaranteed to be available to the application. However, it may not be available for an indefinite amount of time since the vertex data will eventually be overwritten by a future lock request. Hence it is inadvisable that static vertex data be stored in this way. Once finished with, the vertex buffer should be unlocked with RwD3D9DynamicVertexBufferUnlock.


Criterion Software © 1993-2004 Criterion Software Limited. All rights reserved. Built Thu Feb 12 13:46:57 2004. Send Feedback