👍 for this feature

Support for texture atlases is something I've wanted for a while. I've been using multiple tilesets based on size as a workaround.

Alright, I've added it to the Tiled roadmap where you can also vote on it: https://trello.com/b/yl3PAtN0/tiled-roadmap

One worry I have with this feature is that people will pack their images using for example TexturePacker and then use the result in Tiled. When done this way, Tiled has currently no way of numbering the tiles in a way that would remain stable in the event that the texture atlas is re-packed after images have been added/removed. For this use case, the user is expected to use the individual images in Tiled and only use the packed texture in the game, as an optimization.

The reason I still want to support this feature is mainly because it is often convenient for an artist to put related tiles on the same image, even if they have different sizes. In this case, there should be a way to tell Tiled where to find those tiles and to update that information when the image changes, without invalidating tile references.

Also asked for on the forum.

And asked here again 👍

https://discourse.mapeditor.org/t/make-tileset-working-with-texture-atlas/3661

Bjorn,

When a texture atlas is re-packed again, it may impact existing tileset and invalidate the reference.
But I believe it's the responsability of the user to relocate the tileset location in the atlas by providing the following parameters:

• x and y offset (or margin)
• width and height of the tile set
• spacing if any.

If the user is using a tool such as TexturePacker, then he has the possibility to export a Json file that describe the location of each tileset in the atlas.
Therefore, if the texture is repacked he can re-enter manually the parameters above to keep the tile references valid.

Z.

A simple way to add this feature could be to add some attributes to select a "sub" image.

This new attributes could be inspired by canvas drawImage arguments: at least sx and sy, maybe sWidth and sHeight.

<?xml version="1.0" encoding="UTF-8"?>
<tileset version="1.4" tiledversion="1.4.2" name="background">
 <grid orientation="orthogonal" width="1" height="1"/>
 <tile id="0">
  <image sx="1" sy="1" width="32" height="32" source="image.png"/>
 </tile>
<tile id="1">
  <image sx="33" sy="1" width="48" height="64" source="image.png"/>
 </tile>
<tile id="2">
  <image sx="1" sy="33" width="16" height="16" source="image.png"/>
 </tile>
</tileset>

@devnewton Hmm, a similar feature is planned for regular tilesets (#2863), but I agree it could be a good idea to also support this for a collection of images tileset like in your example. Though probably a unified element should be used for specifying the sub-rectangle.

Why even use numbers for the indexes for these kinds of tilesets?
Just use the frame name, so if it moves around on the texture atlas as long as the frame name is the same everything that was using it should still work.

Why even use numbers for the indexes for these kinds of tilesets? Just use the frame name, so if it moves around on the texture atlas as long as the frame name is the same everything that was using it should still work.

Numbers are shorter, easier to deal with, and don't require user input, and Tiled can ensure uniqueness much more easily. If #2863 is implemented, they'll do just as good a job of dealing with arbitrary tile rectangles too.

Why even use numbers for the indexes for these kinds of tilesets?

I think the simple answer is that the tile addressing scheme needs to stay uniform. There is no way a tile layer could refer to some tiles by number and others by name, depending on the kind of tileset it is referencing. It would add least add a form of complexity better avoided.