View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Re-Order Elements in a Vector

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

3 replies to this topic

### #1Vincent_M  Members

Posted 03 March 2014 - 02:47 PM

This may be more of a general programming question. I'm currently batching all of my sprites' vertices in one giant, interleaved vertex array. I don't use VBOs for this right now since I am supporting OpenGL ES 2.0, and data is likely to change frequently bit over time. Since I'm drawing everything in one draw call, I'll need to have my vertices sorted within the array in a back-to-forward fashion. All of my vertices are in stored in an STL vector. I'm trying to figure out an efficient way of doing this, though. Whenever I add a sprite to my batch, I can just insert the sprites based on depth, but what if I had to move 4 vertices making up one of my sprites back 8 vertices? Should I just insert a copy of my sprite's vertices, then erase the original copy from the vector?

### #2JohnnyCode  Members

Posted 03 March 2014 - 03:49 PM

the best I can think of is to scan unordered buffer of sprites, finding ouy their indexes order upon many sort alogrithms available , and than build an index buffer to render the unordered buffer by. This way you can have the buffer static, keeping its footprint in CPU, as in many sprite/particles implementations the count of particle elements do not vary. If in your very case a once ordered buffer does not change unless being added a sprite, what seems unlikely, this given approach is valid as well. One drawback of this approach is that the generated indicies will not be adjency friendly. If you want to have unindexed buffer instead, use this approach and by ordered indexes recreate the buffer instead to be ordered upon those indexes. Once added a sprite, you will have to move sprites behind it and expand the buffer, but you would not have to do it if you index the buffer, but it will be just adjency unfriendly.

### #3L. Spiro  Members

Posted 03 March 2014 - 05:48 PM

The above is correct in using and sorting an index buffer, however you will still not be able to use a static vertex buffer if you manually update the vertex locations with matrix multiplies (since you are not using instancing and keeping everything in one buffer).
Frankly, by this point you might be better off just making a single draw call for each sprite after sorting the order of calls locally. You should at least benchmark it with a static VBO.

In either case you should be using VBO’s and triple-buffering them. Most mobile devices supporting OpenGL ES 2.0 have built-in triple-buffering on the back-buffer and forced v-sync, so triple-buffering your vertex/index buffers should result in little-to-no lag.

L. Spiro

### #4JohnnyCode  Members

Posted 03 March 2014 - 07:43 PM

to use a static vertex buffer if you manually update the vertex locations with matrix multiplies

true, but one can move the tranformation to vertex function, which outperforms CPU tranforming, since paralel pipelines eat it up, and yet, it allows one to have the buffer static. This is yet possible only if Vincent_M will not expand amount of verticies/sprites, keeping them in constant amount. I myself am using a very tripy aproach. I transform sprite quads by the help of their object space z - what allows mi to have any procedural animation, transforming all verticies by the uniformal matrix. Drawing sprites/particles by an indexed buffer is rather vital too, since buffer can contain 100 of them, but with indicies you can specify how many to draw, with what uniform transformation. For example uniform buffer limits you to 128 matricies, so you draw first 128, and then the next ones, in few batches. But I rather use procedural aproach, in case I am drawing fire, not light flies of course.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.