hello and welcome to the forums. am i right to assume you are primarily a gamer and not a developer?
interesting. delicate but interesting.
sounds like vsync. if the game can go up to 115 on 144, it means that being at 52 when 60 it’s 98% sure that it’s not a performance issue.
at 115 you’re pushing it surely, and maybe that helps. but 52 still “should” not be perf bound.
the mod talks about vsync here. maybe you can try with the “no vrr” version?
What to choose between the “VRR” and “No VRR” mod variants?
VRR stands for Variable Refresh Rate, which can translate to G-Sync for NVIDIA or AMD Freesync for AMD.
You need to cross check if it is enabled both on your NVIDIA/AMD Control Panel and the Display itself (Monitor/TV)
If yes on both, use the “VRR” variant of the mod.
If no, use the “No VRR” variant instead.
i wonder if it’s a setting in nvidia drivers. they have a way to set some settings globally and they can break games easily. i’d check for vsync and antialias and anti-tearing (vsync) and vrr.
beware, make a backup or take screenshots of your settings, and i recommend to change one setting at a time
if you’ve tweaked the monitor settings for the refresh rate it could be an issue. it’s super hard for a game to match the monitor refresh (hence techs like vrr and fsync etc, which don’t solve it). sometimes what seems like a perf issue, is a frame sync issue. there’s a great talk explaining why vsync is mostly a monitor/os issue not an engine issue, but i can’t find it.
i assume you are using nvidia since you mentioned it. also i recommend the “studio” drivers, the game drivers tend to have bugs, unless you want to run a very new game i guess. there’s a special uninstaller that its on nvidia web in case you want to reinstall them..
dlss introduces latency, it might mess with frame timings. (though i’m confident it’s not the issue)
can you try disabling that? note that disabling dlss/dlaa with native resolution could really tank perf at >1080p+. but you can lower the resolution.
alternatively there’s a setting for screenpercentage. you could lower that and see if you can get a stable 60. if not, then it’s not a perf issue (which i’m 98% sure).
it’s weird, because those settings you shared says that they “disable vsync”, so it “shouldn’t” have that issue when applied. i’m inclined to say that vsync is being forced by nvidia driver config.
how did you install the game? steam has “cloud saves” and it might be saving the settings. (though steam specifies you shouldn’t but some games do)
you can also install mangohud to get an idea of what’s going on and what settings are being used. if you can put a screenshot of the info.
are you on windows or linux?
could you upload the engine.ini file? (if it doesn’t break their licenses. it asks for registration on that site)
maybe you’d want to keep vsync off and maxfps to above 144. but i wouldn’t go with 0, too high might overstress your gpu and make it throttle (slow down) or introduce stuttering due to a lot of instability. if your monitor is 144 hz i’d put 150 as max.
pd:
those are a toooon of cvars. the logs disabling “should” have no effect on the game as logs are not even compiled on shipping builds. you can’t enable them at all they do not exist (virtually) (unless i’m mistaken). it might have an effect if the build you’re using is not shipping, but testing or dev. (dev would be lower perf). maybe it’s just being paranoid, but makes me think that the person really didn’t tested each var individually, and some stuff might have been added just because.
that gpt summary at the end of the excel file is -500 aura points.
about that image at the bottom, devs don’t always get permission to spend time optimizing, and setting cvars takes a lot of time and testing. some of those vars are very obscure, and as you might notice some of them are specific for a specific platform, rhi and version. so it’s quite possible devs might be unaware those even exists. as they change through engine versions too.
it’s quite difficult (close to prohibitive) to set some of those values before the game is done. since things keep changing at a rapid pace, and close to release the focus is on stability, optimization can conflict with that. also some of those things are low level and it could work on one machine but break another. which is another reason why some devs don’t change them.
in any case i think there’s a lot of value in those mods, but have to be dealt with care. it’s also a good reference for devs.
pd2: for example settings like this
| s.AdaptiveAddToWorld.Enabled=1 |
| s.AsyncLoadingThreadEnabled=1 |
gc.AllowParallelGC=1
are really cool. but if a dev adds a line of code out of place. it could lead to a crash, bug, or lock (since we’re dealing with asynchronous code, which is deceptively hard to make safe). so it can be only safely set when coding is fully done (which only happens once the game is packaged), or having budget for deep optimization and make a rule from the start, which not always is the case. and if you’re unlucky and the devs engineered the game in a way that’s won’t work with async, changing it could require a major refactor.
