Icon of Sin / Baphomet
User Control Panel | Member List | FAQ | Privacy Policy | Blogs | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > WADs & Mods > Doom 2 Minor Sprite Fixing Project - v1.8 Release (updated 11/15/16)
Pages (14): « First ... « 11 12 13 [14]  
Author
All times are GMT. The time now is 10:28. Post New Thread    Post A Reply
Gez
Why don't I have a custom title by now?!


Posts: 15209
Registered: 07-07



Viggles said:
I'm guessing that GZDoom may have hardcoded clipping offsets for certain sprite frames, which it doesn't apply if that frame is replaced in a PWAD.

It's a relatively recent thing.

Old Post Feb 12 2017 01:34 #
Gez is online now || Blog || PM || Post History || Add Buddy IP || Edit || Quote
Revenant100
Ask me about Lost Soul sprites


Posts: 411
Registered: 07-04


This is an interesting predicament, and I'm not sure I have a good answer to it.

Viggles said:
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.

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."

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

Old Post Feb 12 2017 23:52 #
Revenant100 is offline Twitter account Youtube || Blog || PM || Post History || Add Buddy IP || Edit || Quote
Gez
Why don't I have a custom title by now?!


Posts: 15209
Registered: 07-07


If I understand the crux of the issue:

There's an AB animation that jitters.
Sprite Fix solves the problem by changing the A offsets so that it aligns better with B.
GZDoom solves the problem by changing the B offsets so that it aligns better with A.
When combining both, the problem is back.

A simple solution would be to change GZDoom's offset list to make them coincide with the sprite fix project's.

Old Post Feb 13 2017 10:25 #
Gez is online now || Blog || PM || Post History || Add Buddy IP || Edit || Quote
Viggles
Green Marine


Posts: 41
Registered: 01-15


Gez: That's a good summary, though it's not precisely what's going on in this case. It's certainly one version of the problem that can come up.

In this case the original AB animation doesn't jitter vertically at all; Sprite Fix is overriding one of the frames to fix some pixels and make the two match better horizontally, but it doesn't alter the vertical offset of either frame. Those remain consistent with vanilla doom(2)'s.

GZDoom wants to override the Y offset of both the impaled human animation frames (POL6A0 and POL6B0) from 62 to 65, presumably to play nicer with OpenGL's sprite clipping. But because one of the frames is replaced in the PWAD, its Y offset is left alone, so it's now inconsistent with the other frame that receives the offset override.

GZDoom's offset overrides could be altered to be consistent with Sprite Fix's in each case; but that only fixes it in this particular instance, for this particular version of Sprite Fix, and it ignores the decisions that went into GZDoom's offset choices. (Indeed, in this case I imagine Sprite Fix would actually want to use GZDoom's raised offsets - if it didn't mean breaking idgames regs by shipping an unmodified original sprite solely to apply a better offset.)

Moreover I can see this edge case - PWAD replaces part of a sprite animation, keeping the offsets the same as vanilla - coming up for a lot more than just Sprite Fix. As a contrived example, imagine a PWAD that made the zombieman's muzzle flash blue but didn't touch the other frames.

I think Revenant100's proposal - that GZDoom ought to treat sprite animations as a group, and not override any offsets for that group if any sprite in that group has been replaced - would be the safest way to solve this kind of issue.

Old Post Feb 13 2017 11:07 #
Viggles is offline Github || Blog || PM || Post History || Add Buddy IP || Edit || Quote
Viggles
Green Marine


Posts: 41
Registered: 01-15


Looks like there's a fix for the partially-replaced-sprite-offset issue in GZDoom dev builds now: https://github.com/coelckers/gzdoom...805a23294b4799e

(I haven't tested it myself though.)

Old Post Feb 17 2017 12:12 #
Viggles is offline Github || Blog || PM || Post History || Add Buddy IP || Edit || Quote
Revenant100
Ask me about Lost Soul sprites


Posts: 411
Registered: 07-04


I've just tested the newest GZDoom dev build with this change, and everything looks like the cat's pajamas. There are no longer any bouncing issues with any of the sprite clipping settings. Thank you, mysterious code committer!

Old Post Feb 20 2017 03:39 #
Revenant100 is offline Twitter account Youtube || Blog || PM || Post History || Add Buddy IP || Edit || Quote
All times are GMT. The time now is 10:28. Post New Thread    Post A Reply
Pages (14): « First ... « 11 12 13 [14]  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > WADs & Mods > Doom 2 Minor Sprite Fixing Project - v1.8 Release (updated 11/15/16)

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by vBulletin
Copyright vBulletin Solutions, Inc.