Tilemap with Rectangular or No-Square Tiles Broken

[aaschmitz]

Godot version:
Git e22dde1

OS/device including version:
Ubuntu 18.04.2 LTS

Issue description:
The tiles from tilesets are aligned in the "center" instead of the top-left corner (green selection in the image). If the tiles are square, the issue does not appear but if the tiles are rectangular or other shape or flip/transpose the tiles, the map is broken (red selection in the image).

The issue started with commit #28896 about Tilemap displaced textures.

Steps to reproduce:
Check the "Platformer" Demo from Official Godot Demos (2d/platformer), the tile "ramp" and the tile "wall_deco" show the problem.

Minimal reproduction project:
Official Godot 2d Platformer Demo

[YeldhamDev]

CC @Ranoller

[Ranoller]

Well, that was a part of the main idea. If the texture is bigger that the tile, start in the center and use texture offset to move the texture. But if is dessired to always put the texture in top-left, is easy to do, i don't find sense in do that (ex: i think in draw grass bigger than cell and want it in the center). If i think in real use situations, i will find more situations needed texture starting in center or bottom (a tree a statue...), than in top left.... but i do what do you want, fix demo? make texture position in top left?

[Ranoller]

i only have to supposse how to transpose a texture bigger than cell size and placed in top left, because flip is understandable, position is the same... but transpose.... in top left too?

[Ranoller]

To considerate: imagine a tilemap with a tiny texture (smaller that the tile)... Where is the position in the tile that you find more coherent to put the texture? (imagine real use cases).

[Ranoller]

I see 4 possibilities:

1. Make an option to "texture origin" the same that there is an "origin point" (to do different z order) and make default top-left. That makes that demo compatible with the changes, but make tilemap more complicated (will need documentation). (origin point can be renamed to "tile origin" or "tile origin point", more descriptive about the functionality) (texture origin can be "texture and shapes origin" or only "texture origin" and make an explanation in the tooltip about that this option choose the origin of the shapes too)

2. Simply revert my commit. I was sure to do the right thing, but i can be wrong and probably mixing what i need with godot needs (i can change the code in my master to my necesities, no problem about that, i suposse other people do)

3. Fix the demo... well, the problem with that: if is real that people uses textures bigger than cell sizes and make the map with that and current behavior, they will need to fix their tilesets, i don't know if this kind of breaking will be acceptable for 3.2.

4. Make texture origin always top left... well, ugly, but i do not make the decission.

Spoiler:
for option 1 i will need help (to do the option button, the headers in tile_map.h etc...) or time (i can learn, test, learn, test the same that i did with the original commit)

[aaschmitz]

In the Tilemap node has a "Tile Origin" property with the "Top Left", "Center" and "Bottom Left" options:

Maybe this would be the option to set the Tile origin (the default is Top Left)?

[groud]

Yes, it should be at least possible to have the tile origin at top left. When you have big sprites, it is usually because they take several tiles (as a tree for example), so they should align with the grid.

Also this cannot be left as is, as those recent changes broke compatibility.

[Ranoller]

In the Tilemap node has a "Tile Origin" property with the "Top Left", "Center" and "Bottom Left" options:

Maybe this would be the option to set the Tile origin (the default is Top Left)?

That was the beggining of the confusion. The tile origin is not the texture origin. That was the problem that was tried to fix with this commit (textures outside the tile, textures beggining in the bottom of the tile, etc...). And was the problem reported by the issues referenced in the commit. Tile origin is the point to calculate and Z order, and "rotation" if rotation is needed in something like a tilemap... but not the texture origin point. If actual behavior is not tolerable because breaking compatibility, untouched past behaviour is not tolerable because this:

So... if top-left, top-left, but if displacing texture in origin center and bottom-left, you will end with a map that doesn´t follow an understandable logic like the map in the image.

[Ranoller]

Anyway, if breaking compatibility will be the thing, revert should be the option because any change will break something, always exist the chance that any user is using a texture with bottom left and do calculations with map_to_world // world_to_map or something like that... their game will need adjustments. And if someone is using the strange placement of the shapes in not uniform tiles... well, is not possible to fix this placement without break their game. So there will be a "valoration" that what kind of change is tolerable and what not, to take the decission of what to do. And for that I recomended to talk with someone using godot 3.1 in a production ready game with tilemaps to see the real impact of the changes and valorate, this will illustrate better the issues.

[aaschmitz]

Breaking compatibility is not the main problem (I'm developing a 2D game with several maps since Godot 1.1, migrating through all Godot versions and with all breaking changes needed) but how do I align a square Tile with a non square in the grid?

Try using the Godot 2D Platformer Demo, create a new Scene with a Tilemap (using the Tilemap from the demo), put the tile "floor" and the tile "ramp": the Tile "ramp" does not align up on grid.

This is not a question of breaking change but the removal of a feature (being able to use non-square Tiles).

Maybe the best would be to have an option to choose which logic to use in the Texture Origin, ie allow the "old" and "incorrect" form (Texture Origin Top Left) or the "new" form (Texture Origin Center)?

[Ranoller]

top-left texture can be done only by commenting code, so i will do until a definitive solution is discussed.

[isaacremnant]

Maybe the fix helps with iso or weirdly shaped tiles, but it's a pain for top-downs and platformers. The most likely use case is a "main" tilemap (16x16 say) with a few rectangular shapes that are multiples of the base size (32x16, 16x32, etc) and those won't line up properly.

To restore the old alignment, I (would) have to go through all non-rectangular tiles and change their texture, shape, occluder and navigation offsets by the same amount, say (-8,0) for 32x16 tiles. For the non-recangular slope tiles:

Bottom-left = Default behavior, Middle = All offsets changed, Top-right = Only the texture offset changed

If there were only ONE offset to change, then this wouldn't be too bad and a part of tileset creation. Ideally though, there would be a Tilemap option to use the (standard?) "incorrect" behavior and @aaschmitz's comment about Top-Left is probably the best place to implement that.

[Ranoller]

The multiple offsets is a pain... i don't know what was the motivation around that. I,m convinced yet about the default top-left, only need the moment to do, try today or tomorrow. And in the future maybe an option to "center texture" can be added, maybe a checkbox or something like that

[Zireael07]

A checkbox would be a good solution indeed.

[PetePete1984]

Without multiple tile-specific offsets, my SuperTilemap project wouldn't work anymore (Isometric tilemaps with OpenTTD style slopes), because some of those tiles need to sit in specific positions in their 60x48 rectangles to line up with the rest of the current height layer. Moving them in the texture would break the grid, which would mean all regions need to be set manually for every terrain type etc etc

Also, semi-related note, the Hoppy Days platformer tutorial course project by gamedev.tv used irregular shapes in a tileset for easy level building (square grid, rectangular / crooked / whatever tiles), so that would be affected too.

[Ranoller]

Without multiple tile-specific offsets, my SuperTilemap project wouldn't work anymore (Isometric tilemaps with OpenTTD style slopes), because some of those tiles need to sit in specific positions in their 60x48 rectangles to line up with the rest of the current height layer. Moving them in the texture would break the grid, which would mean all regions need to be set manually for every terrain type etc etc

Also, semi-related note, the Hoppy Days platformer tutorial course project by gamedev.tv used irregular shapes in a tileset for easy level building (square grid, rectangular / crooked / whatever tiles), so that would be affected too.

Multiple offset means an offset for shape, an offset for occluder, an offset for navigation, an offset for texture... and all of this per tile. One offset per tile is ok, 4 offset per tile is excesive. In other issue a godot developer was talking about the future of this and probably will be removed. If you need that you should give your opinion in the dessign process of tilemap for 4.0.

[PetePete1984]

I tend to keep all this "extra" stuff on different tilemaps anyway because most projects need like one or two collision shapes, not 40. Much easier to handle that way.

Anyways navigation/occluders are polygons anyway, why do these need an extra offset? They don't follow the sprite automatically, you have to set these up by hand as far as I know?

[Ranoller]

You can offset that individually....

well no... You need offset that individually. So if you offset texture you need offset navigation, occluder and collision. That was a dessign decission that makes every texture offset in a tile x4, but has no meaning, if you need offset a polygon is because is bad drawn, so.... ?¿? dessigned for offset in gameplay? i don't think so