GZDoom Stutter Issues

Hey so I've been noticing a GZDoom issue on my Windows 10-loaded computer. It seems that certain triggers in the game cause the game to stutter. The triggers seem to occur at moments like finding a secret or going up an elevator and it only ever seems to happen once so i assume it has to do with loading the content. What will happen is I will walk in to a spot that triggers asecret and the game will hang for maybe 2.5 seconds before continuing on to it's regular buttery smooth framerate.

After it happens I can exit the program and try to reproduce the problem, but it usually doesn't occur again. I was looking into similar issues and I get the idea that there might be a way to fix this with some form of "precaching sounds" option but i don't know if that exists or if that will solve the problem. Anyone got ideas?

Also, yes, my drivers are up to date (at least as up to date as I can get them to be.)

You have gl_precache set to true, right?

Other than that, all I can suggest is creating a ram drive (only about 512mb is needed unless you're running a huge mod) and putting GZDoom along with the mod you're playing on it.

Oh - and one other thing - if you're running from a pk7 archive, that will cause significant loading delays since more parts of the archive have to be decompressed at a time than what's actually ever used. The highest compression that should ever be used is .zip with LZMA support, or non-solid archiving for 7-zip, or there will be issues.

Sorry for the late reply, but yeah I'm not sure if i have precache set. I remember trying to set that in the console but having trouble so I think I'm gonna give it another go. Setting a RAM drive is a good idea though. Thanks, I'll see how this goes.

dcobs123 said:

Sorry for the late reply, but yeah I'm not sure if i have precache set. I remember trying to set that in the console but having trouble so I think I'm gonna give it another go. Setting a RAM drive is a good idea though. Thanks, I'll see how this goes.

Why do you use the console to set the precache? you can set it in Display options > Opengl options > texture options.

MinerOfWorlds said:

Why do you use the console to set the precache? you can set it in Display options > Opengl options > texture options.

What's so bad about using the console?

Sometimes it's quicker to remember a command than it is to find it in a menu of 2-3 dozen options.

It's all personal preference.

Eruanna said:

What's so bad about using the console?

Sometimes it's quicker to remember a command than it is to find it in a menu of 2-3 dozen options.

It's all personal preference.

It's not bad i just thought a menu is easier to use than a console but i can't remember commands so maybe that's just me.

Yeah I wanna see if i can narrow it down before making a ram drive (that seems daunting). I looked and saw that "precache textures" was checked but I still feel like it's be a sound thing. There's no way to precache sounds at all? Also the files are not in an archive.

I do not know of any way to precache sounds. If the ramdrive thing is daunting, you can install an imdisk front-end that is designed to help you, although the driver itself comes with one already (just open the control panel or use start->run->"imdisk.cpl").

Try not to overthink it. :) That's what makes tools like these scary. They're very simple to use, really, especially if you use the GUI.

MinerOfWorlds said:

It's not bad i just thought a menu is easier to use than a console but i can't remember commands so maybe that's just me.

Of course you're not supposed to remember all console commands that exist, but if you need one, you can relatively easily find it on the zdoom wiki and then use it, and if you use the same command a couple times, you'll remember it naturally.

Another thing I should mention - while the ramdisk isn't guaranteed to solve microstuttering problems it does mitigate them quite a bit so no matter what your GZDoom experience will still be smoother running it. It basically guarantees that no matter what, your files stay in RAM and never hit the disk platter unless you specifically move them there. (Which is important to remember before you shut down your computer...)

But what I did forget to ask is whether or not you're using a 64-bit build. If you have a 64-bit operating system you should never run 32-bit apps if a 64-bit version is available. The reason is simple - 32-bit apps cannot manage memory efficiently as well as 64-bit apps can, due to the 4GB barrier. GZDoom does come in 64-bit flavor, so if you can run it you should (unless your system actually has less than 4GB of RAM).

And lastly - if none of that solves your problems - what mod ARE you running? It may just need its resources converted into a format that GZDoom can parse easier. Some file formats (such as MP3) may just decompress and read easier than others.

I am using the 64 bit version and I don't have any mods on, just Ultimate Doom running through GZ.

One way to help avoid microstuttering is to lower the graphics settings a little bit.

For example, imagine I run it with multisampling 16x and the frame rate with vsync off is 75 FPS. I play it with vsync on and for normal frames that makes it steady, locked at 60 FPS. However, if a disk access enters the picture the time it takes for GZDoom to finish the scene takes just a little bit extra. That means it misses the 16 ms rendering deadline for 60 FPS, and a single frame gets delayed (microstutter).

If I lower the multisampling to lets say 4x, then the frame rate might become something like 120 FPS instead. That gives GZDoom 8 ms of rendering time in its budget to do other stuff, like fetching that sound sample or texture. The end result is that the microstutting disappears. Note that assumes you play with vsync on.

Hope this helps.

This sounds indeed like it may be triggered by sounds not being loaded. Although the engine precaches all actor-attached sounds, it won't do the same for random stuff that gets loaded on request, which is the case for both the secret sound and the moving sector sound.

So, in order to solve this, some information is needed:

1. CPU type and speed
2. Graphics card
3. Operating system.
4. GZDoom settings you are using that may affect render performance (i.e screen size, multisampling setting, scaled textures, postprocessing effects)
5. Which sound backend (OpenAL or FModEx?)

Move your "gzdoom-username-ini" out of the folder so you can test with the default settings. Maybe you have screwed something up.

1. Intel Core i7 6500U (2.50 GHz)
2. GeForce GTX 960M
3. Windows 10 64 bit
4.
Aspect Ratio: 640x480 (on 1080p TV)
Vsync: Off
Resize Textures: Off
Resize Sprites: Off
Texture Filtering Mode: None (Nearest Mipmap)
Antistropic Filter: 8x
Rendering Quality: Quality
Sector Light Mode: Software

All the FMOD stuff is default
Resampler: Linear
Buffer Size: Default
Buffer Count: Default

(Tell me if there's anything else you need to know
I'm not quite sure what multisampling is or where to
find it, does that have to do with Antistropic?)

5.
Midi Device: Sound System
Sound Backend: FMOD EX

VGA said:

Move your "gzdoom-username-ini" out of the folder so you can test with the default settings. Maybe you have screwed something up.

Just tried it and got a secret stutter.

dcobs123 said:

Just tried it and got a secret stutter.

Well, not so secret any more, is it?

If you disable sounds by using the -nosound parameter, does it stutter?

So I decided to give setting a ram drive a try and it works mostly perfect. There's no stuttering issues (so far) but there is the unfortunate side effect of 640x480 resolution being broken. When in 640x480 fullscreen, the program gets stuck in the top left corner of the screen. This issue is usually fixed by turning off dpi scaling but that doesn't work. It's not a huge deal, i guess I'll make due by enabling 1920x1080. Other than it's good.

Only question i have now would be is it alright to just leave the drive on my computer at all times, should i unmount it when it's not in use? Does it eat up resources?

(Also I had multisampling off and the -nosound command doesn't work for me just to answer the other suggestions.)

The RAM drive consumes RAM. How big is it? If it is something like 64mb then you don't need to worry about it.

Yeah, smaller ones will consume no more than a regular program when GZDoom is not actually in use. If it's 512mb or larger though you really should unmount it, depending on how much RAM your system has.

Since you're only playing Ultimate Doom you can get away with formatting a very small drive (such as 64mb or 128mb) and playing GZDoom from that.

So the question about eating resources - yes, it will, but only as much as you tell it to.

Alright, well thank you all for helping me!