Darkplaces Stuttering

[KillPixel]

Seven, I appreciate the kinds words But, as Spike pointed out, I'm using rtlights. If I were still using lightmaps performance would be a non-issue (in my tests, I was still getting near 1k fps at ~1080p on a i3-3217U with integrated graphics).

They play at hardly 25-30 fps and do not complain

This hurts my soul.

Bloodshot, thanks for the suggestion. However, it didn't help and is incompatible with some shader stuff I'm using.

I ran a few tests on some other hardware configs the other day with some interesting results. On low-end machines, it seems DP is more CPU-bound than GPU. Running a stress test map on an e8600 (3.33ghz dual core) and a 9800GTX+ had nearly identical performance to the same CPU paired with an HD 6870, a considerably faster card. The CPU was running at 70-80% ultilization pretty consistently with moments of 100%. I assume it's the rtshadows (or even the rtlights) that are eating up the CPU?

[Bloodshot]

KP, try switching to the dx9 renderer with vid_dx9 "1" and vid_restart

On my laptop opengl frames tank when i see a flickering light (my laptop is a POS) but i know the stutter you are talking about and it's a little glitchy sometimes but dx9 doesn't seem to have it for me

[Spike]

he's using rtlights, so 200fps isn't guaranteed.

[Seven]

I'm making an effort to get acceptable performance on lower-end hardware. IMO, requiring users run the game at 400+ fps simply to achieve performance offered by any other game at 60+ fps is unreasonable. I suppose this is simply the nature of idtech2?

Hello KillPixel,

I think you are worrying too much.
Playing Doom 2016 at 60fps needs quite new hardware, yes. But playing Quake at 200fps does not need new hardware. Quake runs smooth with 200fps in every condition and every laptop should be able to make this.

I know your style and that you most probably will not use any of that silly bling-bling stuff that kills performance for your mod/TC. So you should relax.


I mean, look at all those users out there with their particle overload, pretty water and realtime shadow setup... They play at hardly 25-30 fps and do not complain

So you really should relax and keep on working on your mod/TC. I remember your released work and i am sure it will be gorgeous !

Playing a new Quake map/mod with open jaws and having a great time will not bring up "stutter" complains at all my friend. We need people like you with new ideas and mods for Quake.

Looking forward to your project KillPixel.

All the best,
Seven

[KillPixel]

Maybe this "wait before running another frame" is the root cause ?

This was my suspicion. idtech4 has a similar issue: the engine would stutter at 1 second intervals as it synced game time/frames (regardless of vsync). you could eliminate the stuttering by using fixedTic 1. The drawback, of course, is that if the fps dips below 60 the game time will also slow, since they are linked.

But I am afraid that your mod or TC needs it to be set to 72?

No, it doesn't. But I'm making an effort to get acceptable performance on lower-end hardware. IMO, requiring users run the game at 400+ fps simply to achieve performance offered by any other game at 60+ fps is unreasonable. I suppose this is simply the nature of idtech2?

at lower framerates, like 72, with a monitor refresh rate of 60hz, you're GOING to stutter. ANY engine will.

That was a bad example, not sure why I chose 72 for the video. I've been testing with fps caps of 60, 120, 240, etc. Vsync also has no effect on the stuttering; neither DP's vsync nor the various flavors forced in the nvida control panel.

cl_maxfps_alwayssleep 0

I've tried this and was hopeful it would work since it seems to address what I thought was the issue. Sadly, it doesn't resolve anything

Thanks for the ideas. I'll keep looking for a workaround...

[Spike]

at higher framerates on nvidia drivers, fte tends to be smoother with vsync off. there's some sort of issue in the drivers where it predicts frame times poorly, and ends up waiting two refreshes instead of one. I've not seen this happen with d3d or vk, just opengl. keeping cl_maxfps at 250-500ish should usually work around it.

at lower framerates, like 72, with a monitor refresh rate of 60hz, you're GOING to stutter. ANY engine will. If you're getting 120fps then it'll be a lot less noticable, but 72ish is really stuttery.
just enable vsync, or set cl_maxfps to match your monitor's refresh rate.

regarding DP specifically, try cl_maxfps_alwayssleep 0

[Seven]

Hello KillPixel,

I tried to make the same tests as you did and this is my experience. Using these engine builds:
DP version 20170603
FTE 32-bit version 20170528

Using the cl_maxfps cvar:
DP started stuttering with values <=200 [default is unlimited]
FTE started stuttering with values <= 150 [default is 500]

With value =72 both engines stutter quite much.


Due to the fact that both engines behave approx. identical, the root cause seems to be the usage of the cvar cl_maxfps. FTE doesnt have a description for the cvar. DP prints this description:

if game is running faster than this it will wait before running another frame (useful to make cpu time available to other programs)

Maybe this "wait before running another frame" is the root cause ?


To avoid this issue i suggest to not set this cvar if possible (leave it at default). But I am afraid that your mod or TC needs it to be set to 72 ?
If that is the case, there is not much you can do from my point of view. Maybe Spike can give some valueable tips and insights.

Best regards,
Seven

[KillPixel]

Hi all, I'm experiencing an issue with DP that I can't seem to fix.

DP stutters/lags pretty badly at lower fps (sub 400-500). The stuttering improves the higher the fps cap. Around 400 fps or so it becomes difficult to detect. This is a video using default config and vanilla quake on a 4790k/gtx 980. It's not as obvious in the video as it is in game, but you get the gist.

https://youtu.be/NDmtLIsRrr4

I've tried many different configs, cvars, DP versions, hardware setups and even different computers with no success. The stuttering is not at all present in comparable engines such as FTE. Any ideas?