[CF-Devel] Combing multipart images proposal/thoughts.

[Mark Wedel]

On Wed, 5 Sep 2001, Yann Chachkoff wrote:

>
     
      I simply do not understand the direct relation between the visual aspect of
     
     >
     
      the game and the internal representation of objects. I agree that each
     
     >
     
      object should have one or more associated pictures; I also understand that
     
     >
     
      some "line-of-sight" calculations needs to be done by the server (for
     
     >
     
      example, "what part of a monster can you see by looking at that door ?").
     
     >
     
      But I maintain it: the object handling (movement, size, coordinates,
     
     >
     
      events, etc.) and the graphical handling (the way pictures are sent and
     
     >
     
      displayed) are completely different things, even for tilebased games like
     
     >
     
      CF. That's because it is not true _now_ that I suggested some thinking
     
     >
     
      about improving that situation.
     
     
 I think that at least for me, giving a more precise example of how you
think it should work would be useful.  Off the top of my head, I can't
think of a better way to do it.

 The only possible improvement I can think in terms of handling is
fractional coordinates - in effect, creatures would not move less often,
a creature with 0.25 speed would just move a quarter space a turn.

 This does create some nicer effects of course.  Each object would still
belong to one space, and when it is more than half a space from one,
it moves to the next, but its location is effectively at the other side
(ie, a monster move to the right may start at the center, then be 0.1, 0.2,
... 0.49 off the right of center and still in its original square.  When
it gets to 0.51, it moves to the square to the right, but now is at -0.49)

 The problem is I don't think this will work very good for other
reasons - now every object that is alive needs to get fully processed
each tick (performance hit).  Monsters would now take these partial steps,
and could very well find out that time is wasted as another moves into
their destination space before they get to it (they may be at 0.45
towards and when it gets blocked, so now spend all that time going some
other direction).  This would increase bandwidth (relative positions
to a finer detail needs to get sent).

 IMO, the most useful aspect of such fractional coordinates would be
for the non living objects.  you may be able to place various objects
in such ways to smooth them out much more.

>
     
     
     >
     
      >The overlapping problem I mentioned above for example can only be solved
     
     >
     
      >by the server, unless the whole map gets sent to the client.
     
     >
     
      >Similar, the server has to decide what images the client gets to see
     
     >
     
      >and in which order.
     
     >
     
      I am not sure of that. In reality, what the server has to decide is what
     
     >
     
      _objects_ should be displayed, and in what order IMO.
     
     
 Correct.

>
     
      >I believe the client should get as little information as possible (to save
     
     >
     
      >bandwidth). If that means the server must do some graphic-related work,
     
     >
     
      >still better than lagging the client.
     
     >
     
      I doubt that letting the client handle the graphics would result in lagging
     
     >
     
      it; I never suggested an increase of the data transfers between the server
     
     >
     
      and the client, quite the contrary ! And I do not see why letting the
     
     >
     
      client handle the graphics would result in an increase of that traffic.
     
     
 I am not sure what you have proposed.  One definitive thing you proposed
is that cache image behaviour should be the default - thats fine, but
since that functionality already exists, doesn't really change anything.

 Beyond that, I'm not positive what is being offloaded to the client here.
The client of course is completely responsible for generating and drawing
the images - the only thing the server current provides is the data to
build the individual images (if the client does not already have it),
the stacking of the images, and where they should be.  It sounds like
the last two will remain in either case.