stgatilov 1126 Posted May 2, 2020 Author Report Share Posted May 2, 2020 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. Quote Link to post Share on other sites
duzenko 654 Posted May 2, 2020 Report Share Posted May 2, 2020 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 Quote Link to post Share on other sites
cabalistic 736 Posted May 2, 2020 Report Share Posted May 2, 2020 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. 1 Quote Link to post Share on other sites
duzenko 654 Posted May 3, 2020 Report Share Posted May 3, 2020 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? Quote Link to post Share on other sites
peter_spy 1522 Posted May 3, 2020 Report Share Posted May 3, 2020 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. Quote Misc. assets for TDM Link to post Share on other sites
stgatilov 1126 Posted May 3, 2020 Author Report Share Posted May 3, 2020 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? Quote Link to post Share on other sites
peter_spy 1522 Posted May 3, 2020 Report Share Posted May 3, 2020 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. Quote Misc. assets for TDM Link to post Share on other sites
stgatilov 1126 Posted May 3, 2020 Author Report Share Posted May 3, 2020 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. 1 Quote Link to post Share on other sites
Abusimplea 168 Posted May 3, 2020 Report Share Posted May 3, 2020 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): Quote Link to post Share on other sites
peter_spy 1522 Posted May 3, 2020 Report Share Posted May 3, 2020 Couldn't reproduce that. Quote Misc. assets for TDM Link to post Share on other sites
stgatilov 1126 Posted May 4, 2020 Author Report Share Posted May 4, 2020 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. Quote Link to post Share on other sites
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 (edited) 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 1 Quote 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
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 (edited) Borderless mode issue AMD only (Catalyst 20.4.2) Edited May 4, 2020 by lowenz 2 Quote 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
duzenko 654 Posted May 4, 2020 Report Share Posted May 4, 2020 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 2 Quote Link to post Share on other sites
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 (edited) 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 Quote 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
cabalistic 736 Posted May 4, 2020 Report Share Posted May 4, 2020 What do you mean, have it back? r_showfbo 4 has not been disabled... 1 Quote Link to post Share on other sites
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 Pardon! Testing now! Quote 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
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 * Why r_showFBO 5 crashes the game? * Here's the SSAO issue: 1) Low: 2) Medium/High: 1 Quote 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
cabalistic 736 Posted May 4, 2020 Report Share Posted May 4, 2020 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. Quote Link to post Share on other sites
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 (edited) 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 Quote 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
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 SSAO parameters are @default. Here's the darkmod.cfg: https://pastebin.com/YAYx3izQ Quote 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
cabalistic 736 Posted May 4, 2020 Report Share Posted May 4, 2020 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? 1 Quote Link to post Share on other sites
lowenz 600 Posted May 4, 2020 Report Share Posted May 4, 2020 You're right, tested now on my 1050 Ti and there's no issue! It's AMD-only...... Quote 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
stgatilov 1126 Posted May 4, 2020 Author Report Share Posted May 4, 2020 31 minutes ago, cabalistic said: Are there any other AMD users who can reproduce this? Yes, I reproduce it on RX 550. Any plan? Quote Link to post Share on other sites
cabalistic 736 Posted May 4, 2020 Report Share Posted May 4, 2020 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... Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.