[Hendricks266]

This thread is dedicated to eradicating the stuttering and frame pacing issues that are often reported with EDuke32, NBlood, Ion Fury, and the rest of the family.

This OP may be updated over time, and new posts will be made to point out any significant additions.

For those who experience the issues, please walk though these suggestions and make a post with your responses.

To download the newest EDuke32 / VoidSW builds: https://dukeworld.duke4.net/eduke32/synthesis/
To download the newest NBlood / Rednukem / PCExhumed builds: https://lerppu.net/wannabethesis/
EDuke32 has received fixes since release of Ion Fury v1.02. For testing purposes, please copy eduke32.exe r8494 or later to "%APPDATA%\Ion Fury" and use it for testing instead of the provided fury.exe.

Basic Information

Describe the symptoms you experience. How often and in what circumstances do they occur?
What are your system specs? OS, CPU, GPU, RAM, Disk, Display.
What display settings are you using? Resolution, Bit Depth/Renderer, Refresh Rate, Windowed/Fullscreen.

Most people reporting these issues only get them with the EDuke32 family of ports and have no issue with other games, so it's probably not a matter of simple user error. For completeness we'll list common things to verify here but you may be able to skip to Diagnostic Questions.

Spoiler

Are there any power management or throttling settings active that could interfere with the program's performance?
Are your CPU or GPU downclocking? Are their temperatures higher than they should be?
Are you running on battery or plugged in?
Are there any background programs, tasks, or services taking resources away from the game?
Does disabling overlays such as Steam and Discord help any?

Diagnostic Questions

What FPS limiter settings are you using?
If using NVIDIA, does enabling Threaded Optimization in the driver control panel help any?
Does turning off both Sound and Music help any?
Open the console ([~] in EDuke32/NBlood/etc, [Shift]+[~] in Ion Fury) and try the following cvars: r_glfinish, sys_timer, win_systemtimermode, win_priorityclass. Typing them in by themselves will show the options that are available. Follow them with a number to change their settings. Run the "restartvid" command after changing any of these options to make sure they apply. Do you notice any difference?
[Optional, Advanced] Some CPUs from 2017 onward may have a performance issue with their implementation of the High Performance Event Timer. Try switching Windows' QueryPerformanceCounter from HPET to TSC using the instructions at this link to see if there is any benefit.

If you wish to use VSync:

Is there any difference between turning VSync on in-game, and turning it off in-game and enabling it in your graphics driver's control panel instead?
Does the FPS Offset option in Options > Display Setup > Video Mode help any? Start with -1 and +1.
Is your system capable of GSync or FreeSync? Is it enabled? The preferred way to enable GSync is to enable VSync system wide in the NVIDIA Control Panel (set to On, not to Fast Sync), disable any VSync options in the game, and tweak the FPS Offset option to your satisfaction. Some older GSync monitors may benefit from an FPS Offset around -3.
Does enabling Triple Buffering help at all? If so, does input lag increase?
Open the console (explained above) and try different values for the r_vsync cvar. (Before r8612: r_swapinterval, r_swapcomplete) Run the "restartvid" command after changing it.

[pagb666]

Here's my report. I saw Tekedon also reporting stuttering on a Youtube comment about nBlood, so I know I'm not alone.

Basic Info:
Running nBlood or PCExhumed via Polymost with Vsync ON causes the game to stutter as if it was caching tiles as soon as they appear for the first time, after some time playing it will run fine... just as if the tiles were already cached from before. Latest eDuke releases run fine with either Duke or Fury, even with upscale packs.

Computer Specs:
Ryzen 5 3600 16gb GTX1070, Crucial MX300 SSD, Win10LTSC
Also happened on my old Xeon W3680 24Gb GTX980, Crucial MX300 SSD, Win10LTSC (Can't say for PCEx as it wasn't released yet, but nBlood did sure stutter the very same way)
Happens with every display setting I tried, but my main is 2160p@60hz/Polymost 32bpp... either Windowed, Fullscreen, even with Borderless gaming to force borderless mode.
I tried with little to no background tasks, the result is the same. No overlays of any kind.

Diagnostics:
Tried everything in the list with no results and more stuff in the past, with no success. Only cases when it is solved, it's either running the games with the software renderer or turning off Vsync

[Mr. Death]

I've only been able to try the latest builds of EDuke32 (r8494) & PCExhumed (261119), as those are the only 32-bit compatible ports so far. Both of those definitely have the stuttering issue for me.

I also tried absolutely everything suggested in the list above and nothing works to alleviate the problem.

Here are my specs:

AMD Athlon 64 X2 4600+ (2.4GHz)
NVIDIA Geforce 9800GT (512MB)
4GB RAM
Windows Vista 32-bit
1024x768 Monitor w/ 75hz Refresh Rate & 32-Bit Depth
Western Digital 500GB Hard Drive

It's strange how Lazy Dog & pagb666 have both now reported that the stuttering is gone for them in the new builds of Duke & Ion Fury. I'm still experiencing the same stutter even with the latest builds...

I'm pretty convinced that this problem is specifically related to using vsync in polymost. Neither of the other renderers exhibit the same issue when vsync is enabled, and changing from fullscreen/widescreen or messing with any of the different console commands that were listed doesn't have any effect on the performance. When playing w/ vsync enabled (and frame rate limiter turned off), the game constantly stutters & skips when entering new areas or when enemies are on screen. When the stuttering occurs, the frame rate jumps 3-4 frames above and below my refresh rate, and the game looks as if it's running at 30fps. If I enable the frame rate limiter and lock it to 75, then set the FPS offset to -1, the stuttering completely disappears and everything returns to normal and runs smoothly.

And again, I'm not sure if it really helps diagnose the problem, but the specific build that this issue started for me in was r8031. r8030 and back are perfectly smooth when playing in polymost w/ vsync enabled.

[Hendricks266]

Is there any improvement with the latest synthesis build, r8573?

[Mr. Death]

Hendricks266, on 29 January 2020 - 11:05 AM, said:

Is there any improvement with the latest synthesis build, r8573?

Unfortunately no- the vsync performance seems more or less the same for me.

When playing w/ frame rate limiter turned off, and vsync enabled, the game still stutters & hitches constantly when entering new areas or when enemies are on screen.

The temporary solution of setting the FPS offset to -1 still works perfectly though.

[DisgustedGrunt]

Stuttering is back for me. Started happening in r8572, the previous release, r8534, works fine.

[DisgustedGrunt]

Lazy Dog, on 04 February 2020 - 02:19 PM, said:

Stuttering is back for me. Started happening in r8572, the previous release, r8534, works fine.

Nevermind, works fine in r8616.

[TerminX]

Cool. Can you also test all of the VSync modes in the game menu, please?

[Mr. Death]

TerminX, on 06 February 2020 - 10:23 PM, said:

Cool. Can you also test all of the VSync modes in the game menu, please?

For me, both the regular VSync & Adaptive options still exhibit the same stuttering as before. My frame rate NEVER holds to 75fps and constantly jumps from around 72-78 when enemies are on screen.

The KMT option seems to run much smoother, but I get constant tearing at the top of my screen when using it.

I did actually just notice that setting the Frame Rate Limiter to my exact refresh rate (75hz) does also fix the stuttering, I DON'T have to set the offset to -1. So the best results are when I use the combination of regular VSync w/ the "Automatic" or "75" Frame Rate Limiter options enabled. That relieves both the stuttering and screen tearing, and it holds much better to the 75hz target.

[DisgustedGrunt]

TerminX, on 06 February 2020 - 10:23 PM, said:

Cool. Can you also test all of the VSync modes in the game menu, please?

Normal works perfectly for me.
KMT works the same, except for the same tearing Mr. Death reported.

Adaptive still has the frame pacing issues, but also screen tearing. Also, the skybox "flashes" through the floor when fps drops. Tried to capture that in video, but even though it happens ingame, the video doesn't show it, not even at 60 fps. Weird.

[TerminX]

Sounds like your video driver might not have the best support for adaptive. The only difference between "on" and "adaptive" is that they pass different values to the GL driver. What video card is this?

KMT mode needs a little more work but it should be the best of all of them when finished.

[DisgustedGrunt]

Intel HD 4400 Desktop.

[TerminX]

When you try to enable adaptive mode do you get any log messages that begin with "debug"?

[DisgustedGrunt]

TerminX, on 07 February 2020 - 01:34 PM, said:

When you try to enable adaptive mode do you get any log messages that begin with "debug"?

i always get this one, no matter if vsync is enabled at all or not or in what mode, so idk if is related:

debug: DwmGetCompositionTimingInfo() FAILED!

But only appears after i start a game.

Also, the skybox "flashing" issue seems to only affect Ion Fury

[TerminX]

What version of Windows?

[DisgustedGrunt]

TerminX, on 07 February 2020 - 02:09 PM, said:

What version of Windows?

8.1

And, after some more testing the skybox thing can also happen in Duke 3D.

[TerminX]

Can you download r8620 and tell me what the line concerning DwmGetCompositionTimingInfo() says now?

[DisgustedGrunt]

It says debug: DwmGetCompositionTimingInfo() FAILED! HRESULT: Unknown error

[Mr. Death]

I get the same error message as Lazy Dog.

[mjr4077au]

In the interest of resolving this, is there any chance to get a 'r_showfps 4' option that shows the performance of all functions in the game, not just G_MoveActors() and G_MoveWorld()? When I get the stuttering, the 'Game Update' timer constantly flickers into the red but its too quick to see what it spikes to, etc.

Also, and not to be cheeky, but has anyone taken a serious look into whatever Raze is doing? There's so much talk about "it's not accurate to say that it does X or Y", but these stuttering issues just don't happen in that fork. There's also a significant number of things broken in Raze, and I'm hoping whatever is broken wasn't necessary to fix this.

Lastly, what environments are the devs using? I haven't played EDuke32 on Linux, but perhaps these issues are platform-specific? I assumed Linux given the preference to MinGW over MSVC, but Terminx perhaps indicated it was more for compiler features than anything else. My system for reference is:

Intel Core i7 4770k
32GB RAM
4x SSD in RAID0
Windows 10 Enterprise LTSC 2019

[mjr4077au]

For what it's worth, I installed Arch Linux and compiled the latest trunk release and the stuttering compared to Windows is significantly less, but still noticable. For both, I play with no frame limiter and vsync on.

Further testing on Windows using KMT with a framerate limit of 75 fps (I play on a 60Hz display) based on other comments comparable to Linux under the above circumstances which is a significant improvement.

I still think it'd be great to have some kind of view that shows statistics from all engine/game function so that the function that's causing the stuttering can be easily revealed.

[Hendricks266]

r8795 improves stuttering for me. I've pushed the same change to NBlood as well. Does it help anyone who experiences stuttering on Windows?

r8795 | hendricks266 | 2020-04-04 05:59:22 -0500 (Sat, 04 Apr 2020) | 10 lines

Disable the call to WIN_UpdateClipCursorForWindows in WIN_PumpEvents

Achieved by hex-editing libSDL2.a to change a JE (0x74) to JMP (0xEB).

This should improve micro stuttering-issues on Windows. My settings:

r_vsync 2
r_maxfps 0
win_systemtimermode 1
win_performancemode 1

[mjr4077au]

Hendricks266, on 04 April 2020 - 03:08 AM, said:

r8795 improves stuttering for me. I've pushed the same change to NBlood as well. Does it help anyone who experiences stuttering on Windows?

r8795 | hendricks266 | 2020-04-04 05:59:22 -0500 (Sat, 04 Apr 2020) | 10 lines

Disable the call to WIN_UpdateClipCursorForWindows in WIN_PumpEvents

Achieved by hex-editing libSDL2.a to change a JE (0x74) to JMP (0xEB).

This should improve micro stuttering-issues on Windows. My settings:

r_vsync 2
r_maxfps 0
win_systemtimermode 1
win_performancemode 1

Personally can't really tell any difference. The micro-stutter issues aren't apparent really apparent with Polymost, KMT and no addons. It's when you start adding skyboxes and other things that the issues appear.

From my testing, the best playability experience is Polymer with actual vsync (r_vsync 1). KMT tears for for me and that gives me the shits. It can also have massive frame rate spikes at times, such as the explosion at the start of IF. Polymost with r_vsync 1 has noticable input lag and micro-stutters continuously even without addons. Polymer with r_sync 1 doesn't tear, doesn't have input lag and doesn't micro stutter.

I've also compiled versions that use the native interface and not SDL, and they have the same micro-stutter issues (and actually felt worse from recollection, but it was some months ago).

I strongly believe the issue lies deep in polymost somewhere, and it is a regression of some kind. A recent compile of JFDuke3D with skyboxes etc had zero issues, etc. The only issue I had was remembering how bad so much else was compared to now.

[Hendricks266]

Maybe `r_persistentStreamBuffer 0` is worth trying? You'll need to run `restartvid` or possibly restart the program.

[mjr4077au]

Hendricks266, on 04 April 2020 - 03:39 AM, said:

Maybe `r_persistentStreamBuffer 0` is worth trying? You'll need to run `restartvid` or possibly restart the program.

Changed and restarted the game to be 100% sure, didn't help unfortunately...

[Mr. Death]

Hendricks266, on 04 April 2020 - 03:08 AM, said:

r8795 improves stuttering for me. I've pushed the same change to NBlood as well. Does it help anyone who experiences stuttering on Windows?

r8795 | hendricks266 | 2020-04-04 05:59:22 -0500 (Sat, 04 Apr 2020) | 10 lines

Disable the call to WIN_UpdateClipCursorForWindows in WIN_PumpEvents

Achieved by hex-editing libSDL2.a to change a JE (0x74) to JMP (0xEB).

This should improve micro stuttering-issues on Windows. My settings:

r_vsync 2
r_maxfps 0
win_systemtimermode 1
win_performancemode 1

Using those suggested settings, everything does seem to run smoothly. However, the KMT vsync mode still introduces screen tearing for me, and if I use the regular vsync the stuttering issue returns

Hey Mitch Richters, could you maybe try out r8030 and r8031? I've narrowed down r8031 as the EXACT build that the vsync stuttering issue started with. r8030 runs perfectly smooth for me w/ vsync enabled and frame rate limiter disabled (using Polymost).

I find it very strange that the stuttering starts specifically on that build for me, but nobody else seems to have that problem. Just wondering if you could test those out and maybe try using the skyboxes/addons that you mentioned?

[mjr4077au]

Mr. Death, on 04 April 2020 - 02:32 PM, said:

Using those suggested settings, everything does seem to run smoothly. However, the KMT vsync mode still introduces screen tearing for me, and if I use the regular vsync the stuttering issue returns

Hey Mitch Richters, could you maybe try out r8030 and r8031? I've narrowed down r8031 as the EXACT build that the vsync stuttering issue started with. r8030 runs perfectly smooth for me w/ vsync enabled and frame rate limiter disabled (using Polymost).

I find it very strange that the stuttering starts specifically on that build for me, but nobody else seems to have that problem. Just wondering if you could test those out and maybe try using the skyboxes/addons that you mentioned?

Man, that is dead set fucking it, hey... Literally zero issues on 8030 and the exact issues in 8031. Excellent find!

[Mr. Death]

Mitch Richters, on 04 April 2020 - 11:02 PM, said:

Man, that is dead set fucking it, hey... Literally zero issues on 8030 and the exact issues in 8031. Excellent find!

Right? I thought so...

I actually found that several months ago, and I've mentioned those specific builds before but nobody really took notice.

Hopefully now that both you and me experience the same difference between r8030 & r8031 the devs can look into those specific builds more closely and finally find the problem.

[Mark]

Hopefully the change in 8031 wasn't to fix a different bug. If it was, someone will have to flip a coin to decide which bug to fix.

[mjr4077au]

Mr. Death, on 05 April 2020 - 05:38 AM, said:

Right? I thought so...

I actually found that several months ago, and I've mentioned those specific builds before but nobody really took notice.

Hopefully now that both you and me experience the same difference between r8030 & r8031 the devs can look into those specific builds more closely and finally find the problem.

That's unfortunate but yes I can definitely say that 8030 is great and 8031 is not. 8030 still gets the weird stutter I have when panning around after first loading a level with skyboxes, but I think that's just the engine loading the assets into RAM etc.

Mark, on 05 April 2020 - 06:06 AM, said:

Hopefully the change in 8031 wasn't to fix a different bug. If it was, someone will have to flip a coin to decide which bug to fix.

The chance is so innocent and harmless, and is only about giving the user more control of vsync. The code has since diverged so much that from a quick glance I'm not sure how to best back the change out, but it really shouldn't have had the impact it's having.