Internal resolution scaling/quantization option

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

Internal resolution scaling/quantization option

Postby scalliano » Thu May 04, 2017 4:07 pm

Given that GZDoom now supports tonemaps resulting in more or less software-perfect visuals in OpenGL mode, I was wondering if it would be possible to implement an option to toggle/adjust the game's internal resolution. Since hardware rendering on modern cards can't display at anything less than 640x480, this could be a means of "faking" the old DOS resolution a la Chocolate Doom, giving a true "old school" look.

Thoughts?
User avatar
scalliano
Resident ZDoom Waifu
 
Joined: 21 Jun 2005
Location: Ireland

Re: Internal resolution scaling/quantization option

Postby Caligari87 » Thu May 04, 2017 4:25 pm

I feel like this was very recently addressed and abandoned for some reason...

EDIT: Here's the thread I was thinking of. Looks like it was gonna break legacy support?

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Internal resolution scaling/quantization option

Postby scalliano » Thu May 04, 2017 4:50 pm

Ah, that's why I couldn't find it under a "resolution" search.

Shame.
User avatar
scalliano
Resident ZDoom Waifu
 
Joined: 21 Jun 2005
Location: Ireland

Re: Internal resolution scaling/quantization option

Postby Rachael » Thu May 04, 2017 4:50 pm

I'll see if I can dig up dpJudas's older attempt at it and try and fix it.

But you can definitely expect Graf not to be invested in this. My main interest in it, other than being retro-looking like the tonemap shader, is that it would improve performance on lower-end processing units.

My personal interest in it is being able to play software mode without the fans kicking up to 1500 RPM. I like silent computers. ;)
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Internal resolution scaling/quantization option

Postby AFADoomer » Thu May 04, 2017 5:04 pm

For me, because my monitor is high-dpi (or whatever it's called), to get the window to a decent size to play, my resolution ends up being like 1920x1280 or something like that.

There are maps that work great for me at lower resolutions that drag at these high resolutions. I'd love to be able to have something like the old pixel doubling so that my performance wouldn't tank if I decide to not want to squint at the teeny tiny game screen...

I'm pretty sure I can force Windows to cooperate by tweaking the registry and putting in my own manifest file to override the scaling, but an engine-side capability would be less hackish.
User avatar
AFADoomer
 
Joined: 15 Jul 2003

Re: Internal resolution scaling/quantization option

Postby dpJudas » Thu May 04, 2017 7:41 pm

If you run the software renderer with the OpenGL canvas then you can use vid_max_width and vid_max_height to set a resolution lower than the actual window size.

Note however that those two cvars are not official and may be removed again in a future version without warning. They exist solely because I too have a 4K monitor and needed a way to lock the resolution to 1080 to get a better frame rate.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Internal resolution scaling/quantization option

Postby Hellser » Thu May 04, 2017 8:41 pm

I will actually be totally behind this. I personally like the look of "Chunky Doom", and it'll be different to see how things are looking chunky but yet, pretty.
User avatar
Hellser
Remember Citadel
 
Joined: 25 Jun 2006
Location: Citadel Station
Discord: Hellser#8156
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Internal resolution scaling/quantization option

Postby Graf Zahl » Fri May 05, 2017 2:56 am

dpJudas wrote:If you run the software renderer with the OpenGL canvas then you can use vid_max_width and vid_max_height to set a resolution lower than the actual window size.

Note however that those two cvars are not official and may be removed again in a future version without warning. They exist solely because I too have a 4K monitor and needed a way to lock the resolution to 1080 to get a better frame rate.



This really should be made part of all buffered render paths. Of course the hardware renderer with gl_renderbuffers off needs to be an exception.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Internal resolution scaling/quantization option

Postby dpJudas » Fri May 05, 2017 4:39 am

Graf Zahl wrote:This really should be made part of all buffered render paths. Of course the hardware renderer with gl_renderbuffers off needs to be an exception.

My attempt at creating a generalized solution did try to do that, but I ran into trouble with the D3D 9 backend. Maybe if/when we fix the 2D drawer stuff it will be easier to achieve. For the GL renderer the support is almost already there - in fact, the macOS full screen version is doing it as you describe.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Internal resolution scaling/quantization option

Postby Graf Zahl » Fri May 05, 2017 4:51 am

Oh yes, the D3D9 backend. I really don't get why this code has become this insanely complex. But to unify the different render backends first a lot of cleanup is needed on the texture classes. For too long this suffered from the base class not really being suitable for hardware rendering with the D3D9 stuff haphazardly being tacked on and GL having to do its own subclasses to steer clear of these problems. And to top it off, the Atlassing in the software rendering parts is a mystery on its own. I wonder how much advantage this really brought, but considering that few HUDs draw more than 100 elements it's mostly irrelevant. Instead I'd very much prefer to explicitly create atlas textures for fonts only and do this at a higher level, but forget about this stuff in the backends. Was that old ATI hardware with SM 1.x really that weak that it couldn't deal with 100 draw calls or so that the entire code had to be mucked up with this kind of complexity?

Another thing I'd prefer to eliminate is using two-stage textures with the second texture serving as a palette. It doesn't even fully work! Some years ago I had a bug report about an incorrectly colored translated sprite but was unable to do anything about it because this code's assumptions were wrong.

This WILL need a work branch, though, because temporarily breaking stuff is close to inevitable. And I think some very old hardware may have to suffer a bit and forcibly reverted to software 2D drawing in order to keep the code manageable.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Internal resolution scaling/quantization option

Postby dpJudas » Fri May 05, 2017 9:49 am

Graf Zahl wrote:Oh yes, the D3D9 backend. I really don't get why this code has become this insanely complex. But to unify the different render backends first a lot of cleanup is needed on the texture classes. For too long this suffered from the base class not really being suitable for hardware rendering with the D3D9 stuff haphazardly being tacked on and GL having to do its own subclasses to steer clear of these problems.

I assume you mean FTexture and the derived classes. What changes are you planning there? To move the GetColumn and span stuff to the software renderer?

Graf Zahl wrote:And to top it off, the Atlassing in the software rendering parts is a mystery on its own. I wonder how much advantage this really brought, but considering that few HUDs draw more than 100 elements it's mostly irrelevant. Instead I'd very much prefer to explicitly create atlas textures for fonts only and do this at a higher level, but forget about this stuff in the backends. Was that old ATI hardware with SM 1.x really that weak that it couldn't deal with 100 draw calls or so that the entire code had to be mucked up with this kind of complexity?

The atlas serves both the purpose of reducing state changes as well as making images work with hardware having power-of-two texture limitations. Back in the day batching things could make a really big difference, but I don't know if it is as bad today. One thing is certain tho - poor batching can end up being slower than not doing it at all.

Graf Zahl wrote:Another thing I'd prefer to eliminate is using two-stage textures with the second texture serving as a palette. It doesn't even fully work! Some years ago I had a bug report about an incorrectly colored translated sprite but was unable to do anything about it because this code's assumptions were wrong.

You mean the translation stuff? Or is there another two-stage texture thing?

Graf Zahl wrote:This WILL need a work branch, though, because temporarily breaking stuff is close to inevitable. And I think some very old hardware may have to suffer a bit and forcibly reverted to software 2D drawing in order to keep the code manageable.

Hehe, yes, doubt about that. Just let me know when you think we should start working on this.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Internal resolution scaling/quantization option

Postby Graf Zahl » Fri May 05, 2017 10:16 am

dpJudas wrote:
Graf Zahl wrote:Oh yes, the D3D9 backend. I really don't get why this code has become this insanely complex. But to unify the different render backends first a lot of cleanup is needed on the texture classes. For too long this suffered from the base class not really being suitable for hardware rendering with the D3D9 stuff haphazardly being tacked on and GL having to do its own subclasses to steer clear of these problems.

I assume you mean FTexture and the derived classes. What changes are you planning there? To move the GetColumn and span stuff to the software renderer?


No plans yet. I first need to get an overview over the different backends.

The atlas serves both the purpose of reducing state changes as well as making images work with hardware having power-of-two texture limitations. Back in the day batching things could make a really big difference, but I don't know if it is as bad today. One thing is certain tho - poor batching can end up being slower than not doing it at all.


Sure. The thing is just that the OpenGL renderer never batched at all and with the low number of polygons drawn, even on AMD with their notoriously bad draw call performance it never actually mattered. I cannot say if it was an issue in the beginning. Randi was known for this kind of tinkering, not because it brought an advantage but just for the sake of doing it.
Instead of random unorganized atlassing in the backend I'd very much prefer to atlas the fonts on a higher level and leave it at that. I believe that will allow the same amount of batching but do it in a backend-independent manner.

You mean the translation stuff? Or is there another two-stage texture thing?


I mean putting much of the system independent logic into a higher level class so that all backends can benefit from it. The translations are just one part.


Hehe, yes, doubt about that. Just let me know when you think we should start working on this.


No idea yet, first we need a workable roadmap.

And one thing that absolutely needs fixing is PALVERS handling. That stuff is so totally broken I do not know why it was even added...
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest