🔒 Locked

Vertex Buffer Locks

Started by PumpkinPieman Jan 2, 2005 at 1:48 AM 3 replies 400+ views

Original Post

PumpkinPieman

128

PumpkinPieman

Jan 2, 2005 at 1:48 AM

Alright, I'm trying to think of the uses for the offset in vertex buffer locks.


HRESULT Lock(          UINT OffsetToLock,
    UINT SizeToLock,
    VOID **ppbData,
    DWORD Flags
);

Now, why exactly shouldn't this value be set to 0? I'm trying to eliminate useless parameters in a function declaration and if this is going to be set to 0 anyway it's not worthwhile having it.

MikeyO

Jan 2, 2005 at 2:22 AM

If you don't want to lock the whole buffer, only a small chunk of it. Then you might not use 0.

PumpkinPieman

Author

128

PumpkinPieman

Jan 2, 2005 at 2:29 AM

So if I had 4 objects in the vertex buffer I could lock and unlock it to edit one of those objects based on the offset?

MikeyO

Jan 2, 2005 at 2:36 AM

Yeah, thats right.. suppose you have 4 particles, each takes up 16 bytes, to lock the 2nd particle you set the offset to 16 and the size to 16.

If you retrieve the info from the vb (reading from the VB is not recommended), then you only get that particle, or you can decide only to write to that particle.

I would skip using lock() and unlock() if you can avoid it, and use a vertex shader.

Muhammad Haggag

156

Muhammad Haggag

Jan 2, 2005 at 4:59 AM

Quote:
Original post by PumpkinPieman
So if I had 4 objects in the vertex buffer I could lock and unlock it to edit one of those objects based on the offset?

Yes, though usually static buffers hold objects that aren't edited. What's more likely is that you're using a dynamic vertex buffer with the DISCARD/NOOVERWRITE scheme, where you fill in a batch, render, lock with NOOVERWRITE starting at an empty position, fill in another batch, and render, ...etc

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.