Allow TileMaps to sort by X coordinate for isometric games

[Poobslag]

Describe the project you are working on

I'm working on a 2D game where a player can wander around an isometric world with a similar perspective to Streets Of Rage or River City Ransom.

Describe the problem or limitation you are having in your project

A tilemap in an isometric 2D game may have many objects with the same Y coordinate, but they cannot be drawn in an arbitrary order. For the isometric perspective in this picture objects must be drawn from left to right to occlude each other naturally, like the top row of objects. If drawn from right to left they look strange, like the bottom row of objects.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Instead of only offering two options, "Y Sort On" and "Y Sort Off", TileMaps could offer more detailed sorting options, giving developers the ability to customize TileMaps to draw things from left to right or right to left.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Currently, TileMaps support provide a Y Sort field. This could be replaced with a Drawing Order field with five options: "Top Left", "Top Right", "Bottom Left", "Bottom Right" and "Off". The "Top Left" sort order would draw objects from top to bottom, and left to right. The "Top Right" sort order would draw objects from top to bottom, and right to left. I can't think of a use case for "Bottom Left" and "Bottom Right" but it makes sense to include them for completeness.

If this enhancement will not be used often, can it be worked around with a few lines of script?

When working with tiles at the same Y coordinate, TileMaps currently break ties by rendering the oldest tiles first. With this limitation, the only way I can think of to work around this limitation is to erase all objects in the TileMap and reinsert them from left to right, something like this.

func xsort() -> void:
    var new_used_cells = get_used_cells().duplicate()
    new_used_cells.sort_custom(self, "_compare_by_x")

    var prev_used_cell_x: int
    if new_used_cells:
        prev_used_cell_x = new_used_cells[0].x
    for used_cell in new_used_cells:
        var tile: int = get_cell(used_cell.x, used_cell.y)
        var flip_x: bool = is_cell_x_flipped(used_cell.x, used_cell.y)
        var flip_y: bool = is_cell_y_flipped(used_cell.x, used_cell.y)
        var transpose: bool = is_cell_transposed(used_cell.x, used_cell.y)
        var autotile_coord: Vector2 = get_cell_autotile_coord(used_cell.x, used_cell.y)

        set_cell(used_cell.x, used_cell.y, -1)
        if used_cell.x != prev_used_cell_x:
            prev_used_cell_x = used_cell.x
            yield(get_tree(), "idle_frame")
        set_cell(used_cell.x, used_cell.y, tile, flip_x, flip_y, transpose, autotile_coord)

This code must be executed every time the scene is initialized and every time the TileMap changes. It takes a little while to run and results in a strange visible effect during its duration. It is possible there is a more efficient workaround that I have not thought of.

Is there a reason why this should be core and not an add-on in the asset library?

This is a logical extension of the Godot's current Tilemap functionality, and this is a common feature to TileMaps in other game libraries. As it would replace the current Y Sort functionality it does not seem like feature bloat, but more like replacing a specialized feature with a more generic one.

[Calinou]

cc @groud

[groud]

The idea makes sense, but Y-sorting is built into the renderer. Sadly, it's kind of out of the scope of TileMap themselves so I cannot do it myself.

But regarding the proposal itself, I don't think the "Top Left", etc... options are quite difficult to understand. They would make user think that they are sorted according to a diagonal vector, which would not be the case. Instead, Y-sorting should maybe be made an enum with 3 options, something like:

• Y-sort (then X-Sort)
• Y-sort (then inverse X-Sort)
• Disabled

Or we could simply make the X-sorting options another field, I am not sure.

[Poobslag]

I apologize -- while I promise I searched for similar issues before submitting this one, I just found #664 which is arguably a duplicate. (Or while it describes a different problem, its proposed solution would address my problem as well.)

Regarding the naming, this is a common issue to other libraries and they tend to use concise names. Unity uses names like 'Top Left', 'Top Right', 'Bottom Left' and 'Bottom Right' specifying which tile is drawn first (though I concede it's ambiguous whether the X or Y coordinate is applied first.) GitHub's MapEditor project uses names like 'Left - Up', 'Left - Down', 'Right - Up' and 'Right - Down'. Of course we don't have to copy their names, but I think a typical developer would understand these concise names more intuitively than something more verbose.

[Poobslag]

I came up with an alternate workaround: by changing the second value in the TileMap's cell_custom_transform to a very small number like 0.01, tiles are rendered from left to right. This is because the tiles on the left have an indiscernibly smaller y value. This could be changed to -0.01 to render from right to left.

This does mean that your tiles won't be perfectly horizontally aligned, and will drift by a pixel every 100 tiles. But, this small amount of drift may be preferable to the blinking of the xsort() function I provided.