Re: Pixmaps, and client/server startup

[Mark Wedel <>]

 XPM's are in general very inefficient storage medium.

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

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

 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).

 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.

 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.)

 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.

 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.

 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.

 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.

 --Mark