Using Vertex Buffer Objects for a tile-based game and texture atlases

I'm creating a tile-based game in C# with OpenGL and I'm trying to optimize my code as best as possible.

I've read several articles and sections in books and all come to the same conclusion (as you may know) that use of VBOs greatly increases performance.

I'm not quite sure, however, how they work exactly.

My game will have tiles on the screen, some will change and some will stay the same. To use a VBO for this, I would need to add the coordinates of each tile to an array, correct?

Also, to texture these tiles, I would have to create a separate VBO for this?

I'm not quite sure what the code would look like for tiling these coordinates if 开发者_运维知识库I've got tiles that are animated and tiles that will be static on the screen. Could anyone give me a quick rundown of this?

I plan on using a texture atlas of all of my tiles. I'm not sure where to begin to use this atlas for the textured tiles. Would I need to compute the coordinates of the tile in the atlas to be applied? Is there any way I could simply use the coordinates of the atlas to apply a texture?

If anyone could clear up these questions it would be greatly appreciated. I could even possibly reimburse someone for their time & help if wanted.

Thanks,

Greg

---

OK, so let's split this into parts. You didn't specify which version of OpenGL you want to use - I'll assume GL 3.3.

VBO

---

Vertex buffer objects, when considered as an alternative to client vertex arrays, mostly save the GPU bandwidth. A tile map is not really a lot of geometry. However, in recent GL versions the vertex buffer objects are the only way of specifying the vertices (which makes a lot of sense), so we cannot really talked about "increasing performance" here. If you mean "compared to deprecated vertex specification methods like immediate mode or client-side arrays", then yes, you'll get a performance boost, but you'd probably only feel it with 10k+ vertices per frame, I suppose.

Texture atlases

---

The texture atlases are indeed a nice feature to save on texture switching. However, on GL3 (and DX10)-enabled GPUs you can save yourself a LOT of trouble characteristic to this technique, because a more modern and convenient approach is available. Check the GL reference docs for TEXTURE_2D_ARRAY - you'll like it. If GL3 cards are your target, forget texture atlases. If not, have a google which older cards support texture arrays as an extension, I'm not familiar with the details.

Rendering

---

So how to draw a tile map efficiently? Let's focus on the data. There are lots of tiles and each tile has the following infromation:

• grid position (x,y)
• material (let's call it "material" not "texture" because as you said the image might be animated and change in time; the "material" would then be interpreted as "one texture or set of textures which change in time" or anything you want).

That should be all the "per-tile" data you'd need to send to the GPU. You want to render each tile as a quad or triangle strip, so you have two alternatives:

• send 4 vertices (x,y),(x+w,y),(x+w,y+h),(x,y+h) instead of (x,y) per tile,
• use a geometry shader to calculate the 4 points along with texture coords for every 1 point sent.

Pick your favourite. Also note that directly corresponds to what your VBO is going to contain - the latter solution would make it 4x smaller.

For the material, you can pass it as a symbolic integer, and in your fragment shader - basing on current time (passed as an uniform variable) and the material ID for a given tile - you can decide on the texture ID from the texture array to use. In this way you can make a simple texture animation.