Jump to content

  • Log In with Google      Sign In   
  • Create Account

Felix Ungman

Member Since 19 Nov 2007
Offline Last Active Oct 20 2016 06:44 AM

Posts I've Made

In Topic: Friends living abroad have really laggy connection to me, why?(using raknet,...

21 August 2016 - 05:37 AM

In UDP, instead of waiting for a dropped packet to be resent again, you can just make 100 copies of the same packet and send them all in case some of them are dropped. You kind of flood the network a little bit, but it's faster than the TCP way of handling dropped packets, which is what is needed in FPS games.


That's a bad idea. First, you would increase the bandwidth by two orders of magnitudes, which is not just a little bit. Second, today the majority of packet drops are caused by congestion, meaning that not just one but many packets are dropped, so if you send many at the same time you still risk losing them all.


Back to the original question, your solution is to not only send position but also velocity (and possibly acceleration, depending on the game), as well as a timestamp. On the other end you will then be able to calculate the expected position at any time from the last known values of these parameters. You can improve this further by using various techniques for interpolation and clock synchronization.

In Topic: C++ best way to break out of nested for loops

09 April 2016 - 10:43 AM

C++ desperately needs conditional come-froms

In Topic: [ANSWERED] Questions about public WiFi vs private WiFi

07 April 2016 - 01:45 PM

Most likely a firewall at the cloud provider that is blocking ICMP packets. Could be the university WiFi, try testing some random address, say google.com, and see if it works.

In Topic: Mobile multiplayer game

13 March 2016 - 05:06 AM

Yes, that's a third problem to take care of. If you use UDP you need to detect missing messages and make sure to resend them, while TCP takes care of this and guarantees to deliver the message eventually. But note that even if you use TCP you don't actually know *when* the message will be delivered, only that it will. So if absolute wall-clock synchronization is a requirement, you're right, you need to wait for that acknowledgement. (For games this requirement is usually relaxed, consistency and responsiveness is usually more important than absolute synchronization.)

In Topic: Mobile multiplayer game

12 March 2016 - 01:40 PM

There are two problems here. One is to synchronize wall clock time, either by using a centralized reference (say ntp), or to guessing from the round-trip time between the clients. The other is synchronizing simulation time, which is solved by using a lookahead. If player 1 presses a button at simulation time T, the change is scheduled to take place at time T+D where D is sufficiently large to be sure that this information has been transmitted to player 2.