•Clear only when you must. Only clearing the backbuffer

EDIT: This following information turned out to be incorrect, as I thought :D

I'm not really sure now but I think I saw somewhere that you should clear everything at the same time, that means if you clear backbuffer, you should also clear depthbuffer by the same clear command? But I'm really not sure, I may be imagining this.

By Clear only when you must they mean if you don't need to call Clear(), don't call it at all.

void *pVertexBuffer = NULL; 

struct D3DVERTEX{float x,y,z,rhw;DWORD color;float u;float v;} vertices[40];	// 4 verts * 10 quads
LPDIRECT3DVERTEXBUFFER9 pVertexObject = NULL;

// vertex description for our sprites
for(int n=0;n<10;n++)
{
	vertices[0*n].x=0;vertices[0*n].y=256;vertices[0*n].z=0;vertices[0*n].rhw=1.0f;vertices[0*n].color=0xffffff;vertices[0*n].u=0.0;vertices[0*n].v=1.0;
	vertices[1*n].x=0;vertices[1*n].y=0;vertices[1*n].z=0;vertices[1*n].rhw=1.0f;vertices[1*n].color=0xffffff;vertices[1*n].u=0.0;vertices[1*n].v=0.0;
	vertices[2*n].x=256;vertices[2*n].y=256;vertices[2*n].z=0;vertices[2*n].rhw=1.0f;vertices[2*n].color=0xffffff;vertices[2*n].u=1.0;vertices[2*n].v=1.0;
	vertices[3*n].x=256;vertices[3*n].y=0;vertices[3*n].z=0;vertices[3*n].rhw=1.0f;vertices[3*n].color=0xffffff;vertices[3*n].u=1.0;vertices[3*n].v=0.0;
}

mRenderer->getDevice()->SetTexture(0,mRenderer->pTexture);

// #1: Create vertex buffer. Not static/read-only. Dynamic.
void *pVertexBufferDynamic=NULL;
LPDIRECT3DVERTEXBUFFER9 pVertexObjectDynamic=NULL;

int nQuantity=10;

if(FAILED(mRenderer->getDevice()->CreateVertexBuffer(nQuantity*4*sizeof(D3DVERTEX),NULL,D3DFVF_XYZRHW|D3DFVF_DIFFUSE|D3DFVF_TEX1,D3DPOOL_MANAGED,&pVertexObjectDynamic,NULL)))
	return(1);

// #2: Lock it.
if(FAILED(pVertexObject->Lock(0,nQuantity*4*sizeof(D3DVERTEX),&pVertexBuffer,0)))
	return(2);

// #3: Fill it with the sprite vertices. Drawing 32 sprites means you put 32×4 vertices into the buffer.
memcpy(pVertexBuffer,vertices,nQuantity*4*sizeof(D3DVERTEX));

// #4: Unlock it.
pVertexObject->Unlock();

// #5: Draw it using the pre-generated 16-bit index buffer.
mRenderer->getDevice()->SetStreamSource(0,pVertexObject,0,sizeof(D3DVERTEX));
mRenderer->getDevice()->SetFVF(D3DFVF_XYZRHW|D3DFVF_DIFFUSE|D3DFVF_TEX1);

// **** then what?
// ? Draw it using the pre-generated 16-bit index buffer.

pVertexObjectDynamic->Release();

You didn’t specify the D3DUSAGE_DYNAMIC flag nor did you put it in the D3DPOOL_SYSTEMMEM memory pool.

Is there a specific reason you place the buffer in D3DPOOL_SYSTEMMEM instead of D3DPOOL_DEFAULT? Default resources can be locked when dynamic, I always thought that was the preferred pool to store dynamic resources to. You know, since you have to write to the buffer from CPU-side, but the GPU also has to render from it afterwards.

Also L. Spiro, did you profile double/triplebuffering the vertex buffers, versus justing using nooverwrite-discard after rendering as lock flag, and for submitting the sprites locking with nooverwrite? I've never heard of anyone recommending to do this, and always just read locking like I described, which should have a similar effect as manual doublebuffering. I don't have any data from comparing the both, so thats why I'm asking, would be interesting to hear if there really is an additional performance gain by this

All these suggestions are excellent and I certainly don't mean this as disagreeing with them, but did you try using a much smaller sprite of just a few pixels?

Your numbers really don't fit overhead as the cause, at just 1000 sprites. If you had 100,000 then sure, but at 1000.. doubtful. What graphics card are you running on?

If your 256x256 sprites are on screen and never getting culled, then that's 65 million drawn pixels per frame.. which equals overdrawing fullscreen 1920x1080 32 times.. seems reasonable that would run at about 35 FPS, depending on the graphics card ofcourse.

(If your sprites don't have translucency, GM could very well draw them front to back and let the depth test cut down the number of drawn pixels, or use other similar techniques to improve performance. At 450 FPS x 65M pixels they are approaching the theoretical limit of NVidias $1000 graphics cards which are rarely seen in real numbers, so it seems doubtful that there's not some optimization going on).