Open Player701 opened 2 days ago
does passing -noidle
as a commandline parameter change that? by default gzdoom drops down to a lower process priority when unfocused
-noidle
appears to have absolutely no effect on this whatsoever, unfortunately.
does setting i_pauseinbackground
to false change things? (could be the pause menu is lowering max fps)
does setting
i_pauseinbackground
to false change things?
No, it doesn't look like it - even when I start a level. I mean, the game is progressing in the background as it should be, but my monitor is still stuck at 49 Hz.
i have the slight suspicion this might be windows' doing for minimized programs does any other game behave like this when minimized?
You can try following this image if you want to change Windows' default process scheduling method (does not require restart AFAIK):
Keep in mind that optimizing for background processes is normally used for servers but it ensures all process gain equal time. Also keep in mind that it means all processes, not just the ones you see - so this can be problematic if you have a lot of stuff running on your machine at once.
EDIT: Oh and one other thing - if you have a GSYNC/FreeSync monitor, and unfocus the display, FreeSync will stop working for that application, meaning GZDoom will now be locked to the refresh rate of the foreground application. This may also make things appear slower.
i have the slight suspicion this might be windows' doing for minimized programs does any other game behave like this when minimized?
I think you might be on to something here. I don't have a lot of other games installed, but I do have one that I know supports Vulkan: The Talos Principle (1). And when it's minimized, the observed behavior does indeed appear to be similar, albeit not entirely the same: according to the OSD, the refresh rate fluctuates wildly between 144 Hz and somewhere around 50 Hz. The impact on smoothness is also noticeable, but perhaps a bit less than with GZDoom. And changing the backend to D3D11 makes it go away, just like it does when switching to OpenGL (ES) in GZDoom.
So, not sure about Windows, but could it be a graphics driver issue then, maybe?
You can try following this image if you want to change Windows' default process scheduling method (does not require restart AFAIK):
Thanks, but that didn't change anything, even after a restart.
EDIT: Oh and one other thing - if you have a GSYNC/FreeSync monitor, and unfocus the display, FreeSync will stop working for that application, meaning GZDoom will now be locked to the refresh rate of the foreground application. This may also make things appear slower.
Now, there is one other thing this your other thing prompted me to check:
If I alt-tab out of the game and press Win+D, the refresh rate goes to the usual 144 Hz until I unminimize GZDoom and then alt-tab again. (Interestingly, TTP seems to crash every time I do that, and again only when using Vulkan.)
GZDoom version
4.13.2 and 4.14pre-89-g99c058d16
Which game are you running with GZDoom?
Doom 2
What Operating System are you using?
Windows 11
Please describe your specific OS version
Windows 11 Pro 23H2 (build 22631.4460)
Relevant hardware info
NVIDIA RTX 4090
Have you checked that no other similar issue already exists?
A clear and concise description of what the bug is.
With the latest NVIDIA driver (v. 566.14 as of now) and a G-Sync Compatible monitor with a variable refresh rate, the latter appears to drop severely when Alt-Tabbing out of the game window. For example, my monitor's OSD shows that the refresh rate is 49 Hz (!) when the game is minimized. This is highly noticeable especially compared to the default refresh rate of 144 Hz, making all animations in the OS GUI, like scrolling and even cursor movement, feel very choppy.
Note that this happens regardless of whether the game is paused or not, and it isn't even necessary to start a level in order to witness this effect. But it only happens in fullscreen mode, not windowed. As long as GZDoom is running in windowed mode and the window is brought out of focus, the refresh rate stays at maximum.
This issue manifests only with the Vulkan backend. OpenGL and OpenGL ES are not affected.
Steps to reproduce the behaviour.
Explain how to reproduce
Your configuration
Provide a Log
https://gist.github.com/Player701/128e9c690adcfc64f5daadf98db149e6