You are correct that it should be D3DPOOL_DEFAULT.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.
Of note to the original poster is that in any case you should always use the actual enumerated value, not 0 (and especially not NULL; it’s not a pointer and that is extremely misleading), even though D3DPOOL_DEFAULT is 0.
We use double-buffering at work, and they did (not I) profile it on Xbox 360.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
These days it may be very similar in performance, but it is more likely to be similar to orphaning in OpenGL (which is slower than double-buffering, and I have tested that, as others have) because they are basically the same process, and if the driver tries to secretly double-buffer behind the scenes then the magic that makes that happen is implicitly more cycles than manually double-buffering.
L. Spiro