What's the benefit of higher resolution?

Obviously, I can see a difference between 320x200 and, say, 640x480, but at some point it seems that increasing resolution even further gives no effect except for increased CPU workload.

It looks like monster sprites remain unaffected - is this just an illusion, or is that really so? I assume it may have something to do with Doom's original sprites being designed for 320x200. Source ports still use data from original IWADS, so they probably just resize sprites, instead of making them more detailed etc. Am I right?

I assume increased resolution mainly benefits the maximum distance at which level structure is still clearly recognizable (instead of becoming pixelated mess), but what's the optimal maximum resolution beyond which those gains are negligible (or perhaps even absent)?

Also, what resolution do you play at, assuming you use a higher setting than default?

I play at 1920 x 1080 because its the native resolution of my monitor and anything less will cause black bars on the edge of the display as well as blurriness

640x480 in Pr+.

I play at 1680x1050 on a 22 inch screen, this is comfortable most of the time. For things to become pixelated messes, they'd have to be far enough I wouldn't see much regardless, but there might be an improvement still.

On the other hand I wouldn't want to go below that resolution, trying it now I can see differences in the faraway green texture in Doom2 map01's entry room. In 1280x800 it's not too obvious, but 1024x640 is a definite downgrade.

I play at 1920x1080 because anything less than the native resolution looks like shit on a TFT flatscreen.

Besides, with hardware rendering and a modern graphics card the bottleneck is elsewhere. I could play at the same performance with a resolution 4x as high.

Chocolate Doom's default 640x480 but this thread made me into testing other resolutions. Played like that since the beginning.

Technically, the only immediate benefit of increased resolution is increased view depth (you can now see clearer what before was just a bunch of pixels, a single pixel, or even not rendered at all).

In practice, since increased resolution also implies increased rendering limits by necessity, a port having higher resolution will generally also be "limit removing" up to a point, often . Both features are really needed for large levels. You don't want t to look at very large levels or hundreds of monsters through just 64000 pixels!

The rendering of sprites and other graphics won't be affected in any way simply by increasing the rendering resolution, because the resources and the view scale will still be the same, unless you use other enhancements like hi-res sprite packs or (more realistically) a 3D-accelerated port, which however is practically a totally different renderer.

RadTang said:

Chocolate Doom's default 640x480 but this thread made me into testing other resolutions. Played like that since the beginning.

Only that in Chocolate Doom this is achieved by pixel doubling, not actually rendering at higher resolutions, which requires quite extensive changes to the engine (which are done by branches of ChocoDoom like Crispy Doom BTW).

Graf Zahl said:

I play at 1920x1080 because anything less than the native resolution looks like shit on a TFT flatscreen.

You can also use resolutions that are integer submultiples of the native one in either direction with still crisp-clear pixels, though that might result in using awkward resolutions like e.g. 960 x 540 or 960 x 720 on your monitor

Most important thing for me is to use my monitor's native res, so it's as clear as possible. So any port that doesn't support 1680x1050 (and proper wide screen) goes out the window.

Quite frankly, 1920x1200 with PrBoom-Plus in GL mode is glorious. It's not about making textures clearer (which is impossible...), but there's a good crispness about having it all scaled up nicely to this resolution. Also I disable the silly filters that GL ports always seem to enable by default, so nothing gets a weird blur :P

My monitor's native resolution is 1920 x 1080, so that's what I run Doom at. As mentioned by others, it doesn't really matter for things up close, because the sprites and textures themselves have a limited resolution (though with modern source ports there are options for sprite scaling so that everything looks smudged in photoshop rather than looking like a pixelated mess). However, I really do enjoy the increased draw distance higher resolutions allow.

It reminds me of wearing glasses - I was originally prescribed glasses when I was in elementary school, but I never wore them because the frames bothered my ears (some sort of allergic reaction or something). I got used to not wearing them, and it didn't really come up again until I was vision-tested in high school, and got glasses again. Anyway, I was so used to life without glasses I had no idea how bad my vision was, and when I realized how much more clearly I could see things at a distance, it became almost impossible for me to go back to not wearing glasses. It's basically the same thing with higher resolutions in Doom - could see things in the distance so clearly that it became almost painful to go back to 320x200.

I can't play comfortably with anything higher than 640x480: the visuals become too flat and obviously primitive. Things getting more fuzzy in the distance is an essential part of the game for me, without it there would be no depth to any area. I'd like to play with 320x200 sometimes too but prboom-plus won't let me set it, which is a real pity.

Patrol1985 said:

It looks like monster sprites remain unaffected - is this just an illusion, or is that really so? I assume it may have something to do with Doom's original sprites being designed for 320x200. Source ports still use data from original IWADS, so they probably just resize sprites, instead of making them more detailed etc. Am I right?

Well, vanilla Doom resizes sprites, too.

As you know, when a monster is right in your face, you can see its texels (I'm gonna use pixel only for screen pixel, and texel for game data pixel) being blown up into big squares of pixels. At a "perfect" range, you have one pixel = one texel. Then further beyond, multiple texels get merged into one single pixel. Eventually, the monster itself becomes just one single pixel, and then at even greater ranges it becomes invisible.

With higher resolution the "perfect" range is pushed further away. Monsters keep all their texels longer. They can be seen at greater ranges.

Gez said:

Then further beyond, multiple texels get merged into one single pixel.

They are not even "merged" -if that happened then we'd have a form of simple mipmapping/texture filtering. What happens is that pixels in sprite and texture colums are simply skipped in order to produce scaling, to the point where only one pixel (the first) is drawn, and beyond a certain range the engine simply rejects drawing altogether. With higher resolutions it can keep drawing for longer, hence more visible objects, and the need for increased limits.

If there was any sort of pixel merging, this would actually result in an interesting average-filtered look for Doom -but would be a killer for CPU time!

Memfis said:

I'd like to play with 320x200 sometimes too but prboom-plus won't let me set it, which is a real pity.

FYI Crispy Doom renders at 320x200 when set to low detail. Limit-removing (i.e. complevel 2) maps only though, and not ones that have various "PrBoom+ isms".

For bragging rights. Being able to run software rendering (with a bit of hardware blitting help, yeah) at the likes of ultra-HD is quite a feat for the port author, considering we're counting millions of operations per tic. I wonder how Eternity succeeds it. Does it use vector optimizations?

The res should always be the max res on your screen, anything else will be blurry or have black bars.

Lycaon said:

The res should always be the max res on your screen, anything else will be blurry or have black bars.

Or you play in windowed mode.

Thanks for replies everyone! I received exactly the information I was looking for.

The reason I started this thread is the unfortunate fact that my hardware (contrary to Graf Zahl's statement) IS the bottleneck for performance :(

My main computer got severely damaged (I spilled water on it, don't ask) so now I'm left with two low-spec netbooks.

Most of you use your screens' native resolutions and that's what I'd like to do as well, because even if Doom itself doesn't benefit vastly from extremely high (for its age) resolutions, they simply align nicely with modern displays.

The computer I'd like to play Doom on has a native resolution of 1366x768, but it comes with a rather shitty AMD Radeon HD8210 video card. Furthermore, I have Linux Mint 17 running on this machine, and linux drivers* suck infinitely compared to windows. I actually decided to run windows 7 for a test on the same machine and did -timedemo demo1 of Doom 2 (I used PrBoom+ 2.5.1.4.test) to get some numbers:

Linux, OpenGL, 1366x768 = 60 FPS
Windows 7, OpenGL, 1366x768 = 91 FPS

I know that 60 FPS is still optimal, but Doom 2's demo1 isn't exactly the most hectic thing that can happen in this game. Furthermore, the above numbers were taken with v-sync turned off. V-sync on cuts those numbers rather drastically (48 FPS for linux and 55 FPS for windows 7).

My other netbook has a native resolution of 1024x600, runs on Windows 7, but sports a shitty Intel GMA 3150 card. Still, here are its results:

Windows 7, OpenGL, 1024x600 = 87 FPS

So my shitty intel card performs better under Windows 7, than the Radeon under Linux with its drivers. I could just play on the Intel machine, but the card cannot really run GZDoom without errors due to technical limitations.

Thus, I think I will install Windows 7 to increase performance of the Radeon. 91 FPS at a resolution that high is more than enough for me and I doubt it will fall drastically when a lot happens on the screen.

Interesting note = my intel GMA 3150 gave BETTER performance with v-sync on than the Radeon, even under Windows 7 (72 FPS for the Intel card, under Windows 7 and at 1024x600). However, with v-sync off Radeon wins by a few frames (but at a significantly higher resolution).

*I'm talking about drivers available under the "Driver Manager". I know I could manually update the drivers, but it requires a lot of time and effort, manually updating kernel, firmware and whatnot. I've done it in the past and had to reinstall the whole system so I'm not really eager to try it again.

From the benchmarks you posted, I can't understand whether you're interested in pure software rendering performance (in which the CPU alone would be the bottleneck, the GPU would matter very little), or OpenGL performance (which means you're using glBoom+, nor prBoom+ for the tests).

I would be surprised to see a difference in pure software rendering across different GPUs all other things being equal (which they probably aren't).

On laptops/notebooks usually the bottleneck is the GPU architecture (usually some bastardized half-PCI, half-AGP bus or some other custom/onboard bus) and the shared memory (which practically halves access speed, or worse). This might limit FPS simply because you run out of memory bandwidth, so a laptop with a worse GPU on paper (e.g. GMA 3150 vs Radeon) might perform better simply because the Intel-based system has faster memory, and works better for brute-force pixel pushing.

The benefits of a better GPU and hardware acceleration become evident at higher resolutions: rather than forcing millions of pixels per second to be painstakingly calculated by the CPU one by one and written to your card's frame buffer, passing through the system's bus, it's the GPU itself that renders the scene, with the bulk of the data moving only through the (dedicated, hopefully) GPU memory and channels, and most processing for the pretty effects & texture blurring being done by the GPU.

I'm interested mainly in accelerated performance so yes, I used GLBoom+ for testing.

Doom today is comparatively a very low spec game. It's unlikely that any PC built in the last 10 years would be insufficient for playing even the largest limit-removing levels, as long as you use a decent source port (glBoom+/prBoom+ are optimal for performance, and can handle NUTS.WAD-like monsters and Sunder-style levels with no problems even on a Pentium III).

The only exceptions are some GZDoom-specific maps like Dawn Of Reality, which also have an enormous memory footprint and a large number of textures, and some ultra-complex levels, and playing NUTS.WAD-like levels on a port which hasn't fixed the MBF "friend" behavior.

Well, I want stable 60 FPS in any situation, so 91 FPS seems quite a safe margin. Linux rendered 60 FPS in -timedemo demo1, but those numbers may fall with more action. I could feel the difference when FPS dropped to 48 with v-sync on.

Wanting stable fps performance in a 3D game with variable visuals is impossible, unless the devs go out of their way to include "automatic visual degratation" options such as pop-in, polygon/model degradation and eventually falling back to shaded polygons or even wireframe graphics, if needed to keep FPS constant.

To the next level: the rendering routines could include some sort of "accounting" that calculates precisely how many polygons and texels will a given scene contain and how much memory bandwidth will be consumed, precisely, so that very precise and dynamic detail scaling can be done.

Besides, in Doom rendering is not always the most time-consuming part: gameplay calculations (lots of monsters), BSP recursion etc. can be just as time consuming, if not more, so a faster CPU and a faster memory bus are always better Dooming investments than a fast GPU (unless some sort of GPGPU Doom appears..)

Maes said:

Besides, in Doom rendering is not always the most time-consuming part: gameplay calculations (lots of monsters), BSP recursion etc. can be just as time consuming, if not more,

This guy has done some profiling of Chocolate Doom and it appears that R_DrawSpan and R_DrawColumn share a good 50% of run time:

http://fabiensanglard.net/doomIphone/doomClassicRenderer.php

Doesn't prboom look like crap in high resolutions? I refer to those rendering errors discussed in the other thread. Isn't it the same with glboom?

You should test Zdoom and Eternity for software renderer and 3DGE for OpenGL.

VGA said:

Isn't it the same with glboom?

How can it? The problems come from the fact that PrBoom's software renderer is quite close to Doom's original one.

A hardware renderer works completely differently.
That said, PrBoom's hardware renderer does not support all common vanilla editing hacks - easily shown in BTSX_E1's MAP01.

I'll apply kb1's fix in few days.

fabian said:

This guy has done some profiling of Chocolate Doom and it appears that R_DrawSpan and R_DrawColumn share a good 50% of run time:

http://fabiensanglard.net/doomIphone/doomClassicRenderer.php

This is consistent with what I had once done with Mocha Doom, when investigating how much of a benefit parallelizing the renderer could ever have.

Realizing that the renderer might not be the actual bottleneck can be counterintuitive: you'd think that drawing all those pixels in an inefficient column-wise manner would dominate CPU time, but in maps where heavy rendering is involved, you're also bound to have heavy gameplay calculations to perform as well, so optimizing just the renderer will only get you so far. Even with infinite renderer parallelization (or a renderer which runs in zero-time), you will only get a speedup of 50-60% on most maps, unless treating borderline/pathological cases.

Maes said:

Wanting stable fps performance in a 3D game with variable visuals is impossible

By "stable" I mean "no less than 60". The framerate may be unstable as long as it stays within "60 - infinity" range :P