Changes to the modern Unity versions of Doom

[drfrag]

I think your fix can't be used now becouse the gameinfo flags are not exported to ZScript. But as a curiosity i could add the flag to WadSmooth too as i've hacked it into LZDoom with a CVAR.
Now that i think of it unless i'm missing something we could add the flag to WadSmoosh too since offsets are applied only if the texture is wider than 320 pixels.

[Rachael]

Commit 0204051 making the widescreen status bar handling unity-wad-specific puts WadSmoosh in a slightly annoying position here, as users might bring either their original or new widescreen source WADs, and I'd prefer for either to work with no overrides to built-in GZDoom classes or data - currently it seems like I'd have to include a custom status bar definition with WadSmoosh that uses the method I posted above.

Have you viewed the commits since then?

Adjusting the status bar graphic is only done under very very specific circumstances.

1) alwayscenterstatusbar must be 1 in the iwadinfo (which it is not for wadsmoosh)
2) the width of the status bar must be greater than 320
3) the status bar must have (0,0) for its offsets
4) the "stbar" texture in question must only exist in an iwad, it will not work from a pwad.

Wadsmoosh only fits criteria 3 and 4 above, but all must be true in order for the adjustment to be made.

If you want GZDoom to adjust 'stbar' graphics automatically for Wadsmoosh, just let us know and I'll put the alwayscenterstatusbar flag in the Wadsmoosh definition - or we can even remove wadsmoosh definition entirely and you can take the iwadinfo and make wadsmoosh a ipk3, if that will work better for you.

I am actually going to rename that flag because it has become so much more restrictive since it was created.

[JPL]

Commit 0204051 making the widescreen status bar handling unity-wad-specific puts WadSmoosh in a slightly annoying position here, as users might bring either their original or new widescreen source WADs, and I'd prefer for either to work with no overrides to built-in GZDoom classes or data - currently it seems like I'd have to include a custom status bar definition with WadSmoosh that uses the method I posted above.

Have you viewed the commits since then?

Adjusting the status bar graphic is only done under very very specific circumstances.

1) alwayscenterstatusbar must be 1 in the iwadinfo (which it is not for wadsmoosh)
2) the width of the status bar must be greater than 320
3) the status bar must have (0,0) for its offsets
4) the "stbar" texture in question must only exist in an iwad, it will not work from a pwad.

Wadsmoosh only fits criteria 3 and 4 above, but all must be true in order for the adjustment to be made.

If you want GZDoom to adjust 'stbar' graphics automatically for Wadsmoosh, just let us know and I'll put the alwayscenterstatusbar flag in the Wadsmoosh definition - or we can even remove wadsmoosh definition entirely and you can take the iwadinfo and make wadsmoosh a ipk3, if that will work better for you.

I am actually going to rename that flag because it has become so much more restrictive since it was created.

Ah, excellent, just saw the most recent commits, thank you for adding that. Yes, please go ahead and set AlwaysCenterStatusBar to 1 for the WadSmoosh entry in iwadinfo.

[Rachael]

Will do.

[Graf Zahl]

I think now that there's official widescreen pics the entire logic here needs to be rethought or we will face problems down the line when the first mods appear to make use of it.
The widescreen scaling flag is a good example, I think it now needs to defaullt to 3 - and screw the handful of titlepics and interpics that may be affected by it.
Unfortunately I won't be able to take care of this myself for the next week or so but please let's do it right this time so that it also works with the inevitable map sets that are about to come and use this feature. There's absolutely no need for a hasty inclusion of support here. I opened that thread over at Doomworld for a reason - sadly no other developer seems to be interested...

[Rachael]

So far the only thing I've touched here is the status bar, and I am fairly sure that it was a good change.

However, inevitably with the bad standard that Bethesda has set with the new one, there will be more requiring this change and there will unfortunately be no way for GZDoom to be able to tell apart the good ones from the bad.

As for other developers - you simply can't force anyone to work with you.

[Graf Zahl]

As for other developers - you simply can't force anyone to work with you.

And the end result will be that every port will do its own incompatible variation of support and no mod will run on all of them due to these incompatibilities.

[Rachael]

I renamed the new stbar flag.

[JPL]

The two issues I found running the Unity doom.wad in GZDoom:
- Episodes 1, 2, and 3 intermission screen backgrounds draw as expected, but the small animated portions don't line up properly.
- As others have pointed out, the end-of-ep3 scroller doesn't behave correctly.

[JPL]

Here's a shot of what unity doom.wad's ep1 intermission looks like (discrepancies circled):

Any idea what GZDoom's fix for this will be?

Since the widescreen art is a pretty visible improvement, I'd like to add full support for the Unity IWADs to WadSmoosh, allowing people to either use them alone, use their original WADs, or provide both and only rip the widescreen assets from the former. I'm trying to determine if I should include my own intermission definitions based on which version is provided, or let some future GZDoom compat functionality handle it.

[JPL]

Here are my updated ep1, ep2, and ep3 intermission scripts that work properly with widescreen:

https://heptapod.host/jp-lebreton/wadsm ... widescreen

For WadSmoosh I determine if the user is providing the Unity wad and copy them over. Not sure if this is directly useful to GZDoom but if so the numbers in those files will save someone else the trouble.

[Rachael]

The issue is that we still have the 'old' Unity versions - meaning, that GZDoom needs to be able to support both the old and the new.

With literally no difference in the WAD directory structure between the two (only assets are changed), this poses a major challenge for us because we are unable (as of yet) to filter based on content. This change to the unity version, however, strengthens the case for that, more than it already had one beforehand. (We've been discussing it before with regards to fixing old WAD assets using compatibility)

[JPL]

The one thing I can't make work 100% is the episode 3 bunny scroller. Looking over the wiki page for it and trying a few things (eg splitting the pre-scroll image out into a separate intermission def), I'm not sure there's any existing functionality that will make it look right.

[JPL]

The issue is that we still have the 'old' Unity versions - meaning, that GZDoom needs to be able to support both the old and the new.

With literally no difference in the WAD directory structure between the two (only assets are changed), this poses a major challenge for us because we are unable (as of yet) to filter based on content. This change to the unity version, however, strengthens the case for that, more than it already had one beforehand. (We've been discussing it before with regards to fixing old WAD assets using compatibility)

Yeah, I can definitely see how it puts your codebase in a tight spot. All I do in the WadSmoosh code (which is admittedly only trying to do a very very simple thing, by comparison) is test if the TITLEPIC is >320 pixels wide. But that only works for (and cares about) the tiny known pool of IWAD content.
Good luck!

[Graf Zahl]

TBH, I think that instead of chasing after IWAD changes in the Unity version we should seriously think about including the widescreen images in our .pk3 ourselves and let it override the IWAD content unconditionally, then we are no longer at the mercy of others changing this stuff in breaking ways.