Map size vs tile layer size

given that a map can have various tile layers, each with their own width, height and grid size it makes more sense to me for the map to be defined in a simple width and height in pixels and each tile layer to have it’s own number of rows, columns, and tile size.

In my level I had a base terrain with about 50 smaller layers where each layer is a different coin spawn configuration. the base terrain is 40x40, but each coin layout is around 13x14 (as in, all of them affect the same 13x14 area on the map). I recently went into the .tmx (in vsCode) and changed all of the coin layers from 40x40 to 13x14 and chopped off the zeroes using a regexp and the .tmx went from 153kb down to 28kb.

when I open my level in tiled, it looks exactly the same, in fact each 13x14 layer still has a 40x40 grid even though the xml says it’s 13x14.

Tl;dr: I suggest giving each tile layer its own dimensions rather than copying the map, since the xml allows it anyways, and I recommend defining a map’s dimensions in pixels

Cropping off empty data seems like a great idea, but only as an option, since it would require changes to parsers.

As you pointed out, even though you only stored 13x14 tile layers in your TMX, the actual layer was still 40x40 when parsed. This means that cropping off empty data could be a compression option rather than a fundamental change.

On a more practical note, how are you storing your data? Was that 153kb compressed or uncompressed? If you have long stretches of empty tiles, using the compression options Tiled offers should give you quite small file sizes even without removing them, since long strings of 0 compress very well.

Apparently not, in regards to tile layer’s rows/columns, the tmx already contains the necessary data, only Tiled itself has any issues.

In the .tmx file and in my game the tile layer is 13x14, in Tiled the grid has 40 rows and columns because it’s ignoring it’s own data and using the map size for reasons that don’t make sense to me. I would be very surprised if ANY game engine requires all tilemap objects to have the same rows and columns.

this could be perfectly backwards compatible by adding new pixelwidth and pixelheight attributes to the main map node rather than changing the existing width and height attributes. To be honest I’m less concerned about adding that than I am with Tiled using and allowing me to manipulate the rows and columns of each tile layer, individually

I’d rather not add a decompression step to my game when I can just trim useless data and have smaller and more performant in-game tilemaps

Edit: thanks for pointing that out though, that can come in handy on larger projects

Actually if you change the map file in that way, the layer in Tiled really is only the size it has in the map file, and you will notice that if you try to draw tiles outside of that layer it will not work. One way to be able to draw on those layers everywhere again is to resize the map, which resizes all layers to match the map size.

Indeed in the TMX format and in the tile layer class used by Tiled, the size of the layer does not need to be the same as the map size. But this feature is not fully supported by the UI. There used to be partial UI support in the old Java version of Tiled, but I’ve never added this to the Qt version.

The reason for this is mostly that I didn’t consider the complexity this adds to be worth it. To do this properly, you need to clearly indicate the boundaries of the layer, and you need actions to resize layers. It could be done, but even in your use-case, @Geokureli, I’m not convinced that this would be the way to go. If your goal is to reduce layer storage space, then this can be achieved with an export option that optimizes the tile layers by autocropping them to their used areas. That way you’d avoid repeatedly doing manual steps to tweak layer sizes.

Tiled has another alternative, which is chunked layer data storage. It’s not going to be optimal in all cases, but using chunks you can also efficiently store a large tile layer that is only used in a few small spots, even if they are far apart. However, this is currently only used for infinite maps and of course it is not going to help reduce memory size if your game does not allocate tile layers in chunks. So actually in your case an export option could still be preferable.

Sorry for the late response.

I’m not sure I agree with the logic in leaving the width/height properties hidden. Compression isn’t my only goal here, I fail to see why 100 tilemaps should be 40x40 when I know I only need 13x14. My game is expecting tilemaps of this size, if I used autocropping, some would end up smaller and I don’t want that either.

Export options won’t really help me because I don’t export my files, I use the Tiled level file directly in my game.

I still request that you add a width and height field to the UI, and I think it’s a generally good idea for many users.