TileObject: y-pos wrong

[iJ0N45]

http://imageshack.us/photo/my-images/543/objectbugypos.png/

when i place a tileObject ( object with an Image), the y-pos is to hight.
f.e. when i place a tileobject at (2,13), the pos is (2,14).

[sebbu2]

isn't the text in the status bar the position of the cell containing the title of the object, and not inside the rectangle ?
so the position in the status bar isn't the one of your object.

[geoffb]

I've run into this issue as well. There's indeed discrepancy between the x/y positioning of Objects vs Tile Objects. Take a look at this example:

Both of these objects are at 1 on the Y axis. The "Test 1" object reports its x/y coordinates as 1, 1 while the "Test 2" tile object reports its coordinates as 2, 2 (when it should be 2, 1).

My personal work-around for this bug is to adjust the y coordinate of all tile objects (objects with a gid > 0) by -1 tile on map load. Would love to see it fixed, though!

[Helgiii]

yep guys!!
please fix that! :)
I'll probably see if i can help with that, but i think i just better stick to using usual objects until its fixed

[stefanbeller]

In the old bugtracker https://sourceforge.net/apps/mantisbt/tiled/view.php?id=92 was a duplicate of this.

[stefanbeller]

As the version number is still below 1.0 meaning it is not stable, we could just change it and announce it at release.
Maybe a map converter moving all maps by one could also be provided.

[bgulanowski]

+1 on this issue. One short-term fix would be to distinguish between regular objects and tile objects in the tmx XML. A workaround is to put tile objects into a layer clearly marked as being tile objects and adjust accordingly.

[bgulanowski]

Another workaround which works for Cocos2D, and may work for other OpenGL-backed engines with Y increasing upwards, is to set the tile height to 0, so the Y position ends up correctly converted into pixels.

[Jocchan]

+1, this issue was driving me mad.

I'm using tile objects for crates and rectangles for platforms, with a physics engine. At startup, the crates would start at incorrect y coordinates and sometimes pass through thinner platforms. I thought the issue was somewhere in my (pretty complex) code or the physics engine, until I found out the discrepancy was exactly one tile.

Please fix this, would be greatly appreciated.

[zoneman]

Here's detailed example of a similar problem. Still waiting for a fix. Otherwise, I have to go to the "OffSetMap"(in Tiled) and set the x position to -1, to set the position of the tiles/objects affected layers. Then reset the position (+1) just before I compile the TMX file for export.
http://code.google.com/p/cocos2d-iphone/issues/detail?id=1448

[wesleywerner]

Ah so this is why my tile collisions is going all wonky :P

Proof: Create a new map with an object layer, add a new tile object in the top-left corner. Open the .tmx in a text editor, you will see the y value is one tile ratio too large (32 instead of 0 for a 32x32 size tileset).

<object name="player" gid="57" x="0" y="32"/>

[dylanetaft]

Also ran into this. Writing in a way to provide a workaround for LibGDX users by just exposing the "gid" attribute on objects as only those exhibit this bug....hopefully they accept my pull request. See pull request above.

I don't think this issue is intentional, is it?

[bjorn]

This is not a bug, the issue is better explained at #386.

In short, tile objects are freely positioned so placing them at 0,0 means they will sit exactly at the origin of the map. In addition, Tiled currently aligns tile objects in orthogonal mode to their bottom-left. This is the same for regular tiles, except that regular tiles are positioned in the bottom-left of their cell, which causes the difference in offset.

Going forward Tiled should support defining the alignment for tile objects, so that users can choose to align them to the top-left, which is often more intuitive. However, for backwards compatibility the default would remain bottom-left alignment.

I basically kept this issue open as a reminder to implement a proper solution, though maybe it would be better to open a new issue about that and close this one.

[GreenLightning]

@bjorn "In short, tile objects are freely positioned so placing them at 0,0 means they will sit exactly at the origin of the map."

But actually the tiles are drawn above the map, which is (for me) inconsistent with how real tiles behave.

I think the problem is that the map starts in the top-left corner, but tiles are handled according to their bottom-left corner.

The tiles should be handled according to their top-left corner and they should be aligned to the top-left corner of their cell, when used in a tile layer. This will fix this issue.

[bjorn]

@GreenLightning It's not helping to point to the problem and solution again, I had already explained it in my previous comment. And as I have said there, I can't just change the alignment cause this would break backwards compatibility. An option will have to be introduced for it (especially since the current alignment makes sense for some use-cases).

[pgigena]

Hello @bjorn . Are there any plans to include the setting for the tile object offset to be the top rather than the bottom in the near future?

[kheftel-old]

There are reasons to keep the alignment bottom-left, as well. Imagine your objects are trees on an orthogonal map, and taller than one tile. If the alignment is bottom-left, you place the tree according to its base, as it should be, and in your rendering code you draw the objects starting from the top of the map, and all the overlapping will work properly. If you align taller-than-one-tile objects on the top-left on an orthogonal map, you can no longer place them by their base, but must place them by their top, and that will depend on how tall the object is, and if you ever change the height of that object you'd have to re-align everything.

[bjorn]

@kheftel Well, that explanation was somewhat superfluous since this point was already made clear and @pgigena was informing about a setting for this.

I have no plans to work on this feature in the near future. Currently almost nothing happens in the near future since I have only very limited time to work on Tiled. If you really need a feature to be in soon, you could consider sponsoring it.

[kheftel-old]

oh, whoops. I got the email notification for the comment from 6 hrs ago and it included some of the previous conversation and I didn't realize the rest of the previous conversation was from 2013. my bad.

[mariogarranz]

I agree that depending on the game one may prefer the reference point to stay at the bottom left, top left, center...

So my opinion is it would be great to have a setting to switch this, like an anchor point you can set to any value from (0,0) to (1,1).

Right now I'm fixing it by code in the tile map loader, but well, it would improve the editor IMHO.

[MrJookie]

I just ran into the same. Really strange; object at 0,0 so its position should be 0,0 and now its 0,32. I am used to the start point top left corner, sad it is not the same in Tiled. Time to set new position :) y - tileHeight

[atbigelow]

This behavior is documented but I feel like it could be improved slightly.

For those running into this, it's easy to detect: just see if the XML node has a "gid" attribute. In that case, slide your object up some and you're good.

[bjorn]

@atbigelow While that will work for most people, just note that in general you will need to take into account the rotation of the object in order to slide it in the right direction.

Since my last post from 2014, things are looking rather better in terms of having time for Tiled development thanks to the support I receive on Patreon. This means I will eventually get around to working on a solution for this inconsistency.

[iam-jim]

But in most the cases flipping is done by negative scaling, which has to do with pivot/anchor point. Right now I am offsetting position for flipping. Still, its kinda hack.

[hexus]

Workarounds I've found for this:

• Detecting whether a GID value exists for the object and, if so, decrementing its height from its Y coordinate, with code
• Setting the Drawing Offset Y value of the tileset (Tileset > Tileset Properties) to the height of each tile, if you're not bothered about scale or rotation

I'm using the former just because it's less fiddly and manual.

I just wanted to see object artwork in the editor, it's much more intuitive than remembering what shapes or colours mean.

[justgook]

any chance it will be fixed ? or accepted some change request (i can try dig inside and find out issue)..

looks like problem is in item creation / movement..
https://github.com/bjorn/tiled/blob/master/src/tiled/createtileobjecttool.cpp#L50

if it will be sync with other objects.. that is then we in code could use same logic for all Object items.. so IMPO need to be just adjusted for editor - so all coords would be same, and then other apps can be easily adjusted..

[Geokureli]

I'm greatly infuriated by this issue, please resolve it

[Seanba]

(Please remember to be kind, guys)

"Fixing" this now would require me to refactor and rebuild my pipeline and tools. I'm not saying that should be the deciding factor but there has to be a number of other projects that have made their peace with this inconsistency a long time ago and would now read in TMX data incorrectly. Ultimately, I'll go with whatever Bjorn thinks is best - just give me a head's up first if it changes. :)

[Geokureli]

you can have a setting for the default origin on newly created objects(I.E. edge/corner anchor), and when a project file doesn't specify this for a tile object it defaults to the bottom left.

but lets be real, this should have never been the way it is. it's inconsistent with other parts of tiled as well as every graphics engine that uses it.

[bjorn]

but lets be real, this should have never been the way it is. it's inconsistent with other parts of tiled as well as every graphics engine that uses it.

@Geokureli As I've explained in my first comment, the current way made sense at the time because it was consistent with the way tiles are rendered on tile layers (where they are also bottom-left aligned in their cell). It was also the desired alignment at the time for the game I was involved with (which was top-down, in which case it makes sense to align sprites at the bottom).

you can have a setting for the default origin on newly created objects(I.E. edge/corner anchor), and when a project file doesn't specify this for a tile object it defaults to the bottom left.

Yes, to resolve this problem without incompatibility problems there will need to be an additional alignment/origin option. Simply changing it as done in PR #1894 is not an option.

[Geokureli]

Not to mention an origin point would be super useful for objects you plan to rotate in-game.

And sorry for the tude, when I wrote that I thought it would come off as more lighthearted banter, but rereading it just now I should have rephrased

[bjorn]

After some thoughts on this at #2136 (comment), the current plan forward is to introduce a "tile alignment" option on the tileset, which can be:

• Unset (the default, then it's BottomLeft for orthogonal maps and BottomCenter for tile objects on isometric maps, for compatibility reasons).
• TopLeft, BottomLeft, BottomCenter, Center... maybe more? Choice between completeness or limiting to common options to avoid coding for many never-used cases.

Once set, this alignment option would apply in any map orientation and for both tile layers and tile objects. And it would not only affect the default origin of the tiles in the tileset but also the corner to which the tile is aligned within its cell on a tile layer.

Now, an additional question is how this setting would work together with eventual support for setting individual tile origin, as well as how it works together with the existing tileset drawing offset. I have a hunch that it may be preferable that the individual tile origin defaults to the one based on the alignment + tile drawing offset, but when set would completely override those rather than adding an additional offset. Does this sound reasonable?

[igroglaz]

This sounds great! Can't wait to have this feature! :)

[PeterCassell92]

Also very keen to have the feature with alignment options.

[igroglaz]

Yes, it's very desirable feature. Without it I have to rename dozens of files every time I'm changing my locations :(((((

[mustii82]

Any News?

[Phlosioneer]

I'm working on this, as a good first-project in the tiled codebase.

I'm currently trying to decipher the code that draws tiles. The actual drawing of a tile is delayed for a while, so that multiple copies of a tile can all be drawn in one go. I'm trying to figure out how it saves the position it needs to draw for each saved tile.

So after I figure out this one function (CellRenderer::render), it should be done and ready for PR.

[bjorn]

The referenced commit by @Phlosioneer was a good start, but a lot more work happened as part of PR #2698. In the end, there is a new "Object Alignment" option on the Tileset, which controls the alignment of tile objects using tiles from that tileset.

Essentially any alignment is supported, but I expect commonly people will put this property on "Top Left" to make the tile objects consistent with the other objects. Other useful options could be "Bottom", which centers the objects bottom-aligned and "Center", which is intuitive if you're rotating tile objects.

[5310]

@bjorn Pardon the mention, but the new object-alignment feature isn't in the 1.3.2 release that was also published on the 20th 22nd, right?

[bjorn]

@5310 Tiled 1.3.2 was a bugfixing release. New features like the object alignment will come in Tiled 1.4.

But, you can already use them now by installing the build labeled snapshot, available on https://thorbjorn.itch.io/tiled. I release such development snapshots every few weeks, just keep in mind that sometimes a feature may still change and of course new bugs may be introduced (and any feedback on the changes is really appreciated, because it helps make sure 1.4 becomes a good release!).

[5310]

I never realized there were snapshot builds on Itch! I was trying to compile it myself, but I think I have my Qt dependencies messed up.

I'll move to the snapshot release immediately. Can take bugs and feature-changes for this project :]