Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TileObject: y-pos wrong #91

Open
iJ0N45 opened this issue Oct 9, 2011 · 33 comments

Comments

Projects
None yet
@iJ0N45
Copy link

commented Oct 9, 2011

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

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2011

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

This comment has been minimized.

Copy link

commented Oct 29, 2011

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:

ypzem

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

This comment has been minimized.

Copy link

commented Feb 18, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

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

@stefanbeller

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2012

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

This comment has been minimized.

Copy link

commented Jul 17, 2012

+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

This comment has been minimized.

Copy link

commented Jul 17, 2012

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

This comment has been minimized.

Copy link

commented Jan 1, 2013

+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

This comment has been minimized.

Copy link

commented Jan 1, 2013

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

This comment has been minimized.

Copy link

commented Mar 30, 2013

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

This comment has been minimized.

Copy link

commented May 28, 2013

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 comment has been minimized.

Copy link
Owner

commented May 28, 2013

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

This comment has been minimized.

Copy link

commented Jul 15, 2013

@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

This comment has been minimized.

Copy link
Owner

commented Jul 16, 2013

@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

This comment has been minimized.

Copy link

commented Oct 22, 2014

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

This comment has been minimized.

Copy link

commented Oct 22, 2014

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

This comment has been minimized.

Copy link
Owner

commented Oct 22, 2014

@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

This comment has been minimized.

Copy link

commented Oct 22, 2014

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

This comment has been minimized.

Copy link

commented Feb 13, 2015

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

This comment has been minimized.

Copy link

commented Apr 26, 2015

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 comment has been minimized.

Copy link

commented May 19, 2015

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

This comment has been minimized.

Copy link
Owner

commented May 19, 2015

@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

This comment has been minimized.

Copy link

commented Oct 30, 2015

Hope this issue gets some love soon, having a hard time implementing a consistent object (all kinds of) loader with rotation, flipping, and scaling. If I consider flipping then rotation gets messed up, if I consider rotation then flipping gets messed up because tiled is using different pivot/anchor point for different functionality which is undesired considering most engines has single pivot support for all transformations.

@bjorn

This comment has been minimized.

Copy link
Owner

commented Oct 30, 2015

If I consider flipping then rotation gets messed up, if I consider rotation then flipping gets messed up because tiled is using different pivot/anchor point for different functionality which is undesired considering most engines has single pivot support for all transformations.

Maybe it's easier if you consider the pivot Tiled uses is actually always the "position" of the object, and in that sense it is not inconsistent. The only thing that is inconsistent is where the object is rendered relative to its position, but that has nothing to do with the transformations that are applied to it.

Also, flipping, assuming you mean in the context of tile objects, only changes the texture coordinates, so it also has nothing to do with the rotation.

@iam-jim

This comment has been minimized.

Copy link

commented Oct 31, 2015

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

This comment has been minimized.

Copy link

commented Jul 4, 2017

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

This comment has been minimized.

Copy link

commented Feb 26, 2018

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

This comment has been minimized.

Copy link

commented Mar 23, 2018

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

@Seanba

This comment has been minimized.

Copy link
Contributor

commented Mar 23, 2018

(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

This comment has been minimized.

Copy link

commented Mar 23, 2018

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

This comment has been minimized.

Copy link
Owner

commented Mar 23, 2018

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

This comment has been minimized.

Copy link

commented Mar 24, 2018

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

This comment has been minimized.

Copy link
Owner

commented Jun 19, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.