 |
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. |
 |
My monitor runs at 144hz, new high Hz monitors are 240hz, so 240 would be the max I would suggest. https://www.asus.com/us/Monitors/ROG-SWIFT-PG258Q/ However, users should have the option of syncing their max FPS to monitor refresh, but not V-synced. |
 |
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. |
|
|
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. |
|
|
Okay will give it a try. |
|
|
Seems to run fine now, but I also can't get it over 235 fps. |
|
|
Yes, you can't. Do you need to? =) |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
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? |
|
|
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? |
|
|
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 rate). 166hz sounds like a practical limit based on available consumer hardware options. |
|
|
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. |
|
|
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. |
|
|
http://forums.thedarkmod.com/topic/18999-im-working-on-a-vr-version-early-alpha/ Original thread AFAIK EDIT: That might not be it, there's posts in that thread stating that we had already unlocked FPS. |
|
|
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. |
|
|
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 =) |
|
|
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). |
|
|
Committed in svn rev 7373. I have honestly tried to reproduce the issue in both "The Ravine" and tavern.map, but in both cases I almost did not hear footsteps at all this time. They were clearly playing, but often at infinitesimal volume level. |
|
|
Works perfectly now thank you |
 |
Why is it a problem to make it a cvar? com_maxfps |
|
|
Requires a rebuild of the binaries right now. I guess it could be exposed as a CVAR, stgatilov? |
|
|
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. |
|
|
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. |
|
|
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). |
|
|
I fixed footsteps properly in svn rev 10496. Basically, footsteps are played when headbob changed half-cycle (i.e. changing between left and right feet). But headbob implementation uses 8-bit accumulator, which suffered from radical loss of precision on high FPS. |
- Anonymous
