[CF-Devel] New protocol command: map2

[crossfire-devel at archives.real-time.com]

  As per mail sent earlier this evening about map layering, I quickly wrote up 
the idea for a map2 command, which is much more extensible and should clean up 
some of the existing code nicely (basically does away with the need for the 
mapextended command):

S->C: map2 <coord1><len1/type1><data1><len2/type2><data2>...<coord2>

         This is an update of the map1 commands above.  It is meant to be
         extensible.  It is also meant to incorporate the ideas of the
         extended map info command.

         All data is in standard binary form.

         The coord value is 16 bites.

         the coord values are length + x + y values.
         The data represented looks like this:

         first 5 bits: The x coordinate (0-31)
         next 5 bits: the y coordinate (0-31)
         last 6 bits: the number of type/data pairs to follow (0-63).  While
         a limit of 63 data encodings is hard coded, I can't forsee reaching
         that limit anytime soon - remember, this is the number of type/data
         pairs that are sent for this space - there could be cases where there
         are 300 things on the space, but if we are only sending 63 of them
         this is also fine.

         <len/type> This is a single byte of data.
         This describes the data that is to follow.

         The top 3 bits (len) denote the number of bytes that follow - it is
         possible that this is zero, to denote all the relevant information is
         included in the type.  If this is 7 (all bits set) then the following
         byte is an additive length value.

         The bottom 5 bits is the type of data - this allows for 31 different
         types of data (0-31/0x0-0x1f).  The meaning of the data itself depends
         on what the type is.  List of various types:

         0x0: Denotes this space should be cleared.  Length in this case should
         also be zero, as there is no data that follows.

         0x1: Darkness information - typically a single byte follows that
             denotes how dark the square is.

         0x2: Sound?

         0x10-0x17: Image information - 2 or 3 bytes follow, which is the image
             for the particular layer.  Layer 0x10 is the lowest, 0x17 is the
             highest.  If 3 bytes follow, the first byte is smoothing
             information, followed by 2 bytes for the face.  If only 2 bytes
             follow, then this is only the face.  The number of bytes that
             follow is determined by the len field above.

         Some notes:

         Coordinates outside the viewable may (as requested by the client) may
         be sent.  In these cases, it means that a big image that extends onto
         the viewable map is on that space.  For big images, only the bottom
         right coordinate is sent - this is why it may be off the viewable
         coordinates.  For such spaces, only the actual big image itself will
         be sent for that space.

         Note that unless the 0x0 code to clear the space is sent, all
         operations are considered updates to the space (eg, new image, new
         light level, etc)

         Relative to the map1/map1a commands, this is more bandwidth intensive -
         basically, an additional byte is needed for each piece of data sent.
         Thus, on a 25x25 map, if we presume 1.5 objects/space, this is
         an extra 940 bytes to send.  OTOH, typically the entire map
         is not being sent - only those bits that change, so this may not
         be as costly as that.

         If the player is using smoothing, this may actually save bytes,
         as the redundant coordinates and type/length information
         does not need to be sent.  With the map2 command, the mapextend
         command is deprecated and is not used.

--

  I put Sound is as a question mark, as if sound is added enough, it could make 
sense to include that on the map instead of explicity using protocol commands.

  The other thought is that this can also get extended - one of the ideas I've 
long had is that instead of sending darkness for each space, we send brigtness 
(eg, that space has a 3 glow radius, that has a 6 glow radius, etc), and thus 
the client can more easily do the shading.  With that logic, one could even 
extend the lighting to have different color light sources (eg, 4 radius, red, 2 
radius green, etc).

  The main point being that there are still bunches of types available - it 
would seem hard to use up the remaining 20 or so types.

  However, my other ideas was to remove the len, and instead have the full 8 
bits for types.  The number of data bytes to follow would be based on the type 
itself.  This does mean that the client and server have to be on the same page 
for that type of thing (eg, if the server sent a type the client didn't 
understand, there would be issues).  However, that doesn't seem like much a 
stretch - if the client doesn't understand a type, it probably doesn't want the 
wasted bandwidth receiving that data.




_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel