ZDaemon Forum Index ZDaemon
Client/Server DOOM
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Uncapped is lagging a frame behind AND server unfairness

 
Post new topic   Reply to topic    ZDaemon Forum Index -> Unconfirmed Bugs
View previous topic :: View next topic  
Author Message
Looper
has entered the game!


Joined: 05 Apr 2020

PostPosted: Thu Aug 05, 2021 11:42 pm    Post subject: Uncapped is lagging a frame behind AND server unfairness Reply with quote

Hello,

I think I've finally figured it out what's the deal with "server advantage" vs "server disadvantage".

At times, uncapped is interpolating the frames 'bad way' instead of good way. What I mean is:

100th ENGINE FRAME. Interpolation happens from 99th frame to 100th frame. This means UNCAPPED is showing every thing 1/35th of a second too slow. It shouldn't do that, it should predict what's gonna happen, since it should know it already as the packet is sent anyways. It may cause a bit more 'warping' in the screen if you get hit by opponent, but at least your reaction times are not 1/35 of a second too slow.

When that 'laggy uncapped' happens, it is better to use CAPPED (lol) to have faster reaction times. I've seen it working as intended(?) that there is no such a delay.

Second thing:
by luck, you either get PLAYER1 advantage versus PLAYER2 disadvantage.

It's the old story: when Player1 shoots at Player2 exactly at 100th engine frame, Player2's position is taken from 99th frame because Player1's states/actions get updated first, so the sprite is 'lagging' behind a bit in the vision. (At least this is the case in vanilla Doom. I can confirm this when building a demo frame by frame or when a player teleports/respawns in a deathmatch).

The result of these two mean that:
You either have 1+1 = 2 frames advantage in reaction times OR if the luck is the opposite, you get 1-1 = 0 frame advantage in reaction times. That's total of 57 ms in reaction times when you have 'server advantage'.

Now the funny thing is that when you compare TWO DIFFERENT MATCHES, it maybe so that you had +2 frame ADVANTAGE in the first match, but 2 frame DISADVANTAGE in the second match: end result difference is FOUR (4) difference between those two matches. So when you compare the results of two matches, there can be a whopping 114 ms reaction time difference.

The combination of these two things make it absolutely 'hilarious' when you compare two matches at times. Sometimes you beat your opponent so easily, but at times it seems like your opponent have faster reaction times than what humans are capable of having (according to the Olympics rule: no under 100 ms reaction times are possible.)
Back to top
View user's profile Send private message
Looper
has entered the game!


Joined: 05 Apr 2020

PostPosted: Fri Aug 06, 2021 12:10 am    Post subject: Reply with quote

Proof that the uncapped lags behind a frame:
https://www.youtube.com/watch?v=9v2bdIkTL5A

Here I run a hallway straight forward (straferun), but at the same time I toggle between UNCAPPED/CAPPED very fast. Watch the video frame by frame (by stopping the video and pressing , or . keys).

If you move the video forwards frame by frame, you will see that the player moves BACKWARDS at times because of perfect timing catching the broken uncapped in action. When vid_uncapped_fps is "True", the screen warps to the wrong direction on rare cases.
Back to top
View user's profile Send private message
Krawa
There is a limit


Joined: 23 Nov 2008
Location: #SDA

PostPosted: Fri Aug 13, 2021 4:16 pm    Post subject: Reply with quote

Hi there,

For the first thing:
The physics of the engine, calculating damage, getting input values from mouse and keyboard, etc. run each tick on the engine.
1 tick is 1000 ms / 35 (fps) ≈ 28.6 ms
So that's "real time" each tick.
Uncapped interpolation can't go to "future", because the input values are not there. So interpolation uses the fractal time of the last tick.
That means the view is somewhere between 0 and 28.6 ms delayed, depending of the timing pattern (not always 1 full tick, in average half a tick).

The diagram below shows the timing:
red: capped 35 fps
blue: uncapped 60 fps
green: delay of 3 ticks as reference e.g. the time between pressing fire SSG and damage calculation of the SSG (Single Player, no discussion about ping delay here).

So I would say:
Use capped if
- you want be sure your view is exactly tick related.
- you want to be closer to the oldschool Doom spirit.

Use uncapped if
- you prefer the smoother view.
- getting "stressed" or "getting headache" over time of the "choppy" view in capped.
- you can't really see/feel a difference between SSG firing and damage (Single Player).
- you feel better with uncapped aiming (it's easier to follow your target).

Of course it's taste of matter what you prefer.
Besides of all that theory give different settings a try to see what feels better for you.




For second thing:

That needs deeper investigations.
Back to top
View user's profile Send private message Send e-mail
Looper
has entered the game!


Joined: 05 Apr 2020

PostPosted: Sat Aug 14, 2021 6:48 am    Post subject: Reply with quote

Krawa wrote:
Hi there,

Uncapped interpolation can't go to "future", because the input values are not there. So interpolation uses the fractal time of the last tick.


It can. It just needs to be done differently. For example, wait for the 'logic tic to happen' and only then implement the turning from the interpolated frames. Now the problem is that:
1. You turn and shoot.
2. Your aim is perfect
3. Shot misses because you turned more than what you really turned.

This happens because the uncapped shows that you aimed perfect, but the logic says you turned a lot more, causing you to turn more. It is more severe the higher your FPS/HZ is (video only 60 fps). It happens way too often and it is annoying. The odds for that happening is related to the 1/35 second thing, meaning you aim wrong even with perfect aiming. Even the timing of the SSG (the visual that the SSG shoots in your screen) is affected beause of this, I don't think it is synchronized perfectly. Sometimes you get the shot timing correctly, sometimes not. Sometimes you get the turn correctly, sometimes now.

Check this video for example:
https://www.youtube.com/watch?v=l1EEtui2hgc

The very first shot in the video, check it frame by frame. The shot is not even remotely close to the point where you aim. In my opinion, it would be better that the aiming was taken from the interpolation, so the interpolation would create 'fake logic tics', so it wouldnt lag behind, and every 1/35th of a second it passed them as real logic tics. Then there would be no delay and it would be perfectly matched with the visuals. Well, there would be a delay from the 'press mouse' and then some 0-28.6ms delay till the fire command is taken, hmm. Seems like it is not possible to fix this issue.... well, maybe I use toggle capped/uncapped. When I need high reaction/fast turning, I use capped, otherwise uncapped.



The server unfairness is shown here pretty good (video taken during gameplay, not from replay) https://youtu.be/dF79Dx4--Ds?t=402

The shots that make the bullet counts from 142 -> 141 and 141 -> 140 are both hits, even though the first shot is too much off, especially when you consider that the chaingun had NO SPRAY. The game draws the spritetes 1 game logic delayed for the disadvantageous player (in this case me), another 1/35th of a second delay in the reaction times comes from the uncapped.
Back to top
View user's profile Send private message
Looper
has entered the game!


Joined: 05 Apr 2020

PostPosted: Sat Aug 14, 2021 6:59 am    Post subject: Reply with quote

Hmm, is this the reason why the aiming was lagging one frame before? It fixes it in some sense, but causes other problems, heh.
Back to top
View user's profile Send private message
Looper
has entered the game!


Joined: 05 Apr 2020

PostPosted: Thu Aug 19, 2021 10:43 am    Post subject: Reply with quote

I just had a tiny realization.

Isn't it a bit strange that the weapon's "FIRE" animation is shown at the beginning of the interpolation? It means that the HUD's weapon animation is incorrect, it should be synchronized accordingly with the logic frames.

This fits perfectly with the 'feeling' players have had:
sometimes it feels like SSG is shooting faster than it should
sometimes the game feels faster than what it should be

Maybe it is because sometimes the weapon in HUD is correct, sometimes not, based on pure chance. The SSG really feels faster at times than other times, but it is impossible to capture it (to the video) because it is the response time of the SSG.

I don't know if this is related BUT:
sometimes when you play single-player, the game has like 5 second input lag (no joking, it is around 5 seconds), but sometimes it works as intended. I haven't seen any logic behind it what causes it. But I know it is not web browser behind the scenes affecting anything as it happens even when you have it closed.
Back to top
View user's profile Send private message
Looper
has entered the game!


Joined: 05 Apr 2020

PostPosted: Sat Aug 21, 2021 11:26 am    Post subject: Reply with quote

And here's the input lag I was talking about:
https://www.youtube.com/watch?v=2v0qy8vdnlQ

Interesting is that keyboard is not affect.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ZDaemon Forum Index -> Unconfirmed Bugs All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group