Tag Info

Hot answers tagged

9

Problem analysis Real-time communication over a high-latency connection is obviously impossible. You can of course attempt an illusion (as you're doing by making the remote player appear to have passed an obstacle when it's not yet known). When that illusion fails (as yours does when the remote player didn't actually pass the obstacle, but died instead) ...


4

Lag results from the speed of light limitation, and the processing speed of network protocol translation and switching in intermediate networking devices and at end points. From yours and your players' point of view, these are invariant factors. Game that deal effectively with lag do so by adjusting player perception of the impacts of lag. One example is in ...


4

To complement Anko's answer, you can change a bit your game design by adding the consequence of the failed obstacle after the failure, for instance, a failed jump results in landing in a puddle of mud which disqualifies the player. This way the other player notices the failure by seeing the other fall in the mud, while the player who fails sees it right ...


3

OpenGL never updates the screen, technically. There is a window system API that is separate from GL (e.g. GLX, WGL, CGL, EGL) that does this. Buffer swaps using these APIs generally implicitly invoke glFlush (...) but in some implementations (e.g. the GDI rasterizer on Windows) it does a full glFinish (...):       *On the left ...


3

Any drawing API function called from the CPU will be submitted to the GPU command ring buffer to be executed later by the GPU. This means that OpenGL functions are mostly non-blocking functions. So the CPU and the GPU will be working in parallel. The most important thing to note is that your application can be CPU or GPU bound. once you call glFinish the ...


3

Prediction is the way to go. It still works with 360° movement. All Quake games use it for example. The thing with prediction is that it fails as soon as the direction of movement of a predicted object changes (significantly). If this happens very frequently, prediction can't help you much. There is no other "magic" to fix latency, other than trying to ...


2

I have an idea of where the jittering comes from with vSync and triple buffering. The easiest way to show this is visually. The first example would be 30fps with a 60hz refresh rate vSynced with Double buffering. The pipes are new frames and periods are duplicated frames. |.|.|.|.|.|.|.|.|. This gives an even ~33ms between each new frame, which makes it ...


2

It adds latency because you've got 3 buffers involved instead of 2, so it takes one more frame for your rendered image to get to the screen. I have no idea what kind of "jitter" Carmack is talking about here, though. EDIT Maybe, just maybe, this could make sense in a highly variable framerate context: frames rendered with a given delta-time but displayed ...


2

The general gist is that you have two concepts of "state". Local state (your client) Ghost state (the server) You take input from your client, and update your local client state (and send this to the server). You then "predict" what happens to everyone else, assuming some amount of spatial consistency to last frame. When you get information from the ...


1

I would suggest first reading this great article about networking. It explains fairly well the kind of lockstep issues that you are experiencing. Here is a great series of articles explaining fast-paced networking. These are actually the same techniques that I employ in my own game engine. Now I cannot suggest one solution over another for your exact ...


1

Is it that important for the local player to know the exact position of the remote player's death? Let's say the remote player couldn't jump over one of your obstacles, and thus died. The dead player would see their death immediately, and would continue from the location of the accident. Nothing magical here. The local player (the one still alive and ...


1

I assume you're familiar with this experiment? Essentially John Carmack was doing something similar, recording the screen and timing pixels sent to the screen. He found that a good deal of the latency came from the screen. Other factors were the input delay from the keyboard, video drivers and or course the execution of the program itself.


1

You don't need to correct the errors on the client right away. If you interpolate the current client info with the incoming server info, the client info will converge to the server info in the next few frames. Since you are expecting the server info arrival to be less granular than the client update, when some info arrive at the client it will have enough ...


1

Is it totally necessary to manage reload times server side? Often the simplest way to do this is on the client side for both fairness and responsiveness. I'm no expert but what I would predict is that the current system encourages spamming and the server has to check whether each request is valid before discarding it, taking up more processing power. ...


1

Latency is not only about distance but about the player's connection speed, and the quality of their ISP's infrastructure, and that of the host of the server, and the traffic on the network. So, you could theoretically balance things out by locating a server at the midpoint, but I expect the benefit from that would be dwarved by other factors. You're usually ...


1

I have a few suggestions : Shouldn't you handle network updates on every frame ? What's your status of GameTime.IsRunningSlowly ? Did you try to profile your application ? Here are some links for you : The Indiefreaks Game Profiler for Xna is here! this one might be of interest What Are Some Good .NET Profilers? Plus, on Visual Studio you have Menu ...



Only top voted, non community-wiki answers of a minimum length are eligible