[CF-Devel] RFC: new map protocol command

[Mark Wedel]

 To support maps larger than 15x15 in the client display, a new map command is
needed (old command packed the coordinates into a single byte).  This is what I
came up with, sprinkled liberally with my comments of why I did it that way.

S->C: map1 <coord1>[darkness1][face1a][face1b][face1c]<coord2>[darkness2][face2a
]...

        This is an update of the map command to support large map sizes.
        The old map command supported a maximum map size of 15x15 -
        anything larger than that required a new command.

        Given that this larger map now needs 2 bytes for the coordinates -
        the same as for the images, trying to optimize one vs the other
        does not makes much sense.

        All data is in standard binary form.

        the coord values are flags + x + y values.  The value itself, but
        the data represented looks like this:
        first 6 bits: The x coordinate
        next 6 bits: the y coordinate
        last 4 bits: MSB - true if we send darkness
                     MSB-1 - will send floor face
                     MSB-2 - will send intermediate face
                     MSB-3 (aka LSB) - will send top face

        6 bits is enough for 63x63 maps.  For the time being, it should
        be a safe assumption that we won't be sending anything larger
        than that.

        Through the use of this bitmasks, any and all of the following values
        may be optional.  This allows the update of one face on the space
        without needing to send the others (in the old map command, this is
        not possible, so as an arrow flies over a space, the floor + arrow
        needs to get resent - this allows just the arrow to get sent).
	This should conserve bandwidth when spells are cast (we have an
        extra byte for the coordinate, but save 2 bytes for the image
        itself, plus another 2 potential bytes if there is something on the
        space.)

        If all the flag values are 0, this then means the space is considered
        blocked from view, and should be drawn as black.  This conserves
        bandwidth for sending blocked spaces, which occur pretty frequently.
        Once a space is marked as block, if it re-appears within view, the 3
        layers should be marked is blank.

        For spaces that are empty, one or more of the faces will be sent as
        blank faces (exactly how many will depend on what was on the floor
        before - for example, if a floor disappears, then only the floor needs
        to get updated, but if there was stuff on the floor, then that face
        will also need to get cleared).  There may be cases where
        transitioning from the blocked to empty space occurs, in which case
        the client will send the floor as an empty space.

        The darkness value is a single byte - 0 is pitch black, while 255 is
        fully illuminated.  It is up to the client to figure out what it wants
        to do with this (use masking to reduce visibility, or actually do a
        real light reduction on the image).
    
        the face values are 16 bit values, as before.  They will be sent
        in MSB order of the flag (ie, floor, then intermediate, then
        top, presuming the bit in the flag is set that says that layer
        is being sent)  Blank faces may get sent if an object disappears -
        in the example of the flying arrow, for the space the arrow
        leaves, a blank face will be sent in place of the arrow.

        Note that this implementation is much simpler than the prior one
        because it now works on spaces rather than layers, and most all the
        code also works on spaces.

        The downside of this is that this will need to get redone
        if we want to put more than 3 faces on a space (as we are then
        out of bits).  It would be trivial to do something different, like
        send as many faces as desired and just have a marking tag at the
        end - the problem with this is that if something changes,
        then once again, you need to send the entire space as there is
        no way to say 'face xyz has disappeared'.  And in any case, to
        support more faces will require more work on the server.