 |
So that's what's making the 2.06 console sluggish. |
 |
What is fps number we're talking about here? By moving mouse you mean player's looking around? |
 |
Yes, the player looking around (although, as I said, there's some extraneous oddities I noticed like the console for instance). The baseline FPS would be 60, above which I don't notice any difference. Even a five to ten dip to 50 though and the problem manifests. If you manage to bring the FPS down to 10-20, the problem becomes very noticeable. The movement input I talk about is generally, with lower FPS the player character feels much more sluggish to control when sidestepping or walking back, not really when walking forward. |
 |
Well, the time for console opening is definitely longer when you have lower FPS (on SVN). But I do not notice serious input problems on 20 FPS: it is still well playable. And the the fact that console opens in 1 sec instead of 330 ms is not a serious problem. |
|
|
Ok, when I noclip through the world in Debug version, I manage to reduce FPS to 6. Then I feel some input lag: about 1/3 of second. And console opening is very slow. On 1 FPS (NHAT debug noclipping) I clearly see that player's input takes effect 2-3 frames later than I do it. And console opening is painfully slow. Anyway, I do not notice anything like "tied to the game's framerate" as Spooks wrote. I see only two non-critical things which can be improved: 1. Open console quickly regardless of FPS. 2. Remove 2-3 frames input lag which is clearly present. By the way, I won't be surprised if the input lag is there "by design". Having a 1/30 lag on 60 FPS may give somewhat different feel to the game. Like watching a movie in 24 FPS seems more cooler for someone than in 60 FPS =) |
 |
To give some context here: due to the threaded frontend/backend split, game tics are now calculated simultaneously to the backend rendering the current frame. This means that all game tic updates (including input processing, I assume) will only take effect on the next frame. So there probably is indeed an input lag of 1 frame "by design". If you cap the frame rate at 60 fps, that would be about 16.7 ms. At 20 fps, it would be 50 ms. Is that the amount of lag we are talking about? For very low frame rates, it might even be close to a 2-frame lag, if your input arrives just at the moment that a game tic starts calculating, because then it'll only be seen in the next game tic, which gets active in the frame after that. I must admit, I didn't really think about this when I implemented the threading support. I'm personally not very sensitive to input lag and also mostly interested in the uncapped framerate. Unless there's another issue overlapping here, this may not have an easy fix. I'll have a look at the input handling and also at the BFG code base; perhaps some things can be moved around to make it more responsive. |
|
|
Speaking of input latency, I think it is worth looking into. If there is some clear problem which adds a frame, it may be fixed. But if there is nothing suspicious, then I don't think we really need to do anything. TDM is not an fast-action game, it is a very slow and steady game and input lag should not be a problem. I think the main reason why this lag is annoying is that mappers often need to noclip through the map, and then it gets bad. |
|
|
Comparing with BFG, even Doom 3 BFG has this exact same behaviour. And thinking about it again, even though we are one frame behind, technically with disabled multithreading we would still be a frame behind because user commands can only be processed before the next frame. So if there is such a noticeable change, there might be something else going on. |
|
|
Off topic to this bug, but do we want to limit rendering when outside of any area? Skip dynamic models, models smaller than X units, postprocessing, etc? I do noclip often on my side and would find that useful |
|
|
I think there IS another issue overlapping here, that being 0004663. With that said I'm not too fussed over player movement input lag, but mouselook lag is a downer that would possibly hamper precise actions such as aiming the bow. Speaking of precise actions, I've not even tested whether lockpicking would be harder on lower frames with this issue, but I assume it would be. |
|
|
I have noticed that opening console takes long time on low FPS only with "com_fixedTic 0". With "com_fixedTic 1", console opens almost instantly. As for the mouse look, it seems that latency has increased from 1 frame to 2 frames. But if you try to aim bow at 5 FPS, you'll suffer anyway. |
 |
Is this a 2.06 blocker? Edit: Thread confirms that com_asyncInput cvar has no effect here. |
|
|
Blue_Pill's movement fixes have addressed much of this. Moved to 2.07 for further review. |
|
|
Superseded by 4768 |
|
|
nbohr1more, this cannot be duplicate of 4768. 0004768 covers only mouse in MAIN MENU, it does not affect in-game controls at all. And this issue is clearly about mouse-look in-game, plus movement and whatever else. |
|
|
There may be a relationship between this and "true fullscreen" mode. Moving to 2.08. |
|
|
I think this is solved via 0004924 https://forums.thedarkmod.com/index.php?/topic/20173-limit-timestep/ The console is just as responsive to opening and closing at low FPS and movement tracks pretty well even with low FPS now. |
|
|
Closing until any further concerns are voiced. |
- Anonymous
