OpenGL source ports and their backwards aspect ratio correction. Why?

[Blastfrog]

Alternate thread title: The aspect ratio zealot whines about aspect ratios (again), this time regarding GL.

I can't unsee the perspective distortion of GL ports and it drives me absolutely insane whenever I see screenshots with a viewing pitch of anything but straight forward. I really wish it'd scale the vertices on the Z axis while keeping a proportional vertical and horizontal FOV. As it is, most ports seem to do the inverse by leaving the Z axis unscaled and instead opt to lower the vertical FOV disproportionately to the horizontal FOV.

Why do so many GL ports do the latter and not the former? I'm a shitty coder and thus admittedly have no place in determining this; but I would think that the former solution is a trivial matter (in theory, anyhow). Is it really so difficult to multiply vertex coordinate values by 1.2 before feeding it to the GPU?

[Graf Zahl]

Why? Actually quite simple: Those ports started out without freelook - and handling the distortion in the projection is a lot easier than doing it in every place where coordinates are being handled - especially retroactively.

I have been thinking about doing it in the shader - but so far I haven't found the proper approach.

[fraggle]

Can you give a screenshot and illustrate what you mean? I don't quite follow and I'm curious.

[Blastfrog]

Graf Zahl said:

I have been thinking about doing it in the shader - but so far I haven't found the proper approach.

Why is a shader necessary? Would it truly be infeasible to adjust the world matrix? GZDoom doesn't seem to have a problem disproportionately scaling 3D models on actors, why should it in applying the same principle to the world coordinates?

fraggle said:

Can you give a screenshot and illustrate what you mean? I don't quite follow and I'm curious.

Sure, here's some mock-up shots. This represents looking straight down at the ground.

The first demonstrates how it currently is in GL ports. Note the closeness to the ground (41 units because units are 1:1 in the vertex matrix) and the vertical stretching of the picture, as opposed to the environment being stretched.



The second demonstrates how it should be. Note the further distance from the ground than is seen in the first shot, this is because the viewheight is stretched to 49.2 units (using the horizontal unit scale as the control variable). Also note how the floor texture has square pixels instead of being stretched.



Does this make sense? I apologize if my initial explanation was unclear.

[DaniJ]

Which ports are you referring to, exactly? When looking straight down in Doomsday it looks much like your second pic.

[Graf Zahl]

Sodaholic said:

Why is a shader necessary? Would it truly be infeasible to adjust the world matrix? GZDoom doesn't seem to have a problem disproportionately scaling 3D models on actors, why should it in applying the same principle to the world coordinates?

The end result would be the same, just without the mess caused by a manipulated world matrix. And in the shader I can transparently handle some other values, too, that otherwise I'd have to track throughout the C++ code.

Don't let yourself be fooled by the models, they get their coordinates scaled when they are loaded.

This issue is on my list, but I first want to get a stable 2.0 version out - which is a bit hard because nobody reports any feedback so I still have no good idea how it works on AMD hardware.

[VGA]

AMD users will report their feedback after they get rekt. :-)

[fraggle]

Sodaholic said:

Sure, here's some mock-up shots. This represents looking straight down at the ground.

Okay, I see what you mean. The aspect ratio correction makes sense for things presented vertically (wall textures and sprites) but not floors and ceilings.

Do ports like GZDoom get it right if you're just looking straight ahead? (Like in Vanilla)

[Blastfrog]

fraggle said:

Do ports like GZDoom get it right if you're just looking straight ahead? (Like in Vanilla)

By its very nature, yes. It's just that things get screwed up the further from the center your viewpitch becomes.

Graf Zahl said:

The end result would be the same, just without the mess caused by a manipulated world matrix. And in the shader I can transparently handle some other values, too, that otherwise I'd have to track throughout the C++ code.

Ah, so both are valid methods, but going the shader route is the far cleaner of the two.

Three other things I was wondering about :
1. Regardless of how far down the road it is, are you open to adding an option to use multiple render passes to allow sprites to render through flats?

2. Are you open to the idea of having Quake-like overbright sector brightnesses? Perhaps by setting sector color past [255,255,255], up to [511,511,511]?

3. How easily could it be implemented that the R_Visibility variable affects the software style light in GL? It still changes light intensity just fine in actual software mode, but doesn't do anything in GL.


While I'd certainly like to make use of the above, they're not necessarily requests. I'm only trying to gauge how open you are to those features on principle, even if they're never made.

Graf Zahl said:

This issue is on my list, but I first want to get a stable 2.0 version out - which is a bit hard because nobody reports any feedback so I still have no good idea how it works on AMD hardware.

If I had any AMD hardware, I'd gladly test how it runs on it. I do have some rather old ATI hardware (256MB memory at most, if I still have that card) that was enough to run Doom 3. Not sure if that applies or if you're looking for modern stuff.

[RadTang]

Sodaholic said:
If I had any AMD hardware, I'd gladly test how it runs on it. I do have some rather old ATI hardware (256MB memory at most, if I still have that card) that was enough to run Doom 3. Not sure if that applies or if you're looking for modern stuff.

I think I can help (with modern stuff). I have AMD Radeon R9 270 (if that's important, according to the Wikipedia entry, it's a high end card - http://en.wikipedia.org/wiki/AMD_Radeon_Rx_200_Series ). I'm using Chocolate Doom but I can switch to other source port for test.

[Graf Zahl]

Sodaholic said:

Three other things I was wondering about :
1. Regardless of how far down the road it is, are you open to adding an option to use multiple render passes to allow sprites to render through flats?

If it was that easy... The problem is just - if I disable the depth buffer for sprite rendering it won't just affect how sprites bleed into flats. Unlike the software renderer, though, I have no means to clip anything in this case so the results would not be what you'd expect. Additionally, sprites have to be rendered in order with translucent map geometry and that definitely does need a properly set up depth buffer, so this would have no chance of ever working.

Sodaholic said:

2. Are you open to the idea of having Quake-like overbright sector brightnesses? Perhaps by setting sector color past [255,255,255], up to [511,511,511]?

Only as an opt-in MAPINFO setting, but I'd have to do a thorough check of the code to find all places where lighting is set.

Sodaholic said:

3. How easily could it be implemented that the R_Visibility variable affects the software style light in GL? It still changes light intensity just fine in actual software mode, but doesn't do anything in GL.

I have never tried to understand what r_visibility actually does, so before being able to give a definitive answer I'd have to do some checking first.

Sodaholic said:

If I had any AMD hardware, I'd gladly test how it runs on it. I do have some rather old ATI hardware (256MB memory at most, if I still have that card) that was enough to run Doom 3. Not sure if that applies or if you're looking for modern stuff.

That card is probably too old. GZDoom 2.x requires an OpenGL 3.x capable card, that means from 2006 or later, and the first generation of GL 3.x hardware is barely capable of running medium sized Boom maps at good speed - I still have an old laptop from 2008 with a Geforce 9600, and anything more complex than vanilla maps will suffer from performance breakdowns. So, although this hardware is nominally still supported it won't be able to run any modern maps anyway.

(Fun stuff: 10 years ago my computer was able to run P:AR E1M6's opening cave at 25-30 fps, my current computer and current GZDoom manages 250 fps. And many other maps that are easily playable now would slow down to a crawl on something that old. I wonder how something like Frozen Time would fare on that old system...)

[rampancy]

Graf Zahl said:
...
This issue is on my list, but I first want to get a stable 2.0 version out - which is a bit hard because nobody reports any feedback so I still have no good idea how it works on AMD hardware.

Hey friend. Is the proper place to do this on the gzdoom website? I haven't been there for awhile bc it was collecting dust. I have just been downloading daily builds from the drd site. I have found an issue with the latest builds on my all amd machine regarding a crash at shutdown.

Sodaholic said:

2. Are you open to the idea of having Quake-like overbright sector brightnesses? Perhaps by setting sector color past [255,255,255], up to [511,511,511]?

This would be really nice.