[crossfire] Face "overlays"

[Mark Wedel]

On 07/16/11 01:45 AM, Nicolas Weeger wrote:
>>    Ah - so it sounds like you are looking at one of these 2 possibilites:
>
> <snip>
>
> Correct :)
>
>
>
>>    My gut instinct is that #2 would actually be easier.  For #1, I think it
>> may require potentially more protocol changes (there may be issues with
>> number of layers, so some extension for that, and the map send code would
>> have to look at the object and see if that given object has overlays that
>> need to get sent, look those up) - I'm just not sure how efficient that
>> would be.
>
>
> #2 seems nice too, but this also means there will be a need for many
> "temporary" images.
>
> Imagine the player with a basic armor, and the associated overlay. There will
> be 4 (for most races) directions * 3 pictures (for most animations) so 12
> composite images.
>
> Now the player casts a spell - that's another animation, so 4*3 pictures
> again.

  I wonder if the composite images could also include the animations - for some, 
that may not work if it is a single run action, but for others, one could 
imagine it would work . In particular, I'm thinking auras might be something 
animated to some degree, but the timing on those really isn't critical (if the 
aura animation is a little off from what the server things it should be, no big 
deal).

  But likewise, if the armor or weapon is animated (flaming swords, special 
armor), same thing - those are basically a loop, and if the timing is off on the 
client, no problem.

  Casting is trickier (as may be attacks), as you do those once (more for 
spells).  OTOH, attacks maybe should also be a cycle.

  So one could imagine that if you add a composite image protocol command 
(cmpimage), it could be something like:

cmpimage <type>[<face>|<anim speed><animation>](and repeat those)

Type could basically just describe the next set of data that follows.  If that 
data is an animation, the server would have to send the animation.  Of course 
same is true for face - if the face has not been sent, has to get sent to the 
client also.

Directions would still be an issue, as that is 4x or 8x the number of images.


>
>
> So I'm wondering how many pictures that will imply at total...
>
>
> One way would be for the server to find all "action-related" animations (so
> "player_fenx_spellcasting" and friends) and for each regenerate temporary
> faces for any face. That could mean 200 faces for a player. Maybe not that a
> big evil deal...

  On the server, that is not much a concern - the amount of data for each one 
probably would not be that much (50 bytes?) A bigger concern I would have would 
be that if one used a simple method (new composite face = composite face +1), on 
a long running server,  one could go beyond 16 bits (65536 composite faces), 
which may mean that the server is unable to properly send the data to the client.

  Realistically, probably want to use a hash table that can hash the 
faces/animations for the composite image - that makes lookup much faster, and 
one could limit the hash table size to how many bits the protocol can handle 
(nearest prime less than 65535 for example).  If the hash table fills up, the 
server could basically just give up an die.

  A more complex approach could be that each client connection has a lookup 
table - while it is conceivable that the server will go beyond 16 bits, it is 
pretty unlikely that a client would see all of those.  So for each client, the 
server could literally start at zero and start increasing as that client 
encounters more and more composite faces.  But that does not have to be in the 
original design - if that proves to be an issue, it could always be added later.

>
>
>
> Also it seems the server will need to send faces updates at almost each
> equipment change. Probably not that a big deal either, but still.

  Yes - for each equipment change, there is the potential of a composite face 
protocol command.  But if the player is not changing equipment all the time (eg, 
the change in question lasts for a little time) or the player cycles between a 
few established ones (casting, combat, moving, certain aura going up and down), 
it probably would not take too long (and many composite image commands) for the 
client to get all of those, and the server now saves bandwidth on those future 
updates.  For example, if one has to send all the images that make up the 
player, than that may be 8 bytes (base + armor + weapon + aura) for that, but 
once it is established, it is just 2 bytes (composite image).  The composite 
image command itself is probably something like 20 bytes?  Protocol command 
(cmpimage?) + 2 bytes for the number + the 8-12 of the actual images.  So one 
doesn't have to use it too many times to come out ahead.

> For clients not having this support, the fallback would be simply to send the
> regular player face, imo.

  Yes - the only thing would be that in this case, the composite image, if it 
exists, should probably be stored in a different field in the object, and not 
replace the face - then it is very easy.  If ob->composite_image !=0 and client 
supports it, send composite image.  Otherwise, send ob->face

  Some users/clients could also choose to turn it off in such a model - maybe 
they have a slow system so the extra faces take more time to draw or more 
bandwidth than they really want to give.