Images, was Re: [CF-Devel] And almost a year later...

[Mark Wedel]

Tom Barnes-Lawrence wrote:

>
     
         Personally, I've only seen the screenshots of the PNG set,
     
     >
     
      so I prolly sound a bit stupid now- but I also found the cobble-
     
     >
     
      stone tiles in the zoo pretty awful. I couldn't tell if they
     
     >
     
      were scaled or new. I didn't like the grates either. They looked
     
     >
     
      kind of ill-defined, like all detail and contrast had been sucked
     
     >
     
      out. Is the PNG set currently only usable on the GTK and DX clients?
     
     >
     
      If the GTK one does need imlib, I wont touch it with a 50ft pole...
     
     >
     
      I may try the DX client on my windoze box tho.
     
     
 I think the problem with the zoo is the fact that the cobblestones are a bit
darker.  This is probably OK for dungeons or used with other tiles (ie, a
cobblestone road through  forest probably wouldn't look all that bad), but for
the zoo, it justs gives an overall gloomy look to the map.

 PNG works with gtk, x11 (classic), and dx clients.  All you need for the unix
(gtk,x11) clients is the png library and any libraries it depends on.  I wrote
my own png -> X11 implementation after finding the one in imlib buggy.

 As for contrast, there was even some problem with that in the XPM set.  The
fact is, if you have a grey image (like most weapons), there just isn't much
contrast if that sits on a grey background.  There really isn't much that can be
done about that.

 And to some extent, that is realistic.  I've dropped stuff onto a surface of
similar color, and simply put it made it more difficult to find.


>
     
         I'm not sure either. I got the impression it was sort of a hybrid,
     
     >
     
      where the map had a palette of all colours it wanted (but I'm still
     
     >
     
      hoping only 256 in total...), but then all the images had their
     
     >
     
      own virtual palette which hooked into that so it all worked...:P
     
     >
     
         Actually, I'm not sure if what I've just said makes any sense,
     
     >
     
      or would be any more useful or possible, or anything much as
     
     >
     
      my brain is running down. I need sleep now. I also don't know
     
     >
     
      if what I'm referring to is what MichT was.
     
     >
     
         NO Actually, Im sure that's right, just badly described. I'll
     
     >
     
      have another look at that tomorrow, whilst I try to document my
     
     >
     
      old idea...
     
     
 its sort of odd.

 If the alternate color information is in the map, that really doesn't work very
well.  What happens when you take an item from that map?  Take on item from one
map and drop it on a map with a different pallete?  Code wise, the pallete (and
hence) colors for an image must be stored with the object itself.  Embedding it
as part of the name makes it work easier.

 Now in terms of actually doing it, this might really be an editor feature - ie,
you may set a default pallete in the map attributes, and the editor knows to
append %5 to all the appropriate names or something.  But I'm not even sure if
that works.  pallete 5 for the orcs may be what you want, but pallete 5 for the
hill giants may not be what you want.  And I also think that trying to maintain
consistency of pallets accross all the images would be very difficult (can you
have sparse palletes in the images?  ie, only have pallets 1 and 5 defined, and
nothing for 2,3,4?)

 The more I think about this, the more I like the idea of using an optional part
of the image filename.  This really means very few changes to the server is
needed, and not a lot of changes to the client.

 The only problem with that approach is that magic map colors may be sort of
bogus (ie, if you've made an orange orc, at least as far as master image is
concerned, that may be tan or whatever)