[ENet-discuss] fps networking

[Ruud van Gaal]

With position and orientation both present, you do pretty much the same
thing; you interpolate.
I don't interpolate velocity itself, it didn't seem necessary yet (but then
again, my game is just starting to work on internet; there was no
multiplayer lobby until today, so my knowledge is just starting).
With orientation you take the orientation velocity (rotational velocity) and
for correction you interpolate orientation using slerp, lerp or some other
variation of quaternion interpolation (doing that using matrices seems much
more complicated).

My cars ofcourse take as input forces & torques, not 'move forward' or such.
But even 'move forward' is much the same as a directed force. And indeed
there's always lag. Hope it's ok as it is in my case; I've really only
checked LAN playing. Ouch.
Once, on SGI's, I made a small tool that works as a middle man for all
packets; it got packets, held on to them for a random amount of time, then
passed them on. Together with a variable setting of drop%, it would have
been a great tool to simulate the internet on a LAN. Quite a bit of work
though, would be nice to have such features inside ENet. ;-)

BTW in my sim I send both positions, velocites, accelerations (although it
seems it works WITHOUT) and orientation plus rotational velocity. The client
sends a position(+the other) update to the server, the server sends it on,
mostly untouched, to all other clients. It's just some clock syncing that is
modified to get a similar sim time on all computers. For time syncing, you
can go far but in general pingRoundTrip/2+localTime is a good start. :)

Cheers,
Ruud

> It just seems like so many things could go wrong.  The fact 
> that the client never has exactly the same state as the 
> server means you could be 
> sending a completely different position.   Now i could see 
> extracting a 
> direction based on two positions: the client's and the 
> server's. That way you could say "here is where i want to 
> go", then the server could try to move you there. But what if 
> there's more than just position? 
> Rotational velocity, orientation, etc.. It doesn't quite work 
> in those scenarios. Then again i haven't tried it but for a 
> fullblown physics simulation where your input to your 
> character is torque, seems like it wouldn't work.
> 
> Sending input results in lag? There's always gonna be lag to 
> other clients but if you do client side prediction you won't 
> notice your own lag.
> 
> The one benefit i see is the framerate issue.  If the server 
> has the correct "desired position" that the client sent, then 
> it already has the direction the client wants to go.  If the 
> client sends packets at a slower rate because of fps, then 
> the server can just use the last packet and interpolate.
> 
> Yeah, it just gets frustrating when you ask a specific 
> question but don't get answered or get the run around.
> 
> Ruud van Gaal wrote:
> > What's so odd about not sending input? Once you get into 
> the current 
> > methods used (prediction/interpolation and such) it becomes clear. 
> > There's quite some info on multiplayer methods available on 
> the net, I found.
> >
> > For my racing game for example, no input is sent. Every client