Use UP. The advantage to vertex buffers is that you can store a lot of static geometry on the card and then view it from different positions by sending the card a new matrix, thereby avoiding having to send all new point positions. If you had a large amount of lines which couls all be repositioned with a single matrix, this would be a win for you, but if you need to reposition each line separately it''s not.

Or just benchmark various schemes.

Jeff K: But doesn''t UP automatically lock and unlock the vertex buffer for you when it is called? If that''s the case, I''ve all ready used DrawPrimitive locking and unlocking the vertex buffer, and it is too slow. By the way, I performed a benchmark test using clear, drawprim - linestrip and asm pixel plotting. The pixel plotting won by about 20 fps, drawprim came in second by about 5.
Cheers,
-Jesse

quote:Original post by webmunkey
If the UP function should be avoided, then what should I use? Keep in mind that I''m always drawing vertical lines. Can I offset a line''s vertices with a matrix, so that I could grab a, say, 50-pixel long line, move it over 20, and down 50 without locking/unlocking? Maybe this could be acheived through manipulation of the view matrices?

This sounds like it would work (I have no idea if it will be faster though). Keep a vertex-buffer with vertices for a single screen-column (won''t be very large), and then offset it in the X direction with the model-matrix. This way you will never have to lock the VB, only change the matrix.

Anonymous Poster: Yeah, I was kind of thinking about something like that myself. However, there is one big problem that comes to mind. The "generic" vertex buffer is going to be big because even though it is one column composed of 480 or so pixels, if all the base vertices started from 480, then there would only be 480 different kinds of lines, however, the base vertices move as well, causing there to be a lot more lines. This means that translation on the y-axis would be a nescessity. So the question is, how would I best setup a matrix that can be multiplied against the x and y values in order to translate them?
Another possible solution that came to mind was using LINESTRIP, and tracking the vertices of the voxel columns with arrays, then at the last second performing only one lock per column and pasting in the array defined vertices. The LINESTRIP function would then share the vertices, cutting down vertex processing time, and furthermore, the vertex buffer would only be locked 640 times a frame (i''ll have to perform a benchmark to see what kind of performance hit that brings), instead of being locked 307200 or so times per frame. Suggestions?
Thanks,
-Jesse

quote:Original post by Anonymous Poster
Anonymous Poster: Yeah, I was kind of thinking about something like that myself. However, there is one big problem that comes to mind. The "generic" vertex buffer is going to be big because even though it is one column composed of 480 or so pixels, if all the base vertices started from 480, then there would only be 480 different kinds of lines, however, the base vertices move as well, causing there to be a lot more lines

Why does it matter that the baselines move? It shouldn''t if you are using indexed primitives.

e.g: you need to draw a line between (5,30) and (5,50), use the model-matrix to offset rendering 5 units along the x-axis, and then draw a line between the coordinates with indexes 30 and 50 (which would be predefined in the vertex buffer as (0,30) and (0,50) respectively).

Perhaps I have totally misunderstood what you''re trying to do.

Come to think of it you would have to lock and modify an index buffer, since you don''t want to call DrawPrimitive for each line. Perhaps there is no/little gain to this method (you could of course try it, it shouldn''t be pretty easy).

that last line is of course supposed to be: ... *should* be pretty easy.

Nope it isn''t required that I use dx8, it isn''t even required that I use dx. I already have a voxel engine that runs using direct draw and pixel plotting. However, above resolutions of 640 x 480, speed becomes a problem. This partly due to the fact that the interpolation equations take awhile, and the pixel / line drawing alogrithms aren''t the fastest in the world. I''d like to push my engine into the 800 x 600 range, but in order to do that, I''ll need faster interpolation equations and line drawing. D3D8 has nice fast color interpolation and opens up the possiblity of 3d accelerated line drawing. This technique was first used in Land Warrior, and it is lightning fast. I''m trying to recreate that speed... so this is where I am now. Anyhow,
Anonymous Poster: I see what you''re saying now, that''s a pretty good idea. I was thinking of something along that line, but not exactly like how you put it. I could call DrawPrimtive for each line very easily, getting rid of the buffer lock / unlock problem, however, I wonder how expensive the DrawPrimitive call is... I''ll create some more benchmarks and let you guys know.
Thanks,
-Jesse