[crossfire] Smooth movement

[David Delbecq]

Well, i did not play with smooth movement, but according to what i know,
deciding *when* in the movement the player is on next square has never
been the major issue. Major issues are, i think:

1) All drawing code on client assume a per square position,
not half positions of character, need a very big redo on drawing
routines
2) All server assume objects on a square, need additionnal code to
manage transitions between square of objects. This is not trivial!
Espcially for monster following character. The can't go on a square
until player left it. however if at moment of tick player is 30% away,
monster can't follow the player because square still in use. Also,
what happen if after 30% movement destination square is now blocked?
Rollback? Will end in graphical artefact, you need a 'reseration'
systemn when
you start movement, but then this may end in technically player using
2 squares
at a time when moving.
3) protocol was never made to send partial positions.

Your suggestion just resolve some trivial question on when do player is
in a square, this is trivial imho. Deep problems are above :)

Lalo Martins a écrit :

>
      Ok, I searched for the original thread to ressurect it, but
     >
      couldn't find it, so here goes a new one.
     >
     
     >
      A few weeks ago, when Mark started talking about his new movement
     >
      code, there was some talk about "smoothing" movement - drawing the
     >
      image in partial locations between tiles, so that movement doesn't
     >
      look so jerky.
     >
     
     >
      The problem is that everything happens in a tick-based timeframe,
     >
      so until you move, there's no way to be sure where you will be next
     >
      turn; and starting "smooth" movement only after you already moved
     >
      would be worse, because for some time, you would seem to be in one
     >
      tile while you're actually already on the next one (if "you" are a
     >
      monster, this would cause players to shoot at the wrong tile).
     >
     
     >
      End summary.
     >
     
     >
      Now, the solution to this came to me two days ago just before
     >
      sleep. I'm surprised nobody came up with it before. Although it
     >
      has *serious* implications - it changes drastically the way the
     >
      game works - but then it means it's the best time to introduce it
     >
      now, together with Mark's other changes. And I think it's a
     >
      tangible improvement.
     >
     
     >
      Basically, it consists on accepting "input" (whether it's actual
     >
      input from the user, or a decision from the monster AI code) at a
     >
      point in time half a tick before when the object actually gets its
     >
      tick. Think of that as neural impulse delay.
     >
     
     >
      So, assuming the character was still then moves south, and its
     >
      speeed is such that it gets one tick at each T (T being global
     >
      ticks):
     >
     
     >
      Time | input | face position | actual
     >
      position
     >
      -------------------------------------------------------------------------
     >
      T | - | X,Y | X,Y T+5
     >
      | move south | X,Y | X,Y T+6 | -
     >
      | X,Y+0.1 | X,Y T+7 | - |
     >
      X,Y+0.2 | X,Y T+8 | - |
     >
      X,Y+0.3 | X,Y T+9 | - |
     >
      X,Y+0.4 | X,Y T+10 | - |
     >
      X,Y+0.5 | X,Y+1 (TICK) |
     >
      (exactly on the line b/w tiles) | T+11 | - | X,Y+0.6
     >
      | X,Y+1 T+12 | - | X,Y+0.7 |
     >
      X,Y+1 T+13 | - | X,Y+0.8 |
     >
      X,Y+1 T+14 | - | X,Y+0.9 |
     >
      X,Y+1 T+15 | move south | X,Y+1 |
     >
      X,Y+1 T+16 | - | X,Y+1.1 |
     >
      X,Y+1 ...
     >
     
     >
      In a future version, this logic could also be useful for
     >
      weapon-swing animations, attack sounds, etc etc.
     >
     
     >
      Does that make sense?
     >
     
     >
      best, Lalo Martins -- So many of our dreams at first seem
     >
      impossible, then they seem improbable, and then, when we summon the
     >
      will, they soon become inevitable. -- 
      http://www.exoweb.net/
      
     >
      mailto:
      lalo at exoweb.net
       GNU: never give up freedom
     >
      
      http://www.gnu.org/
      
     >
     
     >
     
     >
      _______________________________________________ crossfire mailing
     >
      list 
      crossfire at metalforge.org
      
     >
      
      http://mailman.metalforge.org/mailman/listinfo/crossfire
      
     >