Beta Testing 2.08

[stgatilov 1126]

1 hour ago, nbohr1more said:

I had to set it manually on first run. I guess if I had restarted it would have self corrected?

Hmm... yes, perhaps you are right.
I had some weird blackness on the first test of the new beta, but could not reproduce it after that.

[duzenko 654]

38 minutes ago, stgatilov said:

Hmm... yes, perhaps you are right.
I had some weird blackness on the first test of the new beta, but could not reproduce it after that.

That should explain it

@nbohr1more

No, multidraws aren't worth it the way I implemented

You need to clip to void to start getting 3% difference

It seems the driver is doing a good job batching draw calls already

Let's see how @cabalistic will do it in 2.08 but generally there is little chance to get capped by draw calls/driver in 2.08 already

[cabalistic 736]

1 hour ago, duzenko said:

That should explain it

@nbohr1more

No, multidraws aren't worth it the way I implemented

You need to clip to void to start getting 3% difference

It seems the driver is doing a good job batching draw calls already

Let's see how @cabalistic will do it in 2.08 but generally there is little chance to get capped by draw calls/driver in 2.08 already

Hm, actually draw calls are very clearly starving the GPU because the CPU overhead per draw call is way too high. It's just that, if you have com_smp enabled, it is almost completely hidden behind the fact that the frontend takes a very similar amount of CPU time. But since the frontend also has some clear potential for improvement (mainly stronger parallelization), optimizing the drawcall overhead is definitely worth our time But yeah, I think I know how to approach this, so let's postpone this after 2.08.

[duzenko 654]

13 hours ago, cabalistic said:

if you have com_smp enabled, it is almost completely hidden behind the fact that the frontend takes a very similar amount of CPU time

Well. my attempt was limited to depth stage only. But then, you probably want to use indirect drawing instead of seemingly redundant glMultiDrawElementsBaseVertex?

[peter_spy 1522]

When using the reloaddecls command, the console complains about errors in core packages now. It's harder to find errors in your work because of this. In 2.07 and previous versions, it only displayed errors in files that have been modified.

[stgatilov 1126]

21 minutes ago, peter_spy said:

When using the reloaddecls command, the console complains about errors in core packages now. It's harder to find errors in your work because of this. In 2.07 and previous versions, it only displayed errors in files that have been modified.

I believe the engine only differentiates between local files and files within pk4.

Do I understand you right that you want everything inside pk4 files to be considered "not changed" in all reload commands?

[peter_spy 1522]

It complains about a series of old unresolved errors that you can often see while loading FMs^. In 2.07 and earlier it didn't show that, I only saw errors of what I did wrong in my materials.

[stgatilov 1126]

There are four reload commands which check for timestamps:

• reloadDecls
• reloadImages
• reloadSounds
• reloadGuis

All of them check for timestamp, which means that files inside pk4 should not be reloaded (unless forced). That's how it works now, and how it worked in 2.07.
However, reloadDecls is the only command which explicitly checks for "zero" timestamp, and reloads decl in case of match. So in 2.07 they were not reloaded inside pk4 file, while in 2.08 they do reload due to the change 5042.

I think I will remove the explicit check for zero timestamp, and it would work as before.

[Abusimplea 168]

On playing 2.08 beta 5 with 64 bit color i noticed that the using-the-correct-lockpick highlight is somewhat too bright (like using an RGB multiplier):
 

[peter_spy 1522]

Couldn't reproduce that.

[stgatilov 1126]

18 hours ago, Abusimplea said:

On playing 2.08 beta 5 with 64 bit color i noticed that the using-the-correct-lockpick highlight is somewhat too bright (like using an RGB multiplier):

Post you config, please. Maybe with condump to avoid more questions.

[lowenz 600]

64 bits colour rendering is just beautiful ! It resolves the root problem of the colour banding! THANKS!

With Ambient Occlusion these 2 new features are visually projecting TDM in the future!

About the visual aspect, there's an old problem that maybe can now be solved (without using FBOResolution=2, it's so perfomance heavy  )

Tha antialiasing transparency problem! There's NO AA applied!

See the brazier iron parts aliasing

No AA:

AA 4x:

Any possibility to see this issues gone? Multisampling AA is way more forgiving than FBOresolution=2 (supersampling/downsampling).....

Edited May 4, 2020 by lowenz

[lowenz 600]

Borderless mode issue

AMD only (Catalyst 20.4.2)

Edited May 4, 2020 by lowenz

[duzenko 654]

23 minutes ago, lowenz said:

Borderless mode issue

AMD only (Catalyst 20.4.2)

"Borderless/fullscreen" voodoo magic returns now on AMD

Quote

They stab it with their steely knives
But they just can't kill the beast

 

[lowenz 600]

Can we have back the SSAO debug ouput?

Cause there's some problems with level 2 and 3 (no issue with SSAO "low" ) : http://www.mediafire.com/file/6666sy2lstmpzo8/Thedarkmodx64_2020_05_04_13_43_08_413-1.mkv/file (MKV - H265 - 1080p)

See those blocks moving around when I'm rotating......

Edited May 4, 2020 by lowenz

[cabalistic 736]

What do you mean, have it back? r_showfbo 4 has not been disabled...

[lowenz 600]

Pardon! Testing now!

[lowenz 600]

* Why r_showFBO 5 crashes the game?

* Here's the SSAO issue:

1) Low:

2) Medium/High:

[cabalistic 736]

I'm not seeing it:

I'll need your darkmod.cfg and console dump.

11 minutes ago, lowenz said:

* Why r_showFBO 5 crashes the game?

Probably because you have bloom deactivated? Although obviously it still shouldn't crash.

[lowenz 600]

Of course you don't see it, in "Low" mode there's no issue.

The issue is only with "Medium" and "High". You don't see the blocks in the SECOND screenshot?

Take a look to the wall and the rooftops.

 

Thanks for the tip about the bloom (it's unrelated to SSAO, just asking).

Edited May 4, 2020 by lowenz

[lowenz 600]

SSAO parameters are @default.

Here's the darkmod.cfg: https://pastebin.com/YAYx3izQ

[cabalistic 736]

 

20 minutes ago, lowenz said:

Of course you don't see it, in "Low" mode there's no issue.

The issue is only with "Medium" and "High". You don't see the blocks in the SECOND screenshot?

Take a look to the wall and the rooftops.

 

Thanks for the tip about the bloom (it's unrelated to SSAO, just asking).

I meant, I don't have the issue and cannot reproduce it, my shot is with ssao level 3. Unfortunately, even with your darkmod.cfg it doesn't happen for me (and yes, I have set r_ssao to 2 and 3, respectively). Are there any other AMD users who can reproduce this?

[lowenz 600]

You're right, tested now on my 1050 Ti and there's no issue! It's AMD-only......

[stgatilov 1126]

31 minutes ago, cabalistic said:

Are there any other AMD users who can reproduce this?

Yes, I reproduce it on RX 550.

Any plan?

[cabalistic 736]

6 minutes ago, stgatilov said:

Yes, I reproduce it on RX 550.

Any plan?

Can you try to play with the random factor in ssao.frag.glsl (line 168, randomPatternRotationAngle) and e.g. modify the factor 3 at the beginning, see if that makes any difference to the pattern (even if it doesn't immediately fix it)? This is one aspect from the original Nvidia implementation that I've had trouble with before. If the patterns are caused by that, we might need to find a different random pattern or even reintroduce a noise texture to get consistent behaviour on all vendors...

If that's not it, you can try to change line 74 to 'const int u_maxMipLevel = 0;' as that will disable the most immediate difference between ssao levels 1 and 2/3.

If it's not that either, then it's going to be more tricky since I can't reproduce it...