   LPDIRECT3DVERTEXBUFFER9
  Can I set the vertex buffer, lock it, unlock it, and then draw primitives without setting the vertex buffer again?I mean can it be like[source lang='c++']pDevice->SetStreamSource ( ... pVertexBuffer ... );...pVertexBuffer->Lock ( ... (void**) &pVertices ... );...pVertexBuffer->Unlock ( ... );...pDevice->DrawIndexedPrimitive ( ... );, or it has to be like[source lang='c++']pDevice->SetStreamSource ( ... pVertexBuffer ... );...pVertexBuffer->Lock ( ... (void**) &pVertices ... );...pVertexBuffer->Unlock ( ... );...pDevice->SetStreamSource ( ... pVertexBuffer ... );pDevice->DrawIndexedPrimitive ( ... );?   
  It should be fine. Just be careful of performance - your drawing can stall the lock (unless you specify D3DLOCK_DONOTWAIT) and vice-versa. Depending on how the rest of your application works you could end up destroying any parallelism between the CPU and GPU [oh]hthJack   ;  Hmm..I'm trying to implement particle system via vertex shaders. Is there any better way to do it? I create a vb/ib of ~255 particles, fill it/render/fill/render... until there are no more particles left to be rendered. The vsh just modifies left/up directions.   ;  When rendering and modifying are tightly bound you either want to make use of flags like NOOVERWRITE and DISCARD or use some sort of bounded-buffer.I got perfectly good results from animation of particle systems running at only 15-20hz and a set of 10 buffers.I'd render all 10 buffers each frame, then on any frame where more than 1/15th of a second had elapsed I'd lock *one* of the buffers (which one would change each time an update occured) and update the particles. Thus at least 9 buffers could always be in play, and by the time I wanted to lock a buffer it'd probably be through the pipeline.In your case, even a simple double or triple-buffering might work. Create an array of vertex buffers and each frame alternate which one you render but lock whichever you rendered on the *previous* frame:Frame 1: Render 0, Lock 2Frame 2: Render 1, Lock 0Frame 3: Render 2, Lock 1Frame 4: Render 0, Lock 2Frame 5: Render 1, Lock 0Its not guaranteed, but it should allow for greater parallelism as the CPU and GPU won't always be fighting for the same resource.hthJack   