[CF-Devel] smoothing code.

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

  First, I'd like to thank tchize for updating the protocol to give a better 
idea on how that code works.

  I do have some questions/comments.

  First, is it expected/thought that the smoothing (blending) of tiles is likely 
to be turned on/off at and object level?  this may be more for the mapmakers - 
do you see cases where you woudl say 'I really don't want this grass tile 
smoothed with the neighboring tile'.

  In a sense, this comes up because if the answer is 'not really', then the 
smoothing attribute could be tied to the face and not object.  That could 
simplify a bunch of things.  If there was a case where smoothing was not 
desired, that would result in a copy of the image however.

  As a note, I also postulated that such smoothing could be done all in the 
client.  Having the server know something about it may not be all that bad however.

I also have some comments about the code as documented:

>
     
      S->C: smooth <facenbr> <sm000> <sm001> <sm010> <sm011> <sm100> <sm101> <sm110>!
     
     >
     
              All parameters are space separated plain text integers.
     
     >
     
              This command informs the client on how to smooth a face, when it will
     
     >
     
              need it.  Following are the facenbr of the different pictures involved
     
     >
     
              in the smoothing algorithm. See doc on smoothing on how to use them.
     
     >
     
              (TODO) This info may be send automatically from server but could also
     
     >
     
              be requested by client using the asksmooth
     
     
  The general convention is that S->C communication is done in binary format. 
This is done for several reasons - it is more efficient cpu wise (easier to pack 
in integers vs converting to strings), and it is also more efficient bandwidth 
wise.  A lot of C->S communication is string based, not for any particular good 
reason, but there is a lot less communication in that direction.

  I'd also like clarification on the comment 'this info may be sent 
automatically'.  It strikes me that either this information will be sent (if 
some parameters are met, like client has enabled smoothing or whatever, or it 
won't be sent.  In other words, this should really be clarified what the 
behaviour would be.

>
     
      C->S: toggleextendedinfos <string1> <string2> .... <stringn>
     
     >
     
              Ask the server to send some additionnal informations about the map.
     
     <snip>

  Is there a reason this can't be handled in the setup protocol command that 
already exists?  the current setup options handle all sorts of options, some 
related to map (size of map, darkness), and other areas (sound, what 
capabilities the client supports).

>
     
      S->C: mapextended <what><length><coord1>[data1a][data1b][data1c]<coord2>...
     
     <much snipped>

  I can understand the need to send the smoothing information someplace 
(presuming we are wanting the information on the server).

  However, sending it as an additional/extra block of data to the map command 
doesn't seem right.  To me, the right approach would be to make a 'map2' command 
to include this.

  This is for a few reasons. one is efficiency - this mapextended command has a 
lot of redundant information to the actual map command we send - 2 bytes for the 
coordinate, and then followed by layering information.  If we are on an outdoor 
map, with say 200 spaces available, this is 400 bytes of redundant information 
(coordinates).

  I'd much rather see a map2 command - toss in another byte for other flags 
(like what layering info is being sent.  This gives space for 8 more flags.  If 
when that is filled up, a map3 command could be done.

  I also am not sure how useful the extensibly of the mapextended command as 
documented would really be.

  IT doesn't really match the current communication model, which is 'if the 
client sends it in a setup command, we will send the data the client wants, and 
assume it knows how to handle the data'.  Thus, having a field saying how large 
each block is so that the client can skip over it if it doesn't understand seems 
of marginal usefulness - if the client doesn't understand, we're just wasting 
resources by sending it to the client.

  And things can be very extensible by using setup commands and minor variations 
of the map commands.  EG, a map2 command could presumably be written using most 
of the same code for the map1 and map1a commands.  There'd just be a few spots 
in there for certain checks, like an 'if using map2, add extra flag byte'.  And 
another 'if using map2, and smoothing enabled, set up the smoothing data'.

  The reason to make a new protocol command (map2) vs just adding extra data to 
an existing command is simplicity - it is much simpler on the client to do 
something like 'a map2 command - I know the format of this data' vs a 'map1. 
Depending on what flags are set, the data could vary widely'.  Much easier to 
also track down bugs.





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