Ask me about Lost Soul sprites
This is an interesting predicament, and I'm not sure I have a good answer to it.
This would indeed be a way to address the issue (the hard coded offsets will be lost, but that seems unavoidable no matter what), but that poses a different problem. A difficulty I faced a year ago was attempting to upload this WAD to the idgames archive. It was initially rejected on the grounds of containing "unmodified id Software resources." I pointed out that every included lump was demonstrably edited in some way, but the concern was that the modifications weren't "substantial enough." While this decision was reevaluated a year later, to now begin deliberately including sprites that are expressly unmodified, even for the purpose of forward compatibility in certain source ports, is veering back towards those original concerns. Granted, it wouldn't require the addition of many unmodified sprites to fix this particular jittering, but that's still content that falls under the description of "unmodified id Software resources."
The jitter does go away if every frame of the animation is replaced in the PWAD, so that could be one way to keep GZDoom happy.
As a more practical matter, I'm wondering if I can realistically offer forward compatibility for all possible future scenarios. In its current state, these sprite fixes are essentially vanilla-compatible. Barring the IWAD itself, it can't go any layer lower. If a source port has troubles handling the sprite fixes, then I think the question should be where the breakdown is occurring in between. It's true that GZDoom's logic in this case is working correctly, but this is also an example of where these hard coded exceptions are failing in a real world test case.
I'll posit a possible solution I've come up with on GZDoom's end: The hard coded offset exceptions examine each sprite individually. However, we know by the sprite names that these are effectively groups, i.e. TGRN** rather than considering TGRNA0, TGRNB0, TGRNC0, and TGRND0 as independent lumps. Hence, they should be treated as groups. If the engine detects any sprites in a loaded PWAD overriding anything within this group (it doesn't have to be a specific frame or all frames), it should disable the hard coded offsets for the entire group. I believe this would fix the problem here with the sprite fixes and may future proof it against most (all?) further similar happenstances.
Last edited by Revenant100 on Feb 13 2017 at 00:01