[CF-Devel] smoothing code.
crossfire-devel-admin at archives.real-time.com
crossfire-devel-admin at archives.real-time.com
Sat Jul 5 10:02:47 CDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le Vendredi 4 Juillet 2003 09:44, Mark Wedel a écrit :
>
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'.
it' controlled a object level ot know the 'smoothing level' of an object.
If you don't want a particular grass (let's say you want a map with
extremly strict separation betwee the road an the map, cause
there are a lot of gardeners working at this (eg: a castle)), simply
lower it's smoothlevel to 0 (will smooth on nothing) at the object level.
So mapmaker have control on smoothing.
>
>
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 first tried only client side, but dropeed 6 months ago. too manny issues to
resolve, no control for mapmakers, difficulties for having 'names' associated
with images under certain configuration. The client server protocol extension
is still the cleanest way.
>
>
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 understand this is a bad choice for the protocol. Am sorry. But this
command is not frequent (like images, server keep a list of smoothing
sequences already send to client, for now ther are only 6 smoothing sequences
i think) and the client/server have already been updated in cvs, i could
switch to binary form if you agree to break client / server which have been
checked out during the past few day when this was not binary.
>
>
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.
>
Like for images, if client asked the smoothing from server, server
will send the smoothing sequence when this is a new one for client
and this sequence is visible in the current map. So this work
of sending is done automatically when sending the mapextend command to client.
>
> 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).
see coment on mapextended below before reading this part.
This help separate things. Since a lot of infos may be, in the future,
associated with map coordinates, this command tells the client what
in the map coordinates it want. And it also respond by telling
what actually are the options activated. Thought it simply easier to handle.
>
>
> 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.
mapextended will contain, in the end, a lot of informations. This command has
been developped so it is easily extendable without breaking the clients and /
or old server. For now this contains only smoothing. Work will be done
next so when text message are used, for example from NPC, they will
be send according to the location. Moreover, the bit fields at the begin of
command allow, from case to case, the server to send only a small part
of the info. (eg, if a nps speak, no need to send smoothing infos
with the localized text).
When i decided to send smoothing informations, i saw all those different
map commands. And i though if we have to add commands, or use tricky code to
upgrade old commands each time we need to send other informations related to
the map from the server to the client, think will get even worse. So i
prefered to create from zero a new command which is extensible. However,
in the near future, nothing prevents from having a command from client to
server saying the server we prefer the 'classical' map informations to be
send with mapextended and not map2 or map2a.
Moreover, i need to
>
>
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.
The fact is some datas may perhaps, in the future, variate in size.
let's say i want to tell the client a NPC said 'Hello' at coordinates dx,dy.
I could send a packet from server, with only the 'TEXT' flag (which doesn't
exist for now, but will exist in future, i hope) and size helping know length
of text.
Moreover, server may send additionnal informations the client doesn't know
about, without having to take care 'may i put those 4 additionnal bits inside
the packet?' 'is the client using the old 1 byte or the new 2 byte ways of
sending smoothing?' etc. The server knows in advance the client will skip
what it doesn't understand, while still reading what he does understand. This
could help a lot, IMO, in the future the readability of server code
>
>
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'.
brings up tricky code, and doesn't help in all case, see above.
>
>
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.
see mapextended as a map2 command with more future extensibility without the
pain of handling 'old cases' in the server and guessing eveyrtime what the
version of client is.
>
>
>
>
>
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
- --
Tchize (David Delbecq)
tchize at myrealbox.com
Public PGP KEY FINGERPRINT:
F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/BuieHHGOa1Q2wXwRAupyAKDhVBG85rCbqFxXu3UXWi6BuTXGTwCg6TPs
527//f/PmZ936UCSkOtllv4=
=wd+k
-----END PGP SIGNATURE-----
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
More information about the crossfire
mailing list