Question about framerates

[wowclassicblows]

Can someone explain to me why everything uses frame interpolation instead of just changing the game to use framerate independent timing (for ports that don't care about demo compatibility etc.)?

[Edward850]

Because no port actually fits that category. Even ZDoom which doesn't care about backwards demo compatibility still has demo support for its own builds, and tries to maintain surface compatibility for all wads which is harder to do if you also need to account for timer drift for scripts and thinker logic. The ACS VM for example must by spec maintain a 35hz cycle rate, given that's how its delays, timers and sequence logic operates in.

 

Plus given it would have such a dramatic shift in physics. Gravity notably doesn't scale the same at different speeds. It's less a case of can't, but more nobody actually wants that and the changes it would entail.

[wowclassicblows]

Doesn't make sense. There are more modern FPS games with demo recording that aren't locked to a specific framerate. Physics can be the same regardless of framerate. There are many games with physics that aren't tied to framerate.

[Edward850]

I think you're misunderstanding something. Interpolation detaches rendering from the framerate, which keeps the physics the same while generating new sub frames for rendering based on the world state without changing it. What you were suggesting was the opposite, turning the physics into a delta time of the framerate, which fundamentally changes the precision of the physics, and also introduces the other timing issues that I mentioned because of that change in precision while still having to keep the actor state machine and ACS VM tied to its original 35hz cycle.

 

And yes there are games that use delta timings and appear to run the same at higher framerates, but the catch there is they have physics simulations built from the ground up to account for this variability in precision, and even then sometimes can't (just because you don't notice something, that doesn't mean the problem isn't still there). Take for example Quake's lineage of the infamous 125FPS jumping bug. You additionally have to start accounting for things you never originally did, such as how to manage edge collisions at different simulation speeds. Doom notably does X/Y and Z calculations at different times, so checking Z edges can fundamentally change as an X/Y movement can be rejected at a lower framerate into a high edge where a higher framerate will succeed where more Z movements are performed sooner to raise above the edge.

 

An additional detail that I feel you might be missing: Computers do not offer infinite precision in ordinary mathematics (you can do arbitrary length numbers, but these are only practical to do in offline simulations for things like scientific research, not live and under 16ms). You either have fixed point or floating point precision, both must fit in 32bit or 64bit values, and both with different limitations.

• Fixed point is easy to convert to integers (the integer is just the upper bits of your value) and stays permanently in the same precision regardless of distance, but means it's inflexible.
• Floating point meanwhile is represented as a limited space scientific notation. You can have numbers representing microscopic or size of the universe values, but not one number that represents both at the same time. It also can only represent binary fractionals, 0.1 + 0.2 does not equal 0.3 in floating point.

So no matter what you pick, you will have problems producing accurate physics at different framerates with a delta timer, as the precision offered cannot produce identical results with different deltas.

Edited July 13, 2022 by Edward850

[dasho]

Even more simply put, why change what works?

[wowclassicblows]

51 minutes ago, Edward850 said:

I think you're misunderstanding something. Interpolation detaches rendering from the framerate, which keeps the physics the same while generating new sub frames for rendering based on the world state without changing it. What you were suggesting was the opposite, turning the physics into a delta time of the framerate, which fundamentally changes the precision of the physics, and also introduces the other timing issues that I mentioned because of that change in precision while still having to keep the actor state machine and ACS VM tied to its original 35hz cycle.

 

And yes there are games that use delta timings and appear to run the same at higher framerates, but the catch there is they have physics simulations built from the ground up to account for this variability in precision, and even then sometimes can't (just because you don't notice something, that doesn't mean the problem isn't still there). Take for example Quake's lineage of the infamous 125FPS jumping bug. You additionally have to start accounting for things you never originally did, such as how to manage edge collisions at different simulation speeds. Doom notably does X/Y and Z calculations at different times, so checking Z edges can fundamentally change as an X/Y movement can be rejected at a lower framerate into a high edge where a higher framerate will succeed where more Z movements are performed sooner to raise above the edge.

 

An additional detail that I feel you might be missing: Computers do not offer infinite precision in ordinary mathematics (you can do arbitrary length numbers, but these are only practical to do in offline simulations for things like scientific research, not live and under 16ms). You either have fixed point or floating point precision, both must fit in 32bit or 64bit values, and both with different limitations.

• Fixed point is easy to convert to integers (the integer is just the upper bits of your value) and stays permanently in the same precision regardless of distance, but means it's inflexible.
• Floating point meanwhile is represented as a limited space scientific notation. You can have numbers representing microscopic or size of the universe values, but not one number that represents both at the same time. It also can only represent binary fractionals, 0.1 + 0.2 does not equal 0.3 in floating point.

So no matter what you pick, you will have problems producing accurate physics at different framerates with a delta timer, as the precision offered cannot produce identical results with different deltas.

 

No, I'm suggesting redoing the physics so that the behavior is observationally the same as it was in the original game even though yes it's technically different and more precise.

 

And no, you don't have to keep the actor state machine. You change everything. That's what I was asking about: why hasn't anyone just gone in and redone it to be framerate independent?

 

It could be redone but still be at least superficially the same relative speed as the original game. Using doubles is more than enough precision where no one is going to have problems.

 

Monitor refresh rates keep going up, but the gameplay isn't scaling with that increased capability.

[wowclassicblows]

1 hour ago, dasho said:

Even more simply put, why change what works?

 

Why add widescreen support? 4:3 "worked." Why add higher resolution support? Why enhance it at all? The DOS Doom still "works" in Dosbox.

 

The truth is that it really doesn't work. You could make the game far more responsive by uncapping the framerate. We're going to have 1000hz displays eventually.

[Edward850]

8 minutes ago, wowclassicblows said:

why hasn't anyone just gone in and redone it to be framerate independent?

Well as explained:

1 hour ago, Edward850 said:

It's less a case of can't, but more nobody actually wants that and the changes it would entail.

1 hour ago, dasho said:

Even more simply put, why change what works?

 

2 minutes ago, wowclassicblows said:

Why add widescreen support? 4:3 "worked." Why add higher resolution support? Why enhance it at all? The DOS Doom still "works" in Dosbox.

Widescreen simply changes the field of view. That's rather different from changing the core fundamental aspects of the games physics simulation and state machine.

[wowclassicblows]

Just now, Edward850 said:

Well as explained:

 

Why add widescreen support? 4:3 "worked." Why add higher resolution support? Why enhance it at all? The DOS Doom still "works" in Dosbox.

 

The truth is that it really doesn't work. You could make the game far more responsive by uncapping the framerate. We're going to have 1000hz displays eventually.

[Edward850]

Well okay, go do that then. Nobody is stopping you.

[wowclassicblows]

Regardless, thanks for answering my question. The answer is apathy. It's just a little amusing to me, though, that in a world where people make stuff as pathologically worthless as Doom running itself, there's no interest in actually making the game better.

[Edward850]

You've mistaken confusing apathy with focus. As I already explained, the focus of all source ports thus far has not included rewriting these things, but instead different fields such as expanding the mapping/scripting capabilities, or even the engine dimensions itself with complex portal structures, or complex rendering engines. Rewriting the core of how the physics plays back just incidentally isn't all that important or even wanted to a lot of developers, especially when compatibility has been the key thing since Boom.

[LexiMax]

25 minutes ago, wowclassicblows said:

No, I'm suggesting redoing the physics so that the behavior is observationally the same as it was in the original game even though yes it's technically different and more precise.

 

There is nothing "more precise" about a variable ticrate engine.  In fact, those engines tend to be less deterministic and consistent than fixed ticrates.  Even if I had the time and determination to, I wouldn't want to because I prefer fixed ticrate.

[wowclassicblows]

1 minute ago, AlexMax said:

 

There is nothing "more precise" about a variable ticrate engine.  In fact, those engines tend to be less deterministic and consistent than fixed ticrates.  Even if I had the time and determination to, I wouldn't want to because I prefer fixed ticrate.

 

Actually, you're wrong. Checking state every frame at, say, 144hz is going to give you much more accurate results than only checking at 35hz. Especially given how fast everything in Doom moves. The game is a poster child for the benefits of increased precision.

[wowclassicblows]

6 minutes ago, Edward850 said:

You've mistaken confusing apathy with focus. As I already explained, the focus of all source ports thus far has not included rewriting these things, but instead different fields such as expanding the mapping/scripting capabilities, or even the engine dimensions itself with complex portal structures, or complex rendering engines. Rewriting the core of how the physics plays back just incidentally isn't all that important or even wanted to a lot of developers, especially when compatibility has been the key thing since Boom.

 

I suspect this is due to them not being that interested in actually, you know, playing the game.

[Edward850]

2 minutes ago, wowclassicblows said:

 

I suspect this is due to them not being that interested in actually, you know, playing the game.

Oh okay this is just a troll thread. Should have guessed.

[LexiMax]

2 minutes ago, wowclassicblows said:

Actually, you're wrong. Checking state every frame at, say, 144hz is going to give you much more accurate results than only checking at 35hz. Especially given how fast everything in Doom moves. The game is a poster child for the benefits of increased precision.

 

In that case, I would simply double the game's ticrate to a fixed 70hz, halve the speeds and frametimes in the gamesim, and call it done.  In no universe would I ever make Doom a variable ticrate game.

[dasho]

22 minutes ago, wowclassicblows said:

Regardless, thanks for answering my question. The answer is apathy. It's just a little amusing to me, though, that in a world where people make stuff as pathologically worthless as Doom running itself, there's no interest in actually making the game better.

I look forward to a post with your progress on Github.

[wowclassicblows]

13 minutes ago, AlexMax said:

 

In that case, I would simply double the game's ticrate to a fixed 70hz, halve the speeds and frametimes in the gamesim, and call it done.  In no universe would I ever make Doom a variable ticrate game.

 

That's just a more limited form of variable rate where everything is a multiple of 35 (ie 140 on a 144hz monitor), but it wouldn't be that great, because what about 240hz monitors? The closest multiple would be 210hz, which just wastes 30hz.

[LexiMax]

At faster fixed ticrates, interpolation artifacts become much less obvious, so it all comes out in the wash.

[GooberMan]

3 hours ago, AlexMax said:

There is nothing "more precise" about a variable ticrate engine.  In fact, those engines tend to be less deterministic and consistent than fixed ticrates.

 

I'm just going to quote this since it is an accurate statement.

 

Even the big boy physics engines (Havok, PhysX) tell you this and prefer you keep things to a fixed timestep. Accounting for variable timesteps means using an integration algorithm that can handle such things, which is more computationally expensive. And when you deal with complex physics worlds like those simulations do, they earn their paycheck/reputation by making things as fast as possible. As an example: Why go to all the trouble of a time correcting algorithm when simple Euler will suffice? If timestep is constant then you don't need to worry about accelerative forces going out of whack.

 

There's often no real need to run your physics sim higher than 30Hz. I've worked on million+ sellers that do this. And while implementing 144Hz support for one of them, there's one conclusion that was obvious: As long as objects are interpolated between those 30Hz steps and the user's camera controls are framerate independent, they will not notice.

 

The simple fact about physics detections in a gaming space is that most collisions do not need to operate at a higher frame rate. Any simple object (sphere, box, etc) that moves less than its bounds each simulation frame will not benefit from a higher update rate. Take something bouncing off a wall. Finding the point where the object penetrates the wall and resolving that collision is simple: find the penetration point, divide the distance to that point from the previous position of the object by the distance the object traveled that frame and you get a percentage that will let you work out every value you need. This works just fine regardless of the frame rate. Adding accelerative forces to your object (such as, say, gravity) and you can make a case that it can be more accurate at a higher framerate. And it will be imperceptibly more to boot. It's like saying 0.333333333333 multiplied by 3 equals 0.999999999999 is more accurate than saying it equals 1, but who cares? We've spent all this computing power on a result that was already good enough already for a video game.

 

For the objects where this isn't good enough, there's a feature in modern physics engines known as Continuous Collision Detection. It's especially useful for objects that travel farther than their bounds each frame. It will collect objects that can potentially collide with another object in a frame and perform more rigorous calculations on them to determine the exact collision points of both. These are more computationally expensive, obviously - but they exist because it's computationally expensive to run a simulation frame. Physics at 120Hz versus physics at 30Hz with interpolation and smart use of CCD is a no brainer - the 30Hz model will win. It will take less time to provide results that are good enough in virtually all cases. And you know what that means - it means designers are free to add more things to their game.

 

Let's bring it back to Doom though.

 

Doom's physics operates on that simple collision model. Virtually all objects move less than their bounds each frame. There's a handful of objects that need something like CCD to eliminate glitches - mancubus fireballs and the player comes to mind. Just about every other object moves less than its radius per frame. There's no advantage to running that simulation at a higher framerate versus both re-implementing the collision resolution algorithms (they're very crude by today's standards, and are full of glitches such as wall running and elastic collisions); and implementing CCD for fast moving objects.

 

And at that point you'll break vanilla compatibility. Save games will work fine, but demos will no longer work.

[wowclassicblows]

It's not an accurate statement. If Doom guy is running at full speed towards a projectile that's also moving towards him, you're going to be able to get more precise collisions by checking more often. At the speed those objects are moving, it'll matter. That's a fact. It's not open to debate. You're wrong. It would objectively be more precise to check more often. 

 

I just find it so hilarious that you'd say something as stupid as "virtually all objects move less than their bounds each frame, except for, you know, the PLAYER, which is the primary thing interacting with objects while you're playing." Gee.

 

We're not talking about modern games. We're talking about Doom, which runs so fast that performance literally doesn't matter at all anymore, so you can do whatever you want regardless of how much more computationally expensive it is. I couldn't care less about demo compatibility. I play Doom. I don't watch demos of other people playing it.

[Lippeth]

3 hours ago, wowclassicblows said:

Why add widescreen support? 4:3 "worked." Why add higher resolution support? Why enhance it at all? The DOS Doom still "works" in Dosbox.

I feel this way exactly most of the time.

[GooberMan]

4 minutes ago, wowclassicblows said:

I just find it so hilarious that you'd say something as stupid as "virtually all objects move less than their bounds each frame, except for, you know, the PLAYER, which is the primary thing interacting with objects while you're playing." Gee.

 

Alright, so it is clear that this is a troll thread if you're going to skip over Continuous Collision Detection.

[wowclassicblows]

Just now, GooberMan said:

 

Alright, so it is clear that this is a troll thread if you're going to skip over Continuous Collision Detection.

 

I think you're trolling me by acting like performance for Doom is a concern on modern computers. It's not a crappy console game. You don't need to cut corners to make it run at an acceptable speed. It's a 30 year old game where you can crank up every dial to 10 and it'll still run fine.

[GooberMan]

I'm writing a source port specifically focused on performance concern for modern computers. I know you know this, because you've replied in the thread.

 

I've got two challenges for you

1. Explain to me how Continuous Collision Detection works.
2. Explain why GZDoom runs way slower on, say, a slaughter map than other ports (let's use Woof as a comparison).

If you can't do either, then I suggest you accept what people are saying in this thread instead of continuing this combative approach.

[Graf Zahl]

19 minutes ago, wowclassicblows said:

 

I think you're trolling me by acting like performance for Doom is a concern on modern computers. It's not a crappy console game. You don't need to cut corners to make it run at an acceptable speed. It's a 30 year old game where you can crank up every dial to 10 and it'll still run fine.

 

Actually, you do. Not on vanilla size maps, but some of the larger outputs of this community are really pushing the limit of what can be done in a 1/35 second time slice - especially if you also need to render the scene multiple times during that 1/35 of a second. Your time will very quickly run out then.

 

But that's all completely beyond the point.

To my knowledge only one port (i.e. Vavoom and its successor k8Vavoom) has altered the gameplay logic to run at frame rate. But this fundamentally alters how the game handles, like Edward850 already explained. I think the only reason why there hasn't been a flood of reports of Vavoom breaking some maps is not that the port is so good at it but that it has never been the port of choice for the masses - if some more popular engine were to implement such an approach I'd say it's a given that its issue tracker will get flooded with reports about some edge cases in certain maps suddenly breaking.

You have to be very, very careful when altering the core principles of how the engine performs object movement and collision detection to avoid breaking maps.

Even some of the seemingly far more harmless changes ZDoom made over the years occasionally tend to break some map which then requires adding a compatibility exception for that map. The main difference here, of course, is, that the engine still runs at the default frame rate so just running the original instead of the fixed code will solve the problem for these maps. With dynamic tic rates you cannot do that, you'd have to throttle the entire engine to 35 fps, so you'd lose all smooth rendering.

 

Last but not least, the entire code is so hardwired to its 35 tics per second setup that trying to change it might keep you occupied for several years to iron out all the kinks and issues to make it feel right. So even on economic terms it is really not worth the effort, even if there were no technical concerns.

 

[Kinsie]

48 minutes ago, wowclassicblows said:

It's not an accurate statement. If Doom guy is running at full speed towards a projectile that's also moving towards him, you're going to be able to get more precise collisions by checking more often. At the speed those objects are moving, it'll matter. That's a fact. It's not open to debate. You're wrong. It would objectively be more precise to check more often. 

 

I just find it so hilarious that you'd say something as stupid as "virtually all objects move less than their bounds each frame, except for, you know, the PLAYER, which is the primary thing interacting with objects while you're playing." Gee.

 

We're not talking about modern games. We're talking about Doom, which runs so fast that performance literally doesn't matter at all anymore, so you can do whatever you want regardless of how much more computationally expensive it is. I couldn't care less about demo compatibility. I play Doom. I don't watch demos of other people playing it.

 

Telling the guy who's shipped multiple AAA console launch titles as an engine programmer that he's wrong about fundamental games tech is a bold move, Cotton.

 

[Redneckerz]

6 hours ago, wowclassicblows said:

Regardless, thanks for answering my question. The answer is apathy.

The answer is that its not interesting enough for people to do, given the inherent status of the game.

 

You however seem to make a big case about this, and since you claim shotgun, what stops you from putting your skillz to the test instead of attempting to be a verbal deadweight? 

 

If you can't do that, then the answer is apathy, from your end. 

6 hours ago, wowclassicblows said:

It's just a little amusing to me, though, that in a world where people make stuff as pathologically worthless as Doom running itself, there's no interest in actually making the game better.

Classic undermining of a significant effort (in this case by @kgsws) by labelling it as worthless. Like you have an idea.

 

And for sure there is interest in making the game better - You liked Gooberman's Rum & Raisin, so there definitely is interest

 

6 hours ago, wowclassicblows said:

 

I suspect this is due to them not being that interested in actually, you know, playing the game.

To me it sounds like you are an Ideas Guy of the aggressive kind. ''I think the game benefits from 144hz framerates, so i think it would be great if someone does this.'' without presenting, you know, an actual idea of how you would implement this.

 

You know what they say about Idea Guys? Its just that, ideas. Not a theory. A theory requires an implementation on paper. All you do is say you have this idea and then shoot down actual developers when they tell you why that idea isn't practical.

 

6 hours ago, Edward850 said:

Oh okay this is just a troll thread. Should have guessed.

Didn't the low post count give it away and the instant ''no u wrong'' on your explanation?

2 hours ago, wowclassicblows said:

We're not talking about modern games. We're talking about Doom, which runs so fast that performance literally doesn't matter at all anymore, so you can do whatever you want regardless of how much more computationally expensive it is. I couldn't care less about demo compatibility. I play Doom. I don't watch demos of other people playing it.

The fact you say this yet we have Planisphere 2 still struggling on modern rigs (And Rum & Raisin making a great effort to improve the gameloop renderer!) tells me you are wrong yourself.

 

Anyway TLDR: New user, strong opinion, u wrong, jadda-jadda. If you were a salesman, i wouldn't buy a painting from you.