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.
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.
Not too big of a priority to me, but allowing tilemap layers would make parallax backgrounds more viable for me. My main maps are something like 1000x1000 tiles. To have a 0.5x0.5 parallax bg of that size it will eventually scroll out of viewable area. One option would be to allow the parallax to be 2000x2000 tiles, or let you make hundreds of little layers of like 60x30 and center them in each room.
Parallax is my use case as well. I often employ foreground parallax, which necessitates making my entire map larger than the “main” part of it, to fit the larger foreground layers. This necessitates manually defining the size of the main layer by hand as custom properties (and ideally also the sizes of all other layers, though I can calculate these by multiplying their parallax factor by the main layer size), and making sure I don’t draw anything important outside of that area. I currently manually mark the area of each layer I should not use with tiles, but this doesn’t actually prevent me from drawing in that area, and gets particularly annoying to account for in Automapping.
While I can use a script to size the map and add the custom properties, having to manually keep my drawing within each layer’s “usable zone” is annoying and unavoidable without the UI being properly aware of my layer sizes. It would also be nice to not parse the extra rows/columns of tiles; chunked storage wouldn’t help since most of the layers aren’t so different in size as store fewer tiles when chunked, and since I use tiles to mark where each layer “ends”, populating the would-be empty chunks in those cases where the chunks happen to line up with the unused areas.
The oversized foreground parallax layers also make using Worlds annoying, since it means my maps often have a significant overlap when they’re aligned according to their main layers, and if a large map is next to a small map, the larger map can completely cover up the smaller map due to the extra space occupied by its foreground layer. If maps could have a size smaller than their largest layer and were clipped to that size in the context of Worlds (IIRC such clipping is already planned to accommodate repeating image layers), it would make using Worlds with parallax-heavy maps more pleasant.
So, not a big priority for me either, but I’d like to see per-layer sizes if possible.