mapeditor / tiled

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

Draw offset for individual tiles #871

Open tcoxon opened 9 years ago

tcoxon commented 9 years ago

In my current project, we have a lot of sprites that we want to be able to place with tile objects in Tiled. Each of these can have a different origin point within the image.

Draw offset is supported as a property of the tileset, whereas, for us, it would be more useful if it was configurable on a per-tile level, as that would allow us to put all these sprites within a single tileset.

I have a workaround I think will work, but it would be nice to be able to do it in Tiled. It would make draw offset more general.

bjorn commented 9 years ago

Thanks to @Ablu for tracking down the following commit which implements part of this functionality:

https://github.com/bjorn/tiled/commit/9b5590795d66ac525b9c9b39b8d390e3b0fa00e6

ElonDev commented 9 years ago

Here is clean code who get custom property in tileset file : 5a97ea6871fbfa998d1176448197f4ea5fb27870

Example

<tile id="0">
    <image width="110" height="70" source="tiles/0.png"/>
    <properties>
        <property name="originalX" value="56"/>
        <property name="originalY" value="28"/>
    </properties>
</tile>
elvisish commented 6 years ago

Is this possible yet in Tiled?

bjorn commented 6 years ago

@elvisish Nobody has worked to integrate this feature so far.

The commit I linked to in my previous comment implements part of the needed functionality. What is missing is:

bjorn commented 6 years ago

Issue came up on the forum.

bjorn commented 5 years ago

Requested again on the forum.

alaa-eddine commented 4 years ago

Hi, Sorry to bring this back again :D (I already reported it here https://github.com/bjorn/tiled/issues/1958 )

I see that both issues was closed, is there any plans to support this at some point, or is there any workaround for it ? (like setting the offests manually in the image tile) ?

sorry for bothering you again with this 😄

alaa-eddine commented 4 years ago

oh sorry I just saw that it's available already.

it was just not obvious to show the tileset properties once we add images to it.

please ignore my previous comment :)

bjorn commented 4 years ago

@alaa-eddine Right, it's just not for individual tiles (hence this issue is still open, actually). But if the tileset-wide offset works for you, that's great!

genericptr commented 3 years ago

Just leaving a comment to reference my request for image offsets in the isometric collision editor (@bjorn says it is related to this issue) https://discourse.mapeditor.org/t/image-offset-in-isometric-collision-editor/4997

ghost commented 3 years ago

Just to add another voice, I'll need this too. Given that this issue seems to surface fairly frequently and is quite fundamental (almost all game engines have the notion of per-object origin), may I be so bold to suggest making this a priority? The editor is a fantastic job otherwise right now -- I find myself very satisfied but regret that this small thing can be quite a dealbreaker.

roomyrooms commented 2 years ago

I'd also love if this were possible. Big issue in trying to import maps into Tiled as of the moment for me

SomethingWithComputers commented 2 years ago

It would be great if there were per-tile offsets similar to how godot/unity allows.

SoupySoups commented 2 years ago

I would also like to see this feature!

TheLegoSensei commented 2 years ago

gimme

eishiya commented 1 year ago

Drawing offsets rather than origins would be helpful for iso/hex tilesheets with depth where the tiles aren't aligned consistently, e.g. when they're all centred within their bounding boxes, rather than having their bottoms all line up.

My thoughts on this topic, and why I don't like the direction the current PR is going:

I see two distinct problems here:

I am not confident that both issues can be solved with the same feature, which seems to be the current goal, even though in most cases, a tile is either meant for use in Tile Layers or as Objects, and it's therefore not common to need distinct values for the offset and for the origin. Even though there's little overlap, these are still distinct needs with distinct purposes.

Tiled currently conflates two distinct aspects of Objects with associated sprites/tiles in game engines: the Object's origin point, and the drawing offset of the sprite relative to the Object. In engines, it's quite common that the Object is not the same size as the sprite representing it, and in Tiled, this is currently only possible to represent with Tile Collision, but the Tile Collision does not affect snapping, and it's not possible to view Tile Object collisions without also viewing Tile Layer collisions. The current handling of drawing offset for Tile Objects is also inconsistent with Tile Layers: in tile layers, it's merely a cosmetic offset that doesn't affect the underlying position of the cell and the way you select the cell, but for Tile Objects, it affects the actual position of the object and affects how you select it, due to the conflation described above.

I think that the solution to this issue should be as stated in the original post: per-tile drawing offset.

Tile Objects could use a bit of rethinking to better match the roles they tend to play in engines: origin should be an object property for all objects, not just Tile Objects, and Tiles should be treated more like sprites drawn on top of an underlying Rectangle rather than the object themselves - they should have their own scale factors independent of the object size as requested in #3129 (but could default to "match object size", and perhaps there could be a per-tile default scale setting), and they should be offset from the object according to their Drawing Offset, but when selecting the object, it should be the object's shape/bounding box that is highlighted, not the tile's bounding box. Per-Object (not per-Tile) origin would also solve #560 and make rotations more convenient in general. If done this way, Tiles can still have a default object origin assigned to them as a convenience, so that when Objects are made with those tiles, they inherit that object origin, since Objects sharing Tiles tend to share the same origin. The origin could still be overridden on a per-Object basis, so two objects using the same tile can have different origins if the user wants. Perhaps it could even be possible to make Tiles something you can attach to any shape, rather than a dedicated Object type :]

duarm commented 1 year ago

While opting for a much simpler tile rendering logic, we decided to have a fixed size for our hexagonal tiles, because of that, we need to set a rendering offset on our tileset, otherwise the grid would be misaligned. The problem is that the tile snapping feature only takes the origin into account, since we need a custom origin for our tiles because they are bigger than the actual hexagon, it snaps incorrectly. Instead of predefined dropdown, the Object Alignment property should accept custom values too.

carlislefox commented 1 year ago

I've unfortunately just ran into this issue myself, I am in the midst of reworking some core engine code in order to transition away from basic Tile maps to a more Entity driven approach, and the "collection of images" tileset plays into this really well... until I have something like a lamp post that sticks out a bit at the edges. For the moment I am going to leverage properties and have the Engine render pipeline handle it, but it would be really nice if I could get Tiled to display things as they appear in game with this feature.

This ticket seems to be targeted at Tile objects, but I think this would be a valuable feature for the "multiple image" tilesets on individual images too. For me, who has statues and lamp-posts and things that stick out horizontally over the edges of adjacent tiles anyway.

Edit: Worth mentioning I forsee a complication with the collision boxes when a render offset is present... I think having the collision bounds also be affected by these offsets makes sense to me and is the obvious thing to do but I thought it best to mention it in case others have good reasons why that is a bad idea ;)