I far prefer the xpms to the png images. I think they look a lot better. I think forcing the use of pngs by default would do more harm at this point than good. Sure, the developers might be a bit more motivated to fix all the ugly ones (of which there are still many): then again, the people who DO use the pngs don't seem to have been fixing very many. But in the meantime, while they're being fixed, the general populace will have these repulsive, ugly pngs, which may put them off the game completely. And these people are the people who will succeed us as the developers one day: *if* we get them hooked. :) I would rather see the pngs wait until someone has fixed them up to an acceptable standard before making them the default (and, in practice, forcing them on everyone.) As to increasing the images size yet further, to 38x38 or whatever. I shudder. I have tried MANY times just to get an artist to draw me a few 2x1 or 2x2 images of demons. There aren't enough middle size/strength demons. I've begged on the list. I've begged some people I met. It's been years. No demons. The 38x38 project, like the png project, will never get done unless one or two people are willing to see the project through to completion. More productive, I think, would be more of a move of image from server to client side. I know this is difficult, but it would allow someone to, say, create his own client which uses ASCII characters for everything, or uses his own custom 128x128 uberimages. We could send the archetype name+ an int to ask for an image? How much additional bandwidth/CPU would this require? Could we send the archetype name once and assign an int for second requests of that image during a single session? This would require a large bitmap (NumImages bits) for each client. PM > > On Wed, Nov 01, 2000 at 02:43:40PM +0100, Andreas Vogl wrote: > > > On Mi, 1.11.00, Jan E. wrote: > > > > I'm using xbms with caching turned off because this seems to be the > > > > fastest setting when playing on a remote server over a slow link. > > > > > > I assume that you play only for code-testing, therefor this argument > > > doesn´t seem fair to me. =) > > > > I don't test code on remote servers. > > > > > On using xbms a player would miss a great part of the fun. I´ve played > > > > Faster response from the server is more important to me than nice > > graphics, but continueing the xbm support is not the right answer to > > this problem. The X11 client does a (superfluous) access() call and a > > file open and read per face command. This means that the first time > > you see a Greater Daemon after the client was started, the client will > > do 42 disk accesses. Meeting a Greater Daemon is not exactly the right > > time for some additional lag. This does not happen when caching of > > images is turned off, and a xbm image is not much larger than a face > > command. Furthermore, you don't ever get these '?' images without > > caching. > > > > These problems could be avoided if the client would request all face > > number -> face name mappings from the server when it is started. It > > could then load the faces from its local cache before playing begins. > > > > This is really what we need: a MAPFACES and GETFACES cmd. > > The server simply do a list of the face of a map you enter the first time, > removes all face the player has got before and send them as a long data > string. > > MAPFACES len <face|name|face|name|face|...> > > This should work very fancy, because you dont get the problem Jan described, > because you must > load a picture in the same moment your socket got hot and the server drop > out hundreds of > fighting datas. > > Also, you do with one cmd was you do with many. One bigger hit, but you save > a many small bastards. > > MichToen > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel