[CF-Devel] Re: My opinion on tossing xbm/xpm in favor of png:

dnh at hawthorn.csse.monash.edu.au dnh at hawthorn.csse.monash.edu.au
Thu Nov 2 03:08:22 CST 2000


On Wed, 1 Nov 2000, Peter Mardahl wrote:

>
     
     
     >
     
      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.
     
     
Agreed, pngs are a better format, but what is the point in switching to a
better format.. if the pictures are worse.
 
>
     
      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.
     
     
Again agreed, tis one thing to argue the toss, tis another to go out and
do it. I make a habit of not putting major suggestions unless I, at least
in part, are willing to contribute to that. Now it is fine to ask about
it, but unless you can do it.. what is the point?

>
     
      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.  :)
     
     
Yup, I dislike the pngs images greatly.. I much prefer the tile based
representation of monsters/chars. If anyone like the pngs.. sure.. but
don't force it on me please. 

>
     
      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.)
     
     
Yup, well i thought about having graphics sets, but that is work.. and I
don't want to waste my time on something which is just gonna be ignored...
nor I think would anyone else. I don't know if you realise how long it
takes to create one character, or one monster, but each one takes me at
least 1 day.. and even then they aren't to my liking usually. A really
nice character (like paladin) takes me around 2 days of fixing.. leaving
it, coming back to it and changing something. That process will be made
even longer with these new changes.

>
     
      As to increasing the images size yet further, to 38x38 or whatever.
     
     >
     
      I shudder.
     
     
Ditto.

>
     
      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.
     
     
Well I am currently making to new dragons, but drawing pngs and xpms is
taking a long long time. Tis a pain ;). none the less, I prefer making
graphics in xpm just to get the basic shape because there isn't much fuss
with an xpm =)

>
     
      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.
     
     
Yup, then we could create various clients for speciality groups (low
bandwidth, low colour, super colour, mega ultra ginormeous bandiwdth ;)

>
     
      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.
     
     
no comment.

dnh (Darth_bob)

ps. I am not against change, but I don't wanna see people rush into an
idea then get bored halfway. Tis a worst case, but it is a possiblity.

pps. My brother has a really neat way of handleing tiles for GTK. Will
probably start mucking around soon hopefully get a much faster frame rate
plus flexibility through it =)

>
     
      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
      
      
     >
     
     
     
    


More information about the crossfire mailing list