Le Vendredi 4 Juillet 2003 23:30, Mark Wedel a écrit : > Todd wrote: > > Is this the transitional graphic set we are going for? This is more > > akin to the shaggy tile. This appears to be the inverse of single tile > > smoothing (if your reading this and don't know what I'm talking about > > you can research in the archives...) than the full transitions proposed > > by Mark and Tim based on the legendary document. I thought we had > > decided to go with the larger number of transitions for greater visual > > appeal. I ask because I am working on some smoothing graphics and don't > > want to redo them. > > The reason I ask is because these seem to have the same issues as the > > 'shaggy tile' scenerio. > > I agree. A URL tchize sent me on some examples is > http://users.skynet.be/am248983/smooth/index.html. > > To me, the only one that would need improvement is the corners (L shaped > pieces). Look at: > http://www.gamedev.net/reference/articles/article934.asp > > What is missing is the U (tile around 3 sides) and L (tiles along to > adjacent edges). Its unclear to me right now how those are handled with > the current tiles - my only guess is that they are layered on top, but that > certainly isn't as good as a properly drawn L or U (ore so because in the L > and U, you probably want to curve in the corner more than for just a simple > side). For now, a L shaped border is handled like this divide you destination picture in 4 the uperleft part is made of the upertleft part the 'left I' case the upperight part is made of the uperright part of the 'nothing' case the bottomleft part is made of the bottomleft part of the 'O' case the bottomright part is made of the bottomright part of the '=' case This all limit needs for drawing to 8 pictures. I did this choice cause, when you look at "Figure 4: Artifact Grassland Transitions" on gamedev, you'll see most pictures share some parts. I didn't think about the possibility, in L shaped case, people might want to convert to a straight line. I wanted to save time from pictures drawers. However, thé 32 pictures case presented seems better. If the crossfire gfxers are ready to do the 32 pictures for each transition, am ready to convert the code to use the Cases shown in document. > > > Also I really want to get the layering sorted out. I understood it that > > water was to be lowest level then we would work up such as : > > water -> sand (and desert), marsh, and cobbles (roads) -> grass and > > swamp -> trees (different types of forest) and hills ->mountain > > > > Where more tiles could be added to the appropriate 'layer' as they come > > on line. > > I think as tchize did it, there is a single byte for what layer something > is on. This is probably overkill, but does make things easy - if you space > things out (water = 0, grass = 10, tree = 20, hills = 30, mountain = 40 for > example), that leaves a lot of space if you get into a case of 'I need to > make a layer between hill and trees'. Put that in at 25, and you're all > set, and still have room in case something needs to be put between your new > object and the hill. > > > This method would allow for the eventual retirement of the river and > > lake arches, which are a royal pain, with appropriate water arches. > > River I think will always be tricky - if you want to run a diagonal > river, I'm not sure you could ever really do it without special archs. I > think putting a line of single space water arch's diagonally would result > in a bunch of small lakes/ponds. And if you something like: > > RR > RR > RR > RR > > I think with the blending you'd get a river that seems to snake a lot, > simply because there isn't a straigh diagonal that would get used for > blending - even if real L shapes are done, that still curves. > > > Also is there any consideration being given to extending this (leaving > > the door open anyway?) to do stuff like health/magic auras over top of > > objects and players or special effects or weather animations? > > It's just a simple matter of extending the protocol/making a new map > command. This isn't really hard. It is very difficult to predict what > information may need to be sent. Adding on/making new map commands isn't a > big deal - the old one still exists in the server, so old clients work. > New clients just ask to use the new command with better features. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel