• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

Regarding "One Frame Thread Lag"

Echo Black

Grizzled Veteran
Jul 14, 2011
294
340
With it on, would your client's view stay one frame behind the information you received from the server (such as extrapolated player positions based on momentum, etc.)? 'Cause I swear the feedback from my hits (like shooting at a wall) appear sooner with it OFF. One frame may look like little but if you average 60FPS, one frame = 16.6ms, which is quite a substantial delay to stay behind when you're shooting someone running in the distance using legacy UT netcode.

Perhaps I'm mistaken about what OFTL really does, and it's just a visual buffer thing with no negative consequences to netplay? I'd appreciate a technical post, as I searched this forum and all I found were guesses which are as a good as the one I have right now. ;)

I guess what I really mean to ask is, would playing with it on give you a less accurate idea of what is actually happening (even if by one frame?). If so, I will have to think twice before leaving it ON, despite it netting me a good 10 extra average FPS.

---
 
Last edited:
Ok, here goes. Since this comes up quite often, I'll try to be as detailed as possible.

First some background. The game runs essentially on 2 main threads - a game thread and a rendering thread. The game thread calculates all gameplay aspects such as shooting, hit registration, animation, IK, etc. The rendering thread calculates shadows, updates particle systems (such as smoke), and sends all the draw calls to the GPU for rendering.

Although for most parts the rendering thread can run on its own, it is not entirely independent of the game thread. The game thread "tells" the render thread where your camera is so that the rendering thread can draw the environment from your current location. Another example would be when you shoot, the game thread evaluates your mouse click, computes the ballistics, and if it hits a wall, it "tells" the render thread the location where it hit so that the render thread can draw a bullet impact decal at that location.

Because of this, the game thread needs to "talk" with the render thread. However, it cannot do so anytime it wants (effective threading simply doesn't work that way). So, it syncs from time to time, but otherwise goes about its own business. This sync time is usually at the end of a frame.

Now, let's assume that your game thread is running faster than your render thread. The game thread computes the Nth frame, sync happens, and then your render thread renders your Nth frame. While the Nth frame is being rendered, the game thread can compute your (N+1)th frame in parallel. By the time the (N+1)th frame is finished by the game thread, the Nth thread MAY or MAY NOT be finished by the rendering thread. This is where "One Frame Thread Lag" comes in. If OFTL is off, the game thread will STALL at this point, waiting for the render thread, resulting in a performance drop. But, if you play with OFTL turned on, it will allow the game thread to queue up the (N+1)th frame and start working on the (N+2)th frame immediately, and the render thread can pick up and render the (N+1)th frame once it has finished rendering the Nth frame. This gives you MORE PARALLELISM, and hence better performance. Keep in mind that this will only happen for one frame - your render thread will NOT keep falling behind more and more as your game progresses.

Now to answer your questions.

With it on, would your client's view stay one frame behind the information you received from the server (such as extrapolated player positions based on momentum, etc.)?
No. It is client side only.


One frame may look like little but if you average 60FPS, one frame = 16.6ms, which is quite a substantial delay to stay behind
To put matters into perspective, I quickly wrote up a code snippet to calculate the time it takes to double-click a mouse as fast as you can without moving. And, the avg. time for that is 13.6ms.

I guess what I really mean to ask is, would playing with it on give you a less accurate idea of what is actually happening (even if by one frame?). If so, I will have to think twice before leaving it ON, despite it netting me a good 10 extra average FPS.
This is a PC title and we like to give you as many options as possible to tweak the game to your liking. Note that most games will just have that on by default since it allows your game to run as fast as it can without any stalls. So, if you want to turn it off, you can. Just be aware of the performance implications. Hopefully, this post will give you a better idea of the pros and cons of this setting.

TL;DR Leave this setting on for better frame rates. It won't adversely affect your hit registration or give you a less accurate idea of what is going on in the game.
 
Upvote 0
Glad I could help.

I think the name of the option should be changed; you read the word 'lag' and your first reaction is, "Nothankyouverymuch!" How about Sync Parallel Threads?

That's a good point, and I have thought about this myself as well. I'm not sure if we'll be re-naming the setting, but adding more information about this in the game FAQ and elsewhere is a good idea.
 
Upvote 0
I find "one frame lag" to be a more honest name for it. I dislike it intensely as on my PC it actually causes more hitching and at the cost of a laggier mouse. Certainly if you're sitting on 60fps then that one frame of lag isn't so bad, but if your frame rate tends to sit lower than that (as mine does), the lag period starts to get unacceptably high, especially if you have other factors causing "input lag" like a monitor with a high processing time, a low polling mouse, or similar.
 
Upvote 0
Are there any cases where allowing the game thread to render ahead would cause the render thread - once it is ready - to render something that now is outdated compared to if it had been rendered without the feature enabled?

Also, in this case, why not just let the game thread go nuts and render as fast as it can asynchronously, and just let the render thread poll it for the most current data whenever it is ready to start the next frame? You'd think this would lead to the most up to date data being rendered on the screen.

Thanks for this explanation though, it helps a lot.

I agree the name of the option sets a negative connotation to the feature. Something like "allow 1 frame render-ahead" sounds more positive :p
 
Upvote 0
Are there any cases where allowing the game thread to render ahead would cause the render thread - once it is ready - to render something that now is outdated compared to if it had been rendered without the feature enabled?

Also, in this case, why not just let the game thread go nuts and render as fast as it can asynchronously, and just let the render thread poll it for the most current data whenever it is ready to start the next frame? You'd think this would lead to the most up to date data being rendered on the screen.
I'm not sure I understand your question perfectly, but I'll attempt to answer it the best I can. The game thread doesn't render, it just updates the state of everything in the game word. The render thread picks up the updated state from the game thread, and renders it.

Whatever the game thread updates, the render thread has to render within a finite amount of time (same frame if OFTL is off, or next frame if OFTL is on). The render thread cannot skip a frame and go to the latest because that'll make the game choppy. It also cannot lag behind too many frames as that will game the game feel laggy.

You can probably get away with being 2 or maybe 3 frames behind in certain games which aren't first person shooters. But being at least 1 thread behind is a good thing to ensure you use your cores effectively. Otherwise, you are basically running single-threaded! (since the game will only use one core at a time)

I agree the name of the option sets a negative connotation to the feature. Something like "allow 1 frame render-ahead" sounds more positive :p
That is why we've removed it from the options menu, and replaced it with the often requested DOF setting :). You can still turn it off in the INI if you wanted to, but for a casual user it is too important a setting to simply expose it in the settings menu with no way to properly convey what it does.
 
Upvote 0
But being at least 1 thread behind is a good thing to ensure you use your cores effectively. Otherwise, you are basically running single-threaded! (since the game will only use one core at a time)

I don't get this. Are you saying that with OFTL off there is no parallelism between the game- and render-thread? Because from your 1st post I got the impression that there was.
 
Upvote 0