[Feature Request] 2D Pixel Aspect Ratio Scaling

[OpenRift412]

As you might know, Quake was originally made with 320x200 resolution in mind, and this is reflected in most if not all of Quake's 2D assets (HUD, menu gfx, console/message text). The thing about 320x200 that this is a resolution that utilizes non-square pixels (1.2:1 ratio). A lot of Quake source ports tend to not acknowledge this at all, rendering all 2D assets with square pixels instead.

Here's a comparison done in DOS Quake for the sake of consistency.

320x200 (non-square pixels, how it's meant to look)

320x240 (square pixels, how most source ports do it)

Perhaps adding a cvar like scr_2dpixelaspect (and a toggle in the settings) would work for this? I do hope you'll take this into consideration, as it's a very overlooked feature that makes an important difference in displaying Quake's artwork.

[j4reporting]

"how it meant to look" is quite far-fetched. 320x200 was the smallest halfway useful resolution available at the time.
You can also argue that dosquake supported many more resolutions with a pixel format of 1x1 from the beginning. With CRTs, you could resize the image to a halfway reasonable format anyway. Then you only need to look at winquake or any of the glquake versions, and there is no questionable aspect correction taking place.

With DOSquake you rather used a higher resolutions anyway, as long as the computer allowed it, just to avoid eye cancer. But then we upgraded to 3dfx cards very quickly when they came out.

I still have my 17" Trinitron CRT and the P1 + P2 systems from back then. Maybe it's time to connect them again after many years ;)

[mhQuake]

Kevin and Adrian didn't design these graphics on a screen with a 320x200 resolution, they would have designed them on a screen with normal square pixels. So how they look on a screen with square pixels was actually how they were designed, and the 320x200 look is actually incorrectly vertically stretching them.

[OpenRift412]

"how it meant to look" is quite far-fetched. 320x200 was the smallest halfway useful resolution available at the time. You can also argue that dosquake supported many more resolutions with a pixel format of 1x1 from the beginning. With CRTs, you could resize the image to a halfway reasonable format anyway. Then you only need to look at winquake or any of the glquake versions, and there is no questionable aspect correction taking place.

With DOSquake you rather used a higher resolutions anyway, as long as the computer allowed it, just to avoid eye cancer. But then we upgraded to 3dfx cards very quickly when they came out.

I still have my 17" Trinitron CRT and the P1 + P2 systems from back then. Maybe it's time to connect them again after many years ;)

WinQuake actually does the exact same thing that DOS Quake does, assuming you're playing in a Win9x environment or with a ddraw wrapper that enables the legacy resolutions. It doesn't usually show you those old resolutions in modern Windows because of poor legacy support. So really, the removal of aspect-correct 2D assets first happened with GLQuake, which while technically impressive, had a lot of things from previous versions missing.

Also, 320x200 is just the most common example for what I'm talking about, 640x400 is another one that falls in this same category.

[OpenRift412]

Kevin and Adrian didn't design these graphics on a screen with a 320x200 resolution, they would have designed them on a screen with normal square pixels. So how they look on a screen with square pixels was actually how they were designed, and the 320x200 look is actually incorrectly vertically stretching them.

They could've been designing them in a program that ran at 640x400. Coming off the back of Doom, it would've made sense that they were working with non-square pixels anyway since that's what Doom was rendered with.

Here's the thing, I know that the vertically stretched versions are the intended look because you'll notice that in the menu pictures above, at 320x240 (square pixels), the Q in Quake and the id software logo are abnormally wide. Meanwhile, 320x200 (1.2:1 pixels) displays these with correct proportions.

But the most clear-cut piece of evidence for this is none other than the console background. The console background graphic (conback) found in Quake's PAK0.PAK is a graphic with a resolution of 320x200. If Kevin and Adrian weren't designing with non-square pixels in mind, why would they make the console background 320x200 instead of 320x240?

[andrei-drexler]

Even if it's a plausible explanation, it's still just speculation. That being said, I think I'll still implement it at some point, but it will be disabled by default - we've been playing with square pixels for a really long time now and changing that would probably look wrong to most people nowadays.

[d-bind]

To add to this speculation, Quake world textures were clearly made with similar guidelines to those in Doom - to be stretched vertically: However, the level designers didn't get the memo, and since in 3D the same textures can cover floors and ceilings, stretching the world geometry in engine wouldn't make sense.

[gilabogus]

Yeah the Quake texture sheets (originally in .LBM format) show the same 8x8 grid with numbers they used for Doom graphics sheets. These have size of 320x200 and it's known they worked on them in Deluxe Paint, according to Carmack's twitter post. For example:

[mhQuake]

To add to this speculation, Quake world textures were clearly made with similar guidelines to those in Doom - to be stretched vertically:

I don't buy that because the surrounding brick textures, buttons, etc are clearly square. Tops of ammo boxes... can't be anything but square. Basically, the biggest argument against "world textures were designed to be stretched vertically" is that as soon as you say it, you have to come up with so many explanations for exceptions, that you're actually left with only a tiny handful of textures where you might have a case. The rest of them clearly weren't.

[OpenRift412]

To add to this speculation, Quake world textures were clearly made with similar guidelines to those in Doom - to be stretched vertically:

I don't buy that because the surrounding brick textures, buttons, etc are clearly square. Tops of ammo boxes... can't be anything but square. Basically, the biggest argument against "world textures were designed to be stretched vertically" is that as soon as you say it, you have to come up with so many explanations for exceptions, that you're actually left with only a tiny handful of textures where you might have a case. The rest of them clearly weren't.

The thing is, world textures weren't really designed to be stretched, but 2D assets were, because they were all consistently scaled in a manner that they look as they should at 320x200 in 4:3.

[d-bind]

I don't buy that because the surrounding brick textures, buttons, etc are clearly square. Tops of ammo boxes...

Buttons don't have to be square. Doom has buttons that are square on the texture and then "tall" in-game. Planets however tend to be more spherical than not. It's true that there is a circular pentagram button among Quake textures - however it's just a cropped "flat" floor switch. Similarly, tops of ammo boxes would have been "flats" (i.e. floors) that don't get stretched in Doom. And I'm not sure why bricks would be some reference for "squareness".

Anyway, you don't just accidentally draw ovals that turn into perfect circles when stretched 120%, and especially not when you're already drawing within a square tile. Though of course, a possible explanation is that the Quake engine wasn't ready, and the artists were still targeting the Doom engine for most of their dev time. Lastly, as I already said, this is just idle speculation (also off-topic and off-website really). Whatever the texture artists' intent was, the level designers had the final say, and it's not like they couldn't see the compiled levels until the game shipped. Oval windows are apparently what's fashionable in the elder world, end of story.

[mhQuake]

You're thinking 2D.

Doom buttons are typically on walls, are vertically oriented, and are only viewable from a very limited subset of angles.

Quake buttons can be on any arbitrary geometry and are viewable from any arbitrary angle. For that kind of button, or anything else, it makes no sense at all for the texture image to be stretched on one axis but not the other.

But it could of course be counter-argued that the Quake artists were also thinking 2D, so yes, it's probably best to just let that one stand.

[andrei-drexler]

Added in 8e76c5f641ef94fb4662144e219417c02f0a48ea:

scr_pixelaspect 1	scr_pixelaspect 4:5

At first I thought this would end up being an option only extreme purists would use, but I've been playing with it for a while now and surprisingly scr_pixelaspect 4:5 ended up looking a lot more natural to me, so much so that I'm actually considering making it the default, even if it might take some getting used to.

[OpenRift412]

Looks great! I will say though, I have noticed a little bit of artifacting where HUD and text graphics aren't properly adhering to a grid.

(Screenshots were taken at 4.5 scale with a 1:1.2 pixel ratio, emulating 320x200 scale at a base resolution of 1920x1080)

[mhQuake]

You can get as good a solution as possible to this by rendering the UI to an appropriately-sized FBO, then drawing that stretched and scaled over the main scene.

[andrei-drexler]

That would definitely help, but it would also generate extra memory traffic that would likely be noticeable on integrated GPUs, and I don't think these artifacts are worth taking a perf hit. The main issue here is the pixel snapping added in d3cb81d3d69d0d1458d23f7d2615f98897bf6f78, luckily there's an alternative solution to the problem that commit was addressing. Things should look a bit better now after 047d93da38e0641ec391383d4a6ab460f562473f, even if still not quite perfect.