35FPS Cap Lumped in with Rendering Interpolation

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

Locked
Minigunner
Posts: 3
Joined: Tue Oct 25, 2016 4:26

35FPS Cap Lumped in with Rendering Interpolation

Post by Minigunner »

There's been a really arbitrary move done with the recent addition of weapon interpolation: no CVar has been created for it, and instead the menu option for cl_capfps has been renamed to "Rendering Interpolation". I'd totally be fine with this feature, but it has the one problem of completely breaking Offset() animations that change sprite frames and require a different offset path to suit. It'd be nice for this feature to have its own CVar for compatibility with older mods, and the menu option reverted.

(In the meantime though, I certainly will be adapting my own mods to suit this system.)
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: 35FPS Cap Lumped in with Rendering Interpolation

Post by Graf Zahl »

Can you describe what precise combination of settings causes a problem? I have yet to see a weapon that is affected by this, although it had been mentioned several times.
Minigunner
Posts: 3
Joined: Tue Oct 25, 2016 4:26

Re: 35FPS Cap Lumped in with Rendering Interpolation

Post by Minigunner »

Let's say, for example, you want to use Offset() to make the shotgun animation smoother. You're gonna want to start SHTGB0 at a lower and to-the-right offset to start off the smooth animation. However, the interpolater takes the offset of the last frame (SHTGA0 at default offset) and applies it to SHTGB0, leading that sprite to jerk down from the default offset to the lower offset before it moves upward to subsequent frames. The way to account for that would be to offset the sprites themselves (or use TEXTURES) in order to make the Offset() path a single path instead of changing for each sprite. Alternatively, making the interpolater account for 0-tic frames would be good, though I've been told it's not possible due to the feature being post-process.

A couple of my own mods have the issue, but it's been noted to be problematic with the Sonic Railgun in Hard Doom, which follows a similar animation method to what I described.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: 35FPS Cap Lumped in with Rendering Interpolation

Post by Graf Zahl »

Actually, this cannot be fixed without adding to the syntax. It's simply impossible to determine whether the offset should be reset or interpolated between frames with different sprites, unless the mod tells the engine.
User avatar
NeuralStunner
Posts: 253
Joined: Tue Dec 29, 2009 3:46
Location: IN SPACE
Contact:

Re: 35FPS Cap Lumped in with Rendering Interpolation

Post by NeuralStunner »

The issue Mini mentioned is not a new discovery at all. "Fix it mod-side" is no solution, when the real issue is a purely cosmetic feature messing up something that's always worked properly. If anything, an opt-in to interpolate between different sprites (assuming that's not what you meant).

Going back to the original problem: These should really not be tied to the same setting. I've mentioned a few times on the ZDoom forum (in almost every thread involving the feature, actually) that I really can't handle the hyper smooth weapon switch, but at the same time, I can't take the camera moving around the world at 35 FPS. "Interpolate Monster Movement" has been its own setting since forever. This should be no different!
Dean Koontz wrote:Human beings can always be relied upon to exert, with vigor, their God-given right to be stupid.
Spoiler: System Specs
Minigunner
Posts: 3
Joined: Tue Oct 25, 2016 4:26

Re: 35FPS Cap Lumped in with Rendering Interpolation

Post by Minigunner »

Oh, Xaser suggested a flag for A_Offset? That would certainly be helpful.
Locked

Return to “GZDoom”