View Issue Details

IDProjectCategoryView StatusLast Update
0004409The Dark ModCodingpublic02.07.2022 16:23
Reporterduzenko Assigned Toduzenko  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.05Fixed in VersionTDM 2.05 
Summary0004409: Add an option to lift the 60 fps lock
DescriptionFor me there are two reasons for this
1 - there are 'gaming' monitors out there that offer 120 fps or more. Even though few people have them it would make TDM look more modern in that regard.
2 - In low-fps situations game tics often take cpu time that otherwise could be utilized by renderer. Running one game tic per graphics frame should add a couple fps.
TagsNo tags attached.


parent of 0004493 resolvedduzenko Some physics events have changed in 2.05 due to faster fps 
parent of 0004698 resolvedstgatilov Timescale command doesn't work with uncapped FPS / com_fixedTic 1 
parent of 0004405 resolvedduzenko com_speed discrepancy 
parent of 0004697 resolvedduzenko Some console commands don't work with GLSL 1 and useFBO 0/1 
parent of 0005464 resolvednbohr1more TDM 2.08-2.09 beta 1: uncapped FPS causing weird player physics 
related to 0003684 new Investigate GPL Renderer Improvements 
related to 0005992 resolvedstgatilov Experiment with game tics longer than 17 ms 




31.10.2016 19:00

developer   ~0008411

Last edited: 31.10.2016 19:00

Not sure how helpful this is but some of the Oculus branches of Doom 3 have broached this:



31.10.2016 19:06

developer   ~0008412

As a matter of fact I already have the code, I'm putting the ticket# in the comments right now


02.11.2016 15:22

developer   ~0008435

Please make sure that no timing or physics changes affect com_fixedTic = 0.

This will make this safe to include in 2.05

For example, if you make changes to "savedVelocity" those should depend on the com_fixedTic cvar value.


Once 2.05 is in the wild and there is a wider testing sample for users with com_fixedTic 1, we can then look at generalizing most of the changes across the codebase in TDM-Next-Version.


02.11.2016 17:54

developer   ~0008436



02.11.2016 21:30

developer   ~0008437

I think I found the problem

In idGameLocal::RunFrame there is a condition

    if (framenum == 0 && player != NULL && !player->IsReady())

that controls if AIs should be thinking.

There is also this "click to start" prompt at the start of a mission.

During this prompt my external code keeps increasing game time.

When player finally enters the game AI's last think time is 0, and current game time is NNN.

They are crashed by gravity in idPhysics_Monster::Evaluate by this line (I think)
            current.velocity += gravityVector * timeStep;
The problem with timers is that game timer is 1 sec granular. I will change to boost precise time for now and later we'll change to c++11 std chrono.

It will also change timer value in save games but we discard save games at each svn revision anyway


03.11.2016 15:43

developer   ~0008439

Problem detected and fixed: head bobbing too fast


03.11.2016 16:05

developer   ~0008440

Problem detected and fixed: console scrolling too fast


10.11.2016 05:17

developer   ~0008460

I'm seeing cases where Objectives Success\Fail are severely delayed.


10.11.2016 11:23

developer   ~0008461

How to reproduce?


10.11.2016 13:28

developer   ~0008462

In any mission where being spotted causes a failed objective, note how long after you are observed the alert notification happens.

1) Launch FM
2) Walk in front of an AI to alert them
3) Note that the "spotted" objective failed message happens several minutes later
when in a completely different area.

Sir Talbot's Collateral is where I witness this behavior last night.


10.11.2016 14:02

developer   ~0008463

Last edited: 10.11.2016 14:04

I don't know, man - did you test with both com_fixedtic 1 and 0?
It's the same for me. I.e. I start that map with com_fixedtic=0 and guards see me, try to attack but objective does not fail.
Looking at AI.cpp there appears to be a recent change - svn rev 6609 by grayman 0004002.
One of the code changes was idAI::Event_AlertAI - line 9913 commented out.
Since this report is coming from you maybe you could contact grayman and ask about this?

Or are you sure that it's related to fps lock and game timing?



17.11.2016 04:35

developer   ~0008501

Last edited: 17.11.2016 13:29

Not a critical bug but I thought I would mention:

Thief's Den 2: Chalice of Kings


Set Anti-Aliasing to 4 (or something taxing)
Set com_fixedTic = 1
Pickup a wood board in front of the switch
Watch as the board toggles between two positions at extreme speed like a flicker
If you center the board and wait is slows down looking much like a plucked guitar string

Cure: Either disable AA or set com_fixedTic 0.

Might be:

COM = this->GetCenterOfMass();
    dragOrigin = COM;

    dir1 = m_dragPosition - dragOrigin;
    l1 = dir1.Normalize();
    dT = MS2SEC( USERCMD_MSEC ); // time elapsed is time between user mouse commands

in Force_Grab.cpp?



17.11.2016 09:22

developer   ~0008502

Last edited: 17.11.2016 11:40

Where is that? Can't remember where the switch is
Found it - svn rev 6675. Thanks for the hint - would have taken ages to find it on my own.



26.06.2017 16:59

administrator   ~0008926

As far as I understand, now there are two options: Vsync (<=60 fps) or uncapped.
Uncapped mode is great, especially for benchmarking. But my video card produces strange sound when main menu renders at 1000 FPS.

Maybe it would be better to set some reasonable FPS limit?
Like com_fpsLimit = 60 | 300 | whatever...


26.06.2017 17:29

developer   ~0008927

Last edited: 26.06.2017 17:30

I've had cards that did noise like that but I think it's easier to assign a keyboard shortcut that toggles r_swapinterval on and off than bother with fps control.



09.09.2017 04:50

administrator   ~0009195

Duzenko, you added millisecond resolution timer for GamePlayTimer during fixing this issue.

However, it can only return diffs between frames in milliseconds, there is no way to get total gameplay time in milliseconds.
Is it something intentional?
We need to check if two seconds have passed for 0004609.
Would it be OK to add a trivial getter of _msecPassed ?


10.09.2017 09:35

developer   ~0009203

Last edited: 10.09.2017 12:45

getter for _msecPassed would have sounded just about right if we did not have gameLocal.time that is incremented by the LastTickCapped() value.
The difference between them is that gameLocal.time is slowed down on low fps (or else the bug above).
So having thought about it for a while I think we should actually add a comment to GamePlayTimer code to never try to get the _msecPassed directly but always use the gameLocal.time instead.
Quite fortunate and considerate that you asked about it because I would not have noticed the possible problem if you had just gone ahead and done it.

Issue History

Date Modified Username Field Change
31.10.2016 18:51 duzenko New Issue
31.10.2016 18:51 duzenko Status new => assigned
31.10.2016 18:51 duzenko Assigned To => duzenko
31.10.2016 19:00 nbohr1more Note Added: 0008411
31.10.2016 19:00 nbohr1more Note Edited: 0008411
31.10.2016 19:06 duzenko Note Added: 0008412
02.11.2016 15:22 nbohr1more Note Added: 0008435
02.11.2016 17:54 duzenko Note Added: 0008436
02.11.2016 21:30 duzenko Note Added: 0008437
03.11.2016 15:43 duzenko Note Added: 0008439
03.11.2016 16:05 duzenko Note Added: 0008440
10.11.2016 05:17 nbohr1more Note Added: 0008460
10.11.2016 11:23 duzenko Note Added: 0008461
10.11.2016 13:28 nbohr1more Note Added: 0008462
10.11.2016 14:02 duzenko Note Added: 0008463
10.11.2016 14:04 duzenko Note Edited: 0008463
15.11.2016 14:54 nbohr1more Status assigned => feedback
15.11.2016 14:54 nbohr1more Product Version => SVN
15.11.2016 14:54 nbohr1more Target Version => TDM 2.05
17.11.2016 04:35 nbohr1more Note Added: 0008501
17.11.2016 04:43 nbohr1more Note Edited: 0008501
17.11.2016 09:22 duzenko Note Added: 0008502
17.11.2016 09:22 duzenko Status feedback => assigned
17.11.2016 11:40 duzenko Note Edited: 0008502
17.11.2016 13:29 nbohr1more Note Edited: 0008501
17.11.2016 13:30 nbohr1more Status assigned => feedback
22.11.2016 17:40 nbohr1more Status feedback => resolved
22.11.2016 17:40 nbohr1more Resolution open => fixed
22.11.2016 17:40 nbohr1more Fixed in Version => TDM 2.05
28.11.2016 02:21 nbohr1more Relationship added related to 0004426
28.11.2016 22:06 nbohr1more Relationship added related to 0004405
01.12.2016 21:07 nbohr1more Relationship added related to 0003684
21.06.2017 01:33 nbohr1more Relationship added related to 0004493
26.06.2017 16:59 stgatilov Note Added: 0008926
26.06.2017 17:29 duzenko Note Added: 0008927
26.06.2017 17:30 duzenko Note Edited: 0008927
09.09.2017 04:50 stgatilov Note Added: 0009195
10.09.2017 09:35 duzenko Note Added: 0009203
10.09.2017 09:39 duzenko Note Edited: 0009203
10.09.2017 09:41 duzenko Note Edited: 0009203
10.09.2017 09:42 duzenko Note Edited: 0009203
10.09.2017 12:45 duzenko Note Edited: 0009203
01.02.2019 05:40 nbohr1more Relationship deleted related to 0004493
01.02.2019 05:40 nbohr1more Relationship added parent of 0004493
01.02.2019 05:42 nbohr1more Relationship added parent of 0004698
01.02.2019 05:43 nbohr1more Relationship deleted related to 0004426
01.02.2019 05:44 nbohr1more Relationship deleted related to 0004405
01.02.2019 05:44 nbohr1more Relationship added parent of 0004405
01.02.2019 05:45 nbohr1more Relationship added parent of 0004697
01.02.2019 05:46 nbohr1more Relationship added parent of 0004696
01.02.2019 05:49 nbohr1more Relationship deleted parent of 0004696
12.01.2021 04:24 nbohr1more Relationship added parent of 0005464
02.07.2022 16:23 stgatilov Relationship added related to 0005992