Hmmm,
Maybe I do it differently but it doesn''t look like your copying the data into your vertex buffer and index buffer properly.
instead of pVertices = verts.somevariable etc.<br><br>use:-<br>int iOffset = 0;<br>for (int i = 0; i < 4; i++) {<br> memcpy(pVertices + iOffset, Verts, sizeof(DROVertex));<br> iOffset += sizeof(DROVertex);<br>}<br><br>If the Verts bit doesn''t work create a pointer to your vertex<br>structure and use the new operator<br>i.e.<br>DROVertex *pVert;<br>pVert = new DROVertex[4];<br>Then fill the structure with data and pass this pointer to the memcpy function instead of Verts. i.e. as pVert.<br><br>Do similar for the index buffers.<br><br>Something else I noticed.<br>You put:-<br>pVertices.position = verts.position;<br>pVertices.color = verts.color;<br><br>Should it be:-<br>pVertices.position = verts.position;<br>pVertices.color = verts.color;<br><br>???<br><br>Hope some of this helps.<br> </i>
Dynamic Buffers
OK, there is some pretty bad form here in many places so bare with me, this post might be long.
First, DYNAMIC index buffers are a waste of time right now. They are their to provide orthaganlity in the event that hardware vendors actually DO have a notion of index buffers at some point in the future.
They don''t right now (I''m not sure about the GF4, but I doubt it does), its all in system memory and gets copied into command stream. The bandwidth required for the index buffer just isn''t high enough for the Hardware vendors to justify implenting in the hardware.
Second, this usage scenario is silly. You are drawing like 4 triangles. If the buffer does manage to be a real dynamic buffer, then getting a new peice of memory from the lock can take as much 5000-10000 CPU cycles. Hardly optimal unless you are really throwing alot of vertices around.
Third, you are locking with NO_SYSLOCK. This is silly to call with so a short copy. NOSYSLOCK should only be used when you are going to party on the buffer for a while and don''t want events such as the mouse cursor not to get updated. There is overhead when using this flag.
Finally, with the tiny amount of drawing you are doing, you are probally going to get better perf with DrawPrimitiveUP, (Before I get flamed, note that DrawPrimitiveUP has the same effective performance as Dynamic vertex buffers that you stuff data into yourself.)
EvilDecl81
First, DYNAMIC index buffers are a waste of time right now. They are their to provide orthaganlity in the event that hardware vendors actually DO have a notion of index buffers at some point in the future.
They don''t right now (I''m not sure about the GF4, but I doubt it does), its all in system memory and gets copied into command stream. The bandwidth required for the index buffer just isn''t high enough for the Hardware vendors to justify implenting in the hardware.
Second, this usage scenario is silly. You are drawing like 4 triangles. If the buffer does manage to be a real dynamic buffer, then getting a new peice of memory from the lock can take as much 5000-10000 CPU cycles. Hardly optimal unless you are really throwing alot of vertices around.
Third, you are locking with NO_SYSLOCK. This is silly to call with so a short copy. NOSYSLOCK should only be used when you are going to party on the buffer for a while and don''t want events such as the mouse cursor not to get updated. There is overhead when using this flag.
Finally, with the tiny amount of drawing you are doing, you are probally going to get better perf with DrawPrimitiveUP, (Before I get flamed, note that DrawPrimitiveUP has the same effective performance as Dynamic vertex buffers that you stuff data into yourself.)
EvilDecl81
To find out if you are in debug bits - look at the dlls that are loaded, if d3d8d.dll is loaded, you are in debug.
I''m sure his simple example is just that: An example. If you''re trying to learn how to use vertex buffers, you don''t start by trying to render an entire level.
~CGameProgrammer( );
~CGameProgrammer( );
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
