You may have also noticed that each layer is labelled as either in front of or behind the player. We’re ignoring the labels for now but they will eventually be used to decide the drawing layer for each tile.
The larger numbers of layers and tile sets have exposed a couple of bugs with how we currently parse the map files:
- We don’t take the first id of the tile set into account when calculating the textures x and y position.
- We store our layers in a map ordered by their name. This does not guarantee that the order of the layers in the map is the same as in Tiled.
We don’t take the first id of the tileset into account when calculating the textures x and y position.
This gives us:
textureX = 4 % 2 – 1 = -1
textureY = 4 / 2 = 2
A position of (-1, 2) for the texture which is not within the texture. The top left position is (0, 0), there is no -1. And there is only one row so we cannot have a y texture position of 2.
We’ve managed to get this far without running into this bug because we’ve only been using the one tile set and these calculations work with the first tile set as it starts at index 0.
To fix this we need to change how we calculate the texture position.
int textureX = (tileId – firstId) % tileSheet->columns;
int textureY = (tileId – firstId) / tileSheet->columns;
textureX = (4 – 4) % 2 = 0
textureY = (4 – 4) / 2 = 0
Now we get the texture position of (0, 0) which lines up with the first tile in the tile set and is exactly what we want.
Hopefully, that is relatively clear. If not, please let me know in the comments and I’ll update it.
Now that we’re retrieving the correct textures you’ll be able to notice the second problem:
We store our layers in a map ordered by their name. This does not guarantee that the order of the layers in the map is the same as in Tiled.
Again this issue wasn’t apparent until now because our previous map had only two layers and they just happened to be in alphabetical order.