Changes to the modern Unity versions of Doom

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: Changes to the modern Unity versions of Doom

Re: Changes to the modern Unity versions of Doom

by Chris » Sun Sep 13, 2020 4:27 pm

JPL wrote:The one thing I can't make work 100% is the episode 3 bunny scroller.
I don't think it'll ever look right. As it is, the original image is sized and laid out such that certain elements come in to view at a specific time relative to the music; the guitars start just as the signs of destruction come into view, and the music picks up as more destruction becomes apparent. Simply extending the width of the image and widening the display ratio to show more of the image will throw that off. You could work around it by redesigning the image, moving elements around to ensure they come into view at the proper time, and adjusting the amount the image scrolls, but it would have to be specific to a given display ratio. I don't think it would be possible to have a single-image-for-all-ratios like the non-scrolling backgrounds, since it would need more work than adding on to the sides.

Re: Changes to the modern Unity versions of Doom

by Gez » Sun Sep 13, 2020 3:33 pm

JPL wrote:I'm not sure there's any existing functionality that will make it look right.
Yep, there isn't at the moment. Horizontal scrollers and widescreens have been a stumbling block, so the widescreen image support was not extended to them yet.

I guess the Unity update forces the issue by providing an official implementation to use as a reference.

Re: Changes to the modern Unity versions of Doom

by Graf Zahl » Sun Sep 13, 2020 3:18 pm

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.

Re: Changes to the modern Unity versions of Doom

by JPL » Sun Sep 13, 2020 2:44 pm

Rachael wrote: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!

Re: Changes to the modern Unity versions of Doom

by JPL » Sun Sep 13, 2020 2:42 pm

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.

Re: Changes to the modern Unity versions of Doom

by Rachael » Sun Sep 13, 2020 2:41 pm

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)

Re: Changes to the modern Unity versions of Doom

by JPL » Sun Sep 13, 2020 1:30 pm

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.

Re: Changes to the modern Unity versions of Doom

by JPL » Sun Sep 13, 2020 10:03 am

Here's a shot of what unity doom.wad's ep1 intermission looks like (discrepancies circled):
Screenshot_Doom_20200913_085625.png
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.

Re: Changes to the modern Unity versions of Doom

by JPL » Tue Sep 08, 2020 7:55 pm

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.

Re: Changes to the modern Unity versions of Doom

by Rachael » Mon Sep 07, 2020 9:38 pm

I renamed the new stbar flag.

Re: Changes to the modern Unity versions of Doom

by Graf Zahl » Sun Sep 06, 2020 1:43 pm

Rachael wrote: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.

Re: Changes to the modern Unity versions of Doom

by Rachael » Sun Sep 06, 2020 6:26 am

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.

Re: Changes to the modern Unity versions of Doom

by Graf Zahl » Sun Sep 06, 2020 5:31 am

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... :?

Re: Changes to the modern Unity versions of Doom

by Rachael » Sat Sep 05, 2020 1:53 pm

Will do.

Re: Changes to the modern Unity versions of Doom

by JPL » Sat Sep 05, 2020 1:41 pm

Rachael wrote:
JPL wrote: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.

Top