Feature request: Low-level functions

I'd like to request functions to get the handles of vertex and index buffers of surfaces.

I assume that whenever AddVertex and AddTriangle are called, these buffers are locked and unlocked. By giving users access to these buffers, we can signifigantly cut down on the amount of calls to these methods per modification of surface.

I can't say how much this would increase speed, but it would likely be faster than locking and unlocking them 3,000 times per frame.

Basically, give people these functions:

LockVertexBuffer(Surface)
UnlockVertexBuffer(Surface)
LockVertexBuffer(Surface)
UnlockVertexBuffer(Surface)
GetVertexBufferGraphicsStream(Surface)
GetIndexBufferGraphicsStream(Surface)
SetVertexCount(Surface,Count)
SetTriangleCount(Surface,Count)

Then we could use the IO functions on the streams to read and write data to these buffers.

I don't know how plausible this sounds to you, but I think it's completely doable.

Why do you assume that, as opposed to it only happening once per frame, if a surface has been modified?

If someone like Tom is hacking the surface structure like he did with Textures, then it could eventually be possible ... but I think only "lowlevel" cracks like him know the answer.

These functions would be very useful if they speed up the changing of vertex & colour in a surface.

I currently have 2048 quads in a surface used as 2D particles. (3D quads allow alpha). If I change one of these vertex then I get an immediate 2ms hit, going up to 2.5ms when changing all the vertex.

There must be something going on as they are plotted in 0.1 to 0.2ms.

Please somebody speed up altering of vertex in surfaces.
Marg

This is a simple prove that the lock is only at the start ...

and the rest is more or less just hardware restriction.
But I think the mainproblem is the way the meshes are saved ... from OGL I know that there are different types of mesh buffers so I assume that DX has them as well. And as Blitz3D is focused on outdated hardware it might be that the used buffertype is the slowest and not the most optimal.

Because modifying one vertex in contrast to modifying lots of vertices in my shader system shows a signifigant difference in speed.

In any case, if the buffers aren't locked and unlocked per modification, then the handles to these streams would still be useful for other purposes (e.g., passing them to external DLLs, software vertex shaders, etc.).

Bump.