   Vertex buffers in D3D... Altering on the fly
  I understand that drawing stuff in D3D using DrawPrimitiveUP is slow. VERY slow. So, I tried to these vertex buffers going. I got it to work somehow, although I don''t quite see how to alter this on the fly, looks like if you need to know how many vertexes you will need room for when creating it. What I''m asking, is how I can add more vertexes to the buffer without re-creating it every frame.The examples I have seen fills the vertex buffer at initialization and don''t touch it later. Is it normal to have one vertex buffer per object, or do you put all vertexes in the program into one or very few buffers? I can''t see how it can be so much faster if I am to use one buffer for each object - especially if I''m to build a 2D game, using quads...Is it as good to use DrawPrimitiveUP for a tile based 2D game?-Trond 
  If I am correct,  I believe that the right way to do it is to use very few vertex buffers, and then used DrawIndexedPrimitive with an Index buffer, atleast thats what I''m learning to do.  That way you can store each vertex that you are ever going to use once, in a vertex buffer, and use the index buffer to jump all arouund in your vertex buffer, drawing any shape using your predefined vertices.    ;  Click: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndxgen/html/directx9devfaq.aspIn particular, take a close look at the "What''s a good usage pattern for vertex buffers if I''m generating dynamic data?"   topic.Basically you lock the same buffer multiple times, with the appropriate flags (detailed above), each time you''ve added some new data you do a Draw*Primitive() for that data.Draw*PrimitiveUP() IS slower than Draw*Primitive(), but I wouldn''t say it''s "VERY slow". In fact if you were to use vertex buffers badly/incorrectly or with inappropriate flags you''d find the UP methods faster!Most of the performance downside of the UP method comes from the fact it has to copy   the data in the array you''ve passed into an internal vertex buffer. The reason is the memory pointed to by the pointer you''ve passed to D3D could be released, trashed etc before D3D got a chance to actually use it (rendering on the graphics card doesn''t always actually take place during the Draw* call).The other big issue is the memory you''ve allocated is always in system memory, many graphics cards can''t read directly from that. For static geometry, AGP memory or even true video memory are often better - so a copy always needs to take place across the graphics bus - even when it isn''t strictly necessary. --Simon O''Connorex  -Creative AsylumProgrammer &Microsoft MVP;  Thanks for the incredibly quick replies!darkawakening:I don''t see how you can make anything useful by having a lot of vertices in the buffer and using them as a base for your shapes...? Then you''d have to know every exact vertex coord you will be using? Won''t that be - a bit static? Or did I completely misunderstand?s1ca:As I understand it, you say that I''ll need to (or should) lock/unlock the vertex buffer and alter the data between each drawprimitive? I have learnt from other DX parts that locking/unlocking should be done as rarely as possible, and in this case I would think that I need to draw a lot of independent objects - thus getting a lot of locking to do...Answers highly appreciated!-Trond ;from MSDNBatch size. Direct3D is optimized for large batches of primitives. The more polygons that can be sent in a single call, the better. A good rule of thumb is to aim to average 1000 vertices per primitive call. Below that level you''re probably not getting optimal performance, above that and you''re into diminishing returns and potential conflicts with concurrency considerations (see below).;  What you want to do is use dynamic vertex buffers, where locking isn''t as much of an issue (it''s designed to be locked many times).Preferrably you won''t lock for each quad.  Find how many quads you''re going to draw of a given texture, lock, fill in verts, unlock, draw, find number of quads of second texture, lock, fill in verts, unlock, draw... and so on.  But, make sure you use the appropriate creation and locking flags.  I didn''t look at Simon''s link, but I''m sure it contains info on how to use the flags correctly.;  I checked the link, and it said pretty much the same as you - Namethatnobodyelsetook. However, let''s say one is creating a iso game, then one can''t consider same textures since they need to be drawn back-front regardless of texture. One can do many of same textures in one run on the floor though, but the floor will probably be a small part of the scene...As far as I can see it, this (vertex buffer) is mostly useful if you''re actually drawing 3D models consisting of several triangles using the same shared texture. Then it would be easy to "fill up" a buffer and draw it in one drawprimitive call. I don''t know why, but OGL seems much faster at this point, drawing many tiles with different textures...-Trond ;  Create one vertex buffer for every major object or group of objects in the game.  One for the map.  One for the enemy characters.  One for the player(s).  Then associate one texture for each object or group of objects.  This way you only lock the buffer three to five times in the game game loop and you call DrawPrimitive and SetTexture the same amount of times (3 to 5 times).  The vertex buffers are all created when the game (or game level) is initialized so you don''t have to create one every frame. ;  You don''t need to draw back to front if:1)  You aren''t doing alpha blendingAND2)  You use a Zbuffer.Also, you generally don''t want a seperate texture for each element on your map.  You want a bitmap with many/all of your tiles on it. ;I read that performance FAQ section and was slightly confused.  I mean instead of, say, rendering 32,000 points with one call, I should batch in amounts around 1,000?  Or is this for triangles only? 