Re: CF: Sliding animation instead of jerking animation

[Mark Wedel <>]

David Sundqvist wrote:
> 
> On Tue, 1 Jun 1999, Peter Mardahl wrote:
> Kjetil Torgrim Homme wrote:
> >
> > > Also consider making it possible to move less than one square at the
> > > time, or at least do sliding animations (may be relegated as a client
> > > issue).
> >
> > Wow, this is a great idea.  The game would seem MUCH smoother.
> > I hope someone can take up this idea of Kjetil's and incorporate
> > it into the client.
> 
> Incorporating it into the client wont work tho, since there isnt enough
> info in the client to do it. A possibility would be to have the client
> know a larger-than-visible area, and keep the character image as a sortof
> 'overlay' in the middle and just slide the map around upon movement, but
> that would require sending first a client-request-move, getting yes/no
> from the server, sliding the map and updating with new location. This
> might look slightly weird tho, since monsters and other players would
> still move jerkily, and shifts in lighting would also be done jerkily. The
> basic problem is that the client doesnt contain any object information, it
> just contains an array of mapsquares and what images they contain. Neither
> do we trust the client with object info. Not even map animations are done
> client-side, they're done through actual map redraws.

 But item inventory animation is done on the client side.

 The map updates/animations get tricky as it is difficult to know what to update
or not - the current method on the server is to store the face and then if the
face is different, send an update for that space.  But the other problem is that
updates for the individual spaces is pretty much done at the space level.

 If you have a floor, sword, and orc, and the client gets that face information,
and the orc dies and an ogre moves on top, trying to handle the logic that the
client has the floor and sword, but not the ogre and only send the ogre as the
top level gets a bit difficult.

 What probably should be done is make images and animation ids more
interchangable - perhaps just flip the high bit or something.  So for map
updates, if the high bit is not set, it knows it is just a face and draw it, if
the high bit is set, we know it is an animation and pay attention to it in
future redraws.  By the same logic, the server could use animation ids for
information it has sent to the client, so an space with just an orc doesn't need
to get reset as the client already has that animation ids'.

 In terms of actually implementing less than square quantums, the way to
probably do it has have some offset within the space.

 To clarify, you still need to know what physical square the player (or other
object) resides in in terms of stuff he can activate and whatnot.  Plus, so much
of the code depends on the current square quantum, to change to something else
would truly be a major rewrite.

 So instead, in the object have a an adjustment value - perhaps ranging for -50
to 50 for left/right and up/down.  For example, if an object is -50, it is at
the extreme left of the present space without actually being in the next space
right.  If it moves slightly more to the left, its logical square changes, and
the adjustment now moves to +50 (now on the extreme right of the new space.)

 In reality, -7 to +7 might be better, as both the up/down and left/right could
fit in a single byte.  But that may not be a big deal - if a larger viewing area
is done, the single byte currently used as a bandwidth saver won't be enough.

 The problem is how to implement this.  Currently, for something to move, it has
a full tick of time, which is enough to move a space.  Now it could be argued
that let objects move an 8'th of a space if the have an 8'th of a tick.  This
will chew up more cpu time on the server (potentially 8 times more objects to be
processed each tick), but also makes the logic harder.  Presumably, a monster
would still need a full tick to attack, so some coding would be needed to have
the monster decide if it wants to do a partial move or save up its time for an
attack.  And if other objects do have partial moves, that is potentially more
updates (bandwidth needed) for the client.

> 
> Of course, the player usually moves too fast to allow stepped animation
> anyway ;).

 The way to do this is to time all needed scrolls to finish in the next tick
(probably should add something to the protocol so the client can have an idea
how long a tick is.)  So for example, if the client gets player moves east, it
times it so it will take 120 ms (1 tick under standard game) for the scroll to
progress.  If it gets another player moved while still scrolling that one,
recompute the time factor so what remains of the current one and to finish the
new one finishes in one tick time (so if we are half done with the first move
and get another, now time things so the 1.5 moves will be done drawing in the
next 120 ms).

 With this, scrolling would happen faster if the player is moving faster.  The
disadvantage is that the view to the player will be slightly behind (instead of
seeing that new edge immediately, he has to wait a tick - if the viewing area is
increase, missing the far away detail immediately may not be as relevant - and
certainly, this smooth scroll could be setable.)

 I was thinking that you could just store the end coordinate as you have them
(so if player moves right then up very quickly, it would scroll diagionall upper
right).  The problem there was that there could be cases where player appears to
move through walls (or at least corners).

 Now in terms of other issues, for the client, it  gets the new viewable area
when the player moves.  What is trickier is the client has to keep track where
to draw the other data for any map updates it gets relative to its scrolling
progress.  The area that is scrolling off won't get updated, so there could be
inconsitencies there (suppose for example an arrow is heading towards the player
from the bottom of the map - player moves north, map is update, client starts
scrolling, but that bottom row is out of data (no more updates since the server
doesn't consider it in the viewable area).  However, that arrow which was in the
bottom (now out of data in terms of viewed area space) moves to the next space,
and hence gets update.  The problem here is that the space the arrow moved from
would still appear to have an arrow (so there would be two visible arrows) until
the scroll finished.

 And to fix that problem starts to get even more complicated - if you update
areas outside the map, a person could certainly say I don't want the scrolling -
show me that extra area instead.  The other option would be to update that area
moving offsite for a few ticks after the server moves the player, but that seems
a bit more complicated than necessary.  Or the other option would be to live
with the inconsintencies, knowing they won't happen all that often, but the
smooth scroll maps things look neeter (one thing I don't like about that is I am
sure there will be questions/bug reports about the edge being scrolled off not
looking right).

 If you also wanted things on the client to look cooler, the other thing to do
would be to have hints/let the client do the darkening/removal of color for
darkness code.  The server would still determine what is completely out of sight
due to darkness, but it could potentially send information on the light location
and intensity to the client, and let the client make smooth circular shading
effects on the map.  That could potentially save bandwidth since right now the
server just sends along the masking images as part of the map updates, and those
would not need to be sent along then.

> 
> I was saving the suggestion of doing real object drawing in the client to
> the Great OpenGL Crossfire Rewrite around 2005 :).

 I think moving to a true perspective game would certainly require updating most
of the maps.

 And to be honest, with the number of perspective games out there, the fact the
crossfire is still overview is sort of nice.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]