 |
Not sure how helpful this is but some of the Oculus branches of Doom 3 have broached this: https://github.com/Perpixel/Doom3 |
 |
As a matter of fact I already have the code, I'm putting the ticket# in the comments right now |
|
|
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. Thanks. 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. |
|
|
Understood. |
|
|
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 |
|
|
Problem detected and fixed: head bobbing too fast |
|
|
Problem detected and fixed: console scrolling too fast |
|
|
I'm seeing cases where Objectives Success\Fail are severely delayed. |
|
|
How to reproduce? |
|
|
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. |
|
|
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? |
|
|
Not a critical bug but I thought I would mention: Thief's Den 2: Chalice of Kings Area: http://missions.thedarkmod.com/screenshots/chalice1800.jpg 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? |
|
|
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. |
 |
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... |
|
|
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. |
|
|
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 ? |
|
|
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. |
- Anonymous
