Added texture offset for entire TileMap2D layer

[bgie]

This PR adds a simple texture offset for entire layers, allowing isometric/hex 2.5D worlds to be created with a layered tilemap.
Implements proposal 6715

I would argue this could even be considered a bugfix, since there is an inconsistency right now:

• Individual tiles in the tileset have a texture origin AND a y-sort offset.
• Layers only have a y-sort offset for the entire layer but no way to offset the textures.

Since the texture origin on individual tiles moves just the texture, and not collision masks/occlusions/navigation/etc, I assumed the texture offset for the entire layer should behave the same. This makes sense for the game I am making, when stacking blocks for a fake 3d voxel look, I want the collision shapes on the ground level and not offset by height.

I tested my code with the attached project.
The top row is non y-sorted and I used a quadrant of size 3 on purpose, this obviously fails but my changes do not make it worse.
The bottom row uses y-sorting.

tilemap_test_project.zip

EDIT: I also consider this change low-risk of breaking existing projects, as I have simply added a Vector2i to the render position of each tile. If this feature is not used, the vector will be (0,0) and nothing will change.

• Bugsquad edit, closes: Add Tilemap Layer offset for Isometric/2.5D/2D depth uses godot-proposals#6715

[bgie]

Putting this issue back in draft, as I have noticed that tile placement in the editor should probably use the offset too.
(the transparent tile hovering under the mouse while placing tiles)

[bgie]

After using this feature for a while, I came to the conclusion that for simplicity and re usability I ought to offset everything in a layer, not just the rendering of the texture. (ie. editor grid, placement of tiles with the mouse, collision shape, navigation, occlusion, ...)

I don't think the PR should be merged as-is.
But completing the feature is a lot more work (me being unfamiliar with the codebase).

Not sure if anyone is really waiting for this or whether it aligns with the core devs roadmap?
I'm willing to continue this but don't want to waste my time on something that doesn't get merged. Judging from the amount of PRs the maintainers are drowning in work and have to prioritize firmly.

For my use case, the simple texture offset per layer is sufficient, I'm using a patched build now.

[groud]

Sorry for the late review. I think the feature might be interesting, it could work but the more we add features to layers, the more complex TileMaps become.

I think that something like godotengine/godot-proposals#7122 would probably be the way to go to avoid this complexity to grow too big.

[bgie]

I agree and think proposal 7122 is the way forward. The latest merge (conflicting with this PR) extracts layers as a private child class and is already moving in the direction of 7122. The abundant use of macros to dispatch a part of the tilemap api to the hidden layer classes to me indicates that the layers deserve to be first-class citizens and not just hidden helper objects.

I guess with 7122 you could get an offset for each layer basically for free, since they could be a node2D subclass?
Though I am not familiar enough with the code (yet) to make a proper assessment. I'll see if I can look into that.

By the way it was not my intent to put pressure on anyone regarding reviews.

As for this PR, I will probably keep using my patched version for a while, so I will keep this up for anyone else to use, until a proper solution is available on the main branch.

[YuriSizov]

Make sure to use the doctool. You seem to have manually edited the documentation XML and put methods in an incorrect order. So your PR doesn't pass the CI.

[bgie]

Make sure to use the doctool. You seem to have manually edited the documentation XML and put methods in an incorrect order. So your PR doesn't pass the CI.

It was git mergetool during the rebase. Thank you!