nbohr1more

The pricing is a little better but still feels much like what you would see in an illegal duopoly. There are almost no cases where two cards have the exact same performance but one is priced lower. They all seem to have their own tidy slots where there are more expensive higher performers above them and less expensive but less performant options below them. Both vendors have scaled back on volumes to clear out legacy stock in the retail channel. Both vendors have done as much as possible to ensure not to drop prices of legacy stock too much. Both vendors have done "just enough" value and performance to fend off Intel ARC offerings in the same price range.

I just don't get it. While having more VRAM on the GPU is an easy solution to improve performance and resource issues, GPU architects have known for ages that the best solution is using some sort of hierarchy where you page out to system RAM once you are low on GPU RAM. AGP Aperture was designed around this idea. When PCIE came out, it was meant to have a flexible memory aperture natively but somehow IHV's never optimized that? Then Nvidia created PCIE "TurboCache" and AMD created HyperMemory. Issue solved? Apparently not? id Software pioneered the use of virtual textures in id Tech 5 and that became a standard graphic feature called "Partially Resident Textures" How in the world is a graphic shader hack more effective than hardware solutions like TurboCache? Anyway, it works but it seems to be cumbersome to implement so it hasn't caught on I guess. Then the AMD Vega architecture launched and AMD began touting how great it's Cache Hierarchy system worked? As if the same idea was not in play per all the above previous examples? Also when Vega launched, they made a branded version of "Resizable BAR" which conceptually is the same idea as PCIE's native flexible aperture but apparently even though we made a flexible specification somewhere in the bowels of the graphic hardware specification we still had harded coded limits that needed to be fixed? Then PS5 console proposed Direct Storage which also has a graphics memory hierarchy design. We have all these tools to use system ram and even SSD \ NVMe for video memory yet we are still designing game engines to front-load all data into VRAM and acting like it's "impossible" to have good performance when dedicated video RAM is below X amount. This should be a solved problem by now.

The latest version has been added to the mission database.

Yes, I create new fresnel mod versions for each TDM release ( latest being 2.11 ). You can copy your whole darkmod directory for backup but all you really need to backup for the Fresnel Mod is tdm_base01.pk4

I am not sure but I believe that ReShade offers a temporal or morphological AA solution which might be much cheaper than using in-game MSAA. Given your high screen resolution, I am surprised that 8x MSAA isn't sufficient. One thing that MSAA doesn't cover is shader aliasing and transparency so cranking up to 16x won't help there. If ReShade doesn't have the needed options, you can also try forcing AA in your Nvidia driver settings. People complain about the blurry nature of FXAA but with really high pixel DPI it should have minimal degradation to image clarity. Try setting MSAA to 4x and forcing FXAA for transparency coverage and see if the results are acceptable. Depending on your aptitude with ReShade settings you might prefer it's SSAO and lighting mods... but I will humbly submit that you can improve the sense of scene depth with my own Fresnel Mod: https://www.moddb.com/mods/the-dark-mod/addons/fresnel-mod-211-unofficial Also you can achieve something similar to the ReShade HDR by modifying the r_postprocess cvars : https://wiki.thedarkmod.com/index.php?title=Advanced_TDM_Visuals_Tweaking Setting r_postprocess_colorCurveBias to something like 0.2 or 0.25 should make the game look more like your ReShade screens but obviously ReShade has many more customization options for color behavior so you have more control there ( with some additional expense due to increased shader parameters ). Note: Some options from that article are gone in favor of a newer bloom implementation controlled by r_bloom settings.

The latest TDM version is 2.11. Did accidentally post 2.10 ?

Yes, we ported some BFG code. Both TDM and RB-DOOM3-BFG have radically changed the shader setup and render backends from vanilla (or vanilla BFG) so it may be difficult to reconcile the two. RB-DOOM3-BFG has a few things that we may be able to port without too much issue though.

OH!!! You have FPS set to Capped under the Advanced Menu eh? Doom 3's old capped FPS mode is "not great". Try setting it to Uncapped then set Max FPS to 60. ( Both under the advanced video options ) Normally this only helps on Linux but perhaps Windows 11 has the same problem.

Thank you! Yes, all the recommended changes you highlighted would be changed via the console. Typically invoking CTRL+ALT+~ ( tilde ) to open the console. Yes, AA is quite expensive, especially in Stencil Shadow mode where fillrate is heavily consumed. I guess I should also suggest that you try "Maps" for Shadow Mode in the advanced menu. To improve shadow map quality, you should set: r_shadowMapSize 1440 and enable single pass shadow maps for better performance too: r_shadowMapSinglePass 1

What TDM version? Is "Frontend Acceleration" enabled in the Advanced Video menu? You may want to try increasing to jobs_numThreads 4 in the console. Also try: tdm_lg_interleave 3 tdm_lg_interleave_min 6 Which missions? What OS version? What is AA set to ? ( 16x MSAA is still really expensive in this engine so we recommend using 8x or forcing AA in your drivers ) See also: https://wiki.thedarkmod.com/index.php?title=Performance_Tweaks for performance tweaking options.

Pretty cool! As a general rule, Doom 3 \ TDM engines both like long narrow tunnels like this. Dram did a bunch of experiments with different map designs and found that long and thin maps can be enormous and still have great performance. I think this is why "No Honor Among Thieves" has lots of long + thin areas. The designers took Dram's findings into consideration.

Sounds like you have things handled. I will only say that I once thought my motherboard was dead but I removed the battery and left it out for 10min so all current drained. After this, I connected my monitor cable to the on-board video out rather than putting my GPU back into the board. This allowed the board to boot properly. It seems that my generation of UEFI BIOS has some funky memory retention issues that can cause boot failure and only fully draining the power will let you get past them.

Did you check \ replace the CR2032 battery? Any bulging capacitors ? Re-seated RAM and Power cables?

I wouldn't necessarily say there is a lack of interest, rather this is lower on the priorities list than other things. I agree that we should consider xdata support though. Especially since it would be easier to hook existing translation code into. ( Though there is also a line of thought that we should completely revamp our translation mechanism and expanding the existing mechanism will make that even harder. ) There's no hard and fast rule but I would say the priorities go something like: 1) Crashes or breakage that needs to be fixed ASAP 2) Community code contributions 3) Community asset contributions 4) Things that are "interesting" or "fun" to implement 5) Things that are "easy" to implement 6) Things that the developers feel would really improve the project game-play 7) Code cleanup and structural fixes 8 ) Performance improvements and optimization 9) Accessibility improvements ( subtitles, translation, etc) 10) Bugfixes for existing assets 11) Enhancements to existing assets 12) New graphics features Given that we are a volunteer project, the priority list is always gonna be a mixture of "proper priorities" and things that are easy, interesting, or fun to implement. Grayman's approach was to survey the bug tracker for trends that revolve around a somewhat narrow topic and then compare that to community comments about the topic and develop a new design that covers all contingencies related to the topic. This would fix a large number of bug reports at once since it would either make them obsolete by removing the wonky parts of the prior design or make the design better match how players interfaced with the issue. The only downside to that approach was that covering "all contingencies" sometimes meant a very large conditional tree and that would span a huge swath of the project code ( thus risking lots of unforeseen bugs ).