Does slowdown in (g)zdoom look/feel the same way as vanilla?

[invictius]

I don't have a machine slow enough to test any iwad levels in, just wondering if zdoom with poor framerates when under load behaves the same way as those old machines with vanilla, e.g not what's going on under the hood but whether the framerate slowdown will look and feel similar.

Also applying the same thing to doom95, I'm guessing that and vanilla will slow down in a very similar way?

[Hellser]

Low framerates look the same regardless of the system.

[invictius]

Low framerates look the same regardless of the system.

And regardless of it being a shortfall/bottleneck in cpu vs gpu power?

[wildweasel]

It'll appear about the same because it's the same underlying game logic, more or less. Doom has always had a frame-skipping system in place to keep the game running roughly the same speed regardless of how quick the machine is. It's not something like, say, Dead Rising 2 or what-have-you where the game logic and framerate are inexorably locked together, where the game will go into slow-motion because the renderer can't keep up with the logic.

[drfrag]

It should be the same, in old DOS Doom despite of frame skipping if the CPU was way too slow the game would actually ran clearly slower (back then 12 fps was considered playable on a 386). But if the limiting factor was the graphic card (such as an isa card on a 486) the game would run at full speed with a low frame rate, just for curiosity.

[invictius]

It should be the same, in old DOS Doom despite of frame skipping if the CPU was way too slow the game would actually ran clearly slower (back then 12 fps was considered playable on a 386). But if the limiting factor was the graphic card (such as an isa card on a 486) the game would run at full speed with a low frame rate, just for curiosity.

You mean in slow (but smooth) motion?

[drfrag]

Of course not, the lower your framerate the slower the game would run. Don't know exactly how much but high detail max screen size could be half speed on a 386 for instance. That smoothness happened with timedemo but it was too slow for a 386 and could take almost forever.
But hey at least vanilla Doom could not freeze since it could not run Brutal Doom.

[invictius]

Of course not, the lower your framerate the slower the game would run. Don't know exactly how much but high detail max screen size could be half speed on a 386 for instance. That smoothness happened with timedemo but it was too slow for a 386 and could take almost forever.
But hey at least vanilla Doom could not freeze since it could not run Brutal Doom.

I'm just trying to picture how it looks running "full speed with a low frame rate" compared to how you said it would frame skip on a 386. Or did you mean that simply on a good system using an isa video card would result in the same framerate slowdown as a 386?

[Graf Zahl]

Yes and no. If I understand it correctly, the performance bottleneck is the speed at which the CPU can feed the data to the graphics card. This is not dependent on floating point performance but it is both dependent on CPU and bus speed.

[drfrag]

I just meant with a low framerate the game will (almost always) be slower (not just choppy) since the frame skip cannot keep up. Remember that higher resolutions also require a faster CPU. My answer to the original question would be yes.
Also i'm the guy who played Doom E1 more than 200 times but unfortunately most of them on a 386sx with only 3 mb of ram, i cheated to make the game run.
On floating point i'm almost sure that the renderer will be slower on a pentium after the floatification but i haven't tried, those machines have dying hard drives and they got no usb. There's a gcc optimization for doubles on pentiums but the performance gain would be minor and the executable would require more ram. I think it's not worth even optimizing for pentium ii.

[Graf Zahl]

The inner loops of the renderer don't need floating point and even with a float-based engine would have been kept as fixed point just for speed. Floats would have been an option to avoid that fixed point mess in the play code mainly.