Re: Pixmaps, and client/server startup

["Carl Edman" <>]

From: Mark Wedel <>:
> XPM's are in general very inefficient storage medium.

I take your word for it.  But then they likely will only be the storage  
format on the server.  Most clients are going to use their own internal  
format to store the pixmaps in a form which they can use quickly and  
which doesn't contain more information than they actually need.   
Conversion is done when the images/sounds are sent.

> An entire character (8 bits) is used for each pixel.  If a pixmap is
> only using 2 colors, this means 7 bits is wasted.

Remember that on really slow connections (which is the only ones on  
which this really matters considering that all pixmaps are tranferred  
_once_ at most and then only when needed) already incorporate some form  
of huffman compression.  That means that a long text consisting only  
out of 1s and 0s doesn't use up much more than 1 bit per character.

> There is some header information that also takes up some space, but
> the main space consumer of XPM files is the pixmap data.

I agree -- a little bit of header information is not worth worrying  
about.

> The nice thing about XPM files, is being that they are text, they are
> very easy to handle.  I doubt it would be that difficult to write a
> simple program that converts it to the native format, without using
> the XPM library.  And in fact, some of the standard XPM header
> information could be discarded (for example, we know that all
> pixmaps, at present time, are 24x24).

If that is so (and again I take your word for it), then I think XPMs  
would be just fine as the specified transport format for the crossfire  
protocol.

> Right now, large montage's of the pixmaps are created to speed up
> load time.  There is no reason that the pixmaps could not be kept
> apart on the server side, so that sending just one or two new pixmaps
> would be easy.  The client end would be responsible for either
> updating its files however it things is appropriate for quick
> loading.

Couldn't agree more.

> It should be possible for the client to keep pixmaps between
> different connections, and also be able to get new pixmaps.  IF the
> client decides to discard the new changes and request new ones each
> time, that is fine, but it is just the clients loss (in terms of
> connect or startup time.)

Just my argument !

> One thing that needs to be kept in mind in general is that the server
> still have to keep track of all actions that client does, to some
> extent. So even if all pickup was handled in the client, the server
> would still need to be notified about anything that is picked up.

Again, I agree completely.  Whenever something actually occurs in the  
"physical" world the server needs to know about it (as a matter of fact  
it needs to actually _do_ it).  But I think it could be feasible to  
have the functionality of the 'pickup' command be part of the client.  
The client knows where the player is and where all the items the player  
sees are and what they are, so why shouldn't it just send 'MOVE <item>  
IN <me>' commands whenever it enters a new square ?  


> I think it might work best if the client just has a bare minimum of
> information.  This saves transferring information that is not needed.
> For objects, probably just the name, pixmaps, number of objects, and
> the animation information should be kept track of.  Things like
> value, magical information, hp, sp, etc, should not be needed by the
> client.

Again, I couldn't agree more.  That is all the ITEM command has (though  
I forgot a field for quantity which is something the client _does_ need  
to know).  To find out more specific information the client uses some  
'EXAMINE <item>' command and the results are sent back by the server in  
form of TEXT descriptions.  HP, SP and food of the player though I  
think is something which the client should know at all times.

> As I said before, the biggest problem is reducing the server->client
> information.  A method needs to be found so that map information does
> not need to be sent very often, but is also only sent as needed. It
> probably is not a good idea to send the entire map - on slow
> connections this could be quite time consuming.  But instead, send
> information about the map in the players immediate area.

Again, I agree.  I do think though that the actual amount of bandwidth  
which is consumed by the protocol I posted two days ago is small enough  
to fit the requirement I made up (1-2 kBytes/sec bandwidth minimum,  
100-200ms round trip time maximum).  Right now I more worried about  
latency and what can be done about it, though I think that is a soluble  
problem as well.

> When the player moves, in general, only a new row and/or column would
> need to be sent, and not the entire 11x11 map area.  And certain
> objects would be pretty static (floors, walls, etc), so only updates
> of information like monsters moving and fireballs would need to be
> sent.

I agree (this is getting repetitive, isn't it ?).  The protocol only  
sends 'MAP' commands for newly visible squares (and 'UNMAP's for newly  
invisible squares) and ITEM commands only when items first come into  
view and when they actually move from one location to another (like a  
moving monster or an item which is picked up/dropped).

	Carl Edman