You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the report. To find what's causing it we need a few things:
the newest log from the logs folder next to the game, from a session where it stuttered;
your CPU, GPU, RAM and Windows version;
which renderer you use (the native renderer from the launcher, or the default emulated one) and the resolution scale;
the game version (2.0.3 is the latest).
The log records your settings and, with the native renderer, the frame times including the worst frames, so it shows drops that overlay tools can miss.
If it stutters in particular places, a save from there would help as well: zip the userdata folder next to the game without userdata\cache and attach the zip here.
Thanks, this 2.0.5 log answered it. On the GTX 1070 at 2x each frame takes about 14 ms of the native renderer's time, and half of that (7-8 ms) is presenting the frame: FSR 3 upscaling the 2560x1440 image to your screen, done on the game's own thread. The actual rendering only takes about 5 ms of GPU time. So the frame fits into 16.7 ms with almost no room left, and any small spike pushes it to 33 ms, which is the stutter you see (your log shows exactly those 33 ms frames), and why overlays don't catch it.
Two things should fix it on this card, try one at a time:
in the launcher set the upscaler to bilinear (or present_effect = "bilinear" in deadlyprem.toml),
or set the native internal resolution to 1x.
If you still get stutter with one of these, please attach the new log and we'll dig further.
Thanks, and sorry, I missed that bilinear was already on. Your new log shows the same thing as before: about 7-8 ms of each frame is spent waiting to present, and every so often a frame takes 33 ms instead of 16.7.
Your launcher screenshot has Vertical sync turned on. With vsync the game has to wait for the monitor's refresh before each frame can be shown, and when a frame is even slightly late it waits for the next refresh: that's exactly the 33 ms frames in the log, and why the overlays show a steady 60. Could you try with Vertical sync off in the launcher (Graphics tab), same place in the game, and attach the new log? If your monitor supports G-Sync/FreeSync, keep "Allow VRR / tearing" on so you don't get tearing.
немає таких падіннь фпс, але статери все одно є, при переміщенні, цікаво що при vsync(60 кадрів), що при відключенному vsync(120 кадрів), завантаження відеокарти однакове, десь 35-40% максимум
Thanks, this log is really helpful. With vsync off the frame times are now steady (16.7 ms, the worst 1% at 17.5 ms) and presenting takes 0.2 ms instead of 7-8 ms, so the 33 ms drops were vsync. The stutter you still see when moving looks like our frame pacing: the game's frame limiter runs very slightly slower than 60 FPS, and every few seconds the game catches up with a double step, which shows up as a jerk when the camera or York moves. We're working on a fix. One question: where does the overlay show 120 FPS? Our log shows 60 frames per second being presented.
2.0.9 is out with the frame pacing fix: frames now follow exact 1/60 s deadlines, so the game no longer catches up with a double step every few seconds. Update from the launcher's Update button, or unzip DPRecomp-2.0.9-win64.zip over your install. Could you check the same places as in your video (the camera turn and 1:27), with vsync on and off if you have time, and attach the new log? If you add dp_60fps_stats = true to deadlyprem.toml before starting, the log also records every catch-up step, so we can see exactly what happens on your PC.
Thanks, the screenshot explained the 120 FPS: besides each game frame, our UI layer was repainting on every monitor refresh, so the overlay counted two presents per frame. That's a bug on our side and it will be fixed. For now, with the native renderer please keep Vertical sync off: in native mode it doesn't sync to your monitor anyway, it only changes the game's internal timing, and that's what adds the waits you see with it on.
дякую за вашу працю, 2.0.10 поки все добре, невелике паддіння було на 1.27, статерів не бачив, моніторінг відповідає дійсності, тільки що роздільна здатність не 19201080, а 25601440
ось лог , vsync увімкнена
Thanks for testing! That log confirms it: presenting now takes 0.25 ms instead of 8 ms with vsync on, and frame times stay at 16.7 ms (the worst 1% at about 17.5 ms) through the whole session, except one loading moment. The 2560x1440 is the native renderer's internal resolution at 2x; it's scaled to your 1920x1080 screen, so that's expected. If the drop at 1:27 keeps showing up in the same spot, a save from just before it would help. Otherwise we'll close this in a few days.
Activity
LittleBitUA commentedon Sep 25, 2026
Thanks for the report. To find what's causing it we need a few things:
logsfolder next to the game, from a session where it stuttered;The log records your settings and, with the native renderer, the frame times including the worst frames, so it shows drops that overlay tools can miss.
LittleBitUA commentedon Sep 25, 2026
If it stutters in particular places, a save from there would help as well: zip the
userdatafolder next to the game withoutuserdata\cacheand attach the zip here.valeraudovenko32-oss commentedon Sep 25, 2026
старий компьютер GTX1070, I7 4771, 24GB DD3-2400, WIN10 22H2
native render
deadlyprem_013(gtx 1070).log
userdata.zip
новий компьтер RTX2080TI, I9 10900K, DDR4-3200, WIN1126H1
native render
deadlyprem_004(rtx2080ti).log
userdatartx2080ti.zip
моніторінг не бачить просадок фпс
valeraudovenko32-oss commentedon Sep 25, 2026
debug level trace
deadlyprem_012rtx 2080ti.log
2.0.5: keyboard driving, "at the wheel" ends when York gets out, Skip…
valeriyjurievich-ctrl commentedon Sep 25, 2026
native render , 2.0.5
gtx 1070
deadlyprem_007.log
userdata.zip
https://getshared.com/d/wktDxKHj
на 1.27 дуже видно, також при повороті камери 0.16
LittleBitUA commentedon Sep 26, 2026
Thanks, this 2.0.5 log answered it. On the GTX 1070 at 2x each frame takes about 14 ms of the native renderer's time, and half of that (7-8 ms) is presenting the frame: FSR 3 upscaling the 2560x1440 image to your screen, done on the game's own thread. The actual rendering only takes about 5 ms of GPU time. So the frame fits into 16.7 ms with almost no room left, and any small spike pushes it to 33 ms, which is the stutter you see (your log shows exactly those 33 ms frames), and why overlays don't catch it.
Two things should fix it on this card, try one at a time:
present_effect = "bilinear"indeadlyprem.toml),If you still get stutter with one of these, please attach the new log and we'll dig further.
valeriyjurievich-ctrl commentedon Sep 27, 2026
в 2.0.5 було білінейне масшатабування
log 2.0.6
deadlyprem_001.log
LittleBitUA commentedon Sep 27, 2026
Thanks, and sorry, I missed that bilinear was already on. Your new log shows the same thing as before: about 7-8 ms of each frame is spent waiting to present, and every so often a frame takes 33 ms instead of 16.7.
Your launcher screenshot has Vertical sync turned on. With vsync the game has to wait for the monitor's refresh before each frame can be shown, and when a frame is even slightly late it waits for the next refresh: that's exactly the 33 ms frames in the log, and why the overlays show a steady 60. Could you try with Vertical sync off in the launcher (Graphics tab), same place in the game, and attach the new log? If your monitor supports G-Sync/FreeSync, keep "Allow VRR / tearing" on so you don't get tearing.
valeriyjurievich-ctrl commentedon Sep 27, 2026
native 2.0.8
deadlyprem_007.log
немає таких падіннь фпс, але статери все одно є, при переміщенні, цікаво що при vsync(60 кадрів), що при відключенному vsync(120 кадрів), завантаження відеокарти однакове, десь 35-40% максимум
LittleBitUA commentedon Sep 27, 2026
Thanks, this log is really helpful. With vsync off the frame times are now steady (16.7 ms, the worst 1% at 17.5 ms) and presenting takes 0.2 ms instead of 7-8 ms, so the 33 ms drops were vsync. The stutter you still see when moving looks like our frame pacing: the game's frame limiter runs very slightly slower than 60 FPS, and every few seconds the game catches up with a double step, which shows up as a jerk when the camera or York moves. We're working on a fix. One question: where does the overlay show 120 FPS? Our log shows 60 frames per second being presented.
2.0.9: even 60 FPS frame pacing (#36)
LittleBitUA commentedon Sep 27, 2026
2.0.9 is out with the frame pacing fix: frames now follow exact 1/60 s deadlines, so the game no longer catches up with a double step every few seconds. Update from the launcher's Update button, or unzip DPRecomp-2.0.9-win64.zip over your install. Could you check the same places as in your video (the camera turn and 1:27), with vsync on and off if you have time, and attach the new log? If you add
dp_60fps_stats = truetodeadlyprem.tomlbefore starting, the log also records every catch-up step, so we can see exactly what happens on your PC.valeriyjurievich-ctrl commentedon Sep 27, 2026
deadlyprem_2026_09_27_22_14_01_605.bmp
можливо msi afterburner неправильно показує
valeriyjurievich-ctrl commentedon Sep 27, 2026
на 2.0.9 досі є проблеми с vsync
deadlyprem_002.1.log
LittleBitUA commentedon Sep 27, 2026
Thanks, the screenshot explained the 120 FPS: besides each game frame, our UI layer was repainting on every monitor refresh, so the overlay counted two presents per frame. That's a bug on our side and it will be fixed. For now, with the native renderer please keep Vertical sync off: in native mode it doesn't sync to your monitor anyway, it only changes the game's internal timing, and that's what adds the waits you see with it on.
2.0.10: one present per game frame (#36)
valeriyjurievich-ctrl commentedon Sep 28, 2026
дякую за вашу працю, 2.0.10 поки все добре, невелике паддіння було на 1.27, статерів не бачив, моніторінг відповідає дійсності, тільки що роздільна здатність не 19201080, а 25601440
ось лог , vsync увімкнена
logs.zip
LittleBitUA commentedon Sep 28, 2026
Thanks for testing! That log confirms it: presenting now takes 0.25 ms instead of 8 ms with vsync on, and frame times stay at 16.7 ms (the worst 1% at about 17.5 ms) through the whole session, except one loading moment. The 2560x1440 is the native renderer's internal resolution at 2x; it's scaled to your 1920x1080 screen, so that's expected. If the drop at 1:27 keeps showing up in the same spot, a save from just before it would help. Otherwise we'll close this in a few days.