🔒 Locked

Strange performance issues..

Started by DvDmanDT Aug 28, 2005 at 6:41 PM 6 replies 1.2k views

Original Post

Aug 28, 2005 at 6:41 PM

Hello everyone.. I have a game, that runs at 24 FPS on my target computer (which is indeed an outdated thing, but anyway).. Now, games like warcraft3, Jedi knight 2 and Swat 3 run fine (with lowest specs ofcorse), but my game can't draw like 8000 tris? I use DrawIndexedPrimitiveUP for this, which I know isn't the fastest thing around, but is it really _that_ slow? I make 64 calls to it, each drawing 126 tris.. One thing I can tell you is that I use software vertex processing.. I can't even use mixed processing.. This is pretty understandable, since it's a very old/sucky card (builtin nvidia vanta, 8mb), but then.. How the heck does it run games like warcraft3? Or Swat3 or Jediknight 2? Sure, they're not high-detail games, but still.. My point is, that they must be using some hardware acceleration.. But why can't I do that? Is it possible that it works with DX8, but not DX9? Thanks to anyone with answers!

Jnz86

Aug 29, 2005 at 1:56 AM

post your drawing code...

Metus

Aug 29, 2005 at 3:11 AM

keep in mind that DrawIndexedPrimitiveUP creates a new vertexbuffer each time is is called - so each frame you create 64 vertexbuffer big enough to store 126 tris.

DvDmanDT

Aug 29, 2005 at 11:17 AM

D3DCOLOR TerrainColors[] = {	D3DCOLOR_XRGB(0,0,0),	D3DCOLOR_XRGB(80,180,0),	D3DCOLOR_XRGB(170,140,170),	D3DCOLOR_XRGB(190,186,0)};Uint32 Ground=0;void CDirect3D::DrawMapTerrain(){	if(Ground==0)Ground=g_container->GfxOutput->LoadImageAndGetId("../Resources/Ground.bmp");	Uint32 num_x=60, num_y=60;	Uint32 start_x=2, start_y=2;	float curr_x=1.0f, curr_y=1.0f;	uh_CMap *Map=g_container->GameData->Map;	Vertex *Verts=new Vertex[num_x*num_y];		m_D3D_Device->SetTexture(0,m_ImgList[Ground].Texture);	HRESULT res = m_D3D_Device->SetFVF(D3DFVF_D3DVertex);	int vertid=0;	for(Uint32 y=0;y<num_y;y++)	{		if(y&1)			curr_x=0.0f;		else 			curr_x = 5.0f;		for(Uint32 x=0;x<num_x;x++)		{			// Perhaps the color component should change with elevation, so you can see different heights			Verts[vertid].color=TerrainColors[Map->GetTerrainType(x+start_x,y+start_y)];						Verts[vertid].tu = ((y&1)?curr_x+5.0f:curr_x)/20.0f;			Verts[vertid].tv = curr_y / 20.0f;			Verts[vertid].x = curr_x;			Verts[vertid].y = curr_y;			Verts[vertid].z = (float)(255-Map->GetElevation(x+start_x,y+start_y))/10.0f;			curr_x += 10.0f;			vertid+=1;		}		curr_y += 10.0f;	}	int curr_ind=0;	for(Uint32 row=0;row<num_y-1;row++)	{		curr_ind=0;		for(Uint32 col=0;col<num_x+1;col++)		{			if(row&1)			{						indices[row][curr_ind++]=row*num_x+col;				indices[row][curr_ind++]=(row+1)*num_x+col;			}			else			{				indices[row][curr_ind++]=(row+1)*num_x+col;				indices[row][curr_ind++]=row*num_x+col;			}		}	}	//m_D3D_Device->SetRenderState(D3DRS_FILLMODE,D3DFILL_SOLID);		m_D3D_Device->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE);			for(Sint32 i=num_y-1;i>=0;i--)		res = m_D3D_Device->DrawIndexedPrimitiveUP(D3DPT_TRIANGLESTRIP, 0,    num_x*num_y,    2*num_x-2,   indices,    D3DFMT_INDEX16,    Verts,    sizeof(Vertex));	m_D3D_Device->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_CURRENT);	delete []Verts;}

Ok, it seems like I'm drawing it in a horribly slow way then.. Never thought it'd be that slow, even if I knew it wasn't the fastest thing around.. Now, this is temporary code for a 64x64 map, and in the near future, I'll have to expand it to like 1024x1024 (or even bigger) maps.. Can I still survive with using 16 bit indices, or will I have to use 32 bit ones? My card seems really buggy when using 32 bit ones you see.. :p

Does anyone know if DX8 can HW accelerate on older things, on which DX9 can't?
I tried some OGL benchmarking tools, and they gave 100+ FPS for some rather high-polycount scenes.. So you'd think the test is using acceleration, no?

Muhammad Haggag

Aug 29, 2005 at 2:15 PM

Quote:
Original post by Metus
keep in mind that DrawIndexedPrimitiveUP creates a new vertexbuffer each time is is called - so each frame you create 64 vertexbuffer big enough to store 126 tris.

It doesn't create a buffer each time - it locks and fills an already-existing dynamic buffer each time you call it.

Metus

Aug 29, 2005 at 6:14 PM

Quote:
Original post by Coder
Quote:
Original post by Metus
keep in mind that DrawIndexedPrimitiveUP creates a new vertexbuffer each time is is called - so each frame you create 64 vertexbuffer big enough to store 126 tris.

It doesn't create a buffer each time - it locks and fills an already-existing dynamic buffer each time you call it.

Hmm.. that has been changed then? because I'm pretty sure it re-created the vertex buffer each frame in an obsolete version of directx ( < 8.0 ) - or atleast that was what my tutor said back at school :p

DvDmanDT

Aug 29, 2005 at 6:15 PM

Well, whatever it does, it's still slow, and I'm obviously using it in a horrible way?

So, how am I supposed to do? I've tried a couple of times to read the documentation for DrawIndexedPrimitiveUP and DrawIndexedPrimitive, but I never understand them.. :S

HRESULT DrawIndexedPrimitiveUP(...UINT MinVertexIndex,UINT NumVertices,...UINT VertexStreamZeroStride);

I think the last one is sizeof(vertex).. NumVertices is the number of Vertices accutually used? At the moment, I can't get it to work unless I do num_x*num_y (which is every vertex).. And one that is an even bigger mistery, MinVertexIndex.. What the heck does this mean? Will that value be added to every index? Or what is it?

[edit]
WOW! I just modified my code a bit, (I consider it a hack) and it suddenly ran at twice the speed on the target comp!

// Old code	for(Sint32 i=num_y-1;i>=0;i--)		res = m_D3D_Device->DrawIndexedPrimitiveUP(D3DPT_TRIANGLESTRIP, 0,    num_x*num_y,    2*num_x-2,   indices,    D3DFMT_INDEX16,    Verts,    sizeof(Vertex));// new code	for(Sint32 i=num_y-1;i>=0;i--)		res = m_D3D_Device->DrawIndexedPrimitiveUP(D3DPT_TRIANGLESTRIP, 0,    num_x*2,    2*num_x-2,   indices[0],    D3DFMT_INDEX16,    &Verts[i*num_x],    sizeof(Vertex));

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.