[TileMap] Looking for a suitable way to store data.

[simpl]

Hello ,

as my topic title says I'm looking for a suitable way to store or rather represent the tile map data in a class.
For a long time now I'm working with the tiled map editor and I like it.
Now I'd like to write my own minimal parser, the xml stuff isnt much the problem, but I have no idea which approach I could make use of, to store the data in a class. There is already a library, written by fallahn (sfml-tmxloader). In my case it just doesnt fit well.

Instead of using arrays of vertices, I stick with simple Sprites as my map isnt very big and array of vertices would just be an overkill. In tiled I use only the iso way of drawing, but that is another pair of shoes.

For now the data is described as follows:

std::vector<std::shared_ptr<sf::Sprite>> mTiles

and for different layers:

std::map<sf::Uint16, SingleLayer::Ptr> mMapLayers

It works very well, but what could I do to get a tile at a specific position?
My idea was to store it somewhere else, maybe in the logic of the mapParser, but that doesnt make much sense to me. Somedays I read a very interesting topic here about two-dimensional vectors for tilemaps, but I'm unable to find it .. .

My finally question is now, what are the best practices to store sprites for a tilemap?
Should I go with the current approach? Im a little bit doubtful..

Thanks for your time

[Stauricus]

can i suggest you something? an array of vertices isn't overkill. but an array of sprites is

that said, first thing would be to have an bidimensional vector - unless your game is a single line of tiles (or maybe you want to make unnecessary calculations, like the ones needed when you have an pseudo-bidimensional array dinamically allocated).

also, i'm not a experienced programmer, so i'd like to know: why are you using  shared_ptr and std::map here? what's the need of a ptr in your tile sprites? and why a std::map instead of a simple vector as layers?

[Ixrec]

can i suggest you something? an array of vertices isn't overkill. but an array of sprites is

I'm not quite sure what you mean by "overkill", but an sf::Sprite is little more than four vertices and a pointer to an sf::Texture, so the two options are almost identical except that using sprites makes it easier to keep track of things like which texture goes with which vertices (which is a good thing).

Though I agree that there's no obvious reason to use shared pointers to sprites or a map from ints to anything in this case.


@simpl: Unfortunately your post is too vague and fragmented for us to really give you any sort of concrete answer, other than pointing out that the two lines of code you did post are extremely strange choices for data structures.  So I'll try quick knee-jerk responses to tiny bits of your post and see if I get lucky with one of them.

It works very well, but what could I do to get a tile at a specific position?

Since you're the one loading the tiles, and we don't know how you're doing it or where you're putting them, not much we can say.

My idea was to store it somewhere else, maybe in the logic of the mapParser, but that doesnt make much sense to me.

Dunno enough about your mapParser to comment in detail.  However, generally speaking, the class that "owns" a piece of memory should be the last (or only) class that actually uses it.  My blind guess is that your mapParser is not this class, so perhaps it should merely take a reference to a container for it to fill up, so the caller can own that container.

Somedays I read a very interesting topic here about two-dimensional vectors for tilemaps, but I'm unable to find it .. .

That might've been me.  Basically, if you want an X by Y grid of something, you can use a vector of vectors (which creates what's called a "ragged array") but for various reasons it's usually better to use a single vector of size X times Y.  Some of my recent posts describe this in more detail.

My finally question is now, what are the best practices to store sprites for a tilemap?

As previously mentioned, a single vector of length X by Y is what I'd recommend.  A simple std::vector<sf::Sprite> is completely fine for this.  It would also be a good idea to wrap this vector in a little class that implements whatever primitive operations you expect to be performing on a tilemap.

Should I go with the current approach? Im a little bit doubtful..

Your current approach appears to be more complicated than the obvious one, so unless you have a good reason for introducing that complexity (I didn't see one in your post), then the answer is no.

[fallahn]

I agree using pointers to sprites in a container is probably not the best idea, as this would be a good case where indirection can be a Bad Thing, as explained here and demonstrated by Herb Sutter. You can always use push_back() (or emplace_back() - I can't remember if sprites are non-copyable) with sprites in a container (in fact this would probably be true in most cases not just with sprites, you often only need a container of pointers when they are pointers to base classes, and you don't know the concrete types to which they point). I'd like to point out though that, while my Tiled library also started out by using sprites for each tile, it quickly became apparent vertex arrays are preferable, not because of storage space, but due to the number of draw calls. Each call to draw() carries its own overhead and, while modern computers can draw thousands of sprites happily, tile maps are a case where that number can rise very quickly.
    For example a small tile map of 32 x 32 tiles will require draw() to be called 1024 times. 64 x 64 tiles calls draw() 4096 times... plus it is not uncommon to have multiple layers when using Tiled (for example when doing something like this) - 3 layers increases the count to 12288... It was at this point I found myself asking 'is it worth reducing that number to 3 (best case, one array per layer) by using vertex arrays?' - and answering: 'probably, yes.'

[Stauricus]

can i suggest you something? an array of vertices isn't overkill. but an array of sprites is

I'm not quite sure what you mean by "overkill", but an sf::Sprite is little more than four vertices and a pointer to an sf::Texture, so the two options are almost identical except that using sprites makes it easier to keep track of things like which texture goes with which vertices (which is a good thing).

actually i was talking about this:

vertex arrays are preferable, not because of storage space, but due to the number of draw calls.

i see no benefit in using lots of sprites as tiles, since a vertexarray behaves as a single big sprite that can be drawn at once. each sprite also stores info as rotation and scale, which will not be different from one to another. it seems a waste of memory (even if its a small) and performance (not so small).

[Raincode]

I don't mean to be rude, but there must be plenty of threads and resources on this... Just sayin