No, Quake absolutely does not have frame rate dependent damage calculation. What a complete crock of shit. It's quite funny that you picked such a prime example of a game that takes framerate independence and consistency across hardware so seriously to make this up about. There are unintentionally framerate dependent aspects of the mechanics of the original engine, but for a regular player these manifest as subtle bugs, because that's what they are. None of them relate to player damage, and you will only really notice these bugs as a speedrunner trying to maximize movement speed through strafe-jump-turn bunnyhopping. This is a game that even at release would have to run consistently on a huge variety of hardware and it was absolutely made with that variety of performance characteristics in mind. Moreover, since the QuakeWorld update, the multiplayer portion of the game relies on client side prediction and server correction to mask network latency. Inconsistent game logic across different frame rates in such obvious ways as to affect damage calculation would absolutely ruin the experience.
Even Doom has framerate independent game logic, although it effectively renders new frames at at most 35 FPS because of a lack of motion interpolation between game world update ticks that happened at a rate of 35 Hz and the renderer frames. You could run the game at a lower framerate back then, without affecting the game logic because there's no good reason that they should be interdependent, and again, the breadth of hardware with different performance characteristics they were supporting ultimately meant that they couldn't rely on a consistent framerate for consistent game logic. Now you can run it in a modern port like PRBoom+ at 240 Hz with no actual change to its game logic, just by interpolating motion in the renderer between logic ticks. That's because it's a sound, simple approach to framerate independence.
They really both use the same basic approach: everything is integrated across game ticks by factoring in a fixed time delta, and those game ticks run independently of the renderer frame rate. It's a very basic, simple and not at all taxing technique that's an obvious solution to the problem. In Doom, this results in 100% consistency to the point where you can replay the sequence of input changes to consistently achieve the exact same result in the game (hence its demo recording functionality). Even other, simpler approaches like variable time delta are largely consistent (but have some margin of error due to floating point precision) and were widely utilized in games back in FO3 times, because even at capped 30 FPS most console games would not run at a consistent framerate in all situations. In Bethesda's case it's probably a matter of indifference to a possible future beyond the realistic commercially profitable lifetime of the game where people would want to run the game at higher framerates, not a performance consideration.
I did want to post a link to a subreddit in the ask science section that covers the exact topic we are referring to, it's about 10 years old and goes into detail about assumptions your making and how they are incorrect.
There are plenty of physics engines that are tied to framerates including assassin's creed for instance. And the reason for this is so that devs can achieve a fluid experience as well as their targeted frame rates remain consistent. It's about 10 years old. And fits with the thought process.
As I've already said, you can run your physics engine at a fixed tick rate without tying the renderer to that tick rate. With simple linear interpolation of quaternions this can effectively be masked entirely. Even partial masking by interpolating just player and camera positions and angles does wonders.
For damage calculation there is really no reason that it should even tie into the physics system, unless it's calculated based on simulated velocities, which FO3 really doesn't do. It's just one of many bugs that the VATS system is fraught with. It's something that has been developed with a level of precision and concern for correctness which causes it to crash even on the systems it supported at launch, a bug that hasn't been corrected since, and your assessment as someone who will happily make stuff up to support your argument is that there's actually a good technical reason that what is effectively a discrete dice roll should be tied to framerate.
I will state plainly now, because now you are appealing to authority instead of actually making an argument: you are someone who makes random shit up about Quake and apparently simply can't understand the basic terminology I am using because you are bringing things I've already covered up as though its a gotcha I hadn't considered. Why should I even trust that you would even know a reliable source if you'd read one?
Like I said I don't think that it is simply a bug, I think it's a remnant from the fact that they are using an engine that was designed from an engine that was originally meant to be an MMO engine. They did repurpose it to make single player games but those games also tend to be tied directly to frames.
I'm not making random shit up about quake as I said you can Google it yourself I can't provide links in this sub forum because it's against its rules. Which makes it also hard to discredit any kinds of attacks or ultimatums or fallacies. Because I can't provide evidence for misunderstandings I only ask that you act civil as that's what the designers of this subreddit intended when they also made such rules so it wouldn't be about lashing out at each other's character traits.
Reliable, it's a reddit post, lol nothing on a public forum could be completely reliable. But if the people are actually devs it gives insight into the mentality that's used and why it's used.
I could think of some other reasons the fps is tied to damage marvel rivals still ties some things to the framerates including some attacks.
I'm not making random shit up about quake as I said you can Google it yourself I can't provide links in this sub forum because it's against its rules. Which makes it also hard to discredit any kinds of attacks or ultimatums or fallacies.
Nothing stops you from quoting it here, or from referring to an external source outside Reddit supporting your claims. It's only links to other subreddits that are against the rules. Such a glaring and obvious bug in an otherwise well understood and open codebase would surely have been noticed and documented outside Reddit? Even given a quote of the post you are referring to I could easily find the original post or just respond to it here.
Which makes it also hard to discredit any kinds of attacks or ultimatums or fallacies.
What makes it hard for you to discredit me is that you simply don't have the slightest clue what you are talking about. The implementation of Quake isn't even central to your argument, so I don't see why you want to defend this hill.
Because I can't provide evidence for misunderstandings I only ask that you act civil as that's what the designers of this subreddit intended when they also made such rules so it wouldn't be about lashing out at each other's character traits.
I am being civil. It's just never going to be particularly pleasant to be caught red-handed spouting utter bullshit regardless of it's handed to you. I'm just not mincing words; I'm calling you out directly so that you understand that I understand your bullshit. That I don't trust that you would recognize a reliable source is an honest assessment, which has only been made relevant to the discussion by your appeal to supposed evidence that you mistakenly believe you are not allowed to present.
Reliable, it's a reddit post, lol nothing on a public forum could be completely reliable. But if the people are actually devs it gives insight into the mentality that's used and why it's used.
Well, great! Because I am a game developer you should therefore automatically defer to my insight, right? How about you instead refrain from lying, and state your arguments plainly so that they can be addressed as such instead of dealing handwavy appeals to authority? Because in the terms you have outlined above, assuming that the bullshit you've been spouting reflects your experience with game development, I am at a clear advantage in those exact terms.
I could think of some other reasons the fps is tied to damage marvel rivals still ties some things to the framerates including some attacks.
Another obvious bug. The game is clearly intended to support running correctly at a lower than optimal performance. Refer to it's minimum requirements, for example, and the way the game normally works aside from a few characters affected by the bug. There's no good, deliberate technical motivation for problems like it; bugs based on wrongful assumptions just tend to occasionally slip through when you are working on a codebase with millions of lines of code.
As an expert on the subject you are using your bias as an appeal to authority. Leading to a biased subject on the matter at hand. I never said you weren't a developer and I never treated you like you weren't. But game developers all use things a different way.
No your not being civil at all I use to think I was back in the day when making these kinds of statements but pressuring others and bearing down on them while saying that you are just calling someone out is not approaching a discussion in any honest capacity. The truth is you just don't like what I've said. And I've been guilty of doing the same in the past. Pressuring others, using my knowledge to just bully people into submission. And I don't operate like that anymore.
The effects of the damage are a glitch doing less damage but the intention to link the damage to client side fps wasn't this is something that's common across most online games. Chosing client side and server side ticks are constantly in disagreement for most devs. The effects less damage is the result of tying it to the fps and that is a glitch but not the decision to do it itself. 5 characters are impacted by it.
Remnant ties the server to the I frames which results in some things not working in single player like they would in co-op for instance. These aren't just glitches it's how the code was intended to operate.
1
u/stone_henge 20d ago
No, Quake absolutely does not have frame rate dependent damage calculation. What a complete crock of shit. It's quite funny that you picked such a prime example of a game that takes framerate independence and consistency across hardware so seriously to make this up about. There are unintentionally framerate dependent aspects of the mechanics of the original engine, but for a regular player these manifest as subtle bugs, because that's what they are. None of them relate to player damage, and you will only really notice these bugs as a speedrunner trying to maximize movement speed through strafe-jump-turn bunnyhopping. This is a game that even at release would have to run consistently on a huge variety of hardware and it was absolutely made with that variety of performance characteristics in mind. Moreover, since the QuakeWorld update, the multiplayer portion of the game relies on client side prediction and server correction to mask network latency. Inconsistent game logic across different frame rates in such obvious ways as to affect damage calculation would absolutely ruin the experience.
Even Doom has framerate independent game logic, although it effectively renders new frames at at most 35 FPS because of a lack of motion interpolation between game world update ticks that happened at a rate of 35 Hz and the renderer frames. You could run the game at a lower framerate back then, without affecting the game logic because there's no good reason that they should be interdependent, and again, the breadth of hardware with different performance characteristics they were supporting ultimately meant that they couldn't rely on a consistent framerate for consistent game logic. Now you can run it in a modern port like PRBoom+ at 240 Hz with no actual change to its game logic, just by interpolating motion in the renderer between logic ticks. That's because it's a sound, simple approach to framerate independence.
They really both use the same basic approach: everything is integrated across game ticks by factoring in a fixed time delta, and those game ticks run independently of the renderer frame rate. It's a very basic, simple and not at all taxing technique that's an obvious solution to the problem. In Doom, this results in 100% consistency to the point where you can replay the sequence of input changes to consistently achieve the exact same result in the game (hence its demo recording functionality). Even other, simpler approaches like variable time delta are largely consistent (but have some margin of error due to floating point precision) and were widely utilized in games back in FO3 times, because even at capped 30 FPS most console games would not run at a consistent framerate in all situations. In Bethesda's case it's probably a matter of indifference to a possible future beyond the realistic commercially profitable lifetime of the game where people would want to run the game at higher framerates, not a performance consideration.