Beta Testing 2.08

[duzenko]

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?

[Guest]

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]

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?

[Guest]

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]

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.

[Oktokolo]

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):
 

[Guest]

Couldn't reproduce that.

[stgatilov]

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]

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]

Borderless mode issue

AMD only (Catalyst 20.4.2)

Edited May 4, 2020 by lowenz

[duzenko]

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]

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]

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

[lowenz]

Pardon! Testing now!

[lowenz]

* Why r_showFBO 5 crashes the game?

* Here's the SSAO issue:

1) Low:

2) Medium/High:

[cabalistic]

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]

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]

SSAO parameters are @default.

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

[cabalistic]

 

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]

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

[stgatilov]

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]

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...

[stgatilov]

40 minutes ago, cabalistic said:

Can you try to play with the random factor in ssao.frag.glsl (line 168, randomPatternRotationAngle)

Does not help. I even tried to replace this pseudorandom with another one which I used for dither yesterday (sin + fract), it looks pretty the same.

Quote

If that's not it, you can try to change line 74 to 'const int u_maxMipLevel = 0;'

This fixes the problem for me.

I see no error messages in debug context, no errors when reloading programs. The issue happens on objects which are far enough from the player, so I guess mipmapping is the culprit.

Should I capture a trace and look at GL states during SSAO rendering?

[cabalistic]

1 minute ago, stgatilov said:

Does not help. I even tried to replace this pseudorandom with another one which I used for dither yesterday (sin + fract), it looks pretty the same.

This fixes the problem for me.

I see no error messages in debug context, no errors when reloading programs. The issue happens on objects which are far enough from the player, so I guess mipmapping is the culprit.

Should I capture a trace and look at GL states during SSAO rendering?

Thanks! Yeah, that might be a good start. I'll also try to think about what could possibly be going wrong and what else we could test to narrow it down.

One thing you might try: in the shader, after the #fidef block from line 80 to 84, you could insert another line 'mipLevel = 1;'. This would force the shader to always look into mip level 1, and you could go through the levels individually to see if there's a specific one that looks obviously wrong, or if they are all bad.

[nbohr1more]

6 hours ago, lowenz said:

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).....

This is not a transparency issue. The brazier is all tris:

https://imgur.com/StbyBJW

This probably just your MSAA algorithm falling down and not filtering at certain angles.

All vendors have these issues where MSAA doesn't cover all angles.

This is another good argument for adding an FXAA mode to TDM.

Incidentally, I couldn't force FXAA via Nvidia drivers in TDM until I changed my desktop to Metacity + Compton (Linux Mint Tessa).

Finally, why r_fboResolution 2? The most you should need is r_fboResolution 1.5. ?

Also, how does forcing SSAA in your driver compare performance wise?