tchize wrote: > > Le Samedi 10 Novembre 2001 18:32, vous avez écrit : > > > It is a short article, URL is > > > http://www.gamedev.net/reference/articles/article943.asp > > > > Opps, that should be: > > > > http://www.gamedev.net/reference/articles/article934.asp > > Thisdis quite interresting since it doesn't need work on the server side. > Only the client should ask for pictures in the corners. However. This mean we > need to draw the graphics. And to do so we need drawers! Don't forget the xpm > to PNG process is not yet finished and we lack drawers. If you can send > terrain transitions, am ready to do the work oon the client.... (GTK) This can only really work on the client side if the client knows the content of the images. EG, if you have image 543 and 865 together, that provides no information if blending happens. But if you know that 543 is plains and 865 is forest (numbers all hypothetical of course), then you can do blending. Now if the client is caching images, it does have the image names, and it probably makes sense to let the client do the blending. Personally, I would think that any images the client needs should be distributed with the client. There has been a lot of discussion about images on the server and so forth - the simple summary is that the server needs to be able to provide images so that all clients don't need to get updated if some new images are added. But if the client must have the image, and in fact the client is the only thing that will use it, it might as well be distributed with the client. I'm not sure what you say when you mean "Don't forget the xpm to PNG process is not yet finished". I'm guessing your are meaning that some of the png images are really just scaled up xpm images and in fact should be redrawn properly? Scott MacFiggen wrote: > I was actually considering taking this problem on for my next project. There > are some good articles on gamedev.net that go over ways to implement this. > The one I was going to try was adding a fringe layer to the maps. > Although the biggest problem with this is it breaks the new map command since > there are not enough bits left to add another map layer. Anyway the basic > idea is you have terrain precedences and a fringe bitmap for each > terrain border. So to take an example from the article, if you had > a forest and a grassland border, the forest would have precedence > over the grassland and stick out a bit into the grassland tile. As tchize mentions, this can all be handled on the client. I can't actually see any reason that it could not be. And there are certain advantages to handling it on the client - less server complexity (and cpu cycles to figure that out), less bandwidth, and in fact no change needed to the protocol. You also have the advantage that all maps basically get updated instantly with this new feature vs people having to redo them. Now I could very well be overlooking something - there could certainly be reasons why this could not be all client - the only one I could really think of is if you really did not want blending in some cases (eg, you really wanted the sharp corners).