koobas.hobune.stream
Fastest way to draw a grid of textures
I'm making a 2D game in which we draw a 200x200 grid of textures -- the pieces on the board. Each cell can only be one of about ten different textures. There are small changes every frame -- a piece dies here, one becomes born there, but most stay where they are. Right now we are drawing it by allocating a GameObject, a textured quad, for each nonempty cell. But when most of the board is filled with pieces, this really starts to be a framerate drag. I'm wondering if there is a better way to do this.
Thanks!
Subdivide your grid world into groups. 10x10 sized chunks for instance. Render those to texture as their component tiles change. And then from that, render your 400 set of chunks. That's still a lot of draw calls, so I'd probably group them even more. Try 20x20 size chunks?
For this kind of thing, normally, you'd probably want to generate grid mesh procedurally in code, where each grid tile is a 2-tri quad with unique vertices (not shared with its neighbours).
You'd then put every texture option on to a single large texture (a.k.a. a "Texture Atlas").
Finally, you'd adjust the UV coordinates for each quad so that it displays the correct portion of the texture atlas - which means it would display the correct tile out of your selection of tiles.
However Unity (like many other game engines) has a maximum limit of 65536 vertices per mesh, and for 200x200 tiles x 4 vertices each, this gives you 160,000 vertices, so this throws a spanner in the works.
If your design is flexible enough to change the grid size down to about 120x120 instead of 200x200, this solution could work for you.
If not, you'll have to start with the above method, but modify it so that it breaks it up into a number of separate meshes so that each individual mesh doesn't exceed the maximum vertices.
Doesn't adjusting the UV coordinates involve updating the entire mesh, which as I recall is not an entirely cheap operation? We have to change it a little bit every frame.
Duck's answer segment to code/script/programmatically solve the grid generation can not be overstated enough. When you look at a 2D Grid that's out of bounds. Think about a 3D grid (concept) Where every change extends into the depth of the second 2D grid. 3D can be seen as a ton of 2D lines (CAT scan PET scan) you can mimick this in your split-grid if you know a bit of code and numbers.
