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

Started by
8 comments, last by utilae 18 years, 10 months ago
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]

HTML5, iOS and Android Game Development using Corona SDK and moai SDK

Advertisement
What's the weird 10920 value in your CreateVertexBuffer call?

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

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.

HTML5, iOS and Android Game Development using Corona SDK and moai SDK

Does DrawPrimitive return an error if it doesn't display anything?. Did you try with debug output? It usually gives a nice message if somethings wrong with the data.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

Drawprimitive doesn't give any errors, it returns s_ok.

HTML5, iOS and Android Game Development using Corona SDK and moai SDK

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.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

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.

Niko Suni

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)

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

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

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

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.

HTML5, iOS and Android Game Development using Corona SDK and moai SDK

This topic is closed to new replies.

Advertisement