ZDoom

Tested with: 2.9pre-1100-gb2a88c1
Test material: Eriguns (load eriguns2.pk3)

Give yourself all weapons, switch to the sword (slot #1) and attack with it once. At the end of attack sequence, as it goes back to its idle position, the weapon "jumps" for a moment.

This is due to the new weapon offset interpolation stuff (which looks awesome BTW). This is one case I can easily patch in the mod, since this seems like something that's difficult to really address in the general case.

I have a similar problem in many of my own weapons (assuming I've understood the issue), which manifests whenever selecting a weapon, if the previous weapon had a very fast Deselect (if A_Lower only needed to be called once or twice). So if this can't be fixed engine-side, I'll need to be told what to do on my end to fix it.

Ed could you show me an example of what you're talking about please?

Here. In this test, the fist is now designed to lower instantly. Try switching away from the fist to your pistol (or any other weapon), and you'll see the pistol briefly flicker in front of your eyes before it gets raised properly. This didn't happen in older versions of ZDoom.

Xaser wrote:since this seems like something that's difficult to really address in the general case.

Yeah I can't really do anything here.
The EriBlade's y offset goes from 32 (because of A_WeaponReady) to 72 when it enters the "RaiseNope" state which means the weapon does actually jump up decorate-wise.
A quick and easy fix would be to set the offset to (10, 72) during the TNT1 frames before the weapon raises back up.

Ed the Bat wrote:Try switching away from the fist to your pistol (or any other weapon), and you'll see the pistol briefly flicker in front of your eyes before it gets raised properly.

Now that's something that actually needs to be properly fixed.
The problem is that some of the already existing issues with overlays that have yet to be addressed will have to rely in part on this fix and I need Graf to respond to have this sorted out.
I guess I'll just PM him then..
In case you'd want it, here's the commit that fixes your issue.

I'll be honest here:

Interpolating the weapon offset cannot be done implicitly because the PSprite severely lacks the needed information to decide when to do it and when not. For now I just disabled this for anything but the bobbing itself. Ultimately the only solution will be to explicitly flag any state that changes offsets or add a weapon flag to tell that it's ok to do so.

Leonard2 wrote:The problem is that some of the already existing issues with overlays that have yet to be addressed will have to rely in part on this fix and I need Graf to respond to have this sorted out.
I guess I'll just PM him then..
In case you'd want it, here's the commit that fixes your issue.

Where's the pull requests for this stuff?

Graf Zahl wrote:Interpolating the weapon offset cannot be done implicitly because the PSprite severely lacks the needed information to decide when to do it and when not. For now I just disabled this for anything but the bobbing itself. Ultimately the only solution will be to explicitly flag any state that changes offsets or add a weapon flag to tell that it's ok to do so.

I was aware that this could have caused some odd movements but I never thought it would be that much of a problem.
A thread about this was already made which caused a whole bunch of other suggestions.
Like Xaser said, this should stay on by default because honestly, having the weapons raise/lower at 35 fps hurts my eyes.
A CVar and some of the listed suggestions would be a good thing in my opinion.

Graf Zahl wrote:Where's the pull requests for this stuff?

It was closed a little while ago.
Here's a new one with all the stuff that needs fixing.
The commits that touch on the strife stuff depend in part on the interpolation fix.

Leonard2 wrote:Like Xaser said, this should stay on by default because honestly, having the weapons raise/lower at 35 fps hurts my eyes.

No, it should not. But A_Raise and A_Lower should flag the current change as ok for interpolation.
I have already disabled the unconditional interpolation but not committed yet.

The main problem right now is to build something robust that won't create a mess, but that will need a bit of thinking first.

Huh. So if I'm reading that correctly, A_Raise/Lower will interpolate by default, but A_WeaponOffset will be opt-in?

I can live with this since it's more backwards-compatible (e.g. Hexen/Eriguns), so long as it doesn't end up being a thing users and modders both have to jump through hoops to enable.

I have no idea yet how to handle this decently. There's just so many edge cases that a universal solution is not possible. Fact is, that without hints the code just cannot determine if a sprite change means a movement step or just a switch to a sprite with a different offset on a state that alters the offset, i.e. it cannot distinguish between a move and an offset change for other reasons.

Again:

I am not a weapon mod designer, so I am not the most qualified person to resolve this issue. Unless you people give some feedback the only way to resolve this issue is to disable interpolation of the non-bobbing stuff.

I believe Leonard might be looking into this. At least, we've been talking, though he has yet to confirm or deny.

All right, here's my set of recommendations (weapon modder's perspective):

• Bobbing: Interpolated by default. Can be disabled on a per-state basis by setting a parameter flag on A_WeaponReady.
• Raise/Lower: Interpolated by default. Can be disabled on a per-state basis by setting a parameter flag on A_Raise/A_Lower.
• A_WeaponOffset: No interpolation by default. Can be enabled on a per-state basis by setting a parameter flag on A_WeaponOffset.
• "Offset" keyword: No interpolation, period, as it's been superseded by A_WeaponOffset.
• Finally, add a CVAR which disables interpolation globally, since some folks are not fond of it in general.

This likely strikes the right balance. Bobbing interpolation is on-by-default as it has not caused any issues as far as I know, and we know that offsets do cause weirdness with existing stuff (e.g. Eriguns2, Hexen), so they're opt-in. Raise/Lower are the grey area since there's at least one claim of it causing a 'jump' in a custom animation (though others work fine -- Zero Tolerance shows no faults, for instance), but since it affects all weapons, it's gotta stay on or else we'll never get PrBoom-style interpolation on vanilla guns and the like. Any issues caused by it ought to be a vast minority.

This scheme offers full control for modders, and for the people who dislike interpolation in general, they can turn it all off.