[crossfire] Client display issue

[Mark Wedel]

Nicolas Weeger wrote:
>
     
      Hello.
     
     >
     
     
     >
     
      With current CVS GTK client, there's a big display issue with
     
     >
     
      multiplart images.
     
     >
     
      Client apparently keeps old parts in memory, and won't erase'em.
     
     >
     
      Casting spells doesn't change display, but using dimension door (thus
     
     >
     
      invalidating cache) fixes the trouble.
     
     >
     
      So I'd guess it's related to caching. But someone who knows more about
     
     >
     
      multipart can tell better :)
     
     
  I've looked at this some.

  I've mostly been experimenting with the opengl logic in the gtkv2 client, 
because it has the distinct advantage that it redraws every space every tick, so 
no worry about the client not drawing something it is supposed to.

  My first finding is that putting a 'return' at the top of expand_face() 
greatly reduced number of errors (but did not eliminate them completely). 
However, this only works for opengl which only cares about the head location - 
it doesn't care about the sub pieces because it is fast enough it can draw 
everything each tick.

  The problem here is that the client is thinking it needs to keep the face 
around erroneously.  I didn't investigate closely what the client is trying to do.

  However, it does seem largely client related, because there is a 'mapredraw' 
command you can invoke - what happens when you invoke it is that the server 
clears out information on all the spaces it sent to the client, which basically 
forces it to send all the data for every spaces again (just as if you changed 
maps).  However, on corrupted maps, that does not fix the problem, pointing out 
an issue that it is the client holding the wrong info.

  Unfortunately, as of this writing, there is no client command to similarly 
clear out all the data the client is holding - if so, would be very easy to 
figure out who is handling the bogus data.

  All that said, the above change greatly reduces the frequency, but does not 
eliminate it 100%.

  I think there may be some interaction related to the large object, which 
pieces of it are visible, and if they have come into and out of visiblity.

  All this is because for the big images, the server only sends the face in the 
bottom right coordinate, even if that space isn't visible.  This unfortunately 
makes server handling more difficult - it could be that the server isn't sending 
a 'this no longer here' type of thing when it should.

  However, at the same time, the client has to remember which spaces it has 
gotten this data from - this isn't really a fog space, so its handling gets odd.

  I'm not 100%, but I could envision oddities in cases like this (imagine a 2x2 
image).  first, the upper left is visible - server sends bottom right location, 
client has to remember to keep that around as 'non fog' drawable.  Entire 
creature then becomes visible, so now the client basically treats all spaces 
normally.  Now, player moves or something, so only the upper left is visible 
again - the client already has record of the the bottom right face, and may get 
confused on updating it.

  My personal finding is that if one goes through the titan quest, one can 
really see the problem here.

  I think there are some fixes to the client that may make this work better. 
But I really think I need to change the map handling on the server, and how it 
is communicated to the client, to really fix this up properly.