Beta Testing 2.06

[duzenko]

 

Is this what's causing the farking stutter?

 

If so, why have I been banging my head against the wall about this these past few weeks, when it was known to others that movement framerate was tinkered with way back in September?

 

Argh!!!

http://forums.thedarkmod.com/topic/19162-beta-testing-206/page-23?do=findComment&comment=418033

[peter_spy]

Well, well.

 

I tested a WIP on 2.05, and here I am crossing a carpeted floor and the forward movement stutters.

 

So what I've been experiencing has been there since 2.05, and it's possible that what others have been seeing is either the same thing, or something different, which I haven't experienced.

 

I've been trying to reproduce that stutter in St. Lucia run on 2.05 and I wasn't able to. The ground can be uneven and everything is still smooth.

[Bikerdude]

I tested a WIP on 2.05, and here I am crossing a carpeted floor and the forward movement stutters.

If by stutter you mean sorta stumbles over the small object, I have seen that for years. Its why I make all small static floor based objects non-solid - so neither the Ai or the player are affected by them.

Edited March 8, 2018 by Bikerdude

[Springheel]

The stuttering I experienced was not from stumbling over slopes or objects. It FELT like that experience, but it happened multiple times in perfectly flat areas.

[grayman]

Same here. Flat floor, no objects.

[Bikerdude]

Just discovered this weird bug, I dont think Ive seen this in 2.05 -

 

https://www.youtube.com/watch?v=C3Cror1rgVY&

Edited March 8, 2018 by Bikerdude

[peter_spy]

If you mean stretching, that's not a bug, you can see that pincusion distortion in 2.05 for every FOV above something like 70 or 75. It's not even subtle. The engine just doesn't seem to use proper correction for 16:9 ratio (separate V and H FOV ratio values).

[Blue_Pill]

Occasionally skipped movement updates (if I understood the bugtracker comment correctly) could indeed cause stuttering. Since it seems to be a workaround for sliding down curbs, I'll see if I can find another option. A simple one might be adding a tiny 'mercy' delay (e.g. 16ms) to the slope check, but I'll take a more extensive look at it on Monday.

[peter_spy]

I can't say I understand specifics of that solution, but you shouldn't have to make changes in the engine to facilitate movement. It's the mapper or modeler, who is responsible for that, either by turning off collision for smaller objects, like Biker said, or by making proper collision for a model, whether it's stairs, ground or anything else. Also, most people play games with Vsync on, and from what I understand from that bugtracker thread, you made a workaround for really high FPS like 300, so with Vsync off.

Edited March 9, 2018 by Judith

[duzenko]

Occasionally skipped movement updates (if I understood the bugtracker comment correctly) could indeed cause stuttering. Since it seems to be a workaround for sliding down curbs, I'll see if I can find another option. A simple one might be adding a tiny 'mercy' delay (e.g. 16ms) to the slope check, but I'll take a more extensive look at it on Monday.

In retrospective capping movement fps is indeed a regrettable choice. At that point I had spent maybe a week dancing on that damn curb and it was more like gesture of despair.

@NB, what was that mission name where guards are searching for you from time zero? Alchemist? The problem was the player not able to walk through the curb because the slope would just bounce him back off at high fps and low movement deltas.

The movement code is a a little too hard a nut for me to crack.

An alternative, possibly simpler workaround could be to not limit movement fps when vsync is on. (Fingers crossed for you 120+Hz guys). More like a new cvar 0 = never limit, 1 = limit if not vsync (default), 2 = always limit.

[duzenko]

It's the mapper or modeler, who is responsible for that, either by turning off collision for smaller objects, like Biker said, or by making proper collision for a model, whether it's stairs, ground or anything else.

In ideal world yeah, but in TDM we can't just say hey, anyone put a curb in your map N years ago? You fix them now for a new feature you don't even care about. Unless the curb is a shared resource and we could fix it on the assets svn with one blow.

[cabalistic]

Hm, shouldn't movement depend on the gametic rate, not on the fps? Because in that case, it shouldn't matter whether you run 60 fps or 300, as long as the gametic update rate is stable.

[peter_spy]

In ideal world yeah, but in TDM we can't just say hey, anyone put a curb in your map N years ago? You fix them now for a new feature you don't even care about. Unless the curb is a shared resource and we could fix it on the assets svn with one blow.

 

Isn't that the other way around here, actually? Everything was fine untill we started discussing high framerates like 300 fps. But that's where most games break, noone is introducing fixes for that in other games. Most miltiplatform games are 30-60 fps locked on consoles and PCs, multiplayer titles have caps for like 120 fps on PCs, but that's it. If I understand this correctly, there was no need to introduce this fix in a first place.

Edited March 10, 2018 by Judith

[Blue_Pill]

The current movement code seems to work good in 60FPS (besides the stutter, which probably is caused by the workaround for curbs on high framerates).

 

I've done some testing without the movement frame limit.

In fact, after commenting out the slope detection (search for "%i:steep\n" in Physics_Player.cpp), I did not longer slide off the curb in TD4:Alchemist. A tiny delay in the slope code after a step up (search for "performing step up" in Physics_Player.cpp) might fix the issue without affecting gameplay (ideally leaving normal framerates completely untouched).

I suspect the problem is that since the step up velocity is smaller at higher framerates, it takes more frames to get up the curb. Once the player has reached the edge of the curb, the ground check thinks the player is on a slope and slides off the curb again.

The relevant console and log messages can be enabled with g_debugMove on 1 and LogClass_Movement (Info).

[Springheel]

I was testing last night and was getting constant stutters walking back and forth on a regular floor. It seemed like it was corresponding to sudden drops of FPS. Normally the fps was bouncing around like mad* in the 50-60 range, but occasionally I would see a "3" pop up in the tens column for a fraction of a second. That _seemed_ to correspond to the stutters though it was hard to say. If it happens again I'll try recording it.

 

 

 

*This is something new in 2.06. In 2.05, if vertical sync was on, FPS would bounce only 1 fps (from 59-60 and back, for example). In 2.06, it seems to bounce around in a much larger range under the same conditions.

[duzenko]

If I understand this correctly, there was no need to introduce this fix in a first place.

Which fix again? Uncapped fps?

No problem, no fixes from me until Judith pre-approves it. (or voted in on this forum).

[Blue_Pill]

I was testing last night and was getting constant stutters walking back and forth on a regular floor. It seemed like it was corresponding to sudden drops of FPS. Normally the fps was bouncing around like mad* in the 50-60 range, but occasionally I would see a "3" pop up in the tens column for a fraction of a second. That _seemed_ to correspond to the stutters though it was hard to say. If it happens again I'll try recording it.

The 63fps (~ 15.9ms) shown might be slightly above (below) the 62.5fps (16ms) of USERCMD_MSEC, causing it to skip a movement frame.

//idPhysics_Player::WalkMove (Physics_Player.cpp) : 906
    moveTimeAccum += frametime;
    while ( moveTimeAccum < MS2SEC( USERCMD_MSEC ) ) {
        return;
    }

Edited March 10, 2018 by Blue_Pill

[Springheel]

*This is something new in 2.06. In 2.05, if vertical sync was on, FPS would bounce only 1 fps (from 59-60 and back, for example). In 2.06, it seems to bounce around in a much larger range under the same conditions.

 

 

Here's an example of the difference. With vsync on in 2.05, the FPS is nearly constant, with a flicker never more than 1. (in this case, 29-30)

 

In 2.06 (I slowed it down to better see the range) the value is never constant. It jumps around from 70 to 49 in that spot. This is quite different behaviour from 2.05 and might be related to the movement stuttering.

 

[peter_spy]

Which fix again? Uncapped fps?

No problem, no fixes from me until Judith pre-approves it. (or voted in on this forum).

 

http://bugs.thedarkmod.com/view.php?id=4493 first comment.

 

No need to get aggressive, TDM Team was always careful not to break stuff like older missions. That's why I'm surprised that this fix was introduced so fast and without much consideration.

[AluminumHaste]

What, my comment in that bug report?

[New Horizon]

What are the default tdm_lg_interleave settings these days?

 

Having tdm_lg_interleave set to anything beyond 2 always caused stutter for me and very similar deep dips in fps. As long as I kept tdm_lg_interleave set to 2, I only saw the 1fps dip. I thought that issue had been smoothed out somewhere along the way, but this looks quite suspicious.

[Blue_Pill]

Uploaded a svn diff file in the movement stutter issue that removes the movement frame lock and fixes moving onto the curb in TD4: Alchemist by adding a 250ms delay to sliding after a step up. Frametimes >= 16ms (up to 62.5fps) will be untouched by the curb workaround.

 

I could not reproduce the head getting stuck issue in Swing mentioned here, but that doesn't have to mean it's fixed.

 

Report back if this resolves the stutter, and of course if there are more frame rate related bugs.

[nbohr1more]

One thing I think I should point out is that Spring's latest example seems to have 2.06 with "EAX\EFX enabled"

compared to 2.05 where EAX is only available if you hack it externally so the performance profile is completely different.

 

For an Apples to Apples comparison, EAX would need to be disabled in 2.06.

 

Sound path finding can be quite expensive (ask Spooks about his woes with the church bell sapping FPS in King of Diamonds).

[Springheel]

Got a report of this on discord:

After updating to 2.06, "Some of the impact noises are being bleeped." "It's a boot, specifically it's the boot in the guard's chest in the guards quarters in Knighton Manor"

 

edit:

You know what? I'm not actually sure it's the boot. It could be something under said boot. I'm gonna try something...

Nope, it's one of the arrows under the boot.

Yeah I'm tossing the boot around by itself and nothing, it's when you try to extract the boot and it jangles around with stuff inside.

The only other physics objects in that chest are arrows.

Wasn't that missing shader sound supposed to be off by default?

For an Apples to Apples comparison, EAX would need to be disabled in 2.06.

 

 

I turned EAX off, but it didn't change anything that I could see. FPS still fluctuated significantly compared to 2.05.

[grayman]

The player probably had the play default sound cvar set to 1 before updating to 2.06