That sounds like some good stuff to try later. Thanks, I appreciate the advice.

After reading the last couple of posts again, I just thought I'd clear up the fact that when I prepare the geometry (by locking/unlocking index and vertex buffers), prior to the DIP calls, there is never any delay.

This process takes around 1ms but is usually less. I'm fairly sure my timing of this is accurate as there are no asynchronous calls involved. This process is:

Lock each vertex buffer that has new viewable data, adjust the height values of a portion of that vertex buffer (my VBs are separated into 9 65x65 vertex chunks) - this generally involves updates to around 7 or 8 vertex buffers (depending on how fast the view is rotating).


I'm using dynamic DEFAULT pool vertex buffers with WRITE_ONLY set. I think if you use DISCARD, it throws away the buffer before writing to it which may be slower - although I haven't tried it yet.

I think what's happening is that the geometry preparation stage is very quick and is immediately followed by the DIP calls. As the DIP calls are asynchronous, the next geometry preparation happens before the DIP calls are finished which might cause lag in the DIP calls. What I think I need to do is:

1) Carry out normal game loop processing/event handling and wait until the card is ready for drawing
2) Prepare geometry
3) Call DIPs

I need to work out how to tell when the card is free for drawing before drawing the next set. Is there something in the API that can tell me when the card is ready for drawing perhaps?

Quote:Original post by RobMaddison
I'm using dynamic DEFAULT pool vertex buffers with WRITE_ONLY set. I think if you use DISCARD, it throws away the buffer before writing to it which may be slower - although I haven't tried it yet.

Have a look at the SDK docs in Direct3D9 -> Programming Guide -> Programming Tips -> Performance Optimizations.

You want to create a large VB and lock it in chunks, with NOOVERWRITE, then once with DISCARD once it's full, which allows D3D to provide a pointer to a virtual buffer, which prevents a stall.

Good news, that worked a treat, Steve.

Thanks again to all for the great advice!