I''ve been profiling my game and found some interesting and troubling results. It seems that the slow point is adding vertices to my dynamic vertex buffer. I correctly call NOOVERWRITE or DISCARD depending on how much space is in the vertex buffer. And I create it with the WRITEONLY flag. I''ve commented out all the code around my drawing routine. If I lock the vertex buffer and then unlock it, and add nothing to it, then my game runs at 1000fps. But if I do a: VB->Lock(..., (void**)&pVertex,...) pVertex->x = 1.0f; VB->Unlock() then my frame rate drops WAY down... and the more I modify the memory I''ve locked, the slower it gets. I''ve tested it on both a GeForce2Mx and a GeForce4 Ti4200 and the same result. Anyone have any ideas? When I lock, I lock enough room for 1000 vertices... and I''m not making any calls to DrawIndexedPrimitive() or anything... I''m just locking the VB and filling it with data... that''s what''s killing the performance.

anyone?

It''s weird because it runs faster on the Mx (31 fps) than the Ti4200 (29).

Well... probably your drivers check to see if there is an alteration and, from there on, once it knows it has data it needs to compress the data...

Another bottleneck you might be facing is the fact that you reserved a lot of space, try reserving the adequate amount of space that you need for every call...

If possible don''t feed you VB every frame (but you can do it if you don''t have another solution), instead, play with a Index buffer every frame. If your making a terrain engine... well all taht ROAM and CLOD stuff has nice results but it''s come to my attention that playing around with blocks (various sizes) of terrain works better then with individual verts (not only can you fit more verts, but you can also do it many folds faster and your only problem arises with how to do transition between blocks). There''s a presentation about this on the net, but I don''t remember where... all I know is that the author was a former Bullfrog employee and worked on the earlier Populous games and Magic Carpet (he even presents some techniques they used on these games)... I think it was either a ppt or a pdf... if you need more keywords for google then I''m not sure (COMPLETELY NOT SURE) but the company name was something like clockworks or clock-something (but you should only try these words as a last resource)...

Okay, done some more testing and here''s the result of where I am..

Case 0:
DynamicVB->Lock(space for 1089 vertices, &pVertex)
DynamicVB->Unlock()
Frame rate: 2000fps

Case 1:
DynamicVB->Lock(space for 1089 vertices, &pVertex)
for(i = 0; i < 1089; i++) {
pVertex[0].x = 1.0f;
}
DynamicVB->Unlock()
Frame Rate: 2000fps

Case 2:
i = 0
DynamicVB->Lock(space for 1089 vertices, &pVertex)
for(i = 0; i < 1089; i++) {
pVertex.x = 1.0f;
}
DynamicVB->Unlock()
Frame Rate: 100fps


Anyone have any ideas what''s going on here? I''m correctly locking the VB using NOOVERWRITE or DISCARD depending on if there is room or not. It seems that filling the memory that Lock returns is killing my performance.

Why not paste your exact code... There may be something wrong with the FVF struct or whatever. These pieces of code don''t help.

It''s a little too much to probably add here... not THAT much but more than I''m willing to sift through and put here. If anyone is willing to give me a little hand, I can send you a zip of all the source. It''s just a simple little terrain engine using DirectX8 and the problem seems to be with copying data to a dynamic vertex buffer.

So if anyone out there has a terrain engine going with a dynamic vertex buffer, or anything that uses a dynamic vertex buffer, I''d love to take a look and I''ve love it even more if u''d request the zip and give me a hand. This is really getting to me that I can''t figure out what the problem is.


Here''s my basic setup...

1. I create a dynamic vertex buffer
2. For each visible leaf in my quad-tree, I create those vertices, lock the VB, and upload to the vertex buffer, then unlock VB.
3. Then I render those polygons
4. Repeat for all visible terrain leaves.

You can see from my previous post that it seems that filling the vertex buffer with data is what''s killing the performance. Each leaf contains 1089 vertices (33x33) and there are a maximum of 64 leaves visible each frame. That''s 1089x64 vertices and each vertex is 40 bytes. That only works out to be 3 megs of data per frame which should be nothing for a 4x AGP Ti4200 vid-card.

HELP! (hahahah, that''s my girly-man scream for assistance)

Also, in the post where I show my 3 cases, the last one should be pVertex.x but it got changed to italics… sorry.

also, I get this message in the output window of VisualC++... I don''t it serious...

Direct3D8: (INFO) :Win2K SP1 or above detected - enabling VB swap workaround

I think that Win2K without SP1 had problems with DirectX that were fixed with SP1+ and this message is just informing me of that.

quote:Case 2:
i = 0
DynamicVB->Lock(space for 1089 vertices, &pVertex)
for(i = 0; i < 1089; i++) {
pVertex.x = 1.0f;<br>}<br>DynamicVB->Unlock()<br>Frame Rate: 100fps<br><br>Anyone have any ideas what''s going &#111;n here? I''m correctly locking the VB using NOOVERWRITE or DISCARD depending &#111;n if there is room or not. It seems that filling the memory that Lock returns is killing my performance.<br> <hr height=1 noshade></SPAN></BLOCKQUOTE> <br><br>When you fill a vertex buffer and unlock, it is sent to the card. If you modify it, it''s possible it has to be read back from the card, and that''s slow. It might be better to treat your VB as a writeonly buffer, and create it with the writeonly flag. Keep an array of vertices &#111;n the side, modify that and copy everything in the vertex buffer between lock and unlock.<br>