Changes to the modern Unity versions of Doom

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

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!

Changes to the modern Unity versions of Doom

Postby Kinsie » Thu Sep 03, 2020 12:16 pm

The Unity versions of Doom and Doom 2 have just released an update (and been released to people who own the old DOS-based Steam versions) that changes how the IWAD works from the previous release, and also makes some changes to the IWAD in general.

1.) The IWAD is no longer stuffed inside of a Unity resource file and no longer needs extraction. It sits comfortably inside DOOM_Data (or DOOM II_Data)\StreamingAssets. They use the same filename as the original releases (doom.wad, doom2.wad)
2.) All 4:3-centric art assets (TITLEPIC, HELP, the HUD etc.) have been updated to work in 16:9. The E3 bunny scroller looks pretty messed up as a result, and the HUD is all offset and as such doesn't look quite right. That last one can likely be fixed with a game-filtered TEXTURES lump, but the scroller might need additional surgery. Everything else (Title screen, Help, Credits, Bossback...) seem to work okay.
3.) An extras.wad file is also present, including an "official" DSSECRET sound and various graphics lumps used for additional elements specific to the Unity-based source port (automap counters, weapon select scroller).
4.) A set of OGG files have been added in a "Soundtrack" subfolder, containing renders of the original MUS files straight from a SC-55 Mk2.

EDIT: The original DOS IWADs are still in the same place for the Steam releases, so nothing has to change there detection-wise, the original experience is still intact.
User avatar
Kinsie
Dog Days
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: Changes to the modern Unity versions of Doom

Postby Redneckerz » Thu Sep 03, 2020 2:09 pm

5). DeHackEd support is now officially in. Note that this goes for the DEHACKED lumps inside a wad. The port does not support seperate .deh's.

Huge news all around.
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)

Re: Changes to the modern Unity versions of Doom

Postby Gez » Thu Sep 03, 2020 2:45 pm

Redneckerz wrote:5). DeHackEd support is now officially in. Note that this goes for the DEHACKED lumps inside a wad. The port does not support seperate .deh's.

Huge news all around.

Yeah, but that one point is a bit off-topic here, since it doesn't concern GZDoom support of the Unity ports' data.

Which is, I think, the reason why this is in the GZDoom development < Bugs forum.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Changes to the modern Unity versions of Doom

Postby JPL » Thu Sep 03, 2020 8:29 pm

The status bar centering can be fixed to work with both original WADs and the Unity WADs by changing line 41 of zscript/ui/statusbar/doom_sbar.zs, from:
Code: Select allExpand view
DrawImage("STBAR", (0, 168), DI_ITEM_OFFSETS);

to:
Code: Select allExpand view
DrawImage("STBAR", (160, 200), DI_ITEM_CENTER_BOTTOM);


but I'm not sure how fraught this makes the mod compatibility situation.

All the other new graphics (intermission and roll call screens) seem to work fine with no changes.
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Re: Changes to the modern Unity versions of Doom

Postby Rachael » Thu Sep 03, 2020 10:03 pm

Fixed the status bar
3.) An extras.wad file is also present, including an "official" DSSECRET sound and various graphics lumps used for additional elements specific to the Unity-based source port (automap counters, weapon select scroller).

This is an easy fix but will have to come later
The E3 bunny scroller looks pretty messed up as a result,

This is something Graf will have to fix.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Changes to the modern Unity versions of Doom

Postby Graf Zahl » Fri Sep 04, 2020 12:19 am

JPL wrote:The status bar centering can be fixed to work with both original WADs and the Unity WADs by changing line 41 of zscript/ui/statusbar/doom_sbar.zs, from:
Code: Select allExpand view
DrawImage("STBAR", (0, 168), DI_ITEM_OFFSETS);

to:
Code: Select allExpand view
DrawImage("STBAR", (160, 200), DI_ITEM_CENTER_BOTTOM);


but I'm not sure how fraught this makes the mod compatibility situation.

All the other new graphics (intermission and roll call screens) seem to work fine with no changes.


Although unlikely it cannot be discounted that some mods contain asymmetric status bars. I haven't seen one yet but we never know. But keep in mind that status bars with more extensive modifications will very likely use SBARINFO or ZScript to render themselves, not depend on this old code.
But we have to consider that in the future there may be more mods with widescreen status bars, if the other ports also adapt,
so this will a) have to be coordinated between ports that compatible solutions are being used and b) should be done in a safe way that doesn't break mods that were trying to render wide status bars with offsetting to work with the old code.

For the bunny scroller an insular solution is also not the way to go - this also needs to be coordinated so that future mods using wide assets work with all of them.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Changes to the modern Unity versions of Doom

Postby Rachael » Fri Sep 04, 2020 3:06 am

Bethesda kind of seems to have thrown the whole idea of compatibility under the bus with this release. I am not really sure how the new status bar works, but centering it was a guess for the start for the way to go. If the graphic gets replaced by a .wad - I have not seen what the Unity port does.

Nevertheless, a standard for how the widescreen bunny scroller should work has been established with this release - even though, incidentally enough, the executable does not even use it at all from what I can tell.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Changes to the modern Unity versions of Doom

Postby Rachael » Fri Sep 04, 2020 4:27 am

It seems TNT and Plutonia have not yet been updated.

So using the same executable, I tried out Plutonia, and the status bar is just placed smack dab in the center. I'm guessing it's going to force this for all status bar graphics.

User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Changes to the modern Unity versions of Doom

Postby Rachael » Fri Sep 04, 2020 6:31 am

Graf Zahl wrote:Although unlikely it cannot be discounted that some mods contain asymmetric status bars. I haven't seen one yet but we never know. But keep in mind that status bars with more extensive modifications will very likely use SBARINFO or ZScript to render themselves, not depend on this old code.
But we have to consider that in the future there may be more mods with widescreen status bars, if the other ports also adapt,
so this will a) have to be coordinated between ports that compatible solutions are being used and b) should be done in a safe way that doesn't break mods that were trying to render wide status bars with offsetting to work with the old code.

For the bunny scroller an insular solution is also not the way to go - this also needs to be coordinated so that future mods using wide assets work with all of them.

That ship has already sailed with the Unity port. For the status bar, I implemented a solution that stays exclusive to it. It's a compatibility entry controlled through IWADINFO - no other mod should be affected by the change I made unless an attempt is made to run it on the Unity version. If that happens - what can we do? For now I'll add in an extra line of code that only adjusts the status bar if its width is greater than 320, but beyond that there's no realistic way that I can think of that GZDoom can tell the difference of the status bars apart - unless it uses a checksum or something.

I don't like the solution but - for now, it is the only way to maintain compatibility with both the old and the new graphics. Either way though - Bethesda is setting the bar here on this one, not us. So we just have to go along with whatever they decide, for now, until they stop arbitrarily changing things on us like this.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Changes to the modern Unity versions of Doom

Postby Gez » Fri Sep 04, 2020 11:16 am

Rachael wrote:It seems TNT and Plutonia have not yet been updated.


They forgot these contained a copy of the status bar because they're loading them as PWADs, not as IWADs. They were otherwise updated, as they have 16:9 titlepics and co.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Changes to the modern Unity versions of Doom

Postby Rachael » Fri Sep 04, 2020 12:41 pm

Ah, I see.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Changes to the modern Unity versions of Doom

Postby drfrag » Fri Sep 04, 2020 12:48 pm

Your code is not portable to my old branches so i've hacked JPL's fix using your flag, it's not pretty but it should work. :P
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Changes to the modern Unity versions of Doom

Postby Abner Bibberdale » Fri Sep 04, 2020 9:11 pm

Hi all!

The changes to the widescreen versions of the lumps were basically the simplest possible way to retain compatibility with all the WADs that don't have widescreen graphics, and the new IWAD/add-ons that have been updated with widescreen graphics. There's not really a way to do this without breaking assumptions in the original engine, and we wouldn't have gained much by having different lump names since the 4:3 ones would never be read anymore anyway. The original DOS WADs are still available in the same path if that is the desire.

However, the approach is extremely simple, in the hopes that if other source ports wanted to draw these graphics from our IWAD it would be minimally invasive.

Most patch drawing is the same, and will adjust position based on an invisible centered 4:3 box, something like x += (426 - 320) / 2 where 426 is the width of the new widescreen framebuffer. The total diff for WS lumps is a couple of dozen lines of mostly moving stuff from V_DrawPatch (centered 4:3 box) to V_DrawPatchLeft (left of screen) based on whether they should be drawn from the left (minimap counters) or drawn in a centered 4:3 box.

This was the cleanest way to get this working within our constraints, which is being able to handle WAD files that contain either 320, or 426 width graphics (or theoretically somewhere in between, but that is not really a concern for us). I did something similar in Quake Live which also assumed 4:3 screenspace to gradually support widescreen UIs and HUDs back in the day and it was straightforward to convert stuff into widescreen aware.

Fullscreen graphics like TITLEPIC and CREDIT and stuff like STBAR are drawn by adding an offset like (426 - lump_width) / 2 to just distribute the empty space evenly. We don't support drawing patches larger than 426, nor is the framebuffer aspect ratio adjustable at runtime, but this would still work just fine if it did.

PFUB0/1 was the only slightly weird one, I think it was the beginning graphic, that was left at 320 width, and then PFUB1 was 426 width. In widescreen, the initial screen starts with both PFUB lumps visible, and it still scrolls 320 pixels with the same timing as the original, ending on showing the full 426 wide PFUB lump. The only change there was to just fill the left of the screen with the second PFUB lump at the start.

Hope this is helpful for anyone!

-sponge
Abner Bibberdale
 

Re: Changes to the modern Unity versions of Doom

Postby Rachael » Sat Sep 05, 2020 4:03 am

Thank you, sponge, for that useful information.

For what it's worth, GZDoom had most of the infrastructure in place already to draw widescreen for the fullscreen lumps (TITLEPIC, CREDIT, episode endings, etc). The notable exception to this was the bunny scroller (E3 ending), and the status bar.

Your post here will definitely serve as a useful reference for implementing the remaining graphics.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Changes to the modern Unity versions of Doom

Postby JPL » Sat Sep 05, 2020 10:37 am

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.
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

Next

Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest