We've have DXVK and VKD3D-Proton for various versions of Direct3D on Linux, but now it seems we're also getting Direct3D 7 as well.
From the GitHub page the developer describes how it works:
A Vulkan-based translation layer for Direct3D 7, which allows running 3D applications on Linux using Wine. It uses DXVK's d3d9 backend as well as Wine's ddraw implementation (or the windows native ddraw) and acts as a proxy between the two, providing a minimal d3d7-on-d3d9 implementation. The project is currently in its early days. Expect most things to run, but not necessarily correctly or optimally.
The project has only recently had a first public release on GitHub (about two weeks ago), but a fresh update on November 5th should make it a whole lot better. As the developer said: "After focusing a bit on performance tuning, things are now anywhere between decent to stellar in most of the supported games".
Sounds like the intent is to keep it as a standalone project, and not merge it into DXVK. Pretty cool to see though, amazing for game preservation to get even more retro Windows games running and most importantly performing well on Linux where even modern Windows will likely struggle with some.

Pictured - Star Trek: Armada
It won't work with every Direct3D 7 game though, things were a bit messy back then with various APIs. The developers notes "d3d7 is a land of highly cursed API inter-operability, and applications that for one reason or another mix and match d3d7 with older ddraw (not ddraw7) and/or with GDI are not expected to ever work". With that in mind, it might also never be an official part of Proton (and certainly not Wine directly) - so this isn't some world-changing thing for Linux (or Steam Deck), but really cool to see anyway.
Going by PCGamingWiki, there's quite a number of games that use Direct3D 7.
You can find it on GitHub.
Last edited by Stella on 10 Nov 2025 at 3:51 pm UTC
d3d7 is a land of highly cursed API inter-operability, and applications that for one reason or another mix and match d3d7 with older ddraw (not ddraw7) and/or with GDI are not expected to ever work
dgvoodoo2 (converts old DirectX into newer DirectX) is closed-source, so couldn't be included directly, but the author of that tool has likely worked through those quirks for many games already; it's probably worth having a conversation.
Besides, if your rig cannot handle anything 7 or less in software rendering mode, then it will unlikely run dxvk.
A pointless, amateur, project.
This almost sounds like amateur would be something bad.
He recently asked Lutris team and other open source projects to no more use his tool.
[https://github.com/lutris/dgvoodoo2/issues/5](https://github.com/lutris/dgvoodoo2/issues/5)
We need a dgvoodoo2 replacement and open source. DXVK (directx 7-8-9-10-11), DxWrapper (DirectDraw/Direct3D 1–7 to Direct3D 9 and more;..), cnc-draw (GDI, OpenGL and Direct3D 9 re-implementation of the DirectDraw API for classic 2D games) replaced a lot of dgvoodoo2 features, but what about open source solutions for 3DFX games on Linux?
Last edited by legluondunet on 10 Nov 2025 at 6:58 pm UTC
Please do not talk about dgvoodoo2, it's closed source and his dev is not friendly with open sourceFor those of you that are curious about the background to this matter, please follow these links:
https://github.com/lutris/dgvoodoo2/issues/5
https://www.vogons.org/viewtopic.php?t=104797
At first it seems that the dev is being reasonable in his concerns until you read on further and discover that his most recent version is having problems in Linux and he doesn't seem to care. It is made worse by the fact that, two months later, he locked down his GitHub site and put the project into read-only mode.
@legluondunet, I can certainly appreciate your frustration in having to deal with this individual. Strange that he cannot comprehend that forcing absolutely everyone to do your beta testing is the wrong approach. Why should they have to potentially wait months for a fix when a previous version will work just fine? Hopefully, someone will step up to produce an alternative to his project. A shame that they will likely have to reinvent the wheel. This is a good beginning.
Last edited by Caldathras on 10 Nov 2025 at 11:27 pm UTC
And yeah, I wouldn't touch any dgvoodo2 stuff if its author can't figure out what open source is for.
Last edited by Shmerl on 10 Nov 2025 at 11:47 pm UTC
0. Watch out for
There can be certain frameworks, launchers and similar craps orbiting out there - like Lutris - bundling dgVoodoo (and who knows how many others there are). This one, for example, runs on a system based on a bloated, multiversion, hack-f(or)est Win32 impleme imitation that cannot even run dgVoodoo, just some old, outdated version (probably in a shitty way) and even that one is defective. I mean, only a few components are shipped - the ones they can't replace by anything else. So, when you're using dgVoodoo on a luxfuxOS distro in such an environment, then:
Keep in mind that you are not getting the full dgVoodoo experience; do not identify this with dgVoodoo
You're not welcome anyway
Nothing screams integrity like using proprietary crap while preaching open-source purity. Bravo, you hypocritical fuck
@Lutris: now that you archived the dgvoodoo2 project on your GitHub page to silence me (btw, FuckYou to you for that), you could finally ditch dgVoodoo itself as well, just like I asked. Anyway, you're now going against the developer's disapproval / license.
You're hated. <finger emoji> <finger emoji> Think about it every time you stumble upon anything dgVoodoo-related when rummaging through your files garbage.
What an utter child...
(PS. I saw fit to replace the emojis with text.)




How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck