Adding tile id to tile

[Anti-Alias]

I'd like for the Tile struct to include it's own id.
For my personal project, I need to know the tile id in order to derive it's coordinates in the tileset it belongs to.

IE:

let id = tile.id;
tile_x: uint = id % tileset.columns;
tile_y: uint = id / tileset.columns;
// Draw code

[Anti-Alias]

Ultimately, what I need (and what others are likely to need) are the XY coordinates of a tile in it's TileSet so that its UV coordinates can be derived for rendering.

It might be better for the Tile to simply store it's XY coordinate and or UV coordinates.
Of course, all can be derived from the tile id, but it introduces more arithmetic in the rendering code than necessary unless the programmer generates a mesh during load time instead of using a simple Batch.

But what do you all think?

[aleokdev]

No; If you have access to Tile, you should have had access to its ID previously. The ID is the key of the tile in the hashmap, that's why it isn't in the actual Tile object. In other words: The ID of a tile is always stored along with it, not inside of it. See LayerTile for instance.

As for UV coordinates, we should probably add a helper in Tileset.

[aleokdev]

Of course, all can be derived from the tile id,

This is not precise; You can't obtain the Tile's UV just from its ID. That's assuming that the tileset isn't an image collection tileset and it has no padding nor margin.

I do agree that obtaining the UV is a complex issue that shouldn't be left to the user. As such, adding the tile ID is not a solution nor a workaround to the issue.

That being said, I'll prioritize having UVs ready for today if possible; Thanks for using the master branch and reporting on everything that's missing!

[Anti-Alias]

I have no idea how I missed LayerTile's id() function....
Just realized that this PR wasn't strictly necessary.

Thanks for using the master branch and reporting on everything that's missing!

Of course! Always good to have code battle tested.

This is not precise; You can't obtain the Tile's UV just from its ID. That's assuming that the tileset isn't an image collection tileset and it has no padding nor margin.

I should have clarified: While I'm iterating a TileLayer<'map>, I acquire a LayerTile<'map> and it's Tileset reference. With both of these, I can derive the UVs. My code does do the margin/spacing calculation. My code also ignores image collection tilesets as they're not yet supported.

That being said, I'll prioritize having UVs ready for today if possible;

Awesome! I discovered that the UV calculation is quite the involved process and easy to mess up. This would definitely make things easier for a ton of folks, I imagine.
Out of curiosity, will the UV calculation be configurable?
IE:

flip_y: bool

The reason I ask is that I'm using Bevy, which uses OpenGL-style UVs, where (0, 0) is bottom left, (1, 1) is top-right.
Some other engines might use DirectX, Metal or Vulkan UVs, where (0, 0) is top left, and (1, 1) is bottom-right, I believe.

[aleokdev]

Since UVs depend on the API as you said, it's probably much better to just provide a tile_texture_rect function that returns the result in pixels which the user can then convert into their desired coordinates. Let's keep track of this issue in #166