Structure of Tile Maps During Runtime

[programmerGuy]

My game is going to have tiled maps and I need help on how I should store the tiles. This question is about how the map is structured during run time not writing the tile data out to a file for storage.

Looking at Laurent's Basic Tiled Map he uses a std::vector<std::vector<sf::VertexArray>> for chunks which I'm also doing. In addition to that though, I need another std::vector<std::vector<>> because my tiles have data associated with them like if their collidable and their texture position. So essentially my map class holds a std::vector<std::vector<sf::VertexArray>> for rendering the chunks and a std::vector<std::vector<Tile>> for storing my "Tile" objects which look like this:

class Tile
{
public:
        Tile();
        Tile(sf::Vector2i texturePosition, bool collidable);

        sf::Vector2i getTexturePosition() const;
        bool getCollidable() const;

        const static int textureSize = 8;
        const static int screenSize = 32;

private:
        sf::Vector2i texturePosition;
        bool collidable;
};

I've included the entire class because I want you to see the size of it so you can answer an important question: My maps are going to have a reasonable size of about 512 tiles by 256 tiles, and I want 3 layers. This means one map will be 512 x 256 x 3 = 393216 tiles. This consequentially means a single map instance (during run time) will hold:

• std::vector<std::vector<sf::VertexArray>> = 3072 sf::VertexArray instances if my chunks are 8 x 8
• std::vector<std::vector<Tile>> = 393216 "Tile" instances

What I'm getting at here is that this is a lot of memory, or at least it seems like it. So question number one is:

Is this enough memory to justify using dynamic allocation? That is when the camera crosses a chunk boundary, some "Tile" instances would get deallocated (what camera can't see) and some new "Tile" instances would get allocated (what camera can see) along with some sf::VertexArray instances for rendering of course. That way only a small consistent amount of memory would be allocated at any given time regardless of the map size.

If you say yes to that question then that means my actual map data file, the file that actually contains each tile ID for the map will need to be present in memory during run time. This means when the camera moves and new chunks need to be allocated I can easily do that because the map file is present in memory. If your wondering how big this map data file is, it's about 512 tiles x 256 tiles x 3 layers x 2 bytes per tile = 786432 bytes = 768 kb = 0.75 mb which isn't a lot for just storing the file on your hard drive, but having 768 kb of memory allocated during run time might be, I don't know.

What do you guys think, should I only load tiles the camera can see using chunks, or should the whole map be loaded?

[Nexus]

Why don't you simply store the type of a tile in your Tile class? A enum typically only uses 4 bytes, and you can even use a smaller underlying type with C++11. You can then lookup the texture position and the bool flag.

You can easily keep all tiles in memory at once. Concerning vertices, it should be enough to hold those that are currently visible. I think it wouldn't even be a problem if you created the vertices anew every time before you draw; but you have to measure to be sure.