Creating a mesh programatically for a tile-based 2D game


currently I create a tilebased mesh programatically. The user can edit the tiles (place or destroy them) in the game. The tiles are all squares, so I can reuse the vertices from the right side of one tile for the left side of the next one. That way I can reduce the vertices in the mesh to 1/4. But now I face a problem with this while applying a texture to the mesh:

The texture is a spritemap, so the uvs determine which sprite the tile will have. It works great for single tiles but leads to a problem when some vertices are reused. For example a vertice belongs to tile 1 as the right bottom corner and tile 2 as the left bottom corner. The texture contains only one sprite for this example. Now both tiles would need different uv coordinates for the same vertice (tile 1 would need (1, 0) and tile 2 (0, 0).

Right now I think it is impossible to reuse the vertices but have different uvs. So there are two options available:

a) Don’t reuse vertices. This would lead to four times as many vertices in the mesh. I got up to 5,000 tiles on the screen, so 20,000 vertices and uvs need to be saved. I don’t know how much this affects performance/ram usage.

b) Don’t use a spritemap but build a texture instead. With this approach I would create a texture for each chunk and paint it with the pixels from the spritemap. With 5000 tiles I would only need around 1250 vertices/uv’s (okay, some more because vertices are currently not shared between chunks) but I had to repaint the texture every time the user changes the map. It would “only” affect the actual edited chunk and it’s direct neighbours. Again I don’t know how the impact on the performance/ram usage is.

Perhaps anyone have experience with this topic and can help me to choose the right option. Or maybe it doesn’t have much impact at all. I could implement both and try to find the best one, but perhaps someone has done something similar and can spare me some struggle.

Don’t reuse vertices. 20k vertices shouldn’t be a problem. If the vertex count gets higher than 65k, you can always divide the mesh into chunks.