mapeditor / tiled

Flexible level editor
https://www.mapeditor.org/
Other
11.26k stars 1.76k forks source link

Image size missing for image layers in json #4028

Closed dcronqvist closed 2 months ago

dcronqvist commented 3 months ago

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:

<?xml version="1.0" encoding="UTF-8"?>
<map version="1.10" tiledversion="1.11.0" orientation="orthogonal" renderorder="right-down" width="5" height="5" tilewidth="32" tileheight="32" infinite="0" nextlayerid="2" nextobjectid="1">
 <imagelayer id="1" name="test">
  <image source="texture.png" width="16" height="16"/>
 </imagelayer>
</map>

Note the available width="16" and height="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)

{
  "compressionlevel": -1,
  "height": 5,
  "infinite": false,
  "layers": [
    {
      "id": 1,
      "image": "texture.png",
      "name": "test",
      "opacity": 1,
      "type": "imagelayer",
      "visible": true,
      "x": 0,
      "y": 0
    }
  ],
  "nextlayerid": 2,
  "nextobjectid": 1,
  "orientation": "orthogonal",
  "renderorder": "right-down",
  "tiledversion": "1.11.0",
  "tileheight": 32,
  "tilesets": [],
  "tilewidth": 32,
  "type": "map",
  "version": "1.10",
  "width": 5
}

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.

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:

bjorn commented 2 months ago

Good idea, and thanks for digging into the details! Should be addressed by #4054.