Tiling sprites is a wonderful example of something that starts off relatively simple and then explodes into all kinds of interesting headaches.
In the beginning, you're looking up a set of UVs in a table indexed by some mask value.
In the end, you're debugging errors where one off by one error cascades into strange realms of indexing the wrong (unloaded) chunk with coordinates rolling over to positions that make no sense, looking up neighbours that look one way yet you end up drawing something completely different.
The suggest solution is an elegant and relatively common approach to what would otherwise be a naive series of nested 40+ if statements consisting of much swearing and sprite editing.
Don't be afraid of if-then chains. Smile and put the word REFACTOR in a comment nearby and move on to the next problem. Ship the thing! Perfectionism is overrated.
If you only had two tilesets, sure. This scales with square of n, so in a real game you're looking at a 4000-8000 long if-else chain.
You're going to spend 100x more time maintaining that disaster than you'd have learning a (to this problem) fundamental algorithm. Shoulders of giants.
There's a lot of explanation here but ultimately this is basically just the standard 16-tile set except assuming you can use rotations to deduplicate and don't need to allocate a tile for empty space. The latter makes sense for platformers (since your tiles likely represent objects that are supposed to be floating over some other background drawn another way) but not so much for, say, RPGs. (And the rotated tiles are often not great in RPGs, either.)
Tiled has some mode where you can paint the tile corners or/and edges to automatically insert tiles. When using only the corners to paint (and only a single terrain type) that would be equivalent to shifting the visual grid by a half tile trick, if I understand correctly?
Adding multiple types of terrain and also making it possible to paint the edges of course will add an explosion of possible tile types that are required. Looks like there is support in Tiled for optional automatic mirroring or rotations to add missing tile variations.
It's kind of a pain in the ass to implement IMHO because you need to strip these bits and iterate all of your tilesets to find the correct tileset and tile for the GID for every ID (which is what the tile layers actually store) but a lot of the inherent performance issues can be improved upon by caching the last result, since consecutive tiles in a tilemap are likely to repeat.
The low tile count simply comes from applying the dual grid approach popularized (if not invented) by Oskar Stålberg to a specific 2d perspective where tiles can be generated through rotations and/or flips.
Oskar does both rotations and flips to his 3D tiles, albeit only in 2 dimensions. He uses basically the same set of 5 tile shapes for any tiles that don't need to take into account verticality (i.e. look at the beach tiles in Bad North)
This only works because this guy's tiles can be rotated without looking weird and he's on modern hardware that can freely rotate sprites with little cost. If your tiles are shaded or have patterns that look different when rotated then it does not work for you. If you are working on a game for the Nintendo entertainment system then it won't work either because you can't just rotate a tile.
Does anyone know the history of auto-tiling in games? I know that Dragon Quest II (1987) had this feature for water tiles on the overworld, before it got backported to the North American version of Dragon Warrior 1.
It would be fun to know what the oldest autotiles game is. DigDug from 1982 had them I think. diggerfrom 1980 might have used them.
There has to be some ancient ascii game that uses them. I'm sure they go back further than 1980.
Edit: now that I look at Digger & digdug I'm not sure either of those used autotiles. But I do think you'll find some games that used them in the very early 80s.
used an autotile system -albiet a very very different sort, that made 3d-looking tiles appear in the correct place. Is that a proper autotiler? I don't know, but the principle is pretty much the same.
Anyway I'll bet there are old games still that are out there with auto-tiles.
I've never been a fan of dual grid, and personally prefer the rpg maker approach of using 5 sample tiles and then chopping up and recombining them to make the 47 tiles needed for what I believe is called "blob tiling".
Tiling sprites is a wonderful example of something that starts off relatively simple and then explodes into all kinds of interesting headaches.
In the beginning, you're looking up a set of UVs in a table indexed by some mask value.
In the end, you're debugging errors where one off by one error cascades into strange realms of indexing the wrong (unloaded) chunk with coordinates rolling over to positions that make no sense, looking up neighbours that look one way yet you end up drawing something completely different.
The suggest solution is an elegant and relatively common approach to what would otherwise be a naive series of nested 40+ if statements consisting of much swearing and sprite editing.
Don't be afraid of if-then chains. Smile and put the word REFACTOR in a comment nearby and move on to the next problem. Ship the thing! Perfectionism is overrated.
If you only had two tilesets, sure. This scales with square of n, so in a real game you're looking at a 4000-8000 long if-else chain.
You're going to spend 100x more time maintaining that disaster than you'd have learning a (to this problem) fundamental algorithm. Shoulders of giants.
There's a lot of explanation here but ultimately this is basically just the standard 16-tile set except assuming you can use rotations to deduplicate and don't need to allocate a tile for empty space. The latter makes sense for platformers (since your tiles likely represent objects that are supposed to be floating over some other background drawn another way) but not so much for, say, RPGs. (And the rotated tiles are often not great in RPGs, either.)
Tiled has some mode where you can paint the tile corners or/and edges to automatically insert tiles. When using only the corners to paint (and only a single terrain type) that would be equivalent to shifting the visual grid by a half tile trick, if I understand correctly?
Adding multiple types of terrain and also making it possible to paint the edges of course will add an explosion of possible tile types that are required. Looks like there is support in Tiled for optional automatic mirroring or rotations to add missing tile variations.
https://doc.mapeditor.org/en/stable/manual/terrain/
> Looks like there is support in Tiled for optional automatic mirroring or rotations to add missing tile variations.
Tiled uses tile "Global IDs" that encode booleans for flip and rotation into the upper bits: https://doc.mapeditor.org/en/latest/reference/global-tile-id...
It's kind of a pain in the ass to implement IMHO because you need to strip these bits and iterate all of your tilesets to find the correct tileset and tile for the GID for every ID (which is what the tile layers actually store) but a lot of the inherent performance issues can be improved upon by caching the last result, since consecutive tiles in a tilemap are likely to repeat.
Also I found this page useful: https://eishiya.com/articles/tiled/
The low tile count simply comes from applying the dual grid approach popularized (if not invented) by Oskar Stålberg to a specific 2d perspective where tiles can be generated through rotations and/or flips.
Oskar does both rotations and flips to his 3D tiles, albeit only in 2 dimensions. He uses basically the same set of 5 tile shapes for any tiles that don't need to take into account verticality (i.e. look at the beach tiles in Bad North)
This only works because this guy's tiles can be rotated without looking weird and he's on modern hardware that can freely rotate sprites with little cost. If your tiles are shaded or have patterns that look different when rotated then it does not work for you. If you are working on a game for the Nintendo entertainment system then it won't work either because you can't just rotate a tile.
The point is not to minimize texture/memory usage. It’s to minimize work for the artist.
https://web.archive.org/web/20260213135614/https://www.kyled...
Seems to be getting the hug of death.
Does anyone know the history of auto-tiling in games? I know that Dragon Quest II (1987) had this feature for water tiles on the overworld, before it got backported to the North American version of Dragon Warrior 1.
It would be fun to know what the oldest autotiles game is. DigDug from 1982 had them I think. diggerfrom 1980 might have used them.
There has to be some ancient ascii game that uses them. I'm sure they go back further than 1980.
Edit: now that I look at Digger & digdug I'm not sure either of those used autotiles. But I do think you'll find some games that used them in the very early 80s.
Ok, I'm pretty sure
3D Monster Maze (1981)
used an autotile system -albiet a very very different sort, that made 3d-looking tiles appear in the correct place. Is that a proper autotiler? I don't know, but the principle is pretty much the same.
Anyway I'll bet there are old games still that are out there with auto-tiles.
I've never been a fan of dual grid, and personally prefer the rpg maker approach of using 5 sample tiles and then chopping up and recombining them to make the 47 tiles needed for what I believe is called "blob tiling".
This is essentially https://en.wikipedia.org/wiki/Marching_squares with right angles, isn't it?
Very cool! Sprite Fusion maker here :)