Those two lines look a bit weird to me. I think the rationale is kind ok but I don't understand why there's a check on whether or not separation.x or separation.y are 0. Wouldn't be seperation += Vector2i(1,1) be enough?

We only need to add 1 to the animation frame movements that are intended. For example, if there is 0 separation for the y component then we aren't selecting any frames to the left and right at all, so adding 1 to it would alter that behavior and not be what we want.

As I was writing the above I realize I hadn't checked the 0 separation case's result in the editor, and I should probably have done that. Sure enough, it fails. I haven't been reasoning about this properly. I am leaving my crossed out comment there to hopefully explain my original train of thought. I should have remembered to test the normal cases as well.

The use of x, y, and combined with column count isn't my normal mental model for animation sequences. However, always adding (1,1) to separation doesn't quite work either. It results in the destination position moving in a diagonal - which does match my original intuitions.

I am working out how to take the src_rect's position, adjusting it to be tile coords and then multiplying it to align with the new atlas size.

Something like this:

	Rect2i src_rect = atlas_source->get_tile_texture_region(tile_id, frame);
	Size2i src_size = src_rect.get_size();				
	Vector2i new_position = Vector2i(
		src_rect.position.x / src_size.width * new_texture_region_size.width,
		src_rect.position.y / src_size.height * new_texture_region_size.height
	);

But that isn't quite working right yet either - though I think I am on the right trail. It leaves worrying about the frame(and separation) to the get_tile_texture_region() call.

If it weren't for the fact that the two merging atlases could use different sized tiles it would be a simple 1 to 1 copy.

I was not on the right trail with my last comment. This time I took heavy inspiration from get_tile_texture_region() and realized a few areas where I was mistaken before.

With that said, unfortunately I just found a new issue in my last round of checks where it fails to properly merge 4 of my larger tilesets. I will have to look deeper into it tomorrow.

I just found a new issue in my last round of checks where it fails to properly merge 4 of my larger tilesets.

This issue has now been fixed. It wasn't properly enlarging the merged atlas vertical size when a tileset had vertical animation sequences. This has now been addressed.

@groud You were right that the the conditional addition to separation was weird. I was nearly completely off with how I understood things to work. Thank you for catching that. I believe I have the right solution now.

The addition of (1,1) could now be thought of as being handled by the size_in_atlas variable in this line