Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: images & caching.

On Thu, 5 Mar 1998, Mark Wedel wrote:

>On Mar 5,  5:08pm, Scott MacFiggen wrote:

>> Conversion is easy I think. I converted some XPM images to
>> PNG and it was quick and easy with ImageMagick. Although I
>> didn't look real close at the new image. I'm not sure what
>> it did with the palete, stuff like that. And I'm also not sure
>> how it dealt with transparency..

> Note that any conversion method must work without user intervention and be
>runable from a script (I am not saying that png does not meet that.)
> Converting 2000+ images require a minimal amount of conversion effort.

No prob -- conversion can be automatic or interactive.  Some of the tools
are scripted, so that we could use some of the special effects possible
with PNG (such as translucency -- I think that would be GREAT).

> As a note - how do space usage compare on xpm vs png images?

Words cannot express the difference.  It's that bad.  XPM doesn't even
pretend to try to be small.

>> To get translucense to work, you would need to work with all the images
>> in PNG format, ie, when combining multiple images, they all have to
>> be PNG, then once you have your finished composite image, you
>> convert it to the OS native format. I know this isn't how the
>> X client does things, I believe it just does an XcopyArea and
>> uses the SHAPE x-extension to take care of the transparent
>> pixels.. But I think translucency would work fine on any OS, although
>> I'm not going to say for sure until I try it...

This is probably an effective way to handle it.

> Ok.  So all image actions handle in PNG until you get your composite image and
>decide to draw it.  I am curious on the performance on that - I would think
>that for most systems, handling in native format will be faster than a generic
>PNG format - although it may not be that significant.  However, redraw logic
>and knowing what to redraw could make things more complicated.

XPM isn't _really_ a native format to anything; it's just standard.  So
any such comparisons...

(BOY, I was up too late last night.  I think it shows.  Sorry.  :)

Anyhow, my point is that the sheer size of XPMs relative to any logical
standard makes them slower to convert to and from visible format, if only
by loading time.  PNGs also have a disadvantage is they're used in
compressed format, but that's why PNG is never _used_ that way (only
transmitted).

>> I'd rather see a format image with more 'feature sets' picked, if
>> we decide to change image formats, so that the client writers
>> have more flexibilty to do things graphics wise if they
>> so chooose.

> On the other hand, feature set should not be the only criteria when deciding
>on something (whether it is image format or package to use for npc logic.)
> Identifying the features that are needed, and then finding what best matches
>that is probalby the best approach to use.

Good point.

> If we go by that - current features of XPM:
> transparency
> alternate color information for greyscale & bw systems

> I believe most other formats loose the second point.  Ideally, if we go to
>another image format, it would be nice to only have 1 set of images needed (ie,
>get read of the bitmaps that are their now) - simplifies stuff all around, and
>means less space used.  Unfortuantely, for black and white support, alternate
>color information is really needed (or do we maybe jsut want to make color a
>requirement?)

IIRC, most other formats can supply two images at the same time -- it's
just that it's an enormous waste of space.  I'd far rather supply the
images seperately.

> Is multiple transparency levels/translucent pixels a big gain/advantage?  The
>argument about nicer lighting code probably doesn't really fall into that
>(better method would be for server to communicate light sources and their
>diameter, and have client deal with shading however it might want - saves some
>server cpu cycles, might save overall bandwidth (don't transfer darkness shadow
>masks), certainly can get better effects (good clients could do smooth light
>calculations, shading, whatever.)

It's a HUGE gain, IMO.  It's as big a gain over transperancy as
transparency is over the lack thereof.

> A simple method, though not perfect, would be to have shadow masks of varying
>diameter (ie, square radius mask - center has all pixels enable, and as you
>move out, fewere are enabled.)  Client then premerges these for the overall
>11x11 viewing area (and thus, overlaps will probably be lit bettter as all the
>pixels won't match out), and then apply over the map.  That way, at least
>smooth radius shading would happen without having to adjust all the various RGB
>values on the fly.

This isn't bad.  If you use translucency this is done automatically by
either dithering (as you propose) or changing the color; whichever works.

Oh, careful use of the alpha channel can allow shading, although I admit
that's a lot more than I'd care to draw.

>> I think I'll experiment a little bit with PNG in windows
>> a see how it goes...

> I would be curious on how good/the number of tools under unix for PNG.  After
>all, that is where crossfire is still developed for the most part, so good
>support under unix is fairly important.

If I were a Windows-only user I would never have heard of PNG.  PNG is
currently strongest (best supported) on Linux, since PNG is designed as a
free alternative to a proprietary system (GIF).

>-- Mark Wedel

-Billy

[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups: References: