Slick Forums

Tiled seems to be loading tilesets repeatedly for every map, so if you have several maps loaded, there are duplicate Images. This can be a major memory hog when you have several maps with big tilesets.

A solution would be to cache the tilesets and reuse them. A similar feature is being implemented in Tiled itself. I may do this one myself, but I want to see if anyone else has input.

edit: Implemented a hack solution, here's the patch. http://slick.pastebin.com/f151103e9

Yeah; I thought about that too; and it is kind of annoying.
If its not asking too much could you stick a commented version of your "hack solution" in the forum? I'm having a bit of a problem following the patch, and I'm to lazy to apply it ATM.

As a side note, I sometimes cycle a group of tiles in a tileset so as to create simple animation like flowing water. This could create unexpected results as cycling the tiles used by one map would cause the tiles to cycle in all maps that use the same tileset. Not a big problem, but if it goes undocumented it could cause some confusion.

_________________
If at first quads don't succeed tri tri again.

Basically I made a HashMap <String, Image>. Whenever the tileset image has to be loaded, it checks for the filename in the HashMap and reuses the image if it's there. If not, it loads from scratch and adds it in. Rudimentary, but it fulfills my requirements for now. A more complex solution is needed for unloading and dynamic updates.

Okay, implementation makes sense.
I think I need to retract my previous comment on it causing problems with tile cycling/swapping. Since you are caching the Image that backs the tileset object and not the tileset object itself as you originally stated; the problem I mentioned should not be an issue.

Myself I like the idea of resource caching, but I haven't run into situations where tileset images are consuming a great amount of memory, so it's difficult to envision the real world gains achieved. Since your project sounds like it benefits from caching tileset images I would very much like to see a comparison of memory consumption before and after the caching was enabled.

_________________
If at first quads don't succeed tri tri again.

Sorry for the double post but I just had a thought on how the caching could be implemented better.

Since TileSet is basically a Wrapper for a SpriteSheet it may be better to add a constructor to TiledMap that takes a SpriteSheet as a parameter. Somthing like:

Then you could have your caching mechanism elsewhere instead of embedded in the TileMap Class. For example you can use the typical Singleton approach and do something like

The down side to this is that there isn't much protection that the SpriteSheet will have the correct number of tiles or the right tile dimensions. So you will either need some magic numbers in the code, ugly and bad, or you will need to load the XML for the tileset when the SpriteSheet is created and then again when you create the tileMap; a little redundant.

I've been thinking of proposing a patch for some of the RFEs regarding TileMap that have been floating around so I figured I'd post to see what you thought of the approach.

_________________
If at first quads don't succeed tri tri again.

The image data is already cached at the image level, if you load the same image twice you'll get the cached version. The tile data itself I can add caching for but I don't know how worthwhile that'd really be.

Kev

The image caching is done on a per TileMap basis isn't it?
One TileMap isn't aware of Images loaded by another, so if I instantiate two TileMaps that happen to use the same image file for their tile set, each TileMap will create a new Image wont it?

_________________
If at first quads don't succeed tri tri again.

No, the Image data (as in the texture data on the card) is done on system wide level. So if two TiledMaps load the same image they should be sharing a single texture.

It will create a new Image but not a new Texture - which is where the actual image data and hence by far the bulk of the memory is taken up.

Kev