SFML community forums

Help => Graphics => Topic started by: tomvidm on October 07, 2018, 08:56:36 pm

Title: A question about VertexBuffer::update
Post by: tomvidm on October 07, 2018, 08:56:36 pm
I'm not into OpenGL coding, so I'm not able to find the answer on my own.

I'm using the VertexBuffer class for a Tilemap system, as I understand that VertexBuffer allows me to make changes to selected vertices, as opposed to VertexArray which copies all the vertices for each draw call.

My question is:
Is the update method an expensive method? If I update one vertex and the draw, I understand that this is much better than updating one vertex in a VertexArray and making a draw call.
But what if I update N vertices of a VertexBuffer, K times? What does the update method really do?
Title: Re: A question about VertexBuffer::update
Post by: fallahn on October 07, 2018, 10:23:28 pm
The update method copies any new vertex data from the CPU to the buffer stored on the GPU - so unless you're copying all the data for the entire buffer (which is what VertexArray does each time you call draw) it's probably going to be better than sf::VertexArray - especially if you're not updating it every single frame.
Title: Re: A question about VertexBuffer::update
Post by: tomvidm on October 07, 2018, 11:24:28 pm
Thanks for the reply.
I need some extra clarification though. Does the update method itself copy to the GPU, or does it do the copying during the draw call?
Let's say I have a lot of vertices stored, and I call update on non-continuous sets of vertices - will this cause a copy to GPU on each call, or is it queued until the draw call?
Title: Re: A question about VertexBuffer::update
Post by: fallahn on October 08, 2018, 12:11:19 am
update() calls glBufferSubData() immediately, which submits the data to your graphics card there and then - although whether it's batched with other calls or copied right away is down to your graphics card driver.
Title: Re: A question about VertexBuffer::update
Post by: tomvidm on October 08, 2018, 10:25:05 am
Thanks. This clears it up!