glitching effect on Steam Deck tied to mouse use?

[booper]

Hi Everyone,

I'm relatively new to gzdoom and primarily play on a Steam Deck in game mode using the gzdoom flatpak. I use game mode so that I can assign different keyboard controls to each of the buttons, eliminating the need for a controller mode and giving me a lot more configuration options w/r/t weapon switching and etc. I had zero problems getting the software to run and in general, I can play with no major errors. Nothing ever crashes, slows down, or stutters.

But I've run into a curious graphical glitch while playing Doom II that I'd love to have your feedback on, as I think it has something to do with using the flatpak in game mode vs. desktop, and therefore maybe something to do with how game mode handles rendering generally?

I'm using the Doom II .wad that is included in the Bethesda Doom + Doom II bundle sold on GOG.com.

If I am in Game Mode on the Steam Deck and I unlock the FPS in gzdoom or turn on vsync, I get the pictured graphical errors on the left and right sides of my screen whenever I move the "mouse" (bound to my right joystick). These errors do not appear if I don't move my mouse. I can run around levels only using WASD and the glitches never show. And they do not appear in any other game that I play on the Steam Deck, whether it is a non-Steam title, a Steam game, or something that I emulate.

If I use gzdoom (not the Steam overlay) to lock the FPS to around 59 or 60 and turn off vsync, the artifacting almost completely disappears even when I am using the "mouse" (bound to my right joystick). I still see it occasionally, especially in dark areas, but it is far less common and far less distracting.

The game runs beautifully otherwise. And my settings are basically what you can find at this link, without any mods installed: https://eev.ee/blog/2021/12/11/recommen ... -settings/

But what's really strange is that I can make the errors go away altogether if I do either of the following:

1) play in desktop mode instead of game mode; in this case, I can use the mouse all I want and I never see an error
2) turn off mouse controls and instead set my right joystick to the left and right arrow keys. I can then go into the controls, bind turning left and right to the arrows, and do away with the need for a "mouse" altogether.

I showed this error to someone in the ZDoom discord and they thought it was a sure sign that my Steam Deck had a hardware problem, but I've since tried playing 5 different games and none of them exhibit this glitch. On top of that, I've found a surefire and repeatable way of eliminating the glitch by playing in desktop mode or by using something other than a "mouse" to control the game in Game Mode. I've also tried enabling and disabling dynamic lights and using different resolutions. None of them seem to make a difference, but getting rid of the mouse controls works every time.

Any idea what could be going on? If you need further info or if there is a way I can dump my settings for all of you to see in a txt file, please let me know.

I'm in flatpak version g4.14.2-m
My Steam Deck is fully up to date on the stable update channel.

Many thanks!

[Rachael]

All I can tell you is this doesn't happen to me. And nothing can be fixed unless it can be reliably recreated - because recreating the error condition that causes the glitches in the first place is necessary for testing if it disappears after the fix is applied so that you know it's a good fix.

I still think it's a hardware error. The exact randomness yet "griddy" pattern of the imprefections is something I have seen before - it appears whenever I have a GPU that needs to be replaced. I can easily accept that there might be more conditions than that but only if I can actually and provably see it being caused by another problem. I also know that problems like this tend to be intermittent - they hide in certain conditions, show in others, they might even hide at certain times and show at other times, but the underlying cause does not go away.

So it's not a hardware problem? What else could it be? Considering no one else has reported that problem on their Steam Deck, it has never happened on mine, and it certainly doesn't appear on any PC's that aren't failing similarly as I suggested.

Prove me wrong. If there is an actual error in the code, I more than probably anyone would like to see it fixed, and I hope that is possible.

(As an aside, check your temps. Make sure that the device is not overheating. If it is try and lower the render resolution and see if it fixes anything - fix could be as simple as keeping it cool - that pattern also appears when overheating is afoot too.)

[booper]

Hi Rachael. Thanks for looking at this again. Definitely don't mean to bug you with something that gzdoom can't control. I did a bit more tinkering after the Discord post and wanted to share it with a wider group in case the extra details were useful. Once I saw that I could get rid of the problem completely in Desktop mode and once I realized none of my other high FPS games exhibited the same problem, I felt a little more certain the error had something to do with Game Mode, gamescope, or... mangohud? Maybe? Could be a driver issue for all I know, but I wanted to check with someone who knew the project before drawing any conclusions and trying to send back the device (or buy a new one).

I don't have any temp problems, don't see any errors in any other games, and the hardware doesn't exhibit any other signs of failure.

I should probably post more pictures because I also realized last night the two I have are not representative at all. Most of the glitches I see are whiter and they follow patterns in the field of view, like they ride along the edge of a pillar or they sparkle around the Doom guy's hand and gun when the pistol is out. The green pillars pop in and out intermittently, but are actually less common. If I set the game to windowed mode and run around, the glitches stay inside the area of the screen where the game is being rendered and do not extend into the black part of the screen that isn't being used.

The only other thing I've noticed is that Steam's framerate limiter doesn't effect the game's FPS at all when in gamemode. And if I force vsync inside gzdoom, then I get some very noticeable input lag. But if I just set the fps in gzdoom to 60, most of the errors disappear... and if I set it to 35, I can play for 45 minutes without ever seeing a single glitch.

Since the flatpak performs perfectly in desktop mode and plays perfectly on my home PC, I'm inclined to think the issue is with Valve, I'm just not 100% certain of the hardware error/damage since I can't reproduce the same glitch in any other software. Something tells me there's a problem with how Valve handles flatpaks in game mode, or maybe with the way Wayland handles flatpaks in game mode? But I'm not technical enough to figure that out.

Thanks again for looking this, and apologies if any of this came across as obnoxious. I'm curious more than anything else, so wanted to get a few more eyes on it if I could.

[phantombeta]

This looks awfully similar to this issue on the Github repo for Valve's "gamescope". It's been seemingly fixed, but my guess would be that either this compositor can't handle GZDoom properly, or MangoHud is causing issues with GZDoom. (I'm pretty sure I've heard of this "MangoHud" causing issues before, so I wouldn't be surprised if it's at fault here)

[booper]

phantombeta wrote:
> This looks awfully similar to
> [url=https://github.com/ValveSoftware/gamescope/issues/1368]this issue on
> the Github repo for Valve's "gamescope"[/url]. It's been
> seemingly fixed, but my guess would be that either this compositor can't
> handle GZDoom properly, or MangoHud is causing issues with GZDoom. (I'm
> pretty sure I've heard of this "MangoHud" causing issues before,
> so I wouldn't be surprised if it's at fault here)

That's it! That's the error, and a (temporary?) solution is listed too. I swear I spent an hour looking for Wayland and MagnoHud-related compositor errors the other night and never came across that thread, but the video in there is a perfect demonstration of what I was seeing in-game, and even the partial solution of lowering the FPS is mentioned.

I activated developer mode, turned on "force composite," and the glitching went away entirely. So nothing to do with gzdoom, but I am surprised that other users don't have the same experience as me when in game mode. Does that come down to drivers? Individual setup? Differences in iterations of the hardware? Super mysterious, but this at least resolves the issue. Thanks so much for posting!!

[Rachael]

Could be something to do with Wayland itself, too. Not a lot of people use Wayland for GZDoom, so that could be why this never got caught.

That being said, even when Wayland is active, SDL itself defaults to using X11 if it is available, and most Wayland compositors have an X11 server included, SteamOS's version of KDE Plasma being no exception. (In fact, Proton, which is based on Wine, cannot even run graphical applications such as games without it, so it's likely considered a critical component for SteamOS)

It might be possible, even using Steam's game mode, to force SDL to use Wayland. In the game's launch parameters, instead of executing GZDoom directly, you can (assuming SteamOS uses bash like everything else) add an environment setting in front of GZDoom to set it for that specific session. Example:

Code: Select all

SDL_VIDEODRIVER=wayland %command%

That should work from Steam's launch parameters.

[Hellser]

Could be something to do with Wayland itself, too. Not a lot of people use Wayland for GZDoom, so that could be why this never got caught.

Unfortunately (or perhaps fortunately?) a lot of distros are switching to Wayland by default. In my experience GZDoom runs fine. Gamescope however does not support Wayland by default and requires an argument to support it - for an example:

Code: Select all

gamescope --expose-wayland %COMMAND%

[Rachael]

I will see about tweaking SDL to use Wayland by default whenever it is available. It can still be overridden to use X11 via environment.