Archived

This topic is now archived and is closed to further replies.

lun123

strange TL-vertices behaviour

Recommended Posts

I get strange behaviour when rendering TL-vertices... (1) the device is created with D3DCREATE_SOFTWARE_VERTEXPROCESSING (2) the vertex buffer is created in this way: hr = g_pd3dDevice->CreateVertexBuffer( ..., // length D3DUSAGE_WRITEONLY, // usage D3DFVF_XYZRHW | D3DFVF_DIFFUSE, // FVF D3DPOOL_DEFAULT, // pool &m_pVB, // vertex buffer NULL ); // reserved Rendering using this VB is okay. But, when I changed the device from D3DCREATE_SOFTWARE_VERTEXPROCESSING to D3DCREATE_HARDWARE_VERTEXPROCESSING, rendering the VB shows up nothing. I run more tests, and get the following behaviour (when the vb is holding TL-vertices): device: D3DCREATE_SOFTWARE_VERTEXPROCESSING, vb: D3DPOOL_DEFAULT or D3DPOOL_MANAGED --- all okay device: D3DCREATE_HARDWARE_VERTEXPROCESSING vb: D3DPOOL_DEFAULT --- nothing shows up vb: D3DPOOL_MANAGED --- okay Why is that?? [edited by - lun123 on August 6, 2003 8:40:09 AM]

Share this post


Link to post
Share on other sites
1) Use the debug runtime and check if there are any errors or warnings reported to your debug output window

2) Try setting D3DRS_CLIPPING=FALSE. If that fixes it, then make sure you have a valid viewport and valid (sensible with respect to what your XYZRHW vertices say) projection matrix.

3) If none of your XYZRHW stuff ever goes outside of the viewport, leave D3DRS_CLIPPING as FALSE anyway. It''ll prevent D3D or the chip needing to back transform (i.e. by the inverse of the projection - which is why it needs to be valid) to clip.

4) Never *assume* anything about defaults either. Set *known* values for all states that matter to you. Even if you don''t think that particular primitive uses them.

--
Simon O''Connor
ex -Creative Asylum
Programmer &
Microsoft MVP

Share this post


Link to post
Share on other sites