this post was submitted on 08 Jan 2026
58 points (96.8% liked)
Linux Gaming
23158 readers
532 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
Resources
WWW:
- Linux Gaming wiki
- Gaming on Linux
- ProtonDB
- Lutris
- PCGamingWiki
- LibreGameWiki
- Boiling Steam
- Phoronix
- Linux VR Adventures
Discord:
IRC:
Matrix:
Telegram:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Typically when (some) 3D games don't work, I've found that 3D library support for one of the 32-bit or 64-bit binaries isn't present
Steam relies on the systemwide libraries
and the game bails or tries to do software rendering. I've hit some other users on here who have had the same issue.
It looks like the full versions of those are all run through Proton, are Windows binaries, though there are Linux-native demo binaries.
I have Dystopika myself.
installs
So probably 64-bit.
There's some environment variable that will force Proton to use the older Direct3D backend based on OpenGL (WineD3D) instead of Vulkan (DXVK). Let me see if I can find that.
searches
You want:
In the Steam launch properties for the game; that'll force it to use OpenGL instead of Vulkan. Here, it will run with or without it. Does that magically make it work?
One useful tool for debugging 3D issues is
mangohud. If you stick it in the Steam launch properties before "%command%" and it can display anything at all, it'll show an overlay showing which API (WineD3D or DXVK) is being used as well as what the rendering device being used is, which will let you know whether it's trying to render using software or hardware. SoMANGOHUD_CONFIG=full mangohud %command%.On my system, Dystopika appears able to render in pure software (not at a great framerate, mind):
So I don't know if it'd be falling back to software causing that. Rendering in software is listed in the mangohud overlay as being "llvmpipe".
Another way to check that each path functions is to run the following programs, see if they display correctly and at a reasonable clip. They're in the mesa-utils-bin:i386 and mesa-utils-bin:amd64 packages on Debian, so probably same for Mint:
That'll be a simple test of all of the OpenGL and Vulkan 32-bit and 64-bit interfaces.
Whether this fixes the OPs issue or not, this is a valuable post and my future self thanks you for making it as I'm sure I'll hit similar problems eventually. And I thank you now!