[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Blended tile systems



> 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