Tiles ID and flipping (bug/feature)

Hello, Bjorn,

I don’t know is it a bug or strange feature, but it can get some people stucked.

When I put a check to “Flipping / Horizontal” or “Flipping / Vertical”, Tiled changes gid (set up bit 30 and bit 29 respectively for horizontal and vertical checkbox) instead of add some useful attributes. It makes errors on some software which directly using gid to link map objects with tileset tile IDs.

So I’d say in case this is a BUG - you could to fix it, or if it is a “feature” you could to document it somewhere so anyone can know about it.

Thank you for all your hard job on this awesome application!

It’s a feature because it is consistent with the global tile IDs used to refer to tiles on a tile layer. But you’re right that it is not documented very clearly. I’ll work on this.

You’re welcome! And also thank you for bringing up areas where things are still lacking. :slight_smile:


What should I know about other gid’s bits (except 30 and 29) ? What is a best mask to get exact tile id?

Thank you.

Well, you only need to know that the three most significant bits are used for the flipping flags. And in fact the third bit (diagonal flip) won’t ever be used for objects since they can be rotated freely, but I wouldn’t code special logic for that unless it makes things easier for you.

For some example code for reading out and clearing the flags, see this part of the TMX format documentation:


The same applies to the gid attribute of the tile objects.

Thank you, it is really helpful.

I was looking at that over the weekend.
It’s kind of annoying that have these bits part of the GID when they could be in separated fields…

If they were in separated fields, the GID would represent only the ID

1 Like

Absolutely agree with you, Richard. However, author’s word is the last :wink:

I agree the large numbers are not nice to look at, but from a code perspective it made perfect sense to store the tile reference along with the flipping bits the same way as done on tile layers. Doing it differently would require more code to be written in any TMX reader supporting this.

And leaving out the flags would not make it a plain ID. It would still be a GID, because a tile object can refer to a tile from any of the added tilesets.

But, it’s all not perfect. The TMX format has more serious flaws than this. I tried to be pragmatic but it would be nice to reconsider the format at some point, and you’re welcome to help with this.

100% agree. Bigger fish to fry :slight_smile:

Richard Lalancette
Ottawa, Ontario, Canada

This problem got me confused as well. I’m no stranger to bitflags, but I fully expected a flipH / flipV property to be exported for my flipped objects. Luckily I’ve already written an extensive data converter, so I’ll just need to extend it so that these flips will be translated to negative scale / scaleX / scaleY values instead, which is what our game engine uses.

Just like with scale, I’d like to stress that an option to include these flip properties in Tiled’s export would be super convenient. Or actually it’s the other way around: the current output format for a developer who’s using their own game engine (like myself) is quite confusing and inconvenient. And to be asked to learn how to write a Tiled extension just for the sake of getting more readable output is quite a big hurdle for a piece of software that’s supposed to make it super easy to edit levels in a visual manner and export it into a useful format.

But there are quite a few things about it that feel awfully confusing. No programmer new to Tiled would expect the gid to suddenly become a huge number when using the flip feature and it’s so frustrating to get seemingly random output like that. I’m sure you lose quite some potential users along the way when they encounter things like this and decide to look for less confusing software instead.

I very much appreciate all the effort that’s gone into Tiled and I full well realize this software cannot serve everyone’s needs. Thank you for your hard work and I hope you don’t mind the feedback. :slight_smile:

Agree, this is quite confusing, as is the example code showing how to deconstruct it back into something usable. :face_with_spiral_eyes: