The most efficient method of drawing multiple quads in OpenGL

I've been producing this 2d tile-based game engine to be used in several projects.

I have a class called "ScreenObject" which is mainly composed of a

Dictionary<Point, Tile>

The Point key is to show where to render the Tile on the screen, and the Tile contains one or more textures to be drawn at that point. This ScreenObject is where the tiles will be modified, deleted, added, etc..

My original method of drawing the tiles in the testing I've done was to iterate through the ScreenObject and draw each quad at each location separately. From what I've read, this is a massive waste of resources. It wasn't horribly slow in the testing, but after I've completed the animation classes and effect classes, I'm sure it would be extremely slow.

And one 开发者_JAVA百科last thing, if you wouldn't mind.. As I said before, the Tile class can contain multiple textures to be drawn at the Point location on the screen.

I recognize possibly two options for me here. Either add a quad at that location for each texture to be drawn, or, somehow.. use a multiple texture for the same quad (if it's possible). Even if each tile contained one texture only, that would be 64 quads to be drawn on the screen. Most of the tiles will contain 2-5 textures, so the number of total quads would increase dramatically with this method. Would it be feasible to add a quad for each new texture, or am I ignoring a better way to do this?

---

I'd suspect using a Dictionary would be slower than just using a straight array. If your world consists of 512x512 tiles then you allocate an array 512x512 (262144) in length. YTou can get any given tile in that array by using "array[x + (y * 512)]".

You know how many tiles there are so store an array where each either points to the tile at that position or has an index to the tile in a list (you will likely save memory this way as you can probably keep all your tiles in an array less than 65536, or maybe even 256, in size and thus store the index as a 16-bit.

You then find the area of your array you want to render. To do this optimally you want to avoid switching textures as much as possible. So first thing I'd check to see how big your tiles are I'd then try and combine as many of the texture into 1 big texture. Then set your UVs to sample a sub portion of this large texture. This way you should be able to limit the number of textures in use with a few big textures. Of course you will probably find that a given tile set (lets say rocky ground, for example) will use the same groups of textures. There may also be some blending across to grass somewhere so it may well be worth holding the grass textures in BOTH big texture to avoid doing so many texture swaps. ie sacrifice video memory for speed.

You then iterate over the visible portion of the array and draw all the tiles using texture 1 and then all tiles using texture 2 and so on.

---

I would recommend to use single VAO object composed from triangles + indices. Calculate position on client side and just update it on each frame (streaming).

Use texture atlas to store everything in single texture (to avoid switching states). You can use texture packer tool.

Render in one shot (if you have depth buffer enabled). Otherwise render first objects that opaque and then render everything that should be blended.