Re: A few thoughts on client/server

[Mark Wedel <>]

 A few notes:

 The server will be sending the pixmap ID/name to the client, and not
what the object necessarily is (thus, an earthwall and stone block
would both have the name name/ID until one is damaged.)

 A few of the wall categories at least of XPM files with very minor
differences for the weak walls. (ie, extra pixel added in), so if you
look closely, you can notice that a weak wall exists.  A client could
obviously make its version of hte pixmap much more obvious - the only
solution is really to make sure that all weak walls appear the same
as normal walls until damaged (perhaps a detect weak wall spell could
be added to make finding them easier, if it is a problem).

 Light: As I said, it really should be done on the client side.  This
offloads a little cpu time from the server, but more important, if light
information is transmitted with image data, then a lot of information would
be sent each time as light information changes.

 Light should not be too hard to do.  However, a lot of clients may not
do anything with it (for XPM images, (or in fact, any image type on
X systems), it would not be easy (quick) to do it on the fly - that is to
say to create a new pixmap with the shading lightened/darkened because of
the light.  And creating alternate pixmaps for every lighitng situtation
at start up would chew up huge amounts of memory.)

 I suppose a smart caching system could be used (keep a couple hundred
pixmaps around, and knew their lighting value).  But also, on 8 bit
display systems, depending on the number of lighting types, a lot of colors
could also be used up (about 30 colors are used right now for all the 
XPM images.  If you assume that dimming them due to light very rarely
matches up with an already used color, then depending on the number of
dimming categories, you could easily have more than 256 colors
needed.)

 I suppose dynamic updating of the color map as required could be done.

 I guess, in quick summary, the client on X systems could handle light
changes, but it would be fairly complicted to do (display light
changes, that is)

 Thus, it makes even more sense to handle light on the client side - if
client is not using light for display, it can just choose not to even
figure out intensity on any of the squares.  And the server doesn't waste
time workign on information that is not needed.

 --Mark