Jump to content
The Dark Mod Forums

Recommended Posts

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.

Link to post
Share on other sites
  • Replies 488
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

beta208-07 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update

beta208-06 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update

[Forgive me if this is the wrong place for this discussion.]   I've been beta testing two new FMs: JackFarmer's Hidden Hands: The Last Citadel, and The Painter's Wife. They are both large miss

Posted Images

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

Link to post
Share on other sites
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.

  • Like 1
Link to post
Share on other sites
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?

Link to post
Share on other sites

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.

Link to post
Share on other sites
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?

Link to post
Share on other sites

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.

  • Thanks 1
Link to post
Share on other sites
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.

Link to post
Share on other sites

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:

newjob-2020-05-04-10-25-25.jpg

AA 4x:

newjob-2020-05-04-10-25-35.jpg

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

Edited by lowenz
  • Like 1

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites

Borderless mode issue

AMD only (Catalyst 20.4.2)

Untitled.jpg

Edited by lowenz
  • Like 2

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites
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

 

  • Like 2
Link to post
Share on other sites

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 by lowenz

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites

Pardon! Testing now!

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites

* Why r_showFBO 5 crashes the game?

* Here's the SSAO issue:

1) Low:

stlucia-2020-05-04-14-02-52.jpg

2) Medium/High:

stlucia-2020-05-04-14-03-03.jpg

  • Like 1

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites

I'm not seeing it:

stlucia_2020-05-04_14_21_43.thumb.jpg.aa2c40194e0f3f15f73729a329e6e28c.jpg

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.

Link to post
Share on other sites

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 by lowenz

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites

 

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?

  • Like 1
Link to post
Share on other sites

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

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites
31 minutes ago, cabalistic said:

Are there any other AMD users who can reproduce this?

Yes, I reproduce it on RX 550.

Any plan?

Link to post
Share on other sites
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...

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...