CF: Re: png for images.

["Michael Toennies" <>]

Hi

Hm, i  am a prof. game programmer and i have a whole win95/directX engine
from an old
realtime project.

I have think about implement an DX client with much better gfx, possible is
a new isometric
like style.With some little tricks it can work.

What needed is a server protocol with "dynamic" tile ids. The idea to send
the gfx data in the
way crossfire do it yet, is not up to date.

The server don't add/change gfx at "runtime" and all maps are included at
server start, so why not
crossfire give the gfx to the client?

At this time, i have 10 gig free space on my new hd, and crossfire stores
the tiles in any case in the
his temp/swap dir.

If you let come the gfx in loaded packages, with global ids, you can load
for your client the gfx design
you want; you drop the server packages size and you seperate server data
from gfx data - which is
a major task for crossfire in the future.

So, why not yet?

Michael

----- Original Message -----
From: Mark Wedel <>
To: crossfire mailing list <>
Sent: Saturday, April 29, 2000 10:08 AM
Subject: CF: png for images.


>
>  This was discussed on the mailing list quite a while ago, but nothing
really
> seemed to come from it.
>
>  The general proposal is to add png to the server and the client.  At some
> point, xpm would be discontinued, and maybe/maybe not bitmaps.
>
>  Reasons this is a good thing:
> 1) png images are smaller than xpm's, so save bandwidth & disk
> 2) png is arguably has more wide spread support than Xpm does
> 3) png has some more advanced features in its library (although, I don't
think
> it will make much sense for the client to use most of these, as for
reasons of
> performance, the client is likely to convert the png to the native format
as
> soon as it gets it and not play around with png after that.)
>
>  Reasons this could be a bad thing:
> 1) change from xpm is likely to break something, but that is true of most
> change.
> 2) Another library (png) that must be installed.  Note sure how bad that
is, as
> the xpm library is hardly standard, so requiring png probably is not any
worse
> than that.
> 3) a pngtoxpixmap function probably needs to be written.  It appears there
are
> some libraries out there that do that, but I don't want to start requiring
too
> many extra libraries - plus most of those libraries look to do other more
> advanced stuff we are not interested in - this also makes it harder to
just pull
> the code from someplace else and put it in the client.
>
>  Tha main reason this is coming up now is that quite a while ago, David
> Sundqvist made a set of images in 32x32 format.  Originally, I was going
to wait
> until crossfire 0.96.0 to deal with that, but I can see right now that is
still
> a ways away.  I would rather get those in now because that way they will
remain
> up to date.  Also, the realization came to me that addition of these
images will
> only change the client and the protocol areas of the server - the later is
not
> likely to be affected in any substantial way in the cf96 changes.
>
>  My further thinking was that instead of just using the new larger xpm
images
> and then having to deal with older clients that want 24x24 images and what
not,
> addition of a new image format (and size) makes life easier, and now would
be
> one of the better times to do it.
> -
> [you can put yourself on the announcement list only or unsubscribe
altogether
> by sending an email stating your wishes to ]
>

-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]