1. Create a general compositing system(paste and offset any number of images) for each tile.
2. Subdivide tiles with corners into 16 subtiles, one per corner.
3. Run some brute force logic(also based on bitmasking) to create the composite information for each tile.
4. Cache the result with a key of some kind, so that we don't have to do the full composite for every tile every time it's changed. (Extra credit: Maintain a fixed-size cache and flush less-used tiles to keep memory usage down.)
The result: you can do any kind of corner or intersection with a minimum of unique art assets, which has benefits in making it easier to see the tiling in action. For corners there are only two basic kinds of algorithms - inside corners(border ends at the edge of the tile) and outside corners(border slops over the edge).
If you need other types of algorithms(e.g. applying alpha-transparent borders, or making double-sized images auto-tile) you can plug them into the compositor too. You can even combine these algorithms by adding more data to the tile - e.g. a "tall" (walls/solid objects) and a "blend" or "background" layer(underlying terrain).
If you want to break some new ground, try this: Make the 3D version, and create a Minecraft with beautiful "auto-smoothing" behavior.
Even though HN has seen enough of my site in the last couple days, I also have a little tilemap demo using the two approaches shown here (4-bit and 8-bit). I initially wrote the 8-bit version (I had to make a lookup table mapping the 256 possible neighbor combinations to the 48 unique tile types for each type of terrain) and it looks like this: http://a1k0n.net/jsrpg/
But eventually rejected it for being "too blocky" in favor of the 4-bit version which has a smoother demo: http://a1k0n.net/code/jscroll/b/
No, the marching cubes algorithm has a very specific meaning, because it's patented. It builds a 3D surface from a 3D grid (each grid cell is either 'filled' or 'empty').
1. Create a general compositing system(paste and offset any number of images) for each tile.
2. Subdivide tiles with corners into 16 subtiles, one per corner.
3. Run some brute force logic(also based on bitmasking) to create the composite information for each tile.
4. Cache the result with a key of some kind, so that we don't have to do the full composite for every tile every time it's changed. (Extra credit: Maintain a fixed-size cache and flush less-used tiles to keep memory usage down.)
The result: you can do any kind of corner or intersection with a minimum of unique art assets, which has benefits in making it easier to see the tiling in action. For corners there are only two basic kinds of algorithms - inside corners(border ends at the edge of the tile) and outside corners(border slops over the edge).
If you need other types of algorithms(e.g. applying alpha-transparent borders, or making double-sized images auto-tile) you can plug them into the compositor too. You can even combine these algorithms by adding more data to the tile - e.g. a "tall" (walls/solid objects) and a "blend" or "background" layer(underlying terrain).
If you want to break some new ground, try this: Make the 3D version, and create a Minecraft with beautiful "auto-smoothing" behavior.