strange TL-vertices behaviour
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]
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement