Beta Testing 2.09

[nbohr1more 2239]

Hmm...

While I don't see any performance regression in standard stencil mode, soft shadows with stencil

seems to have regressed here.

I barely use that mode anymore but it used to be higher performance than shadow maps...

Can anyone confirm?

[lowenz 612]

Suggestion/Request: we already have "144" as a dedicated FPS limit (for 144 Hz monitors), can you add "75" as another one? Thanks!

 

60

70 -> 75

80

90

100

110

120

130

140 -> 144

150

etc.

 

G-Sync (compatible) issue (low performance value after loading a savegame) still is there.

Press ESC, stand by in the menu screen for some seconds, return to the game and the framerate is alright.

Or move around a little.

Edited January 18 by lowenz

[stgatilov 1319]

2 hours ago, lowenz said:

Suggestion/Request: we already have "144" as a dedicated FPS limit (for 144 Hz monitors), can you add "75" as another one? Thanks!

You can set value 144 via console. but I don't think it will give you 144 FPS.

There is some place in the main loop, which ensure that at least 1000 / 144 milliseconds have passed since last time we have been here. The real FPS is usually lower than this cap.

[lowenz 612]

No problem about that, it's just about coherency of the FPS limiter option in the menu.

144 is already there, the only other common value missing is 75.

Edited January 18 by lowenz

[AluminumHaste 1084]

How about we just do this instead:

 

 

 

[lowenz 612]

It would be perfect

[cabalistic 861]

Really? I feel that would be pretty stupid, honestly... The fps cap is there so your GPU doesn't run amok in the menu and other lightweight scenes, or to keep a more stable average FPS. There is absolutely no use case to select every value between 30 and 300, so a slider just isn't the right tool, imho. There are only a few select values that actually make sense.

[nbohr1more 2239]

The only thing I think we should do is set the max to 300.

Physics gets out-of-hand above that:

https://bugs.thedarkmod.com/view.php?id=5464

 

[AluminumHaste 1084]

Ok, I'll leave it as is. To be clear, I set the steps to be "5" in the slider in the gui file, but it's ignoring that.

[lowenz 612]

2 hours ago, cabalistic said:

Really? I feel that would be pretty stupid, honestly... The fps cap is there so your GPU doesn't run amok in the menu and other lightweight scenes, or to keep a more stable average FPS. There is absolutely no use case to select every value between 30 and 300, so a slider just isn't the right tool, imho. There are only a few select values that actually make sense.

But the selected value doesn't (can't?) reflect the actual value as stgatilov says, so a slider is a more adaptive solution.

If I want adaptive sync on a 75 Hz monitor I must limit the frametime to 1/74 *actual* seconds, not a "75" nominal value.

Edited January 18 by lowenz

[MirceaKitsune 260]

2 hours ago, nbohr1more said:

The only thing I think we should do is set the max to 300.

Physics gets out-of-hand above that:

https://bugs.thedarkmod.com/view.php?id=5464

 

Thought those bugs were fixed a while ago, hope that can be solved. If there should be a hard limit, I think that should be 1000 honestly: That would allow one frame per millisecond, which is where there may be a structural code limitation if going beyond. Also there will probably never be a monitor that runs at 1000 Hz in the history of the world, at least not for personal computers... the eye would not pick up on anything that fast anyway.

[AluminumHaste 1084]

Dude, don't.

We already have 360hz displays and nvidia showed off a 1700hz display back in 2016.

 

 

 

[AluminumHaste 1084]

And yeah, some games and some monitors running freesync (like mine), don't use freesync on anything AT or OVER the cap.

For example, if my game is running at 144 fps, I don't get freesync, but between 30-143 fps I do.

Now, what happens is that I get the occasional frame drop to below 144 fps and it stutters. If I keep it at 143 fps, it's butter smooth, even when it drops lower.

 

[lowenz 612]

That's exactly the point of having a slider.

[MirceaKitsune 260]

1 hour ago, AluminumHaste said:

Dude, don't.

We already have 360hz displays and nvidia showed off a 1700hz display back in 2016.

 

Huh, never knew that. In 2016 I would have thought only NASA may have 1000 Hz screens. Yeah ideally there can be no limitation, but I'm not sure to what extent the system can allow that... great work was done modernizing the engine though so it's hopefully not impossible.

[HMart 343]

Personally I have a 165hz monitor and I set it to 120hz, why you may ask, because most old games can't go past 60fps without something breaking and most modern games that can run at above 60fps, are to heavy for my modest GPU to constantly run at 165fps or above, to take full advantage of the fast refresh rate. Plus imo is a waste of energy, 120hz is good enough for me.

Edited January 18 by HMart

[nbohr1more 2239]

23 hours ago, nbohr1more said:

Hmm...

While I don't see any performance regression in standard stencil mode, soft shadows with stencil

seems to have regressed here.

I barely use that mode anymore but it used to be higher performance than shadow maps...

Can anyone confirm?

OK, I went back to 2.07 and it is the same. RTTC v1 is just super heavy on Soft Stencil Shadows mode. ( 13FPS ... )

I will update to 2.08 and confirm further but I think this is pretty definitive.

Edit: Yep. 2.08 is the same. No regression (phew).

[AluminumHaste 1084]

Something that has been broken or never worked, is skyboxes turning black when using either g_stopTime 1, or using the jitter option for screenshot command (screenshot <width><height><samples>).

 

https://bugs.thedarkmod.com/view.php?id=5494

 

I don't expect it to get fixed, but I've brought it up before in passing, but I guess it's time to make a bugtracker for it.

Here is a 32 sampled screenshot, skybox turns black

[nbohr1more 2239]

On 1/19/2021 at 9:38 AM, AluminumHaste said:

Something that has been broken or never worked, is skyboxes turning black when using either g_stopTime 1, or using the jitter option for screenshot command (screenshot <width><height><samples>).

 

https://bugs.thedarkmod.com/view.php?id=5494

 

I don't expect it to get fixed, but I've brought it up before in passing, but I guess it's time to make a bugtracker for it.

Here is a 32 sampled screenshot, skybox turns black

I think this happens because the "hacked view" for portalsky relies on "shake angle" and Player.cpp disables "calculate shake" during g_stopTime:

 

if ( !g_stopTime.GetBool() ) {

UpdateAnimation();

Present();

UpdateDamageEffects();

LinkCombat();

playerView.CalculateShake();

}

Maybe just add an "else { playerView.CalculateShake(); }" there?

Edit: Nope, there must be something more. I fear that there may need to be a skybox specific update animation routine to make this work...

[MirceaKitsune 260]

I just remembered an audio bug I experienced which seems to affect some Linux users. There's an opportunity to fix it in 2.09 which can be done by changing an OpenAL default. I posted a thread about it a while ago:

Essentially we might want to default "period_size = 64" or something that's under 256. A higher OpenAL period size can cause lag when the game starts with sound only playing in interruptions, until a few seconds or minutes later when it finally stops. I don't know if lower end audio boards might have issues with a low value however so this should be investigated first.

[stgatilov 1319]

beta209-04 is available.

Changelog is provided in its usual place.
Use tdm_installer to get the new version, and don't forget to check "Get custom version".

[grayman 2982]

Would it be possible for each new version to show which version it is?

"TDM 2.09-beta04/64" is more informative than "TDM 2.09/64" on the main menu.

Thanks.

[stgatilov 1319]

13 minutes ago, grayman said:

Would it be possible for each new version to show which version it is?
"TDM 2.09-beta04/64" is more informative than "TDM 2.09/64" on the main menu.

Hardly possible.

The name is only set in tdm_installer. Right now we bump some constant manually after every official release, so that the game could show 2.08 or 2.09 correctly. I don't see any solution for showing beta build, except for adding another constant for it... in which case I'll most likely occasionally forget to update it, so it won't be very reliable

Right now you can open game console and see revision of source code SVN in its bottom-right corner. Then you can go to changelog and see which beta build it is.

Or you can start tdm_installer, click "custom version", and go to version selection page. In most cases it should show the name of the version which you installed last in the top field. And there is nothing wrong in updating to the version you already have (except that you'll probably want to save your config).

[grayman 2982]

Or I can just remain confused. The normal beta tester shouldn't have to follow "check this, then check that" instructions.

Sorry it's not a simple solution, as in "go through a completely new code path".

 

[nbohr1more 2239]

I find the TDM installer to be quite easy:

Just select custom build and choose your beta version.

This probably should be pinned at the top of the thread.