 |
Okay the crate test is confirmed and it's significant. With fps at 60 fps max, the smallest crate moves quickly and easily. At 300 fps, it's slooooooooooooooooooow. Find test map attached Steps: Open TDM map falltest.map move smallest crate around. Set com_fixedTic 1 vid_restart (not sure if this is necessary) Try moving small crate again. |
|
|
Another issue is the player crouching and standing, those animations can play a lot faster. |
 |
Dragging/carrying as well as throwing entities is affected, too. Crouching slowly is much slower with high fps (at least 400+), everything else (crouching normally, crouching fast, walking slow, etc.) seems to work fine. I've attached a PoC fix for the push crate issue. It still needs to be tested in actual missions as well as with different walk speeds and light items that can be kicked away. At least it seemed to fix that issue in the falltest map. The player velocity value is not per second but per frame (at least that's my observation) and is used as the push velocity. idPhysics_RigidBody::Evaluate also applies frametime as a velocity factor, causing the distance per frame to be in the order of velocity*frametime². The fix removes the first frametime factor in the push velocity using a constant frametime of 1/60. Another issue was that the entity was only pushed every ~6th frame because the trace distance used to check for entities to push was too small (lower frametime -> lower velocity -> lower trace distance). The fix uses a constant distance of 15 units. |
|
|
Added a fix for crouch smoothing. The grab speed basically has the same issue as pushing entities. It can be fixed by uncommenting "dT = MS2SEC( USERCMD_MSEC );" (Force_Grab.cpp line 218 in rev. 6946) and commenting the following line but according to duzenko's comment, it'd cause flickering. I haven't seen such flickering but I'm not sure about low framerates. The throwing range seems to be a non-issue since it only halves from 60 to 500 fps. |
|
|
Ideally all this should be moved to time based instead of gametic, so even at 1 fps throwing an object would go as far as at 3000fps. |
|
|
The actual problem for the player velocity while crouching slowly seems to be friction. While idPhysics_Player::Accelerate accelerates less per frame with a lower frametime to keep the same acceleration over real time, idPhysics_Player::Friction always resets the velocity in the next frame because of the small creep acceleration. At normal framerates, the same thing also occurs but the "temporary" velocity in that frame caused by acceleration is higher (though at 60fps that's still below 1/2 of the maximum slow creep speed). The friction calculation likely needs a more physically correct approach, at least to determine whether static friction is overcome, in which case it should not "eat away" all the velocity. It needs to take acceleration (or accelerating force) into account for that, currently it only uses the current velocity. It might also be necessary (and better?) to move the friction calculation directly after the acceleration. |
 |
Very nice! A few testing notes: KO'd or Killed (Ragdoll) AI still float down in slow motion when FPS is very high. "noclip" mode still has slow movement or freezing at high FPS. |
|
|
Attached movespeed_cratepush_grabentity_betafixes.txt, which overrides proofofconcept-pushentityfix.txt. Replaced acceleration as well as friction in idPhysics_Player with a smoothing calculation that takes the frametime into account. I've first tried to fix the old algorithms but wasn't able to find a way to make slow movement equal for different framerates. [Edit : The new Friction function doesn't touch the velocity in acceleration direction since the Acceleration calculation automatically "accelerates backwards" when the player is too fast. It only applies friction to all directions when the player doesn't accelerate (no move buttons pressed).] I've refined the crate push distance a bit and used USERCMD_MSEC instead of a hardcoded 1/60 reference frametime. The grab entity fix that reverts someone else's change is also included, I included further "investigation" of that in the ToDo-list below. It looks good so far (tested LadderMove, NoclipMove, WalkMove and WaterMove; not sure how to test AirMove and FlyMove), using the original friction constants with the new function. One map that definitely needs further testing with this is Swing. At least the start where one has to jump on small swings seemed different to me than with TDM 2.05. Other than that, I couldn't find any issues with the changes. I couldn't find differences in 20/30/40/50/60fps and above, except that pushing crates feels less smooth on lower framerates due to the crates moving away from the player by a higher distance per frame (didn't look like a real issue though). Current ToDo-list : - Compare different movement speeds before and after the fixes since the previous movement modifiers are still used in a different calculation. - Take a look at AI ragdolls (fall, grab and throw). - Take a look at the entity throwing range. - Test whether steep slopes still work as intended. - Test the effects of all changes in actual missions. - Find out more about duzenko's comment in Force_Grab.cpp ("fixed tick + USERCMD_MSEC -> flickering"); grabbing seems fine even with that change reverted. |
|
|
The Force_Grab change is almost certainly: http://bugs.thedarkmod.com/view.php?id=4426 |
|
|
Hmm, movespeed_cratepush_grabentity_betafixes.txt doesn't require proofofconcept-pushentityfix.txt does it? I applied the crouch fix and your latest betafix and all seemed to be working well but then I shot an arrow at an AI in noclip mode and the game crashed to Desktop. |
|
|
Attached grabentity_dropbody_betafixes.txt. For all fixes, apply movespeed_cratepush_grabentity_betafixes.txt without the Force_Grab.cpp changes and then this patch. The frame time used for the grab speed now is limited to the default 16ms tick but the actual frame time is used for anything above that. That should prevent flickering at low frame rates and the slowdown at high frame rates. I've also added a frame time dependant factor to the body friction calculation in Physics_AF.cpp that should fix the slow motion ragdoll issue. |
 |
Applied to trunk, didn't test. However I think limiting grab speed on low fps could lead to slow movement? (Mortal Kombat Kompete behaves like that) |
|
|
Thanks! If this works out, I guess the last remaining issue with uncapped FPS is audio timing issues. I think they are limited to triggered events but I haven't even begun untangling that side of things. |
 |
One other area I'm concerned about: interleaved thinking. The amount of frames between each time an AI thinks is governed by the AI spawnarg "max_interleave_think_frames". Each AI uses "idAI::GetThinkInterleave()" to determine the next frame where it should think. Increasing the frames between thinking events improves performance. See http://wiki.thedarkmod.com/index.php?title=Interleaved_Thinking_optimization With increased frame rates, this might now need to be a time-based measure, rather than a frame-based measure. --------------------------------------------- In general, how does increased frame rate affect cycles like general entity thinking, frame-based events, etc.? Perhaps researching anywhere gameLocal.framenum is used might show other areas that need to become time-based rather than frame-based. |
|
|
When I run TheDarkMod.exe, I noticed that when running then trying to stop, there's now a small slide at the end. If I use TheDarkModTools.exe, there's no sliding, which is how it works in TDM 2.05. I tried with fixedTic off and on, and at 60 and 144 fps. Behaviour is the same, but the sliding might be more pronounced at 144 fps. Video: https://www.youtube.com/watch?v=bvL6f7F_Xsc First part is TheDarkMod.exe, second part is TheDarkModTools.exe |
|
|
2.05 works correctly: when walking and stopping, there's a short slide at the end, and when running and stopping, there's a longer slide at the end. Testing with the latest SVN (@60fps), the behavior is the same. My sense is that the sliding might take slightly longer to stop, but it's still reasonable behavior. There have been no changes to the sliding code to make it behave differently since I corrected it in 1.03, 6.5 years ago. It's possible that any changes for different fps settings might have affected the way friction works, which might account for differences you're seeing. If a different FPS setting makes sliding behave WAY differently than the 2.05 behavior, then adjustments are needed to bring it back in line with 2.05. |
|
|
I don't see major changes with stopping either. And I think it makes sense to stop in a fraction of second rather than immediately when running? |
|
|
In 2.05 ... A walking slide stops in about a second. A running slide stops in about 2.5 seconds. 2.06 should do the same. |
|
|
Just wanted to clarify; the sliding on stop is on other surfaces such as wood or stone. In 2.04 and 2.05 you stop almost immediately. In SVN TheDarkMod.exe, there's a slide before coming to a stop. No other EXE is affected (TheDarkModTools.exe, TheDarkModx64.exe, TheDarkModx64Tools.exe) |
|
|
I've added a patch in the child issue 4552 that should solve the sliding issue. While the new sliding duration is higher (except for running) the difference should be minimal since the sliding speed goes toward zero during that time frame. Another difference from 2.05 is that slow crouch / creep speed is higher because the new friction doesn't longer prevent reaching the wishspeed of around 16.6 instead of 8, meaning that it might be necessary to add another movement multiplier for that case. Other movement types aren't affected. |
 |
"Underwater air time". This is accelerated with uncapped FPS. |
|
|
In SVN, even though the FPS is uncapped at either setting com_fixedTic 0 fixes the "underwater air time" issue. |
|
|
Don't know if it's related to this or not, but my mouse sensitivity slider has changed completely compared to 2.05. There are 8 levels, and anything above two is so fast now that it's hard to select anything. |
|
|
What is the value of the sensitivity cvar in console when you move the slider to the middle position? It was recently changed from int to float to allow for modern high-dpi mice. |
|
|
"What is the value of the sensitivity cvar in console" How would I find that? |
|
|
UsercmdGen.cpp idCVar idUsercmdGenLocal::sensitivity( "sensitivity", "5", CVAR_SYSTEM | CVAR_ARCHIVE | CVAR_FLOAT, "mouse view sensitivity" ); sensitivity = 5 (default) |
|
|
Another bug specific to com_fixedTic 1 Mission: Swing 1) Climb onto the first ledge from the ladder 2) When fully upright, jump 3) Note that you will hover as if your head is stuck in the ceiling This does not happen in other modes. |
|
|
And another: Mission: The Alchemist With com_fixedTic 1, simply crouch-walking from the street to the side-walk fails. You must jump or mantle onto the sidewalk even though the curb is very shallow. com_fixedTic 0 solves this even with uncapped FPS via com_smp 1. |
|
|
Fixed the underwater air time (svn rev 7131) - needs testing. I think the mouse slider is 1 to 30 with step of 0.5? Any way it makes sense to create a separate bug. |
|
|
Sidewalk climb. I think the problem here is that when moving in small steps there's a chance player kinda puts his foot on the curb side which causes him to slide down and back. Please not that the curb side is not exactly vertical but very steep slope. Unless someone can make out how to adopt the existing code to such situations I'm going to go ahead and just skip frames here which is a bummer... Might also fix the Swing issues though I was never able to repeat that. |
|
|
Swing no longer exhibits the stuck-head problem but now has a new issue... Landing on the moving platform causes you to wildly jump positions and it's nearly impossible to get a proper landing. com_fixedTic 0 solves that. Edit: Climbing stairs while crouched causes lots of hopping motion too. |
|
|
Try rev 7137 Do we have more slope surfaces to test? Like http://www.valdisole.net/upload/cms/Piste_a_Folgarida_Marilleva.jpg |
|
|
"The Rift" is full of slopes as I recall... Rev 7137 fixes the platform jumping issue in "Swing" and cures the hopping motion while climbing stairs in "Briarwood Manor". Unfortunately, the head-getting-stuck issue has returned to "Swing" but it is pretty brief and is not infuriating like the curb issue in "The Alchemist". It doesn't break the mission, eg. low priority IMHO. |
|
|
I tested a recent build and the none of the issues were seen in Swing. I'll retest tonight. |
 |
I think it worth noting here that a major change was committed for uncapped FPS mode in svn rev 8435. See related issue 0004924, or more specifically: https://bugs.thedarkmod.com/view.php?id=4924#c11885 And the forums: http://forums.thedarkmod.com/index.php?/topic/20173-limit-timestep/ |
|
|
I fixed some bug in zeroing vertical velocity when walking (svn rev 10498). More importantly, I commented out a piece of code (removing difference between current velocity and desired velocity) in svn rev 10499 (0006333). It would great if someone could explain why it was necessary, or "let's hope I didn't break anything" =) |
- Anonymous
