[CF-Devel] arch/object changes.

David Hurst dnh at hawthorn.csse.monash.edu.au
Sun Dec 9 06:40:13 CST 2001


>
     
      For the different graphic sets: I agree with the idea of a new naming 
     
     >
     
      convention (name.111.<setnr>.png), allowing different gfx sets to coexist 
     
     >
     
      without problem. If a picture does not exist in set x, the default one (from 
     
     >
     
      set 0) could be used instead.
     
     
I would rather see an image grabbed by request from a set, if that image doesn't exist.. look in the other sets. Hmm it might cause problems with trying to figure out exactly what images do exists I suppose =\.

>
     
      I also suggest the creation of a user command "changegfx <id>", where id is 
     
     >
     
      the graphic set sent by the server.
     
     
What is this for?

>
     
      Now for the old XPMs: I agree that supporting more than one gfx format was 
     
     >
     
      somewhat useless. Now what you need to understand is that some people still 
     
     >
     
      used it because of the smaller size of their screens (XPMs were smaller 
     
     >
     
      (24x24) than PNGs (32x32)). 
     
     >
     
      Wouldn't it be possible to convert all the existing XPMs into PNGs and make 
     
     >
     
      them an alternate gfx set ? This would remove the needs for XPM support while 
     
     >
     
      allowing crossfire to be still played without problem on smaller screens.
     
     
GROAN. The alternate set originally was for players of xpm who didn't like the style. When PM decided to do it, we agreed that it was best to stick with 32x32 and thus remove the whole redrawing images specifically for a set. This has been a blessing, images can easily be transfered between sets, nps. let me say right now, that trying to implement a 24x24 set would completely destroy the point of the png sets really. The reason we moved to only 32x32 was to avoid having to redraw (or simply edit) images to cover all the sets. As soon as we need a new size, we will need to scale the image which is tragic, and any image which new will have to have this done.. this process is amazingly tiresome. Is it possible to use an sdl scale image command? What level output do you get? and how fast is it? 

Of course the problem of screen size was the ONLY major reason other than that png wasn't completely supported (which is defn is now). 

dnh

    
    


More information about the crossfire mailing list