[Red5] realtime movement ; latency ; dead reckoning ; coordinate prediction

Wed Nov 7 12:40:04 PST 2007

Heh , this is a popular subject I think.
I'm playing around with some ideas too.
I'm hoping the collision detection will be added to the sandy library
soon.
http://www.flashsandy.org/projects/redsandy

-----Original Message-----
From: red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] On
Behalf Of Trevor Burton
Sent: Wednesday, November 07, 2007 8:20 AM
To: red5 at osflash.org
Subject: Re: [Red5] realtime movement ; latency ; dead reckoning
;coordinate prediction

I'm just starting working on the same issue... i found this article
quite interesting as an approach

http://www.gaffer.org/game-physics/fix-your-timestep/

T

On Nov 7, 2007 3:38 PM, Naicu Octavian <naicuoctavian at gmail.com> wrote:
> Check out the archives on the FLASHMEDIA list , there is a long thread
in
> there about the efficiency of onSync cals vs. repeated
> ns.call(function,vars) calls.
>
> --
> Naicu Octavian,
> Project Manager for AVChat
> http://www.avchat.net
>
> On 07/11/2007, Walter Tak <walter at waltertak.com> wrote:
> >
> >
> > Management excerpt:
> >
> > a. Has anyone decent experience with realtime 'smooth' movement of
objects
> in multiplayer environments ?
> > b. What would be the performance impact of using SO.send() at a
decent
> framerate (say 10 times a second) versus normal usage of SO + onSync.
> >
> > The long version why option b. would be needed.
> >
> > I'm working on a realtime multiplayer game and things are going fine
but
> I'm having difficulties syncing movement of all players using a SO and
> .onSync.
> >
> > Image a flying game with fast moving planes on a large playground.
Each
> plane travels at least 100 pixels per second ~ 3 pixels per frame (@
30 fps)
> >
> > I've studied a lot of available info on dead reckoning (= prediction
where
> a player might go to in the next XXX frames , until a new update of
the
> players coordinates+vector came along).
> >
> > The default shared ball tutorial for FMS and Red5 shows exactly the
> problem of onSync ;
> > if you move the ball fast then the updates on the other client are
> horrible ;
> > you will see the ball being updated around 10 fps and it moves
unnatural.
> > Increasing the setFps to insane numbers (50 updates per sec for
example)
> don't work ; the other players won't receive 50 onSyncs ! Neither
should
> they.
> >
> > To prevent the stuttering I calculate the deltaX and deltaY between
the
> last known and previous update of onSync and let the client move the
ball
> (player1) in an onEnterFrame,
> > with deltaX and deltaY / (framerate / syncrate) . If a plane would
travel
> 100 pixels (on the x-axis) between 2 onsyncs  then the actual
displacement
> of the plane would be
> > 100pixels / (30fps / 10syncs) = ~ 33 pixels per (onEnter) frame ;
the
> plane would fly 3 frames before a new onSync will arive.
> >
> > E.g. when using setFps(5) (5 updates max per second, to minimize
traffic
> and load on the server) the table of the movement looks like this:
> >
> > New situation ; plane starts at position 100,100 and flies around.
> >
> > At timestamp t0 ( 0 ms ) the position of player1 is 100,100 - Data
is
> synced to Red5 , timestamp s0 (0 ms)
> > At timestamp t1 ( 50 ms )  the position of player1 is 110,101
> >
> > At timestamp t2 ( 100 ms )  the position of player1 is 120,102
> >
> > At timestamp t3 ( 150 ms )  the position of player1 is 130,103
> >
> > At timestamp t4 ( 200 ms )  the position of player1 is 140,104
> > At timestamp t5 ( 250 ms )  the position of player1 is 150,105 -
Data is
> synced to Red5 , timestamp s1
> >
> > As you can see the remote client only receives 2 updates, one at s0
and
> one at s1. The deltaX is 150-100 = 50 .. The deltaY is 105-100 = 5.
> >
> > If I'd know the exact update-rate of onSync (which is variable since
it
> only transmits changes) I could calculate the exact 'movement per
frame'
> like this:
> >
> > If player1 moves from 100,100 to 150,100 in 5 frames then the
> deltaX,deltaY per frame is (150-100)/5 = 10 (pixels) and (105-100)/5 =
1
> (pixels)
> >
> > This way we can "predict" the movement of the player for the next 5
frames
> from t5. However this is a prediction and chances are high that the
actual
> position of
> > player1 at next sync timestamp t9 / s2 will be something like
160,130
> (instead of 150 + 5*10 = 200 and 110 + 5*1 = 110) so we have to
correct the
> correct position of player 1
> > asap from 200,110 to 160,110 (which is tbh a pretty large delta)
> >
> > The timeline would look like this:
> >
> > t5 (250 ms) position predicted 160,106
> >
> > t6 (300 ms) position predicted 170,107
> >
> > t7 (350 ms) position predicted 180,108
> >
> > t8 (400 ms) position predicted 190,109
> >
> > t9 (450 ms) position predicted 200,110 - Data is synced to Red5 from
> player1, timestamp s2 , actual coordinates of player1 are 160,130
> >
> > new deltaX : 160 (s2) -150 (s1) = 10 and deltaY : 130 (s2) - 105
(s1) = 25
> (per 5 frames)
> >
> > At this point 2 things need to be done ;
> > 1. correct the wrong current position of player1 and
> > 2. recalculate the new delta's
> > 3. combine 1 + 2
> >
> > The above is relative simple math and can be implemented in a day.
> >
> > However ; we don't know at what rate the onSync comes in ; if
player1
> doesn't move for 3 seconds (!) then nothing will be send to Red5 and
the
> onSync event at player 2 will not trigger ;
> > if we would keep moving virtual player 1 at the last calculated
delta's
> then he will end up at the edge of the screen while in fact he already
had
> stopped.
> >
> > To counter this it would be better to get onSyncs that repeat the
last
> position instead of a silent onSync.
> >
> > E.g. player 1 moves towards position 150,100 ; in an onEnterFrame
the
> Flash-client would transmit 150,100 to the server, no matter if the
player
> stopped.
> > That way it's easy to calculate delta's between the current and last
known
> position.
> >
> > --
> >
> > However this starts to become fairly complicated and I don't want to
> reinvent the wheel,
> > let alone think that I'm the only one capable of solving the
problem, so
> does anyone have a good idea ?
> >
> > If not I'll try to develop a (Flash) class for this , if needed
combined
> with a Red5-class , and share it with the rest of the community.
> >
> >
> > Regards,
> > Walter
> >
> > ________________________________
> I am using the free version of SPAMfighter for private users.
> > It has removed 13728 spam emails to date.
> > Paying users do not have this message in their emails.
> > Try SPAMfighter for free now!
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> >
> >
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>

-- 
Trevor Burton
http://www.paperworld3d.com

_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org