Re: CF: Re: png for images.

[Mark Wedel <mwedel@scruznet.com>]

Michael Toennies wrote:
> 
> 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?

 various portions of the orignal were cut.

 I'm not 100% sure I understand the question, but I think I do.

 What you seem to be wanting is for images to be done in a similar way as the
sounds are - when the server tells the client to play a sound, it doesn't tell
the client the filename of the wav file - rather, there is an agreed upon
numbering system where sound 5 has some meaning, sound 18 has different meaning,
and the client determines how to deal with that.

 This works OK for the sounds, but doesn't work quite as well for images.  As
for now, pretty much all the sounds are hard coded into the server, so the
addition of new sounds is unlikely.  Even if new sounds are added, at current
time, sound support is not required to successfully play the game.

 It is much more likely that new images will be added.  While right now I can be
pretty certain and say that you can go to any currently running crossfire server
and have the same number of sounds in use, I can not say that with regards to
maps.  Often, some servers add new maps and corresponding objects & images to go
with those.  And in all likelihood, this will continue in the future - private
servers will be the right place to check out new maps & archetypes - checking
them into the CVS tree and then debugging them is not the way to go.

 However, that said, it is up to the client to determine how to actually display
the images.  Currently, the server & client does implement an image caching
mechanism - in that, when an image number is referanced for the first time, the
server sends the client the name of that image instead of the image itself.  the
client then sees if it has a copy, and if not, requests it from the server.

 In the client checking for a copy, there is no requirement (and could not be
enforced in any case) that the image is really the right one.  It is fully
possible for the client to actually have converted the image to a native format
and saved that in its cache directory, and thus is pulling that out.  Or you
could distribute clients with a preset cache directory with images in whatever
form.

 However, the above distribution is not perfect - the comment of different
servers adding images is still valid.  In that case, the client needs to get
this new/unknown image from the server and do the right thing.  I don't think it
is realistic to have an image cache/client for each server out there - and even
if you did, you still have problems (suppose server xyz, of which you have
client_xyz, adds some new maps with new images - do you really want to
re-download a new version of client_xyz each time that happens)

Hypothetically, your are correct - if it comes to a point where all the image
become static and no new ones are added, there is no reason for the server to
have anything - the client could be distributed with the images.  However, I
don't think that will ever happen - in fact, I hope it will never happen, as
that then suggests that crossfire has stagnated.

 But if a client wants its own style, it could do that now.  However, the images
the server has (png, xpm, whatever) should still be seen as a fallback for when
a new image is added and for the client to deal with it.  So the question is
really should that fallback go to something like png, or remain xpm.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]