Linux grahpics problems?

[hfc2x]

Not really Linux problems, but I have no idea how to ask this, and I have no idea how I had not noticed until now.

 

The other day I decided to switch over to DSDA Doom after I realized PrBoom+ had reached end of life. After setting the video mode to OpenGL, I noticed it looks a little bit weird:

 

Notice how some of the pixels in some characters look out of place (the second E letter in "Fullscreen" looks pretty bad).

 

Setting the video mode to Software makes it look better, but not perfect:

 

And I thought it was probably just DSDA Doom, but then I realized that any game that uses hardware accelerated graphics has some weird things happening to the pixels if you look closely.

 

Has anyone ever noticed this? Is this mipmapping or something? I'm pretty sure it's actually Mesa doing something funky, and I know it can likely be disabled. I'm running Fedora 39 KDE (X11, although Wayland makes no difference) with the freeworld drivers, and I have an AMD GPU. I have no idea how to Google this problem.

 

Does anyone know what's going on?

Edited March 21 by hfc2x

[act]

I, I don't see shit.

[hfc2x]

When the picture gets shrunk like that it's harder to see, but here, have a magnification:

 

[Blzut3]

What issues bother people varies person to person, so when pointing out minor cosmetic issues it's usually a good idea to explain in detail what you're being bothered by rather than using vague terms like "something funky".

 

Since you say software is still "not perfect," I believe what you're talking about is rounding issues mostly intrinsic to non-integer scaling.  However it does look like in OpenGL some of the pixels have a slight skew to them (not rectangles) which seems odd even given that.

[hfc2x]

It's not that it particularly bothers me. It's not really noticeable most of the time, just that the fact that pixels were not actual rectangles when the game is set to hardware-accelerated that seemed curious to me. Software mode seemed to do a better job at scaling up pixels in a uniform way, and I just wanted to know if it can be adjusted somehow.

 

If it can't be adjusted, well, it's not a big deal.

[Blzut3]

The software mode is doing more or less the best it can (arguably some improvements could be made, but it often turns into a game of whac-a-mole as the round off moves to a different resolution or some other limitation comes into play).  That skewing on OpenGL I can't really comment on since I'm not familiar with working with OpenGL and what may be coming into play there, but it certainly feels like something is not entirely right there.

[Calinou1]

1920x1080 is not an integer multiple of the game's base resolution (neither 320x200 nor 320x240), so you'll want to use a different screen resolution to avoid this issue in source ports that don't use integer scaling for everything. On a 1920x1080 display, the highest you can go while ensuring integer scaling is 960x600 (960x720 with aspect ratio correction). If your display doesn't accept this fullscreen resolution, you'll have to play in a window and use IntegerScaler to remove borders and insert a black background.

 

If you want the game to use aspect ratio correction, you should also change the sprite scaling setting in DSDA to "Doom format" (I don't remember where it is exactly, perhaps in the status bar/HUD options).

 

The ideal solution would be to modify the source port so that it always draws 2D elements at an integer multiple of the original scale, even if this means text will appear slightly smaller at fractional scale factors. GZDoom has extensive options for this (with separate sliders for menu scale, HUD scale, status bar scale and console scale). A short-term workaround is to upgrade to a 1440p (6x scale) or 2160p (9x scale) monitor, which don't have this issue for any 240p games :)

Edited March 24 by Calinou1

[hfc2x]

On 3/23/2024 at 10:10 PM, Calinou1 said:

1920x1080 is not an integer multiple of the game's base resolution (neither 320x200 nor 320x240), so you'll want to use a different screen resolution to avoid this issue in source ports that don't use integer scaling for everything. On a 1920x1080 display, the highest you can go while ensuring integer scaling is 960x600 (960x720 with aspect ratio correction). If your display doesn't accept this fullscreen resolution, you'll have to play in a window and use IntegerScaler to remove borders and insert a black background. 

I don't know where I've given the impression that I have zero idea about any of this. Of course I know 320x200 doesn't perfectly scale to 1080p, and I know how integer scaling looks like with the black border and all. I don't expect things to look perfect, but this thread was mostly a question about Mesa drivers because I know for a fact on my Windows laptop things don't look like this, but that's a different and unrelated thing at that point because Windows doesn't use Mesa.

 

On 3/23/2024 at 10:10 PM, Calinou1 said:

If you want the game to use aspect ratio correction, you should also change the sprite scaling setting in DSDA to "Doom format" (I don't remember where it is exactly, perhaps in the status bar/HUD options).

This has nothing to do with what I'm asking. Aspect ratio correction should always be enabled because of how Doom's graphics were designed to look like. In any case, that's in Options>General>Video>Aspect Ratio.

 

On 3/23/2024 at 10:10 PM, Calinou1 said:

The ideal solution would be to modify the source port so that it always draws 2D elements at an integer multiple of the original scale, even if this means text will appear slightly smaller at fractional scale factors. GZDoom has extensive options for this (with separate sliders for menu scale, HUD scale, status bar scale and console scale).

Funny that you imply GZDoom "does it correctly", because it has the exact same problem:

 

Here, magnified in case you can't see it:

 

Also, even funnier that it is Chocolate Doom of all things doesn't exhibit this problem at all:

 

Which is exactly why I'm asking if there's some Mesa configuration that I'm currently unaware of that might be the cause because it's obviously not related to these source ports. And that's because it's undeniably a Mesa thing. And I already said it's not really that big of a deal that I care too much to fix, because it doesn't really hinder my enjoyment of Doom, but I digress. All I wanted to know was what particular part of Mesa causes this.

 

On 3/23/2024 at 10:10 PM, Calinou1 said:

A short-term workaround is to upgrade to a 1440p (6x scale) or 2160p (9x scale) monitor, which don't have this issue for any 240p games :)

No thanks. I don't really see the point of "upgrading" to a lower refresh rate than I currently have to "fix" something that's this inconsequential.

[dpJudas]

This can't be caused by integer scaling from what I can tell on the images. The most likely source is low quality math in the GPU itself. Maybe there's a setting somewhere in the control panel for your GPU where you can set some quality level. I'm about 99.99% sure that this isn't an issue with any of the source ports.

 

Edit: if you have a spare cable for your computer, try replacing the one you are using for the monitor. This could theoretically be a transfer issue when sending the video signal to the monitor.

 

Edit 2: never mind that theory, since then you wouldn't have been able to make screenshots of it. :)

Edited March 28 by dpJudas

[Blzut3]

Should you feel like tracking this down, one thing you could test is to see if the issue happens with llvmpipe, zink+radv (assuming your GPU is Vulkan capable), and zink+lavapipe (Archwiki has info on environment variables to set to run a program with these drivers).  Either way you could try reporting the issue to Mesa, although you'd probably want to figure out how to install the latest Mesa on Fedora (or I guess Fedora 40 should be out soonish).  They would obviously be the best people to advise.

 

1 hour ago, dpJudas said:

Maybe there's a setting somewhere in the control panel for your GPU where you can set some quality level.

Besides nvidia's proprietary driver, there's no control panel for Linux.  (Well there are some third party projects.)  Pretty much everyone operates on defaults.  On the plus side this also means the driver shouldn't be mucking with things.

[dpJudas]

The artifacts we see here happens between lines of the same text glyph. Each such glyph is drawn by two triangles. Even a bad projection matrix can't create this effect. It was already clear to me with just the DSDA screenshot that it was very unlikely the source port's doing. When it then is shown that it also happens for an entirely different application (GZDoom) then its goes to incredibly unlikely to be the game at all. Chocolate Doom is irrelevant because even if SDL is using OpenGL it would be outputting only one or two triangles covering the entire window surface.

 

 

About the control panel thing, what I strongly suspect is going on here is that it isn't actually using a hardware GPU. It looks suspiciously like the kind of artifact the fastest SSE approximation instructions would produce (i.e. _mm_rcp_ps). I used the term control panel purely as a simple way of saying this could be something configured for speed rather than quality. Either way, I'm sure this is a "GPU" issue, not the game.

[hfc2x]

Smh my head, this is why Nvidia is winning!!! AMD ARE YOU LISTENING???

lmao

 

19 hours ago, Blzut3 said:

Should you feel like tracking this down, one thing you could test is to see if the issue happens with llvmpipe, zink+radv (assuming your GPU is Vulkan capable), and zink+lavapipe (Archwiki has info on environment variables to set to run a program with these drivers).  Either way you could try reporting the issue to Mesa, although you'd probably want to figure out how to install the latest Mesa on Fedora (or I guess Fedora 40 should be out soonish).  They would obviously be the best people to advise.

Thank you! This is exactly what I was looking for, because if this is really a Mesa bug (which I'm convinced it is), then it certainly needs to be reported as such. The problem is that I had no idea where to start poking, or even how to Google this because how specific this issue really is. I thought about looking at the Arch wiki, but then again, I had no idea how to even look for this specific level of troubleshooting.

 

Fedora 40 should officially be dropping on April, so I think I'll just wait and then see if anything has changed (and if not, then install mesa-git to see if it's been fixed there lol).

 

Guess we can close the thread now.