Skip to main content
gamedev.net
🔒 Locked

Quad Engine Speed problems

Started by Insodus 9 replies 350+ views
Original Post
Insodus
Insodus
I have a quad engine the im using to draw an isometric map. I'm using static indexed primitives to draw about 200 tri's. For some reason, if I have meshes and other stuff I get high frame rates, I can add in all kinds of other code and it doesn't slow down a hair, but with the 200 tri's it's slow ass malassis. They are all using the same texture, which is 256x256 in memory. This is the indexed primitive code. Can someone tell me what here might be slowing it down almost to a crawl? If I comment out just the render call, the FPS shoots right back up to normal. So it's not the creation or memcpy of the map. Just the render. ???????? Any ideas? Thanks, Insodus
      
void Direct3D::CreateIndexedVertexBuffer(DWORD flags, LPDIRECT3DVERTEXBUFFER8 & vertbuff, LPDIRECT3DINDEXBUFFER8 & indbuff, int size, int num_elems, int num_inds) {
	pD3DDevice->CreateVertexBuffer(size * num_elems, D3DUSAGE_WRITEONLY, flags, D3DPOOL_DEFAULT, &vertbuff);	
        if( FAILED(hRet) ) {
		MainErr->HandleError(__FILE__, __LINE__, CRITICAL, D3D_ERROR, "Error creating vertex buffer.", hRet);
	}
	pD3DDevice->CreateIndexBuffer(sizeof(WORD) * num_inds, D3DUSAGE_WRITEONLY, D3DFMT_INDEX16, D3DPOOL_DEFAULT, &indbuff);

	if( FAILED(hRet) ) {
		MainErr->HandleError(__FILE__, __LINE__, CRITICAL, D3D_ERROR, "Error creating vertex buffer.", hRet);

	}}

inline void Direct3D::RenderIndexedBuffer(D3DPRIMITIVETYPE type, DWORD flags, LPDIRECT3DVERTEXBUFFER8 vertbuff, LPDIRECT3DINDEXBUFFER8 indbuff, int size, int num_elems, int num_inds) {
	pD3DDevice->SetStreamSource( 0, vertbuff, size );
	pD3DDevice->SetVertexShader(flags);	pD3DDevice->SetIndices( indbuff, 0 );	
        pD3DDevice->DrawIndexedPrimitive(type, 0, num_elems, 0, num_inds / 3);
}

      
[edited by - Insodus on April 18, 2002 11:11:18 AM] [edited by - Insodus on April 18, 2002 11:12:24 AM]
---------------------------------"Without C, all we would have is Pasal, Basi, and obol.""Black holes are where god divided by zero."http://www.insodus.com
BenHanson
BenHanson
For optimal rendering you should send from 500-10,000 vertices per draw-primitive call.

Anything less and it will be progressively slower. There is a chart on the relationship between vertex fvf sizes, number of vertices sent per drawprimitive, and all sorts of other data on vertex buffers at developer.nvidia.com; check there.
"All programmers are playwrights and all computers are lousy actors." -Anon.
Insodus
Insodus
The site says about 500 tris is good and thats what I''m sending.
---------------------------------"Without C, all we would have is Pasal, Basi, and obol.""Black holes are where god divided by zero."http://www.insodus.com
Insodus
Insodus
Please help, this is killing me.
---------------------------------"Without C, all we would have is Pasal, Basi, and obol.""Black holes are where god divided by zero."http://www.insodus.com
Insodus
Insodus
No, i have a texture of 256x256 and I divide it into 16 quads of 64x64. Then I am mapping a single 64x64 area of it to a 80x40 isometric tile.
---------------------------------"Without C, all we would have is Pasal, Basi, and obol.""Black holes are where god divided by zero."http://www.insodus.com
Insodus
Insodus
Your suggestion made me try a few things...
1) I had my renderer set at 2 texture stages even though I was only using 1, I tried fixing that. It did''t do much.
2) I tried changing the filter type, I had it set to bilinear, I tried linear and anisotropic; they all had about the same performance.
3) I tried messing with the texture coords a little. Seeing if applying more or less pixles to each quad did anything, it didn''t.
4) Then I messed with my render states. Most had little or no effect, this one jumped it about 10 FPS, but that was it.
D3DInst->pD3DDevice->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);

Again, its at about 60 FPS with just a render of about 550 tri''s. If I add a mesh with a few hundred tri''s it doesn''t change FPS at all. If I take away just the render call on the 55o tri''s the FPS goes up to aboout 170. What am I doing wrong here, this shouldn''t happen.
---------------------------------"Without C, all we would have is Pasal, Basi, and obol.""Black holes are where god divided by zero."http://www.insodus.com
Insodus
Insodus
I also tried setting the texture to null, so it just drew white. That only helped for 10 or so FPS as well.

Could the ordering of the triangles have anything to do with it?

I know my vertices are ordered right (clockwise) but the tri''s are kind of in a spiral pattern.
---------------------------------"Without C, all we would have is Pasal, Basi, and obol.""Black holes are where god divided by zero."http://www.insodus.com
Tessellator
Tessellator
If you create a d3d device with presentation params with the refresh interval set at default, then your apps frame rate will be limited by the refresh rate of your monitor, which can typically be 60hz.

Try setting FullScreen_PresentationInterval to D3DPRESENT_INTERVAL_IMMEDIATE. (Also, you can try setting FullScreen_RefreshRateInHz to D3DPRESENT_RATE_UNLIMITED, but read up in the docs about the settings as well).

T
Insodus
Insodus
I have tried this, but I know it''s not the refresh rate because it refreshes at 160+ fps with just the mouse drawn or with meshes. Just the 500 tri list makes it go down to 50''s
---------------------------------"Without C, all we would have is Pasal, Basi, and obol.""Black holes are where god divided by zero."http://www.insodus.com
Wreakon
Wreakon
Well, 200 is minimal to send to a video card, but as far as I remember they were static so it doesn''t really matter. Some things to do would be:
VB should be in DEFAULT MEMORY
Are your triangles properly ordered? They are supposed to be clock-wise or counter-clockwise (otherwise they will render but there is a penalty I believe.)
Are the UV coords all valid? Basicly make sure you are sending quality data to the video card. Other than that that is a very good framerate(60fps) you want to keep it there or close to there.

-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: www.ussshrike.com/pcwebvia/
-------Homepage: http://www.pclx.com

Topic Locked

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

Sign in to reply to this topic.