Unity Doom's widescreen assets - how should we handle them?

[Graf Zahl]

I am referring to the new status bar and the bunny scroller in particular. Drawing a wide fullscreen image should be as simple as rendering it from the center to ensure that it gets displayed correctly but these other two things definitely need a bit more work and run a greater risk of doing incompatible solutions.

 

Before doing an insular and potentially conflicting implementation, I think all interested port authors should think about how to handle these in a compatible fashion with consistent rules that allows future modders to make use of widescreen assets without breaking single ports that choose to do a different implementation from the rest - and without breaking existing content that may already exist.

 

 

 

 

 

[Gez]

For reference, the image resolution of the new full screen graphics is 426x200. (Obviously for the status bar it's 426x32.) The 200 height means that aspect ratio correction is still needed.

 

The bunny scroller is still made of two images, PFUB1 and PFUB2, but PFUB1 remains at 320x200 while PFUB2 is 426x200; meaning the total scene is 746x200 instead of 640x200 (or 852x200). The scene was extended by 53 pixels on both sides (i.e., on PFUB1 the rabbit is 53 pixels more to the left, and the leftmost 53 columns of the original PFUB1 are now part of PFUB2), which means that the initial scene and the final scene are centered appropriately.

 

To make this clearer, a comparison picture. Top: the original, bottom: the new. There's a one pixel gap between each image.

 

So the start condition is showing PFUB1 and the rightmost bit of PFUB2, the end condition is showing only PFUB2.

[Graf Zahl]

Thanks for that bit of info. It should make it a lot easier to handle this screen.

Of course it still leaves the question open for 21:9 assets. With this uneven distribution it would only be guesswork to determine how wide such a combined image is supposed to be - I guess the only way is to take the total width of both images and subtract 640 from it. If the result is around 53 we got a 16:9 scroller, if it is around 120 we got a 21:9 scroller.

 

But I think the status bar is a bit more critical. So far, widescreen status bars had to set their origin to (53, 0) to be rendered properly in GZDoom and I am quite certain that such bars exist. So to achieve consistency here some rules need to be defined that preferably all ports adhere to. Would it be enough to just say, if the bar is 426 pixels and wider, treat it as a widescreen bar with needs to be manually offset or are there reasonable scenarios where this may not work?

 

[Gez]

58 minutes ago, Graf Zahl said:

Of course it still leaves the question open for 21:9 assets. With this uneven distribution it would only be guesswork to determine how wide such a combined image is supposed to be - I guess the only way is to take the total width of both images and subtract 640 from it. If the result is around 53 we got a 16:9 scroller, if it is around 120 we got a 21:9 scroller.

Yes, though you'll get 106 or 240 if you don't divide by two. ;)

 

The same approach as used in the official port, if extended to 21:9, would spoil a little bit of the smoke clouds. Maybe not enough to actually make clear it's smoke, though. (And with something like 24:9, the flames would be spoiled right from the start.) Oh well, I guess it's like spoiling that Darth Vader is Luke's father: everyone knows it already anyway.

[drfrag]

sponge wrote this at zdoom.org:

"

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

"