Small suggestions

[heinezen]

Age-of-Empires-II-Grid-Generator/grid_generator.py

Line 21 in 38a2c32

coordinates = [int(spacing * i) for i in range(11)]

I suggest casting to int in line 18. Currently, spacing is 51.2 which creastes a tiny offset of 1 pixel when i > 5.

The HD edition tiles have a size of 53x53 pixels. They overlap by 2 tiles, which creates the 512x512 resolution for the whole terrain file (512 = (10 * 53) - (9 * 2)). The reason for this is the isometric algorithm they use which requires these overlaps. Ideally, the grid is located where the tiles overlap, so it's ideal if spacing == 51.

Age-of-Empires-II-Grid-Generator/grid_generator.py

Line 102 in 38a2c32

if original.size != (512, 512):

This is a problem for older version than HD. Legacy AoC has a terrain of size 481x481 (or 490x490 for some modding tools). Upscaling can cause issues with older modding tools. I suggest you either just leave the resulting image at the original size or add a new argument --upscale.

Age-of-Empires-II-Grid-Generator/grid_generator.py

Line 112 in 38a2c32

result.rotate(45, resample=Image.LANCZOS, expand=True).show()

For an ingame isometric view, you can use the transform algorithm of the openage repo.

SFTtech/openage-modding#8

It's the inverse_transform() that you want to do. We call it "dimetric transform", but that's just the scientific term for the isometric transformation used in games. The transformation might also help you if you want to create terrain files for legacy versions of AoC (e.g. the one used for Voobly).

[e00E]

Thank you for the details.
What is the tile size (or spacing) for the non HD versions? Your explanation for for the HD version makes sense but wouldn't a spacing of 51 be wrong for the other versions? And how can AoC have both 481 and 490 as valid terrain sizes?

[e00E]

Thinking about this more I am not sure I understand the overlap fully either.
Our 512 input image has to be turned into 10 tiles of 53. So where exactly do the extra pixels come from?
In python notation are the tiles created like this?

start = 0
for i in range(10):
    tiles[i] = input[start:start+53]
    start += 51 # not 53, because the next tile will include the last 2 pixels of this tile

I think this is what you were describing but I want to be sure in order to draw the grid in the most accurate way.

[heinezen]

Maybe it helps if I explain what purpose the overlay has. It has something to do with the transformation. Here is a texture split up in tiles (not HD, but old AoC version):

Trying to puzzle the tiles together without overlaying doesn't work here because you will end up with some holes in the texture. To fit them together the borders have to overlay a bit. At these overlay points the tiles share the same pixels (= same RGB color).

One individual tile has size 53x53, but when we want to place two tiles next to each other in dimetric transformation, they have to share some pixels where they overlap. That's why two tiles merged together have slightly less pixels than two individual tiles. Of course, that adds up when we look at 10x10 tiles: Merging them with a 2 pixel overlap to a giant terrain tile results in the 512x512 resolution.

Getting the 53x53 tiles is easy: The first tile uses the pixels [0,52], the second tile uses [51,103], the third [102,154], ..., and the last one [459,511].

[heinezen]

Your explanation for for the HD version makes sense but wouldn't a spacing of 51 be wrong for the other versions? And how can AoC have both 481 and 490 as valid terrain sizes?

Original AoC had 49x49 tile size and an overlap of 1. 481x481 is the valid terrain size if AoC would use flat terrain textures like HD edition, but it saves them as individual transformed tiles in an SLP.

490x490 is used by a popular mod Turtle Pack. I think this is an error on their behalf because they didn't account for the overlay, but it's not open source so i can't confirm that. This resolution can cause textures to be messed up a bit.

[e00E]

I have changed the spacing to 51 and added a warning message when files get resized.
Since I do not support the old versions (yet) anyway by not being able to handle drs and slp files there does not seem to be much of a point in handling their textures correctly.

Your explanations have been very helpful so far but I am still wondering about a few things:

If we need overlap to prevent holes when placing tiles next to each other then shouldn't the same be true for the very first and last tiles in the texture since they are neighbours as well? Yet if this was true then the texture files should be just 510x510.

Finally, when I zoom in to pixel level in your tile image and move the top left and its right neighbour next to each other in the way they would look in the game I can see the 1 pixel overlap BUT some of the pixels are actually of different colors.

What is happening there?

[heinezen]

If we need overlap to prevent holes when placing tiles next to each other then shouldn't the same be true for the very first and last tiles in the texture since they are neighbours as well? Yet if this was true then the texture files should be just 510x510.

True. I guess they don't do this because then the last tile would not be a single block that you can cut out. You would have to stitch it together which might be more complicated.

Btw, the very first and last tile of some textures don't blend into each other well. The above texture is an example of this. If you play around with this texture in the editor, you can notice a barely noticeable seam between each chunk of 10x10 tiles.

Finally, when I zoom in to pixel level in your tile image and move the top left and its right neighbour next to each other in the way they would look in the game I can see the 1 pixel overlap BUT some of the pixels are actually of different colors. What is happening there?

That's weird. I never noticed this before. And I've looked at a lot of edges. It could be an issue with the openage converter, since these are not the original AoC files, but an extraction from the SLP files. Or it could be some mechanic I have not discovered yet.