ZDoom

This is probably implicit, but agreed with Leonard2 and Graf. That oughta square it away for everyone.

And hopefully can fix a [url=http://forum.zdoom.org/viewtopic.php?f=2&t=54033]certain bug[/url] that's been bothering me for a while.

Agreed and agreed. The "never/default/always" setting is the best way to handle it.

Agreed mostly. I think, though, 'offset' should be extended then by an optional third boolean parameter that can explicitly enable interpolation. With that the Hexen weapons could be fixed and everything was perfect.

The discussion at the time basically stopped at "when should we interpolate movements implicitely" [url=http://forum.zdoom.org/viewtopic.php?f=2&t=52759&start=15#p928177]here[/url].
Looking back at it, here's what I think should be done based on one of Xaser's posts:
[list][*][b]Bobbing:[/b] Interpolated period. Why would you want to disable interpolation for such a thing honestly?
[*][b]Raise/Lower:[/b] Interpolated by default. Can be disabled with an A_Raise/A_Lower parameter.
[*][b]A_WeaponOffset:[/b] Interpolated by default. Can be disabled with a parameter as well. IIRC this function came around at the same time I did the overlay stuff so people using it should be aware of the interpolation which is why I think it should be on by default.
[*][b]"Offset" keyword:[/b] I'll have to agree with Xaser here and make it off by default as old mods used (and could only use that) it without the interpolation in mind which gave rise to some reported issues HOWEVER I would like the possibility to turn it back on with a CVAR as I think it looks great regardless with some old weapons that made proper use of offset animations.
[*]Finally, add a level-based CVAR with the following options: never interpolate, default behavior and default with enforced interpolation for the offset keyword on top of that for people like me.[/list]
This should make everyone happy: every issues should be fixed, modders have access to the interpolation using the proposed parameters and users can set it up to their liking.

That's a question for Leonard2.

Did anyone ever figure out a way to selectively disable the interpolation for overlaid/HUD sprites? The sprites tend to jump visibly if you change their offsets on the fly.

Currently, I figured I could weave in an invisible frame, and change to the new offset during this frame, hiding the jumping effect. The downside to this is that it requires 1 tic where the overlay is showing nothing, every time you want to change an offset.

Alternatively, I would have to manage my sprites in a way that keeps their offsets fixed throughout the animation.

I think I'm going to split the flipping from it and make a separate pull request so that part doesn't have to wait as long, if you think that's alright. A mere flip of the X axis, nothing more. I understand the renderstyle testing should still happen, but it was foolish of me to get something so simple barred by something much more complex.

I'm mainly waiting for someone else to drop a word but that doesn't seem to happen ever... :(

I'm aware. I figured you were waiting on something for the alpha/style types, so I committed these separately since they're a lot simpler.

Looks ok to me. Be aware that this conflicts with your other overlay related PR.

I would like Graf to confirm that though, it would be nice to hear from him directly on this.

Well it passes my cursory test, then. But a more seasoned developer will need to do a more thorough check - as I've said, I'm not qualified to make that determination. (Yet)

Oh. That line actually includes the same check plus a few others that are necessary in order to retrieve the function mPSPIndex which is what makes OverlayID tick. It makes sure a player exists, along with it being an action function and there being a non-null stateinfo stuffs.

So no worries there. :P

Just this one: https://github.com/rheit/zdoom/pull/842/files#diff-9e2daeb2926e243ec52303e8b3c196f7R1036 - like I said, it's probably just because I don't know what it does. The reason it red-flags me is because you replaced a nullptr check.

[quote]Though at this point I wouldn't be surprised if Zscript supercedes it entirely.[/quote]
I had actually written up a much longer post predicting exactly this, but I deleted most of it before I submitted that. >_>

[quote]This is neither code bloat nor a hack.[/quote]
I know. I didn't say this was, I was just saying in general.