Michael Toennies wrote: > > The point is, that the move from xpm to png must a action of the whole > dev team. At this time, xpm are the default grafik and png are only > a unfinished extension. But waiting for a finished png set and a change > then will never work. Then we have the xpms also in 2 years. > > Also, to support all these grafik sets and files waste time and power. > There is no real argument to support the xbms. Thats nonsense. > They should be dropped at first. If anything, I would drop xpm before xbm's. As mentioned, xbm's are small, so they don't take much space on the server, and are bandwidth efficient. Also, as of at least a year ago, some people still played on black and white xterms and the like, and xbm's are very friendly on black and white displays. The usefulness of xpm's have decreased with png. I disagree with your assessment of moving to png. In my view, the problem with png has nothing to do with code, it has to do with getting them updated/cleaned up so they look better. And this has 100% to do with somebody deciding to do it, and not the fact that xpm's are still around. If xpm's and xbm's went away tomorrow, I don't think the png are going to get much better looking much quicker - it really takes someone to decide to do that. And by and large, very few to no people working on crossfire are artists, so you get the effect of 'well, that png doesn't look really good, but I can't make it look any better'. I don't see any one out there spending time making xpm's or xbm's look better, so I don't think you can really argue that that is reducing the effort on png's. > > Think more general about the palettes. The server defines a sets of xx > 256 standard palettes which have (only for example) 128 draw colors and > 128 color space colors. > > so, the first 12 palettes are used for buildings. So the first 128 colors of > them should have a set > of brown and grey for stones. the color space for example has a set of red & > green for the first one. > the 2nd palette has orange and blue in it and so on. My impression on this is that it isn't going to be trivial for a non artist to create these palletes so they look good. But just to make sure that I understand this 100% correct. Is the alternate pallete information stored in the image, or is this yet something else the server keeps track of? And how to you deal with the generation of these new palettes when say someone adds a new set of images? It sounds like a neat idea, but unless creation of these alternate palettes (so that buildings look good with alternate palettes and not like scrambled colors because the person isn't sure what they are doing), and the requirement that for example you need a pallete informaiton bit added or all objects, this requires a lot of work which can probably be better put elsewhere. > Well, making the the map bigger, kills the 38 pngs. then you should use > 15x15 in 32x32 or 13x13 > in 34x34. The point is, that around pixel of 35x35 is a critical area. If > you have a smaller tile, > your pixels and with it your details go fast down. Beyond it, you got much > more pixel for much more > details. > > Thats because one pixel in y and x more or not is not strictly linear. 70x70 > pixels are not 2 times more > then 35x35 of course. Its the factor 4. I work some times as professional > game writer and i had thsi dis- > cussion with some artist who telling me just this facts. Yes, I know the amount of pixels in an image is the multiplication of the x & y. But realistically, given the fact that we just recently went to png and had decided to go with 32x32, changing it yet again seems unlikely. As display resolution increases, there will always be a call for bigger images. I can see going to 35x35, and then a year from now someone say 'well, 40x40 would really be a lot better'. But perhaps I'm a bit biased. To me, gameplay and quality of maps and other such things are more interesting than the graphics looking slightly more spiffy. There will always be something out there that looks better than crossfire.