Changes to the modern Unity versions of Doom

[Kinsie]

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.

[Redneckerz]

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.

[Gez]

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.

[JPL]

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 all

DrawImage("STBAR", (0, 168), DI_ITEM_OFFSETS);

to:

Code: Select all

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.

[Rachael]

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.

[Graf Zahl]

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 all

DrawImage("STBAR", (0, 168), DI_ITEM_OFFSETS);

to:

Code: Select all

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.

[Rachael]

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.

[Rachael]

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.

[Rachael]

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.

[Gez]

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.

[Rachael]

Ah, I see.

[drfrag]

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.

[Guest]

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

[Rachael]

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.

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