Jump to content
  • Advertisement
Sign in to follow this  
utilae

If my vertex buffer has any more than 72 vertices, nothing renders(*solved*)

This topic is 4827 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I am using C++ and Direct3D9. My problem is that if I have any more than 72 vertices sent to the vertex buffer nothing renders. If there are 72 vertices, everything renders. If I have 78 vertices nothing renders (well, none of the primitives sent to the vertex buffer renders). My app is 2d, I have z buffer disabled and a dynamic vertex buffer. My vertices are size 24, eg sizeof(VERTEX)=24 (I'm not sure whether it's bits, bytes). According to my code checking the directx9 device caps, my max vertex count=65535 and my max primitive count=65535. //Create a dynamic vertex buffer in system memory
void CVertexManager::SetupVertexBuffer(void)
{		
	//create d3d9 vertex buffer
	HRESULT hr=g_pD3DDevice9->CreateVertexBuffer(sizeof(VERTEX)*10920,D3DUSAGE_DYNAMIC|D3DUSAGE_WRITEONLY,g_dwFVF,D3DPOOL_SYSTEMMEM,&g_pVertexBuffer,NULL);
	g_Log<<"SetupVertices() Create Vertex Buffer: "<<DXGetErrorString9(hr)<<endl;
}



//add 6 vertices to list of vertices (vertex buffer will later be filled with vertices from the list)
void CVertexManager::AddSquare(RECT &recPos,const float &fZOrder,TILE &TilePos)
{	
	if(m_lstVertexList.empty()==true)
	{
		m_nPrimitiveCount=0;
	}
	
	//vertices must be sort in order of Z value (0.0 close, >0.0 far). Z values closer to 0 are rendered first.
	//Use RECT coordinates to create vertices
	VERTEX vrtBottomLeft,vrtTopLeft,vrtTopRight,vrtBottomRight;
	vrtBottomLeft.x=recPos.left;   vrtBottomLeft.y=recPos.bottom;  vrtBottomLeft.z=fZOrder;  vrtBottomLeft.rhw=1.0f;  vrtBottomLeft.tu=TilePos.m_tuLeft;   vrtBottomLeft.tv=TilePos.m_TvBottom;
	vrtTopLeft.x=recPos.left;      vrtTopLeft.y=recPos.top;        vrtTopLeft.z=fZOrder;     vrtTopLeft.rhw=1.0f;     vrtTopLeft.tu=TilePos.m_tuLeft;      vrtTopLeft.tv=TilePos.m_tvTop;
	vrtTopRight.x=recPos.right;    vrtTopRight.y=recPos.top;       vrtTopRight.z=fZOrder;    vrtTopRight.rhw=1.0f;    vrtTopRight.tu=TilePos.m_tuRight;    vrtTopRight.tv=TilePos.m_tvTop;
	vrtBottomRight.x=recPos.right; vrtBottomRight.y=recPos.bottom; vrtBottomRight.z=fZOrder; vrtBottomRight.rhw=1.0f; vrtBottomRight.tu=TilePos.m_tuRight; vrtBottomRight.tv=TilePos.m_TvBottom;

	//add six vertices to the list of vertices(orignal)
	// v2---v3|v5  //0.0-----0.0 //tu=horizontal
	// |     /|    //|     /  |  //tv=vertical
	// |   /  |    //|   /    |
	// | /    |    //| /      |
	//v1|v4---v6   //0.0-----1.0
	m_lstVertexList.push_back(vrtBottomLeft);
	m_lstVertexList.push_back(vrtTopLeft);
	m_lstVertexList.push_back(vrtTopRight);
	m_lstVertexList.push_back(vrtBottomLeft);
	m_lstVertexList.push_back(vrtTopRight);
	m_lstVertexList.push_back(vrtBottomRight);

	//update how many primitives and vertices there are to render
	++m_nPrimitiveCount;++m_nPrimitiveCount;
}



//filling the vertex buffer with vertices from a vector list
void CVertexManager::FillVertexBuffer(void)
{
	//stable sort vertices in order of z value
	stable_sort(m_lstVertexList.begin(),m_lstVertexList.end());
	
	//fill vertex buffer
    void *vb_vertices;
    g_pVertexBuffer->Lock(0,0,&vb_vertices,0);
    memcpy(vb_vertices,&(m_lstVertexList[0]),m_lstVertexList.size()*sizeof(VERTEX));
    g_pVertexBuffer->Unlock();
	
	//clear list of vertices
	m_lstVertexList.clear();
}



Anyone able to help? [Edited by - utilae on June 1, 2005 7:20:02 PM]

Share this post


Link to post
Share on other sites
Advertisement
For 10920 vertices, though I guess it was pretty random. I changed it to 65535. Though increasing the size of the vertex buffer did not do a thing. The 78 vertices still won't render, yet 72 vertices do render.

Share this post


Link to post
Share on other sites
What happens if you choose the REF device?

If it behaves the same there then something is wrong in your code. If it shows fine on the REF device the driver of your card may be buggy.

Share this post


Link to post
Share on other sites
Quote:
Original post by utilae
Drawprimitive doesn't give any errors, it returns s_ok.


HRESULT from DrawPrimitive() != Debug runtime information [smile] S_OK just means that the call succeeded, in this case.

See "Debugging DirectX Applications" topic in the SDK for more info.

Share this post


Link to post
Share on other sites
1. D3DPOOL_SYSTEMMEM - some graphics chips don't support pre-transformed vertices (those with D3DFVF_XYZRHW) in system memory buffers. Check for D3DDEVCAPS_TLVERTEXSYSTEMMEMORY in D3DCAPS9.DevCaps.


2. D3DPOOL_SYSTEMMEM - it's not a commonly done thing to have vertices explicitly put in system memory when you're not using software vertex processing. Not being common also means not well tested in some drivers.
The DYNAMIC|WRITEONLY flags you specified are enough for D3D and the driver to decide on the best location automatically - try using the DEFAULT pool.


3. Good advice from Nik02. The debug runtime will output warnings as well as errors; warnings won't cause DrawIndexedPrimitive to fail.


4. Good advice from Endurion. The REF device should help catch abuse that a hardware device has no way of complaining about.

A variation on this that I personally prefer when debugging is to use software vertex processing with a HAL device; simply change your CreateDevice() and all CreateVertexBuffer()/CreateIndexBuffer() calls so that they have the relevent SOFTWARE_VERTEX_PROCESSING flag.

If you then run your app with the debug runtime, software vertex processing and with the "maximum validation" debug option checked, all your indices will be checked to make sure they're in range etc. The runtime will spew lots of stuff if there is a problem between your IB and VB.


5. Don't use a PURE device when debugging - doing so bypasses a lot of good stuff in the D3D runtime that can be useful for catching errors.


6. If you haven't done already, set your Clear() colour to something other than black - just in case the polygons are being displayed but come out black after sending more than 72 vertice.


7. Can you post the structure of VERTEX; the order of the members of a vertex is important when using the fixed function pipeline (e.g. positions must come after colours, and colours must be before texture coordinates)

Share this post


Link to post
Share on other sites
Quote:
Original post by Nik02
Quote:
Original post by utilae
Drawprimitive doesn't give any errors, it returns s_ok.


HRESULT from DrawPrimitive() != Debug runtime information [smile] S_OK just means that the call succeeded, in this case.

See "Debugging DirectX Applications" topic in the SDK for more info.


You might also want to look at NeXe: Debugging, it's a good place to start.

I rewrote ID3DXMesh::DrawSubset() a few weeks ago, and kept getting params wrong (a lot of guesstimating involved[smile]) yet each time the debug runtimes gave me a pretty damn good idea of what I'd done wrong. Remember - They ARE your friend!

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by S1CA
4. Good advice from Endurion. The REF device should help catch abuse that a hardware device has no way of complaining about.

I tried with HAL device and hardware vertex processing, the polygons don't show.
I tried with HAL device and software vertex processing, the polygons don't show.
I tried with REF device and software vertex processing, the polygons show.

I do want to use hardware though, eg HAL + hardware vertex processing.


Quote:
Original post by S1CA
2. D3DPOOL_SYSTEMMEM - it's not a commonly done thing to have vertices explicitly put in system memory when you're not using software vertex

processing. Not being common also means not well tested in some drivers.
The DYNAMIC|WRITEONLY flags you specified are enough for D3D and the driver to decide on the best location automatically - try using the

DEFAULT pool.

I put my dynamic vertex buffer in D3DPOOL_DEFAULT memory and the polygons show. Thanks guys, my problem is solved now.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!