View Issue Details

IDProjectCategoryView StatusLast Update
0004696The Dark ModSoundpublic04.03.2019 16:33
ReporterAluminumHasteAssigned Tostgatilov 
Status resolvedResolutionfixed 
PlatformX64OSWindowsOS Version7
Product VersionSVN 
Target VersionTDM 2.06Fixed in VersionTDM 2.06 
Summary0004696: At high FPS player footsteps don't always play
DescriptionI've been playing with FPS uncapped and over 200 fps I noticed that the player footsteps don't play while walking or running except in certain situations.

Turning on Vsync fixes the issue.

Steps To ReproduceUncap FPS on a small map so you can get really high FPS, and run and/or walk. You should notice that the footstep sounds either don't play, or only sometimes play.
Additional InformationI've uploaded a test map, you'll have to DMAP it.
TagsNo tags attached.


related to 0004865 feedbackcabalistic Improve the way how FPS cap works (uncapped FPS) 
related to 0004514 resolvedstgatilov Game runs sluggish randomly 
child of 0004493 resolvedduzenko Some physics events have changed in 2.05 due to faster fps 




12.12.2017 02:45

developer (28,930 bytes)


20.12.2017 14:53

developer   ~0009855

1. I still hear my footsteps up to 400 FPS, but at 500 FPS I don't hear them at all.

2. I always hear swings of my blackjack, regardless of FPS.

3. If I jump during running at 500 FPS, then I do not fall down until I release "move forward" button or press movement button (I simply levitate forward at constaint height). If I jump from place, then I get stuck in the air, very slowly going down.

I'm pretty sure that there are tons of issues with framerate this high. The most reliable solution is to cap FPS. For instance, a cap of 200 FPS should be: 1) high enough to not want anything higher 2) small enough to avoid physics issues like mentioned above 3) small enough to avoid GPU whining.


20.12.2017 15:45

developer   ~0009856

Last edited: 20.12.2017 15:47

View 2 revisions

My monitor runs at 144hz, new high Hz monitors are 240hz, so 240 would be the max I would suggest.

However, users should have the option of syncing their max FPS to monitor refresh, but not V-synced.



20.12.2017 16:03

developer   ~0009857

Last edited: 20.12.2017 16:10

View 3 revisions

Yeah, I was gonna say the 250 or 246 might be better so there is engineering overhead for 244hz monitors.

I took a stab at making USERCMD_HZ configurable awhile back but it's too high up in the code hierarchy.
The console and all basic UI operations start after this has been initialized.
Not that this would be "required" to cap FPS but it would unify the way the current cap works.



20.12.2017 17:40

developer   ~0009858

Last edited: 20.12.2017 17:41

View 3 revisions

Committed in svn rev 7354.

I have added a strict condition that 4000 microseconds must pass between frames. This sets FPS cap 250, although I see only 210-220 locally.
Please review if this is a plausible way of capping FPS.

P.S. To be honest, time handling code is a complete mess now.



20.12.2017 19:19

developer   ~0009860

Okay will give it a try.


21.12.2017 04:44

developer   ~0009861

Seems to run fine now, but I also can't get it over 235 fps.


21.12.2017 04:55

developer   ~0009862

Yes, you can't.
Do you need to? =)


24.01.2018 01:18

developer   ~0010035

I'm playing The Ravine on the latest code, and I have no footsteps while crouch walking anymore. Every now and then I'll get a footstep sound.


14.03.2018 00:55

developer   ~0010053

This is still happening with uncapped FPS option.
Once my FPS reaches close to the max 235 fps, my foot step sounds while crouch walking, disappear.
Once FPS dips a bit I start getting some of the foot fall sounds, and once I get to around 150 fps, they're all there.
This happens with smp on or off.
With com_fixedtic set to 1(ON).
With it set to off, fps is capped at 60 fps, so I can't tell if it works because FPS is low, or because fixedtic is off.


19.03.2018 12:23

developer   ~0010073

To allow 2.06 to get out of the door faster, can we lower the FPS cap to 166 FPS or similar speed, and can look at this later for 2.07?


19.03.2018 12:46

developer   ~0010075

Yes, we can.
But I have a feeling that this will not solve the problem for everyone: the good cap depends on the machine. For me sound work well with 400 fps, but for you 250 fps is too high. Someone will still miss sound with 150 fps, so what will we do then?
Is there any sense to have "unlocked FPS" with 100 FPS cap? with 120 FPS cap? with 166 FPS cap? Which hard limit on FPS is good enough for the "unlocked FPS" mode to be still considered the "unlocked FPS" mode?


19.03.2018 12:54

developer   ~0010077

Well, there's been complaints for years on Quake Live at 250fps (game cap), some sounds don't play.
The old cap was 400 fps.
So it's not just this engine.
For me personally, I just would like a cap over my monitors refresh rate (144hz), for a smooth as possible experience.
To be clear, the only sounds I'm missing at 250fps, are when I'm crouch walking/running. Every other sound seems to play as normal.

Have you checked to see if you hear crouch walking/running sounds at 250fps?


19.03.2018 13:54

developer   ~0010084

Last edited: 19.03.2018 13:54

View 2 revisions

From a cursory review of the current state of refresh rates available to
consumers, anything over 144hz is mostly "faked" via some LCD strobing algorithm
rather than actually updating the pixel states. There are scant few 240hz capable
screens and there are even fewer 480hz screens (and I was unable to find any
evidence that the ANY of the 480hz models were doing real pixel updates at that

166hz sounds like a practical limit based on available consumer hardware options.



19.03.2018 14:03

developer   ~0010085

Last edited: 19.03.2018 14:05

View 2 revisions

Game FPS is not only about refresh rate, it is also about reducing game lag.
Currently we have something like 2-3 frames of lag, which is probably hardly noticeable even on 150 FPS.

But once again: what was the original purpose of doing the "unlocked FPS" mode? Was it only about supporting monitors with high refresh rate?

UPDATE: I would like to hear from someone who originally created this "unlocked FPS" mode if he considers 150 FPS hard cap a viable solution 1) in long run 2) temporarily for 2.06.



19.03.2018 14:08

developer   ~0010086

It was for the VR version, 60 FPS is too low for VR.
Once the FPS cap was removed, we started noticing issues.

I've been wanting higher FPS for years now, and I could live with 166fps.


19.03.2018 14:21

developer   ~0010087

Last edited: 19.03.2018 14:28

View 2 revisions
Original thread AFAIK

EDIT: That might not be it, there's posts in that thread stating that we had already unlocked FPS.



19.03.2018 14:43

developer   ~0010088

Last edited: 19.03.2018 15:02

View 3 revisions

Actually Duzenko started the uncapped FPS process in 2.05 before Cabalistic broached it.

I was in favor of the change because drivers are\were becoming increasingly unfriendly to capped FPS on the PC since the introduction of N-Sync \ Free-Sync tech.

Doom 3, in particular, would produce some pretty nasty frame pacing if you didn't specifically tell the engine that the monitor was running at 60hz

seta r_displayRefresh "60"

because Windows 10 was not reporting the correct refresh rate to the display
drivers. Uncapping FPS is a way to side-step some of that mess and modernize
things as well as fulfill a longstanding community request.



19.03.2018 14:43

developer   ~0010089

Yes, com_fixedTic was present in the original Doom 3 code, I think.

Well, let's increase the hard pause to 6000 microseconds then (166.6 FPS --- in practice is would be less, smth like 140 or 135 FPS probably).
If anyone complains that "unlocked FPS" is not unlocked enough, than we'll see =)


19.03.2018 15:01

developer   ~0010090

Thank you, we can always revisit it later on, we just need to get 2.06 out the door without this game breaking bug. (AI don't hear your footsteps either).


19.03.2018 17:20

developer   ~0010103

Committed in svn rev 7373.

I have honestly tried to reproduce the issue in both "The Ravine" and, but in both cases I almost did not hear footsteps at all this time. They were clearly playing, but often at infinitesimal volume level.


20.03.2018 00:42

developer   ~0010108

Works perfectly now thank you


20.03.2018 08:27

developer   ~0010112

Last edited: 20.03.2018 11:05

View 2 revisions

Why is it a problem to make it a cvar?



20.03.2018 11:53

developer   ~0010115

Requires a rebuild of the binaries right now.
I guess it could be exposed as a CVAR, stgatilov?


20.03.2018 13:25

developer   ~0010117

It is a problem because there are already smth like 3 cvars related to FPS, most of them has more than two meanings, some have quite weird meaning (why fixedTic = true means that duration of tic becomes unfixed?!).

If anyone wants to create a cvar, feel free to do it.
Although I feel than com_fixedTic becomes redundant after adding com_maxfps, but I guess no one wants to mess with them now.


20.03.2018 13:30

developer   ~0010118

Leave it for now as is and we'll come around and look again for 2.07. Let Grayman know to include your SVN commit in the 2.06 Beta thread.


20.03.2018 14:10

developer   ~0010120

Last edited: 20.03.2018 14:12

View 2 revisions

I suppose I was not entirely correct in what I wrote about cvar.
So let me phrase it like this:

It is technically trivial to add a cvar, but I'm not sure that it is necessary. The current amount of cvars has freaked me out to the point where I am not eager to add a new one =) But I definitely won't argue. Having a cvar make world more configurable/hackable.

P.S. If you are sure that cvar should be added, either directly tell me to do so or simply do it yourself (it is obvious how to do it from the commits I noted here).

Issue History

Date Modified Username Field Change
12.12.2017 02:45 AluminumHaste New Issue
12.12.2017 02:45 AluminumHaste File Added:
20.12.2017 14:53 stgatilov Note Added: 0009855
20.12.2017 15:45 AluminumHaste Note Added: 0009856
20.12.2017 15:47 AluminumHaste Note Edited: 0009856 View Revisions
20.12.2017 16:03 nbohr1more Note Added: 0009857
20.12.2017 16:09 nbohr1more Note Edited: 0009857 View Revisions
20.12.2017 16:10 nbohr1more Note Edited: 0009857 View Revisions
20.12.2017 17:37 stgatilov Assigned To => stgatilov
20.12.2017 17:37 stgatilov Status new => assigned
20.12.2017 17:40 stgatilov Note Added: 0009858
20.12.2017 17:40 stgatilov Note Edited: 0009858 View Revisions
20.12.2017 17:41 stgatilov Note Edited: 0009858 View Revisions
20.12.2017 19:19 AluminumHaste Note Added: 0009860
21.12.2017 04:44 AluminumHaste Note Added: 0009861
21.12.2017 04:55 stgatilov Note Added: 0009862
23.12.2017 10:02 stgatilov Status assigned => resolved
23.12.2017 10:02 stgatilov Fixed in Version => TDM 2.06
23.12.2017 10:02 stgatilov Resolution open => fixed
24.01.2018 01:18 AluminumHaste Note Added: 0010035
24.01.2018 02:06 Springheel Status resolved => assigned
14.03.2018 00:55 AluminumHaste Note Added: 0010053
19.03.2018 12:23 AluminumHaste Note Added: 0010073
19.03.2018 12:46 stgatilov Note Added: 0010075
19.03.2018 12:54 AluminumHaste Note Added: 0010077
19.03.2018 13:54 nbohr1more Note Added: 0010084
19.03.2018 13:54 nbohr1more Note Edited: 0010084 View Revisions
19.03.2018 14:03 stgatilov Note Added: 0010085
19.03.2018 14:05 stgatilov Note Edited: 0010085 View Revisions
19.03.2018 14:08 AluminumHaste Note Added: 0010086
19.03.2018 14:21 AluminumHaste Note Added: 0010087
19.03.2018 14:28 AluminumHaste Note Edited: 0010087 View Revisions
19.03.2018 14:43 nbohr1more Note Added: 0010088
19.03.2018 14:43 stgatilov Note Added: 0010089
19.03.2018 15:01 nbohr1more Note Edited: 0010088 View Revisions
19.03.2018 15:01 AluminumHaste Note Added: 0010090
19.03.2018 15:02 nbohr1more Note Edited: 0010088 View Revisions
19.03.2018 17:20 stgatilov Note Added: 0010103
20.03.2018 00:42 AluminumHaste Note Added: 0010108
20.03.2018 08:27 duzenko Note Added: 0010112
20.03.2018 11:05 duzenko Note Edited: 0010112 View Revisions
20.03.2018 11:53 AluminumHaste Note Added: 0010115
20.03.2018 13:25 stgatilov Note Added: 0010117
20.03.2018 13:30 AluminumHaste Note Added: 0010118
20.03.2018 14:10 stgatilov Note Added: 0010120
20.03.2018 14:11 stgatilov Status assigned => resolved
20.03.2018 14:12 stgatilov Note Edited: 0010120 View Revisions
15.07.2018 03:57 stgatilov Relationship added related to 0004865
01.02.2019 05:46 nbohr1more Relationship added child of 0004409
01.02.2019 05:46 nbohr1more Relationship added child of 0004493
01.02.2019 05:49 nbohr1more Relationship deleted child of 0004409
04.03.2019 16:33 stgatilov Relationship added related to 0004514