> I think you are talking about something very similar to "texture splatting", > described in excellent detail here:
For sure in the same class of ideas but I think mine is a bit more simple. My idea is for 2d only. I mean tile the tile set you might use for wesnoth. http://www.wesnoth.org/wiki/Screenshots My idea is really just to have let say two tile sets to keep it simple but you could have many. So for example we take one tile, say grass. You first make a normal grass tile that is 10x10 pixels. Just a nice picture of grass. Then for the second tile you might pick a picture that is black and white and looks sort of like clouds. Here is one. Lets make this tile 27x27. http://www.candeekis.com/textcloud/textcloud.html Now you do an alpha blend of the two tiles. As you can see they do not overlap and the pattern is very large before they repeat. If you used three tiles with the next one being another size like 43, then the repeat size would be huge. The tile sets are not that huge, that being the advantage of having and using tile sets anyway. You know that the picture tile must be blitted to x,y on your screen. So then you blit tile x,y to screen x,y with a width of 10 and a height of 10. But what about the blends under it? Those must almost always be more than one tile or if they are big just a piece of one tile. That can be done using modulus math and just assuming that the tile repeats over the whole screen map. Thus you end up with what bits of that tile must also be blitted and blended. If the picture tile is always smaller that the texture tiles than you know that a 3x3 texture tile group will always have the picture tile in it somewhere. Thus you could just make this 3x3 tiled surface ahead of time for each texture tile. Does this make more sense now? > http://www.cbloom.com/3d/techdocs/splatting.txt > > I actually have a python implementation for a tile-based iso game I've been > working on. It uses Pyglet/OpenGL > and creates splat textures and vertex lists based on a text file: > > http://code.google.com/p/caseman/source/browse/trunk/mech/mechazoid/map.py > > Right now the tileset is hardcoded, but I intend to extend it to support > tilesets derived from config files later. As written it doesn't support much > in the way of different elevations, but that's a (deliberate) limitation of > the underlying map definition class (which just defines the topography, it > does no drawing). The view class is more general and supports arbitrary tile > elevations, though since it is for an iso game, the transitions are rather > abrupt rather than smooth, but this could be worked around by making the > tiles small and the difference in elevation low, at the cost of a more > complex terrain mesh. Are you talking 2d or 3d? > It does support arbitrarily large maps by dividing the mesh and textures > into chunks, so it can draw only the visible chunks. It does not support > more advanced features like automagic LOD control, which isn't useful for an > iso game not drawn in perspective. > > I don't have a screenshot of the current code handy, but I could post one if > you like. You mean a screen shot of the pictures the code makes right? Yes, I would love to see that. > -Casey > Thanks, -- Douglas E Knapp http://sf-journey-creations.wikispot.org/Front_Page
