Regarding "One Frame Thread Lag"

[Echo Black]

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.

---

[[TW]redeye]

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.

Originally Posted by Echo Black

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.

Originally Posted by Echo Black

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.

Originally Posted by Echo Black

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.

[ledurpy]

always wondered what this setting was for!

thanks devs for the input!

now i will turn it on

[Echo Black]

Many thanks for the thorough (and quick!) post. Far better than wading through incomplete theories and not knowing what to believe.

---

[PermenentMarker]

+1
Fantastic instructive and detailed post.

[defektive]

Very informative and well explained. Have a chocolate cookie, redeye.

[burninglegionx]

This info should be in the FAQ.

[Westernesse]

Lol, I was just discussing this with someone yesterday and decided to turn it off to see if it would help with with hit detection and did notice the performance hit.

Thanks for the dev input! Guess I'll turn it back on.

[Lavalampdrinker]

Amazing reply from the TWI team.

[DesiQ]

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?

[Mekhazzio]

Originally Posted by DesiQ

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

That's a correct response to it, though. It's a potential delay versus a potential framerate loss. You get to decide which you dislike more.

[[TW]redeye]

Glad I could help.

Originally Posted by DesiQ

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.

[Der Metzgermeister]

Many thanks. I wasn't sure at all what it done and couldn't find any concrete info.

[PsYcH0_Ch!cKeN]

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.

[fiftyone]

The first two posts in this thread need to be rendered in sync and added to the FAQ, Stickied .
No need to rename, we have the explanation.

Liked x 2.

[mattlach]

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

[[TW]redeye]

Originally Posted by mattlach

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)

Originally Posted by mattlach

I agree the name of the option sets a negative connotation to the feature. Something like "allow 1 frame render-ahead" sounds more positive

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.

[Proud_God]

Originally Posted by [TW]redeye

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.

[[TW]redeye]

Originally Posted by Proud_God

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.

There is, but it is negligible to the point that you are 'essentially' running single threaded.

[Proud_God]

I have 2 questions/ concerns:

1) if your game thread is consistently faster than your render thread, won't you be in the same situation with OFTL on as off, with the added downside that you are constantly 1 frame behind?

2) I suppose the client side hit detection uses the game thread to determine the game state. But, with OFTL on, won't that mean that it is more difficult to hit people, since you might be looking at a screen that is no longer current with regards to the game thread.
I seem to notice it is harder for me to hit enemies with OFTL on, which supports this.