Describe the issue
In my general purpose parser creation endeavours, I have encountered an inconsistency between the .tmx and .tmj map formats. For maps that contain image layers that are saved to the .tmx format, those maps will look something like this:
The image layer in the json does not contain any image size properties, which means that for my general purpose parser, I will unfortunately have to return a slightly lossy model of the image layer to users that opt for the json format.
However, this is likely not a crucial issue at all. Image layers do not support any kind of free form scaling or rotating, which I'm sure is why the docs recommend you use tile objects instead. Since it doesn't support free form scaling/rotating, renderers will not have any kind of parameters to apply before rendering anyway, its file path should act as an enough identifier for a given renderer to know what to display and where.
The problem only lies in the inconsistency between the file formats, as I believe both formats should provide a similar amount of information.
Potential solution
I believe it would be a relatively simple fix to add imagewidth and imageheight to the image layer json output, similar to how tilesets provide image size properties. The addition of new properties like this should not be a problem regarding backwards compatibility either, if I'm not mistaken.
Describe the issue In my general purpose parser creation endeavours, I have encountered an inconsistency between the
.tmx
and.tmj
map formats. For maps that contain image layers that are saved to the.tmx
format, those maps will look something like this:Note the available
width="16"
andheight="16
on the<image .. />
tag.The exact same map, but instead saved to the
.tmj
format looks like the following: (formatted nicely for your ease of reading)The image layer in the json does not contain any image size properties, which means that for my general purpose parser, I will unfortunately have to return a slightly lossy model of the image layer to users that opt for the json format.
However, this is likely not a crucial issue at all. Image layers do not support any kind of free form scaling or rotating, which I'm sure is why the docs recommend you use tile objects instead. Since it doesn't support free form scaling/rotating, renderers will not have any kind of parameters to apply before rendering anyway, its file path should act as an enough identifier for a given renderer to know what to display and where.
The problem only lies in the inconsistency between the file formats, as I believe both formats should provide a similar amount of information.
Potential solution I believe it would be a relatively simple fix to add
imagewidth
andimageheight
to the image layer json output, similar to how tilesets provide image size properties. The addition of new properties like this should not be a problem regarding backwards compatibility either, if I'm not mistaken.Adding something similar to this: https://github.com/mapeditor/tiled/blob/e42fb8b426a4a9c964f3facd906141c9d8aae563/src/libtiled/mapwriter.cpp#L948-L956 To this function: https://github.com/mapeditor/tiled/blob/e42fb8b426a4a9c964f3facd906141c9d8aae563/src/libtiled/maptovariantconverter.cpp#L686-L706
Specifications: