Messages

1

General / Structure of Tile Maps During Runtime

« on: August 25, 2013, 03:51:15 pm »

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?

2

General / Re: Derive from sf::Drawable?

« on: August 07, 2013, 11:43:08 pm »

Thanks for the answer! Cleared up the confusion.

3

General / Derive from sf::Drawable?

« on: August 07, 2013, 10:29:53 pm »

The question of whether you should derive a class that draws something from sf::Drawable or give it a separate draw function has already been asked before.

This:

window.draw(menu)

or:

menu.draw(window)

However, I haven't seen this discussion for SFML 2.0 and higher. In SFML 1.6 the sf::Drawable class had things like:
- set/get position
- set/get rotation
- set/get scale
- set/get color
- set/get blend mode

And if it made since to have these in your class then you would derive from sf::Drawable, but now(in 2.0+) the drawable class just has a single draw function.

So should you always just derive from sf::Drawable if your class draws something? Or am I missing something else?