I decided to start a new project and make a game and I want to keep it 2D sprite based only. So I started learning today how to use OpenGLand was able to get a hang of it very qucikly.

Now I really just have few questions about using VBOs and using them for sprites

1. I know VBO is considered the fastest when it comes to rendering, but is it the best option for a 2D only game?2. Would I be able to transform sprites when and if I need to (Rotation and scale)?3. What about transforming sprites based on a world matrix or 2D camera?

And my last question!

I created the below code which uses a VBO to render the sprites I have in an array of sprite objects.Is this the right way / best way of rendering quads with textures on them using a VBO? Is there a better way?

//bind the texture to use and handle the rest of the drawingglBindTexture(GL_TEXTURE_2D, sprite[i].texture.getTextureID());glBindBuffer(GL_ARRAY_BUFFER, vboVertexHandle);glBufferData(GL_ARRAY_BUFFER, vertexData, GL_STATIC_DRAW);glBindBuffer(GL_ARRAY_BUFFER, 0);

1. It's a good option. So is vertex arrays. Or geometry shaders, if supported.2. Yes. Generally scaling would be done on CPU by simply specifying different vertex positions. Rotation could also be done on CPU, by transforming each vertex before placing it in your array. Alternatively, you could send the model transform as a uniform matrix to the shader, which allows you to do the transformation on the GPU. Maybe a system comprised of both would be ideal.3. Easy as pie if you're using a shader.

LibGDX's sprite batch actually uses simple vertex arrays. When it comes to streaming data every frame, they are almost as fast as VBOs, or on some drivers even faster. There are also some implications on Android.

Your code looks a little strange. Why are you calling glBindTexture on a buffer ID? Creating a new float array every frame seems like a waste. And you're using VBOs for such a small amount of data that it won't be very effective. Further, your system isn't very flexible; what if you wanted to add many more textures?

You should also think about texture atlases; i.e. using a single texture comprised of many sprites, in order to reduces texture binds and batch renders.

It introduces you to textures, shaders, a simple orthographic projection matrix, vertex arrays, and a simple SpriteBatch implementation. Once you are comfortable with those ideas, you could try implementing VBOs to see if it's any more performant.

Hey its GiraffeTap22 I forgot my pass and the email I used... anyway...

Thank you both very much for the replies! But if I can I would like to make my game from scratch.

Davedes I looked at the link to your classes. It gave me a few ideas, but I have a few questions about the whole thing

Could you explain the shaders program to me? I am completely confused about them, because when I hear the word shader I think about 3D models and lighting. Something not used in a 2D game.

Also, this maybe stupid of me asking, but what is the difference between drawRegion and draw?

Is drawRegion just drawing sprites that fall in a certain area?

Also I went back and changed my code up a bit. Its seems I can render 10000 sprites in about 180 - 215 milliseconds according to a simple execution run time check. I get the execution time by rendering all the of the sprites once and then closing down the program.

Shaders can be used for 2D or 3D purposes -- OpenGL doesn't know what kind of game you're making.

drawRegion is used for sprite sheets or "texture atlases" -- for example, instead of loading multiple PNG files into different textures, you create a single texture which contains all of your sprites. That way, you don't need to bind a new texture for each sprite, and you can also batch all of your sprites into the same render call.

You didn't really change or fix your example... It's still rendering one sprite at a time -- the whole point of a sprite batcher is to render many sprites in one render call.

I'd strongly recommend trying to learn the basics, like how to load and draw a texture without using SlickUtil, before tackling something like VBOs. Check out Stumpy's SpriteBatcher guide, and read through the lwjgl-basics library I've posted to try and get a better grasp on what's going on.

Like I said, you don't really need VBOs for a simple sprite renderer... Just stick with vertex arrays.

I guess I really didn't understand the concept of a sprite batcher then.

Correct me if I'm wrong. Ok so when we make a sprite batcher, we are really just calculating the vertex, texture, and color data for an X amount of quads (sprites) and thenplacing them in giant arrays.

Then when we reach our X amount of quads to handle at one time we render them using a single bind call

So basically this :

1 2 3 4 5 6

myBatcher.Begin();

myBatcher.draw(sprite1, 50, 50);myBatcher.draw(sprite2, 12, 9);

myBatcher.End();

Would start up the batcher Then add sprite 1 to the batcher and plan to draw it at x cord 50 and y cord 50.Then add sprite 2 to the batcher and set up its position. Finally the batcher's end function is called whichactually renders everything and does any clean up

Yep, that's the basic idea. Calling drawSprite puts that sprite's data into the array, and then increases the index pointer for the next call. Your array (or ByteBuffer) is a fixed size (generally something really big), and you render it all at once.

You only "flush" or "render" the batch when:- You reach the end of your array (index pointer > max)- You need to change the texture; i.e. render the batch with the old texture, then bind the new one- The user explicitly requested you to "flush" or render the batch, i.e. if they wanted to change the blend function.

@OP: not quite. It can depend on your implementation on how you handle thing but in general it would be more of.

1 2 3 4 5 6

myBatcher.Begin();myBatcher.draw(sprite1, 50, 50);myBatcher.End();

myBatcher.draw(sprite2, 50, 50);myBatcher.End();

The glBegin is normally not expensive as it only sets things up. It is the filling of they arrays/buffers that will slow you down the most. Then if you are using Texture Atlases, flushing to the gpu.

But yes the concept is like that in the respect that once you bind a new texture, everything currently in the batch needs to be sent to the gpu before you can start using the new texture otherwise your sprites will use the wrong image.

Awesome! One part does part concern me a little, you said I would call my renderfunction if I changed textures, but wouldn't that have the potential to slow me down?

What I mean is that if sprite 1 is texture A and sprite 2 is texture B then code below

Yes -- this is because (given the way it's currently set up) you can only have one texture bound at a time. That's why I suggested texture atlases to reduce texture binds and increase batch count. Every 2D game should use texture atlases to improve performance, where applicable.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org