6 ms·

I still like the original Quake1 networking code (NetQuake) the best, which has zero prediction. It feels extremely stable and responsive. There's no warping/je

• smokinn 16y ago
  No, broadband connections are starting to have major latency issues and it's only going to get worse in the short term. Check out this earlier discussion on bufferbloat: http://news.ycombinator.com/item?id=2002992 http://news.ycombinator.com/item?id=2002992 Basically, if you have a broadband connection, a wireless card and a wireless N router expect bizarre latency spikes. The reason you get those unpredictable spikes is because of the unnecessarily big buffers at every step down the line.
  • deleted 16y ago
    [deleted]
  • cma 16y ago
    Explain why large buffers in and of themselves would matter? The only relation I could see there would be if they were flush-on-fill, or constant rate in, constant rate out (like the audio buffer in a receiver). Aside from those cases, if the new bigger buffers are actually always being utilized near the new bigger sizes, then a smaller buffer scenario would just mean you'd get more packet loss and even more latency, right?
    • smokinn 16y ago
      It's indeed because they're flush on fill. Games that don't optimize and use more data on the wire actually feel more responsive than games that are wasteful with data.
      • ericflo 16y ago
        > Games that don't optimize and use more data on the wire actually feel more responsive than games that are wasteful with data. I re-read this three times and still can't parse what you're trying to say. Mind clarifying?
        • JeffL 16y ago
          If the game doesn't optimize down the total data it sends, then it's constantly filling the buffers, so there's no waiting for buffers to fill which can reduce ping times.
        • ijuhygtfhyuj 16y ago
          Flush on full means the data is only sent when the buffer is full. If the buffer is large and you have an optimized game that minimizes the amount of data sent then the buffer takes longer to fill up and packets are sent less often. Older games that send more data may get quicker response if your throughput is high but your packets are large
        • TheSOB88 16y ago
          I think op means games that aren't wasteful, i.e. they send a smaller amount of information with less redundance.
    • smokinn 16y ago
      Here's an example of me pinging my router: smokinn@ubuntu:~$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.24 ms 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.21 ms 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=75.4 ms 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=1.26 ms 64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.18 ms 64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1.21 ms 64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=1.20 ms 64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1.28 ms 64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=1.28 ms 64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=1.23 ms 64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=1.23 ms 64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=1.24 ms 64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=1.19 ms 64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=1.22 ms 64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=101 ms 64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=1.31 ms 64 bytes from 192.168.1.1: icmp_req=17 ttl=64 time=1.69 ms Notice number 3 and 15. I'm not yet sure why exactly it does this, I haven't had time to investigate fully and honestly it's a minor problem since I don't really play games so it's pretty low on my priority list but I suspect it's either bufferbloat or a driver issue.
  • deleted 16y ago
    [deleted]
  • deleted 16y ago
    [deleted]
• coderdude 16y ago
  Are you actually certain that Quake1 didn't use prediction? I mean, there's this entire part of the Quake source code devoted to it: http://www.fabiensanglard.net/quakeSource/quakeSourcePrediction.php http://www.fabiensanglard.net/quakeSource/quakeSourcePredict...
  • acon 16y ago
    I believe this prediction code wasn't included in the original Quake. It was added later in QuakeWorld which was some sort of multiplayer enhancement for Quake. Please correct me if I'm wrong.
    • coderdude 16y ago
      Edit: My bad, this code IS for QuakeWorld. As far as I'm concerned I have no evidence to put forth that the original commenter is wrong in his assessment. --- You may be right. I'm genuinely asking the guy if he knows one way or the other, as I do not know but certainly am curious. I mean, no lag compensation in the days of dialup? Seems like id/John Carmack would have know better even at that stage. But then again, it could just as easily be that they didn't realize the need for that tech in the beginning.
      • staunch 16y ago
        There was no prediction in NetQuake. The main reason for QuakeWorld was the addition of client-side prediction. It was pretty controversial and many people stayed with NetQuake. Even back then many people (including id software) had ISDN, T1s, or college connections that had the kind of latency most people have today. This was also in the days when LAN parties and LAN events were much more popular.
      • dasil003 16y ago
        Internet play wasn't important when Quake was released. Serious gaming was pretty much LAN only, and Quake was the epitome of serious gaming. At the time the graphics and 3d environments alone were the big selling point. I remember playing that first version over a modem, and indeed there was no client prediction at all. Not just shooting, but every single thing. You press forward, wait 300ms before anything happens, you switch weapons, wait 300ms. Even basic things like running and timing a jump over a small gap were extraordinarily difficult. But it was still kind of fun for the novelty of it, at least until somebody on a T1 or ISDN joined at which point you simply died before you even saw the enemy (ie. you saw them before you saw yourself die, but by then you had in fact already died on the server).
• roxstar 16y ago
  Qwest has interleave on for DSL which means my first hop is easily over 40 ms so a minimum ping of 60-80 is rather likely for me. I don't know if the same holds true for their fiber but I'm sure interleave is common among DSL providers. Cable also suffers from neighborhood overselling where in peak hours people get ping times in like 200-600 ms when they are likely to play. I don't know if this problem will be fixed soon but I think prediction is still necessary (or more so required) for a large population. This may just be limited to American broadband services though, and I'm sure larger cities may have less of a problem.
• mambodog 16y ago
  To be fair, modern games throw around a lot more data every frame, games such as the Battlefield series[1] would not have been feasible without client-side prediction. [1]http://en.wikipedia.org/wiki/Battlefield_(series) http://en.wikipedia.org/wiki/Battlefield_(series)
  • staunch 16y ago
    How do you know that's true? I'm not saying you're wrong, I'm genuinely curious. Older games built on the Quake{1,2,3} engines use hardly any network bandwidth. Most Bad Company 2 games have only 32 players, which is hardly bigger than Quake1. What's going on that's so much more bandwidth intensive?
    • mambodog 16y ago
      Way more dynamic objects (vehicles, destructible environments) with a much larger playable area (more room for more objects). Usually objects further from the player are updated less frequently (to deal with the sheer volume of objects) but may still be visible to the player, client-side prediction comes in handy here. Also the need for more detailed positional/vector data for much more complex physics simulation, which also requires both a higher resolution of updates to function realistically. Additionally, fast moving vehicles with more delicate control/handling, such as fighter aircraft, also a require higher resolution of updates so that you can actually fly them without crashing due to the feedback loop of perceiving jerky/delayed movement and input response. Prediction can help to smooth this out. Additionally modern games use things like physically simulated projectiles (think bullet drop[1]) with collisions calculated using mesh-based collisions instead of simple hitboxes, over much longer distances, so there is a need for prediction as timing is more of a factor. Quake 1, 2 and 3[2] use the 'hitscan' method[3] of calculating whether a bullet hits its target, which is instant and calculates a linear trajectory, which has the side effect of making it easier for players to adjust to lag (basically any difference between the player firing and the hit registering is network lag, and should be more or less consistent). Finally, two slightly different issues that have become apparent in recent years are automatic match-making and local servers (ie, the game running on one player's console). Auto matchmaking is often fairly shitty, meaning that (on average) players end up playing on servers to which they have a higher ping time than if they had chosen the server from a server browser (something that is sadly becoming rare in today's games). The phenomena of local servers, on the other hand, puts pressure on the total available throughput, rather than ping time, as the player that is hosting likely has more limited outgoing bandwidth than a dedicated server might. [1]http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop [2] only for some weapons, a rare exception for the time [3]http://en.wikipedia.org/wiki/Hitscan http://en.wikipedia.org/wiki/Hitscan
• light3 16y ago
  Sure, when everybody has connections of 20-40ms this prediction is not much of a feature. But back in the days when everybody were on modem connections with 120ms latency, this was important. It means you don't have to physically aim 'in front' of where the target is moving towards, this may not be an issue with automatic or AOE weapons, but if you're trying to use a sniper rifle this can be pretty hard.
• baq 16y ago
  quake3+cpma or quakelive (which uses cpma netcode) are better - very good at low latencies while also being very good up to 100 ms (which makes competitive intercontinental matches a realistic possibility - if you're not rat already).