[GH-ISSUE #5] It's time for dgvoodoo to be canned

bsakaguchi commented

2026-10-31 13:05:40 +00:00

Owner

Originally created by @dege-diosg on GitHub (Sep 18, 2025).
Original GitHub issue: https://github.com/lutris/dgvoodoo2/issues/5

Lutris currently bundles/comes with/installs a defective, old, pile of crap version of dgvoodoo (2.8.2 or sg like that), which is outdated and misrepresents the current state of the project. Since you clearly have no intention of updating it, I want you to remove dgVoodoo entirely from your platform. Let users decide whether they want to use it, and if so, which version and install that version manually. Continuing to distribute an obsolete build under the dgVoodoo name is misleading and unacceptable.

Originally created by @dege-diosg on GitHub (Sep 18, 2025). Original GitHub issue: https://github.com/lutris/dgvoodoo2/issues/5 Lutris currently bundles/comes with/installs a defective, old, pile of crap version of dgvoodoo (2.8.2 or sg like that), which is outdated and misrepresents the current state of the project. Since you clearly have no intention of updating it, I want you to remove dgVoodoo entirely from your platform. Let users decide whether they want to use it, and if so, which version and install that version manually. Continuing to distribute an obsolete build under the dgVoodoo name is misleading and unacceptable.

bsakaguchi referenced this issue

2026-10-31 13:05:40 +00:00

[GH-ISSUE #4] dgVoodoo2 2.85 works with GOG Omikron with some hacks [Request Testing] #5

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@strycore commented on GitHub (Sep 22, 2025):

Hi,
I would really prefer to keep DgVoodoo included in the project. I have received some reports that the current latest version didn't work on Linux, is that still the case? If not, I can go ahead and update it to latest without issue.

I'm not sure what is the issue with the current version we use, it has shown some good results and has proven to be really useful. Of course, it's always preferable to stay on the current version but I want to make sure it is fully compatible before doing so.

If the latest version of DgVoodoo proves to be working on Linux, then the old version will be removed (I'll change the DgVoodoo option to no longer have a version selector, it will always use the latest). If users need an older version for whatever reason, that can be implemented in scripts.

@strycore commented on GitHub (Sep 22, 2025): Hi, I would really prefer to keep DgVoodoo included in the project. I have received some reports that the current latest version didn't work on Linux, is that still the case? If not, I can go ahead and update it to latest without issue. I'm not sure what is the issue with the current version we use, it has shown some good results and has proven to be really useful. Of course, it's always preferable to stay on the current version but I want to make sure it is fully compatible before doing so. If the latest version of DgVoodoo proves to be working on Linux, then the old version will be removed (I'll change the DgVoodoo option to no longer have a version selector, it will always use the latest). If users need an older version for whatever reason, that can be implemented in scripts.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 22, 2025):

Last dgVoodoo2 versions had a bug on DXVK/DXGI code that fail to detect or enumerate correctly the virtual dgVoodoo2 device, but a found a hack that could be useful for debugging and fix the bug of DXVK/DXGI or other Wine component.

One game (Omikron) could be used to trace the bug.
For starter, you need to use the old working version 2.80 (and unpack the newer version ready) to the game detect dgVoodoo2 and works. Once saved the ingame graphical settings, you can now Change to the New (2.86) version and starts normally.

I made this hack with two machines and worked with this instructions.

@Arucard1983 commented on GitHub (Sep 22, 2025): Last dgVoodoo2 versions had a bug on DXVK/DXGI code that fail to detect or enumerate correctly the virtual dgVoodoo2 device, but a found a hack that could be useful for debugging and fix the bug of DXVK/DXGI or other Wine component. One game (Omikron) could be used to trace the bug. For starter, you need to use the old working version 2.80 (and unpack the newer version ready) to the game detect dgVoodoo2 and works. Once saved the ingame graphical settings, you can now Change to the New (2.86) version and starts normally. I made this hack with two machines and worked with this instructions.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 22, 2025):

I made a simpler discovery. The old game Montezuma Return which is an old DirectX 5 game (with no 3D render) and 3dfx Glide game (dgVoodoo2 provides both support) always run correctly within 3dfx mode. No matter the old or the last dgVoodoo2 version (2.86.2) the game start and play.
The game always outputs a log file that shows that the virtual dgVoodoo2 3dfx device was initialized and displays the hardware features (A custom Voodoo2 board exactly as implemented by the wrapper.)

This means that the new dgVoodoo2 runs under Wine, but the detection and enumeration of the render device (specially on old DirectX versions) is broken, and this should be tested and traced the bug. I think that the culprit is an incomplete implementation of some function under DXGI that is critical on Direct3D 11 and 12 (that dgVoodoo2 use).
The Omikron game fails on newer dgVoodoo2 (but runs the Direct3D HAL using the Intel HD GPU that is the first device.), and only runs on 2.82. But once started on 2.82 and save the new display settings in-game, and switch back to 2.86 the wrapper now works, due to the correct display enumerator been properly stored and loaded.

Still I agree that Lutris should maintain a version menu with the most stable and tested version, to avoid regressions, while the newest version should be made available.

@Arucard1983 commented on GitHub (Sep 22, 2025): I made a simpler discovery. The old game Montezuma Return which is an old DirectX 5 game (with no 3D render) and 3dfx Glide game (dgVoodoo2 provides both support) always run correctly within 3dfx mode. No matter the old or the last dgVoodoo2 version (2.86.2) the game start and play. The game always outputs a log file that shows that the virtual dgVoodoo2 3dfx device was initialized and displays the hardware features (A custom Voodoo2 board exactly as implemented by the wrapper.) This means that the new dgVoodoo2 runs under Wine, but the detection and enumeration of the render device (specially on old DirectX versions) is broken, and this should be tested and traced the bug. I think that the culprit is an incomplete implementation of some function under DXGI that is critical on Direct3D 11 and 12 (that dgVoodoo2 use). The Omikron game fails on newer dgVoodoo2 (but runs the Direct3D HAL using the Intel HD GPU that is the first device.), and only runs on 2.82. But once started on 2.82 and save the new display settings in-game, and switch back to 2.86 the wrapper now works, due to the correct display enumerator been properly stored and loaded. Still I agree that Lutris should maintain a version menu with the most stable and tested version, to avoid regressions, while the newest version should be made available.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Sep 22, 2025):

I can confirm that dgVoodoo2 is unusable since 2.8x version, I can no more launch a game with newer versions.
The last version that works for me on Linux with Wine is 2.79.1.
Linux users that want to play their old Windows games on Linux do not have other choice than using older dgVoodoo2 version.

@Arucard1983 can you report that issue and your tests on winehq? It could be usefull for Wine team.

@legluondunet commented on GitHub (Sep 22, 2025): I can confirm that dgVoodoo2 is unusable since 2.8x version, I can no more launch a game with newer versions. The last version that works for me on Linux with Wine is 2.79.1. Linux users that want to play their old Windows games on Linux do not have other choice than using older dgVoodoo2 version. @Arucard1983 can you report that issue and your tests on winehq? It could be usefull for Wine team.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 22, 2025):

I can confirm that dgVoodoo2 is unusable since 2.8x version, I can no more launch a game with newer versions. The last version that works for me on Linux with Wine is 2.79.1. Linux users that want to play their old Windows games on Linux do not have other choice than using older dgVoodoo2 version.

@Arucard1983 can you report that issue and your tests on winehq? It could be usefull for Wine team.

I made a bug report to the DXVK team, since it was the middleware to make dgVoodoo2 work on Linux.

The Omikron game on Lutris requires the Wine-GE 8.26 with dgVoodoo2 2.86 to work, but you need to Start the older dgVoodoo2 2.80 first and then swap.
Other games that had setup tools that enumerate video devices, when older dgVoodoo2 is used the dgVoodoo2 wrapper device is listed, while on newer versions it is not detected or listed. If the game stored the dgVoodoo2 profiles earlier, it could load correctly with newer versions.

At least this is a strong clue to understand the bug.

@Arucard1983 commented on GitHub (Sep 22, 2025): > I can confirm that dgVoodoo2 is unusable since 2.8x version, I can no more launch a game with newer versions. The last version that works for me on Linux with Wine is 2.79.1. Linux users that want to play their old Windows games on Linux do not have other choice than using older dgVoodoo2 version. > > [@Arucard1983](https://github.com/Arucard1983) can you report that issue and your tests on winehq? It could be usefull for Wine team. I made a bug report to the DXVK team, since it was the middleware to make dgVoodoo2 work on Linux. The Omikron game on Lutris requires the Wine-GE 8.26 with dgVoodoo2 2.86 to work, but you need to Start the older dgVoodoo2 2.80 first and then swap. Other games that had setup tools that enumerate video devices, when older dgVoodoo2 is used the dgVoodoo2 wrapper device is listed, while on newer versions it is not detected or listed. If the game stored the dgVoodoo2 profiles earlier, it could load correctly with newer versions. At least this is a strong clue to understand the bug.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Sep 22, 2025):

I don't think it's a DXVK issue since even if I disable DXVK, dgvoodoo makes game crash at start.
I think it will be better to open an issue on WineHQ.

@legluondunet commented on GitHub (Sep 22, 2025): I don't think it's a DXVK issue since even if I disable DXVK, dgvoodoo makes game crash at start. I think it will be better to open an issue on WineHQ.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@strycore commented on GitHub (Sep 23, 2025):

Thanks for all the testing @Arucard1983 , can you by any chance see how this behaves with Proton GE 10.16? We're going to be deprecating Wine GE 2.26 rather soon...

@strycore commented on GitHub (Sep 23, 2025): Thanks for all the testing @Arucard1983 , can you by any chance see how this behaves with Proton GE 10.16? We're going to be deprecating Wine GE 2.26 rather soon...

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 23, 2025):

I retest the Montezuma Returns with Wine 10.8 from Lutris repository and the game works with dgVoodoo2 2.86.2, but since it is an old 3dfx Glide game, the bug that triggers on modern games is skipped.

Returning to Omikron but running the Settings applet I notice the following difference:

Using an older version of dgVoodoo2 the virtual device called dgVoodoo DirectX Wrapper appears on Video Driver list (along the software renderer ones), while on the new dgVoodoo2 version it shows the DirectDraw HAL which will cause the game to run badly (The HAL is Wine's software rendering). The dgVoodoo2 driver do not appears on the list.

Omikron appears to run with dgVoodoo2 2.86.2 when you use Mesa drivers (Intel HD), and not the proprietary Nvidia one which defaults to HAL (software rendering). Also you need to use the older dgVoodoo2 first before swap.

@Arucard1983 commented on GitHub (Sep 23, 2025): I retest the Montezuma Returns with Wine 10.8 from Lutris repository and the game works with dgVoodoo2 2.86.2, but since it is an old 3dfx Glide game, the bug that triggers on modern games is skipped. Returning to Omikron but running the Settings applet I notice the following difference: Using an older version of dgVoodoo2 the virtual device called dgVoodoo DirectX Wrapper appears on Video Driver list (along the software renderer ones), while on the new dgVoodoo2 version it shows the DirectDraw HAL which will cause the game to run badly (The HAL is Wine's software rendering). The dgVoodoo2 driver do not appears on the list. Omikron appears to run with dgVoodoo2 2.86.2 when you use Mesa drivers (Intel HD), and not the proprietary Nvidia one which defaults to HAL (software rendering). Also you need to use the older dgVoodoo2 first before swap.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 23, 2025):

I don't think it's a DXVK issue since even if I disable DXVK, dgvoodoo makes game crash at start. I think it will be better to open an issue on WineHQ.

I retest Montezuma and disable DXVK in order to use Wine OpenGL wrapper and the game just works exactly as with DXVK enabled. Also Omikron only works with older dgVoodoo2 due to not detection of the wrapper on newer versions.
This mean that the bug is around Wine's code and related to video adapters enumeration and detection.

Although in some cases, the games can work with certain hacks, this is a bug that should be notified to Wine's team.

@Arucard1983 commented on GitHub (Sep 23, 2025): > I don't think it's a DXVK issue since even if I disable DXVK, dgvoodoo makes game crash at start. I think it will be better to open an issue on WineHQ. I retest Montezuma and disable DXVK in order to use Wine OpenGL wrapper and the game just works exactly as with DXVK enabled. Also Omikron only works with older dgVoodoo2 due to not detection of the wrapper on newer versions. This mean that the bug is around Wine's code and related to video adapters enumeration and detection. Although in some cases, the games can work with certain hacks, this is a bug that should be notified to Wine's team.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 23, 2025):

WineHQ bug report made.

https://bugs.winehq.org/show_bug.cgi?id=58731

@Arucard1983 commented on GitHub (Sep 23, 2025): WineHQ bug report made. https://bugs.winehq.org/show_bug.cgi?id=58731

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@dege-diosg commented on GitHub (Sep 23, 2025):

No, just drop dgVoodoo. Anyone desperate enough can still throw the DLLs into the game folder manually, even the ones that are not bundled by default (glide, d3d8/9). That's how it works with any other launcher/whatever.

@dege-diosg commented on GitHub (Sep 23, 2025): No, just drop dgVoodoo. Anyone desperate enough can still throw the DLLs into the game folder manually, even the ones that are not bundled by default (glide, d3d8/9). That's how it works with any other launcher/whatever.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Sep 23, 2025):

@dege-diosg If Lutris no more provide old dgVoodoo2 version compatible with Wine, could you tell us where Linux users can download officially old dgVoodoo2 versions that are still compatible with Wine? You erased all your old versions from your official site and github too.

@legluondunet commented on GitHub (Sep 23, 2025): @dege-diosg If Lutris no more provide old dgVoodoo2 version compatible with Wine, could you tell us where Linux users can download officially old dgVoodoo2 versions that are still compatible with Wine? You erased all your old versions from your official site and github too.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 23, 2025):

And I made the Omikron test with the recent dgVoodoo2 with DXVK disabled. The game appears to crash on any Wine 10.x versions (page fault) and quickly broken the wineprefix (requiring to start a clean one), so I reuse the trusty 8.26-GE.

It confirmed that dgVoodoo2 issue is independent of the DXVK, and version 2.86.2 only runs at a second try with Mesa drivers (and continues to run after that.). The only (expected) issue is that Wine's own implementation of Direct3D 11 is too slow to handle dgVoodoo2 (that's why DXVK exists at first place.).

Montezuma's Return works with dgVoodoo2 2.86.2 and also with Wine 10.x which means that some old games should need older versions of Wine until all regressions are fixed. (And probably unrelated to dgVoodoo2 bug)
Further investigation reveals that the Glide mode always started, but the DirectDraw mode fails (the wrapper) and uses Wine's HAL instead that is enough to run this game.

Machines with Nvidia proprietary drivers do not work, and dgVoodoo2 is not detected when newer versions of the wrapper are used (like the WineHQ bug description).

@Arucard1983 commented on GitHub (Sep 23, 2025): And I made the Omikron test with the recent dgVoodoo2 with DXVK disabled. The game appears to crash on any Wine 10.x versions (page fault) and quickly broken the wineprefix (requiring to start a clean one), so I reuse the trusty 8.26-GE. It confirmed that dgVoodoo2 issue is independent of the DXVK, and version 2.86.2 only runs at a second try with Mesa drivers (and continues to run after that.). The only (expected) issue is that Wine's own implementation of Direct3D 11 is too slow to handle dgVoodoo2 (that's why DXVK exists at first place.). Montezuma's Return works with dgVoodoo2 2.86.2 and also with Wine 10.x which means that some old games should need older versions of Wine until all regressions are fixed. (And probably unrelated to dgVoodoo2 bug) Further investigation reveals that the Glide mode always started, but the DirectDraw mode fails (the wrapper) and uses Wine's HAL instead that is enough to run this game. Machines with Nvidia proprietary drivers do not work, and dgVoodoo2 is not detected when newer versions of the wrapper are used (like the WineHQ bug description).

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@epistulae-ad-infernum-pro-te commented on GitHub (Nov 11, 2025):

time for dgvoodoo to be canned

thats right! a privately owned, proprietary software & without a license

no licence
https://web.archive.org/web/20251007184831/https://dege.fw.hu/dgVoodoo2/ReadmeGeneral/

doesnt have rights respecting licensing
not compatible with free open source software

thats it.
nothing to see here
move along

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. 🖕🖕 Think about it every time you stumble upon anything dgVoodoo-related when rummaging through your files garbage.

1. Redistribution rights
You can freely ship your game or game mod with individual dgVoodoo files included.
If you want to host or re-distribute dgVoodoo as a standalone component for any reason then you must provide the full .zip package.

If you are a game publisher with whom I have not signed a contract then you should not use (further) dgVoodoo for the distributed games.

You cannot bundle dgVoodoo inside launchers or frameworks, for general use across multiple applications

@epistulae-ad-infernum-pro-te commented on GitHub (Nov 11, 2025): ### time for dgvoodoo to be canned thats right! a privately owned, proprietary software & without a license * no licence https://web.archive.org/web/20251007184831/https://dege.fw.hu/dgVoodoo2/ReadmeGeneral/ doesnt have rights respecting licensing not compatible with free open source software thats it. _nothing to see here move along_ ``` 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. 🖕🖕 Think about it every time you stumble upon anything dgVoodoo-related when rummaging through your files garbage. 1. Redistribution rights You can freely ship your game or game mod with individual dgVoodoo files included. If you want to host or re-distribute dgVoodoo as a standalone component for any reason then you must provide the full .zip package. If you are a game publisher with whom I have not signed a contract then you should not use (further) dgVoodoo for the distributed games. You cannot bundle dgVoodoo inside launchers or frameworks, for general use across multiple applications ```

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Nov 11, 2025):

dgvoodoo2 is not the only DirectX wrapper available. We should boycott this despicable developer and replace his tool with other similar ones such as dxwrapper, cnc-draw...and more recently DXVK7.

For 3DFX/Glide, we can use nglide, it's closed source but his dev is Linux/Wine friendly.

Yes, It's time for dgvoodoo to be canned, to use other similar tools and to let it die for not having been able to evolve.

@legluondunet commented on GitHub (Nov 11, 2025): dgvoodoo2 is not the only DirectX wrapper available. We should boycott this despicable developer and replace his tool with other similar ones such as dxwrapper, cnc-draw...and more recently DXVK7. For 3DFX/Glide, we can use nglide, it's closed source but his dev is Linux/Wine friendly. Yes, It's time for dgvoodoo to be canned, to use other similar tools and to let it die for not having been able to evolve.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@dege-diosg commented on GitHub (Nov 11, 2025):

We should boycott this despicable developer and replace his tool with other similar ones such as dxwrapper, cnc-draw...and more recently DXVK7.

Just do it, basically that's what I've been asking for.
You should stick to your own policies and use only FOS stuffs anyway. Everybody knows in the world that those are the best, by definition.

Yes, It's time for dgvoodoo to be canned, to use other similar tools and to let it die for not having been able to evolve.

dgVoodoo evolves because it's used on your Hack32 implementation? hahaha
Its evolution has nothing to do with the linux communi(s)ty and open source in general.

@dege-diosg commented on GitHub (Nov 11, 2025): > We should boycott this despicable developer and replace his tool with other similar ones such as dxwrapper, cnc-draw...and more recently DXVK7. Just do it, basically that's what I've been asking for. You should stick to your own policies and use only FOS stuffs anyway. Everybody knows in the world that those are the best, by definition. > Yes, It's time for dgvoodoo to be canned, to use other similar tools and to let it die for not having been able to evolve. dgVoodoo evolves because it's used on your Hack32 implementation? hahaha Its evolution has nothing to do with the linux communi(s)ty and open source in general.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@nesper8 commented on GitHub (Nov 12, 2025):

im a third party but hear me out
just keep it to spite on this guy

but i will wholly accept the decision of lutris whatever it would be

@nesper8 commented on GitHub (Nov 12, 2025): im a third party but hear me out just keep it to spite on this guy but i will wholly accept the decision of lutris whatever it would be

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@dege-diosg commented on GitHub (Nov 12, 2025):

What to be expected, according to open source cancer-like development practices (it'd be nice to bet money on this):

you keep it until your d7vk or whatever is in development, using MY stuff for reverse engineering the api implementation details (instead of an old win xp/7 machine, just to save yourself a lot of work, I mean, years of work), being paid by an ugly capitalist company, and then all the sect members and random clueless idiots will be ranting all over the net that you're the best

then and only then you will ditch dgVoodoo, the "propietary shit", independently on what the quality of your crap is like

but, in the meantime, at least anybody can read into how much you're being loved

@dege-diosg commented on GitHub (Nov 12, 2025): What to be expected, according to open source cancer-like development practices (it'd be nice to bet money on this): you keep it until your d7vk or whatever is in development, using MY stuff for reverse engineering the api implementation details (instead of an old win xp/7 machine, just to save yourself a lot of work, I mean, years of work), being paid by an ugly capitalist company, and then all the sect members and random clueless idiots will be ranting all over the net that you're the best then and only then you will ditch dgVoodoo, the "propietary shit", independently on what the quality of your crap is like but, in the meantime, at least anybody can read into how much you're being loved

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Nov 12, 2025):

Be patient, it's now a question of time your little crap proprietary code becomes obsolete.

@strycore could you close all tickets in this repository and archive it?

I'm tired to read @dege-diosg vomit.

@legluondunet commented on GitHub (Nov 12, 2025): Be patient, it's now a question of time your little crap proprietary code becomes obsolete. @strycore could you close all tickets in this repository and archive it? I'm tired to read @dege-diosg vomit.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@dege-diosg commented on GitHub (Nov 12, 2025):

Be patient, it's now a question of time your little crap proprietary code becomes obsolete.

Then why are you crying all over the net for dgVoodoo?

you f idiot

I'm tired to read @dege-diosg vomit.

A vomit that you can't even refute.

@dege-diosg commented on GitHub (Nov 12, 2025): > Be patient, it's now a question of time your little crap proprietary code becomes obsolete. Then why are you crying all over the net for dgVoodoo? you f idiot > I'm tired to read @dege-diosg vomit. A vomit that you can't even refute.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Nov 12, 2025):

| Then why are you crying all over the net for dgVoodoo?

I'm not crying, I'm just help you to reach your goal: to become the most hated developer in the Linux and open source community.
You seem to be more gifted at programming than at communication.
And you doesn't seem very smart either, because otherwise you would have sold your experience to this "ugly capitalist company" instead of accusing it of stealing your work (proof?).

@legluondunet commented on GitHub (Nov 12, 2025): | Then why are you crying all over the net for dgVoodoo? I'm not crying, I'm just help you to reach your goal: to become the most hated developer in the Linux and open source community. You seem to be more gifted at programming than at communication. And you doesn't seem very smart either, because otherwise you would have sold your experience to this "ugly capitalist company" instead of accusing it of stealing your work (proof?).

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@QmwJlHuSg9pa commented on GitHub (Nov 12, 2025):

The level of discourse in this thread is quite low, on all sides. That said, I greatly respect the work Dege has done with dgVoodoo over many, many years, and have enjoyed his work (even personally submitted bug reports along the way) for much of that time -- primarily on Windows -- and more recently on Linux platforms. I have no stake in this discussion, other than to shake my head at all of the mudslinging, which seems quite volatile and non-constructive. Everyone here is clearly passionate about videogame preservation, no matter our individual journeys to reach that end-goal.

@legluondunet, I will particularly single you out for dragging this out more than need be. I saw your reddit threads from September -- a seeming attempt at stirring more discontent on r/wine_gaming and r/linux_gaming. You seem entitled to Dege's work, though now that he wants to be rid of part of his audience (and honestly, seeing many of the comments around in these communities, it's hard to blame the notion) you would rather stir shit -- though to what end?

Please, someone -- lock this thread, or hide these inflammatory comments. I see no use in this flame-war carrying on further.

@QmwJlHuSg9pa commented on GitHub (Nov 12, 2025): The level of discourse in this thread is quite low, on all sides. That said, I greatly respect the work Dege has done with dgVoodoo over many, many years, and have enjoyed his work (even personally submitted bug reports along the way) for much of that time -- primarily on Windows -- and more recently on Linux platforms. I have no stake in this discussion, other than to shake my head at all of the mudslinging, which seems quite volatile and non-constructive. Everyone here is clearly passionate about videogame preservation, no matter our individual journeys to reach that end-goal. @legluondunet, I will particularly single you out for dragging this out more than need be. I saw your reddit threads from September -- a seeming attempt at stirring more discontent on r/wine_gaming and r/linux_gaming. You seem entitled to Dege's work, though now that he wants to be rid of part of his audience (and honestly, seeing many of the comments around in these communities, it's hard to blame the notion) you would rather stir shit -- though to what end? Please, someone -- lock this thread, or hide these inflammatory comments. I see no use in this flame-war carrying on further.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@dege-diosg commented on GitHub (Nov 12, 2025):

I'm not crying,

Vogons, reddit, github, you even hosted a dgvoodoo release on your github page, etc. But of course, you're not crying.

I'm just help you to reach your goal: to become the most hated developer in the Linux and open source community.

Ok then, thanks for that.

sold your experience to this "ugly capitalist company"

what company exactly?

accusing it of stealing your work (proof?).

No proof, what I said is the simplest method for a developer, and always the simplest way what is taken, especially when results need to be delivered quickly.

@dege-diosg commented on GitHub (Nov 12, 2025): > I'm not crying, Vogons, reddit, github, you even hosted a dgvoodoo release on your github page, etc. But of course, you're not crying. >I'm just help you to reach your goal: to become the most hated developer in the Linux and open source community. Ok then, thanks for that. >sold your experience to this "ugly capitalist company" what company exactly? >accusing it of stealing your work (proof?). No proof, what I said is the simplest method for a developer, and always the simplest way what is taken, especially when results need to be delivered quickly.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Nov 12, 2025):

| you even hosted a dgvoodoo release on your github page

Don't worry about that, your attitude has convinced me to remove dgvoodoo2 from my Github page and from all my Lutris scripts: I want nothing more to do with you and your buggy software. This would have been difficult a few years ago when I started writing installation scripts for Lutris. But today, I have other tools like dxwrapper, dxvk, cnc-draw etc., which perfectly replace dgvoodoo2, and communication with their developers is not toxic but smooth and constructive.

@legluondunet commented on GitHub (Nov 12, 2025): | you even hosted a dgvoodoo release on your github page Don't worry about that, your attitude has convinced me to remove dgvoodoo2 from my Github page and from all my Lutris scripts: I want nothing more to do with you and your buggy software. This would have been difficult a few years ago when I started writing installation scripts for Lutris. But today, I have other tools like dxwrapper, dxvk, cnc-draw etc., which perfectly replace dgvoodoo2, and communication with their developers is not toxic but smooth and constructive.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@legluondunet commented on GitHub (Nov 12, 2025):

@QmwJlHuSg9pa please read this page http://dege.fw.hu/dgVoodoo2/ReadmeGeneral/#watchoutfor before to take sides, do you find this acceptable?

@legluondunet commented on GitHub (Nov 12, 2025): @QmwJlHuSg9pa please read this page http://dege.fw.hu/dgVoodoo2/ReadmeGeneral/#watchoutfor before to take sides, do you find this acceptable?

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@allneuts commented on GitHub (Nov 12, 2025):

What to be expected, according to open source cancer-like development practices (it'd be nice to bet money on this):

@dege-diosg I don't know why anyone cares about dgVoodoo2.

I always saw it as a check box in Lutris and assumed it was a patch or work-around for games that were made to run on a Voodoo 2 graphics card.
Never needed it. Never used it.
It was completely irrelevant to me and I didn't notice it in our support channels either.

As to your comment about "Open Source Cancer-Like Development practises", I have a little list of companies that support these practises and throw money at them.
I guess you better stop using products from Meta, Intel, Google and Microsoft, just to name the top platinum contributors.
That also means you should get off github.com (bought out by Microsoft) and avoid GitLab, since they were built on these "Open Source Cancer-like Development practises".

I hope you enjoy your time on your Zhaoxin Kaixin machine, as I think only Viacom's licenser is the only non-contributor, (ARM, RISC-V and AMD support these "Cancer-like" practises too) and I hope you have a wonderful experience with TempleOS (MacOS runs on BSD, also part of the "Cancer-like Open Source" practises).
Edit: Oh and you also need to avoid 90% of websites, that are running on Linux, no AWS, OneDrive, iCloud, etc. I don't even know how you will look up which sites to avoid since I think all the whois and DNS architecture is hosted on Linux. Good luck with building your own DNS of closed sourced Microsoft hosted websites and routing your Internet traffic through non-Linux servers (you might find it a tiny bit difficult to connect to anywhere, so adding your own WiFi, satellite and radio bridges could be quite costly).
Edit 2: Apologies, I forgot about phones. You need to throw out any iPhones (BSD) or Android (Linux) ones. You will need an old Eriksson or something because even the Nokias ran on Java ("Cancer-like Open Source").

So yeah, this whole drama is a storm in a tea cup, that will probably be completely forgotten by everyone else, except you, by this time next year.

@allneuts commented on GitHub (Nov 12, 2025): > What to be expected, according to open source cancer-like development practices (it'd be nice to bet money on this): @dege-diosg I don't know why anyone cares about dgVoodoo2. I always saw it as a check box in Lutris and assumed it was a patch or work-around for games that were made to run on a Voodoo 2 graphics card. Never needed it. Never used it. It was completely irrelevant to me and I didn't notice it in our support channels either. As to your comment about "Open Source Cancer-Like Development practises", I have a [little list of companies that support these practises](https://www.linuxfoundation.org/about/members) and throw money at them. I guess you better stop using products from Meta, Intel, Google and **Microsoft**, just to name the top platinum contributors. That also means you should get off github.com (bought out by Microsoft) and avoid GitLab, since they were built on these "Open Source Cancer-like Development practises". I hope you enjoy your time on your Zhaoxin Kaixin machine, as I think only Viacom's licenser is the only non-contributor, (ARM, RISC-V and AMD support these "Cancer-like" practises too) and I hope you have a wonderful experience with TempleOS (MacOS runs on BSD, also part of the "Cancer-like Open Source" practises). Edit: Oh and you also need to avoid 90% of websites, that are running on Linux, no AWS, OneDrive, iCloud, etc. I don't even know how you will look up which sites to avoid since I think all the whois and DNS architecture is hosted on Linux. Good luck with building your own DNS of closed sourced **Microsoft** hosted websites and routing your Internet traffic through non-Linux servers (you might find it a tiny bit difficult to connect to anywhere, so adding your own WiFi, satellite and radio bridges could be quite costly). Edit 2: Apologies, I forgot about phones. You need to throw out any iPhones (BSD) or Android (Linux) ones. You will need an old Eriksson or something because even the Nokias ran on Java ("Cancer-like Open Source"). So yeah, this whole drama is a storm in a tea cup, that will probably be completely forgotten by everyone else, except you, by this time next year.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@dege-diosg commented on GitHub (Nov 12, 2025):

I don't know why anyone cares about dgVoodoo2.
Never needed it. Never used it.
It was completely irrelevant to me and I didn't notice it in our support channels either.

Well, that's why it won't be a pain for anybody if it's removed from lutris. I only asked for this in the first place without expecting any "drama". It wasn't up to me.

Just remove it and I won't have a look here anymore, I won't even remember what lutris and wine craps are, by the next week.
Except if some baby cries about dgVoodoo at me again that it's not running under wine while that was never a target in the first place.

@dege-diosg commented on GitHub (Nov 12, 2025): > I don't know why anyone cares about dgVoodoo2. > Never needed it. Never used it. > It was completely irrelevant to me and I didn't notice it in our support channels either. Well, that's why it won't be a pain for anybody if it's removed from lutris. I only asked for this in the first place without expecting any "drama". It wasn't up to me. Just remove it and I won't have a look here anymore, I won't even remember what lutris and wine craps are, by the next week. Except if some baby cries about dgVoodoo at me again that it's not running under wine while that was never a target in the first place.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@allneuts commented on GitHub (Nov 12, 2025):

I only asked for this in the first place without expecting any "drama". It wasn't up to me.

I doubt it.
If you had started by dropping into the Lutris Discord with some questions, we could have told you that strycore has been so busy with his 07:00 to 22:00 job that he hasn't released an update for Lutris in 10 months or so, which is unusual for him.

If you had dropped strycore a DM saying, ""Hi Strider. My project was made for Windows. I am tired of getting support questions from Linux users. Could you use an alternative like dxwrapper please?"

This probably would have been sorted.

Instead, you went around screaming in public places.
You can't even help yourself, you have to throw in a little "wine craps".

If I were strycore, I would ignore you and drop this right to the bottom of my priorities list now.

@allneuts commented on GitHub (Nov 12, 2025): > I only asked for this in the first place without expecting any "drama". It wasn't up to me. I doubt it. If you had started by dropping into the Lutris Discord with some questions, we could have told you that strycore has been so busy with his 07:00 to 22:00 job that he hasn't released an update for Lutris in 10 months or so, which is unusual for him. If you had dropped strycore a DM saying, ""Hi Strider. My project was made for Windows. I am tired of getting support questions from Linux users. Could you use an alternative like dxwrapper please?" This probably would have been sorted. Instead, you went around [screaming in public places](https://www.dege.freeweb.hu/dgVoodoo2/ReadmeGeneral/). You can't even help yourself, you have to throw in a little "wine craps". If I were strycore, I would ignore you and drop this right to the bottom of my priorities list now.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@strycore commented on GitHub (Nov 13, 2025):

Alright, everyone needs to chill.
The topmost priority is not to break games for our existing users. dgVoodoo has worked wonderfully in the past, yes, even that old so called "broken" version. There's a whole bunch of games that were made playable just but ticking the dgVoodoo checkbox.

@dege-diosg's demands were quite sudden and unexpected. For the longest time, I was under the impression that there were some kind of agreement that Tannis and Dege made to be able to redistribute dgVoodoo2 which at the time was "you can redistribute but only the Glide part, not the DirectX part.
Then a few months ago, I agreed to remove our Github hosted version, leave the latest version used by Lutris on one of our servers and find a better migration path in the future.
Now, all of a sudden, this has escalated to "remove everything right now".

I don't understand what has triggered this level of anger, which has gone as far as deleting things from the Internet Archive. This leaves me perplexed but honestly, this is not my problem. We've been doing our thing for years without issue. I've never made any demands or complaints to dgVoodoo and was quite happy with the situation.

I was also happy to work on a way forward to try and get the full and latest version of dgVoodoo to work with Lutris. Given the current level of discussion here, this now seems unlikely...

As I've said above, the most important part is keeping games to work, because that's what Lutris is all about. So what we need now is make a list of all games using dgVoodoo and ensure they are still working using an alternative wrapper. I see some references to d7vk in this thread which is kinda out of scope since our feature only provides Glide.

This is quite a sad situation since I've always considered dgVoodoo2 to be a cool project and never had considered our usage of it harmful. That said, @legluondunet is by far the most proficient contributor of scripts for the 3DFX era and now that some bridges have been burnt, I don't really see a way forward except looking into other wrappers.

Lutris 0.5.20 is going to enter its beta testing phase. It's too late to add or remove features at this point. We can plan a migration from dgVoodoo in 0.5.21 which should be a much smaller and faster to ship version than 0.5.20.

@strycore commented on GitHub (Nov 13, 2025): Alright, everyone needs to chill. The topmost priority is not to break games for our existing users. dgVoodoo has worked wonderfully in the past, yes, even that old so called "broken" version. There's a whole bunch of games that were made playable just but ticking the dgVoodoo checkbox. @dege-diosg's demands were quite sudden and unexpected. For the longest time, I was under the impression that there were some kind of agreement that Tannis and Dege made to be able to redistribute dgVoodoo2 which at the time was "you can redistribute but only the Glide part, not the DirectX part. Then a few months ago, I agreed to remove our Github hosted version, leave the latest version used by Lutris on one of our servers and find a better migration path in the future. Now, all of a sudden, this has escalated to "remove everything right now". I don't understand what has triggered this level of anger, which has gone as far as deleting things from the Internet Archive. This leaves me perplexed but honestly, this is not my problem. We've been doing our thing for years without issue. I've never made any demands or complaints to dgVoodoo and was quite happy with the situation. I was also happy to work on a way forward to try and get the full and latest version of dgVoodoo to work with Lutris. Given the current level of discussion here, this now seems unlikely... As I've said above, the most important part is keeping games to work, because that's what Lutris is all about. So what we need now is make a list of all games using dgVoodoo and ensure they are still working using an alternative wrapper. I see some references to d7vk in this thread which is kinda out of scope since our feature only provides Glide. This is quite a sad situation since I've always considered dgVoodoo2 to be a cool project and never had considered our usage of it harmful. That said, @legluondunet is by far the most proficient contributor of scripts for the 3DFX era and now that some bridges have been burnt, I don't really see a way forward except looking into other wrappers. Lutris 0.5.20 is going to enter its beta testing phase. It's too late to add or remove features at this point. We can plan a migration from dgVoodoo in 0.5.21 which should be a much smaller and faster to ship version than 0.5.20.

bsakaguchi commented

2026-10-31 13:05:41 +00:00

Author

Owner

@dege-diosg commented on GitHub (Nov 13, 2025):

Well, okay, yes, I have my frustrations. I never liked the idea of open source, especially the current form which is basically free labor for the big tech from individuals, and virtue signaling by big tech (partly funded by the hated ads and telemetry), and people supporting this setup. But I always hated the fact that open-source advocates openly disparage everything proprietary or closed source yet still use such software when/while they have no alternatives. I also hated that you were distributing an incomplete version of dgvoodoo (the components only needed for you). As far as I know, even if a software is redistributable, distributing a cherry-picked version is generally not permitted by any company anyway, for understandable reasons.

So, ok, I tried to make you remove dgvoodoo from lutris, but I see that this won't be an easy go. It's a "this is what it is" situation by now but I'd like to put an end to this all. So, I've decided not to worry anymore about whether you use dgvoodoo in lutris or not, and whether you remove it or you'll only do it sometime in the future, replacing it with some other piece of software.

I'll remove the lutris part from the README, and let's just move on, go our separate ways.

@dege-diosg commented on GitHub (Nov 13, 2025): Well, okay, yes, I have my frustrations. I never liked the idea of open source, especially the current form which is basically free labor for the big tech from individuals, and virtue signaling by big tech (partly funded by the hated ads and telemetry), and people supporting this setup. But I always hated the fact that open-source advocates openly disparage everything proprietary or closed source yet still use such software when/while they have no alternatives. I also hated that you were distributing an incomplete version of dgvoodoo (the components only needed for you). As far as I know, even if a software is redistributable, distributing a cherry-picked version is generally not permitted by any company anyway, for understandable reasons. So, ok, I tried to make you remove dgvoodoo from lutris, but I see that this won't be an easy go. It's a "this is what it is" situation by now but I'd like to put an end to this all. So, I've decided not to worry anymore about whether you use dgvoodoo in lutris or not, and whether you remove it or you'll only do it sometime in the future, replacing it with some other piece of software. I'll remove the lutris part from the README, and let's just move on, go our separate ways.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@allneuts commented on GitHub (Nov 13, 2025):

I was under the impression that there were some kind of agreement that Tannis and Dege made to be able to redistribute dgVoodoo2 which at the time was "you can redistribute but only the Glide part, not the DirectX part." - strycore

I also hated that you were distributing an incomplete version of dgvoodoo (the components only needed for you). - dege-diosg

Seems like there was a miscommunication or something was forgotten.

I use what ever tool is best.
Generally, I find that Open Source is better.

For example, an old lady I helped by swopping out her WinXP on her old PC to the latest Ubuntu, somehow managed to break her network manager. Pop a Live USB in, downloaded the packages needed, swop to the installed drive and install them.
Had that been Windows, sfc /scannow or DISM might have fixed it, however, it is far more likely that the machine would have required formatting and reinstalling.

We tend to use closed source components and solutions in Linux because those games and applications were built on closed garden components. Thankfully Vulkan is at least being used to convert DirectX shaders. However, much is still reliant on DirectX, it was used to trap those applications onto Windows for a long time.
WINE's approach is to reverse engineer Windows and not "look under the hood". WinXP's source code was leaked, they could be miles ahead by now; at the least they could have DirectX 9 fully re-written to be "DirectinX_9" and yet they are sticking to their principles when an easy way forward, to subvert questionable practises, is available.

virtue signaling by big tech (partly funded by the hated ads and telemetry),

I ignore, block, firewall, delete and seek alternatives.

Attacking mom and pop projects won't change corporate practises. If you want to see real change, start a movement like "Stop Killing Games" and "Right to Repair" has done.

P.S. There have always been people coding for free. How much historically were Skyrim modders paid? Did the creator of Windows RAM defragmenter and compressor get a single dime?

@allneuts commented on GitHub (Nov 13, 2025): > I was under the impression that there were some kind of agreement that Tannis and Dege made to be able to redistribute dgVoodoo2 which at the time was "you _can redistribute but **only** the Glide part_, **not** the DirectX part." - strycore > I also hated that you were distributing an **incomplete** version of dgvoodoo (the components only needed for you). - dege-diosg Seems like there was a miscommunication or something was forgotten. I use what ever tool is best. **_Generally_**, I find that Open Source is better. For example, an old lady I helped by swopping out her WinXP on her old PC to the latest Ubuntu, somehow managed to break her network manager. Pop a Live USB in, downloaded the packages needed, swop to the installed drive and install them. Had that been Windows, `sfc /scannow` or `DISM` _**might**_ have fixed it, however, it is far more likely that the machine would have required formatting and reinstalling. We tend to use closed source components and solutions in Linux because those games and applications were built on closed garden components. Thankfully Vulkan is at least being used to convert DirectX shaders. However, much is still reliant on DirectX, it was used to trap those applications onto Windows for a long time. `WINE`'s approach is to reverse engineer Windows and not "look under the hood". WinXP's source code was leaked, they could be miles ahead by now; at the least they could have DirectX 9 fully re-written to be "Direct**inX**_9" and yet they are sticking to their principles when an easy way forward, to subvert questionable practises, is available. > virtue signaling by big tech (partly funded by the hated ads and telemetry), I ignore, block, firewall, delete and seek alternatives. Attacking mom and pop projects won't change corporate practises. If you want to see real change, start a movement like "Stop Killing Games" and "Right to Repair" has done. P.S. There have always been people coding for free. How much historically were Skyrim modders paid? Did the creator of Windows RAM defragmenter and compressor get a single dime?

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@strycore commented on GitHub (Nov 13, 2025):

I never liked the idea of open source, especially the current form which is basically free labor for the big tech from individuals, and virtue signaling by big tech (partly funded by the hated ads and telemetry), and people supporting this setup.

As with most issues these days, the problem is with capitalism, not open source.

But I always hated the fact that open-source advocates openly disparage everything proprietary or closed source yet still use such software when/while they have no alternatives.

There are open source advocates with extreme positions, yes. In the case of Lutris, let's be honest, the whole goal is to run proprietary software (games). We've been using whatever tools are best to get games to run on Linux.

So, ok, I tried to make you remove dgvoodoo from lutris, but I see that this won't be an easy go.

I said I wouldn't remove it from this upcoming release, which I've also stated in the past. But for the next release, we'll likely be removing the dgVoodoo feature. Note that this won't affect Lutris install scripts using dgVoodoo independently from the Lutris feature.

@strycore commented on GitHub (Nov 13, 2025): > I never liked the idea of open source, especially the current form which is basically free labor for the big tech from individuals, and virtue signaling by big tech (partly funded by the hated ads and telemetry), and people supporting this setup. As with most issues these days, the problem is with capitalism, not open source. > But I always hated the fact that open-source advocates openly disparage everything proprietary or closed source yet still use such software when/while they have no alternatives. There are open source advocates with extreme positions, yes. In the case of Lutris, let's be honest, the whole goal is to run proprietary software (games). We've been using whatever tools are best to get games to run on Linux. > So, ok, I tried to make you remove dgvoodoo from lutris, but I see that this won't be an easy go. I said I wouldn't remove it from this upcoming release, which I've also stated in the past. But for the next release, we'll likely be removing the dgVoodoo feature. Note that this won't affect Lutris install scripts using dgVoodoo independently from the Lutris feature.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@allneuts commented on GitHub (Nov 13, 2025):

But for the next release, we'll likely be removing the dgVoodoo feature.

Will it be possible to automatically swop dgVoodoo2 references for dxwrapper ones?

@allneuts commented on GitHub (Nov 13, 2025): > But for the next release, we'll likely be removing the dgVoodoo feature. Will it be possible to automatically swop dgVoodoo2 references for dxwrapper ones?

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@legluondunet commented on GitHub (Nov 13, 2025):

| Will it be possible to automatically swop dgVoodoo2 references for dxwrapper ones?

no, it will not be so simple.

There are two different situations:

Lutris interface has an option to enable dgvoodoo2 for a game (Strider planned to remove it in 0.5.21)
Lutris community wrote games scripts installer which use dgvoodoo2, download dgvoodoo2 from different sources...

point 1 and 2 are independent.

DxWrapper and dgVoodoo2 needs different config file and options...
And DxWrapper can not replace dgVoodoo in all case, for Glide games, we will need to use another wrapper.
It's a lot of work to do all this changes, it will take time.

@legluondunet commented on GitHub (Nov 13, 2025): | Will it be possible to automatically swop dgVoodoo2 references for dxwrapper ones? no, it will not be so simple. There are two different situations: 1) Lutris interface has an option to enable dgvoodoo2 for a game (Strider planned to remove it in 0.5.21) 2) Lutris community wrote games scripts installer which use dgvoodoo2, download dgvoodoo2 from different sources... point 1 and 2 are independent. DxWrapper and dgVoodoo2 needs different config file and options... And DxWrapper can not replace dgVoodoo in all case, for Glide games, we will need to use another wrapper. It's a lot of work to do all this changes, it will take time.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@QmwJlHuSg9pa commented on GitHub (Nov 13, 2025):

| Will it be possible to automatically swop dgVoodoo2 references for dxwrapper ones?

no, it will not be so simple.

There are two different situations:
1. Lutris interface has an option to enable dgvoodoo2 for a game (Strider planned to remove it in 0.5.21)

2. Lutris community wrote games scripts installer which use dgvoodoo2, download dgvoodoo2 from different sources...
point 1 and 2 are independent.

DxWrapper and dgVoodoo2 needs different config file and options... And DxWrapper can not replace dgVoodoo in all case, for Glide games, we will need to use another wrapper. It's a lot of work to do all this changes, it will take time.

Personally, I make good use of many features that I believe are unique to dgVoodoo's Direct3D wrappers; I would not wish to see individual scripts I've submitted to be degraded in this way, merely to suit extreme FOSS tastes (as @strycore pointed out, we are primarily working with proprietary software anyway). If there were to be a policy of removing dgV from existing scripts, then I would advocate for support of third-party script repositories to be integrated directly into the Lutris client as an alternative, and pending Dege's current permissions for referencing and installing his zip package within individual scripts.

@QmwJlHuSg9pa commented on GitHub (Nov 13, 2025): > | Will it be possible to automatically swop dgVoodoo2 references for dxwrapper ones? > > no, it will not be so simple. > > There are two different situations: > > 1. Lutris interface has an option to enable dgvoodoo2 for a game (Strider planned to remove it in 0.5.21) > > 2. Lutris community wrote games scripts installer which use dgvoodoo2, download dgvoodoo2 from different sources... > > > point 1 and 2 are independent. > > DxWrapper and dgVoodoo2 needs different config file and options... And DxWrapper can not replace dgVoodoo in all case, for Glide games, we will need to use another wrapper. It's a lot of work to do all this changes, it will take time. Personally, I make good use of many features that I believe are unique to dgVoodoo's Direct3D wrappers; I would not wish to see individual scripts I've submitted to be degraded in this way, merely to suit extreme FOSS tastes (as @strycore pointed out, we are primarily working with proprietary software anyway). If there were to be a policy of removing dgV from existing scripts, then I would advocate for support of third-party script repositories to be integrated directly into the Lutris client as an alternative, and pending Dege's current permissions for referencing and installing his zip package within individual scripts.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@allneuts commented on GitHub (Nov 14, 2025):

2. Lutris community wrote games scripts installer which use dgvoodoo2, download dgvoodoo2 from different sources...

Could 2. be fixed with a Find & Replace with some case code on the server side?

Arbitrary example:

CASE
 "dgVoodoo2 -a -r" THEN "dxwrapper -p -Q"
 "dgVoodoo2 -b --install" THEN "dxwrapper -install -Z"
END

@allneuts commented on GitHub (Nov 14, 2025): > 2. Lutris community wrote games scripts installer which use dgvoodoo2, download dgvoodoo2 from different sources... Could 2. be fixed with a Find & Replace with some case code on the server side? Arbitrary example: ``` CASE "dgVoodoo2 -a -r" THEN "dxwrapper -p -Q" "dgVoodoo2 -b --install" THEN "dxwrapper -install -Z" END ```

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@strycore commented on GitHub (Nov 14, 2025):

Could 2. be fixed with a Find & Replace with some case code on the server side?

Good way to speedrun the breakage of all scripts using dgvoodoo

Personally, I make good use of many features that I believe are unique to dgVoodoo's Direct3D wrappers;

The removal request is about the dgVoodoo feature in Lutris, not the usage of dgVoodoo in scripts, especially ones for D3D since those have to use a full archive of dgVoodoo.

@strycore commented on GitHub (Nov 14, 2025): > Could 2. be fixed with a Find & Replace with some case code on the server side? Good way to speedrun the breakage of all scripts using dgvoodoo > Personally, I make good use of many features that I believe are unique to dgVoodoo's Direct3D wrappers; The removal request is about the dgVoodoo feature in Lutris, not the usage of dgVoodoo in scripts, especially ones for D3D since those have to use a full archive of dgVoodoo.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@TheGuyWhoIsIdiot commented on GitHub (Mar 11, 2026):

This is full of crap and I had a stroke reading the entire issue's comments 😭😭😭

@TheGuyWhoIsIdiot commented on GitHub (Mar 11, 2026): This is full of crap and I had a stroke reading the entire issue's comments 😭😭😭

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@allneuts commented on GitHub (May 4, 2026):

Name checks out.

@allneuts commented on GitHub (May 4, 2026): Name checks out.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@powersupersport commented on GitHub (Jun 29, 2026):

As other comments have mentioned, just use D7VK: https://github.com/WinterSnowfall/d7vk
Used it to fix random stutters on Colin McRae Rally 2.0 and improve anisotropic filtering.

GE-Proton 11 also seems to include D7VK out of the box, but you have to enable it manually.

@powersupersport commented on GitHub (Jun 29, 2026): As other comments have mentioned, just use D7VK: https://github.com/WinterSnowfall/d7vk Used it to fix random stutters on Colin McRae Rally 2.0 and improve anisotropic filtering. GE-Proton 11 also seems to include D7VK out of the box, but you have to enable it manually.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@strycore commented on GitHub (Jun 29, 2026):

D7VK emulates Voodoo graphics??!

@strycore commented on GitHub (Jun 29, 2026): D7VK emulates Voodoo graphics??!

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@powersupersport commented on GitHub (Jun 30, 2026):

TLDR; D7VK cannot perfectly replace dgVoodoo, but can replace the DirectX part of it.

I apologize for the confusion I may have caused. By Voodoo graphics I assume you mean Glide. No, D7VK does not have Glide.
(Until today I didn't even know there was an actual series of graphics cards called Voodoo)

What I meant to say is that I was advised to use dgVoodoo for older versions of DirectX (prior to 8). Since the obvious rabbithole that dgVoodoo has become, not to mention the "newest and shiniest, full and complete experience of a latest version" kept crashing on me, I came across D7VK for games that use older-than DirectX 8 API.

Colin McRae Rally 2.0 uses DirectX 7, so D7VK worked perfectly fine. I have not personally played a game that uses Glide and cannot give a recommendation for that.

@powersupersport commented on GitHub (Jun 30, 2026): TLDR; D7VK cannot perfectly replace dgVoodoo, but can replace the DirectX part of it. I apologize for the confusion I may have caused. By Voodoo graphics I assume you mean Glide. No, D7VK does not have Glide. (Until today I didn't even know there was an actual series of graphics cards called Voodoo) What I meant to say is that I was advised to use dgVoodoo for older versions of **DirectX** (prior to 8). Since the obvious rabbithole that dgVoodoo has become, not to mention the "newest and shiniest, full and complete experience of a latest version" kept crashing on me, I came across D7VK for games that use older-than DirectX 8 API. Colin McRae Rally 2.0 uses DirectX 7, so D7VK worked perfectly fine. I have not personally played a game that uses Glide and cannot give a recommendation for that.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@strycore commented on GitHub (Jun 30, 2026):

D7VK is cool but the whole drama about DgVoodoo started from a misunderstanding that we could distribute the Glide part and not the DirectX parts, thus we were shipping an incomplete build of DgVoodoo. And the feature in Lutris always was about using DgVoodoo to emulate 3DFX / Glide.

So for Glide itself, we should rely on another wrapper, there's nGlide but that's Windows only (just like dgVoodoo was, to be fair). It would be cool if we had the equivalent of D7VK for Voodoo (GlideVK, for which there's only a suggestion of it in a forum: https://www.zeus-software.com/forum/viewtopic.php?t=6887 ).

With D7VK, nGlide (or a future GlideVK) and cncdraw, we should have a good coverage of legacy graphics APIs.

@strycore commented on GitHub (Jun 30, 2026): D7VK is cool but the whole drama about DgVoodoo started from a misunderstanding that we could distribute the Glide part and not the DirectX parts, thus we were shipping an incomplete build of DgVoodoo. And the feature in Lutris always was about using DgVoodoo to emulate 3DFX / Glide. So for Glide itself, we should rely on another wrapper, there's nGlide but that's Windows only (just like dgVoodoo was, to be fair). It would be cool if we had the equivalent of D7VK for Voodoo (GlideVK, for which there's only a suggestion of it in a forum: https://www.zeus-software.com/forum/viewtopic.php?t=6887 ). With D7VK, nGlide (or a future GlideVK) and cncdraw, we should have a good coverage of legacy graphics APIs.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@epistulae-ad-infernum-pro-te commented on GitHub (Jul 2, 2026):

GlideVK would be interesting, converting glide api calls to vulkan. while also not converting glide to directx to vulkan (3 steps) or glide to opengl to vulkan.

mesa has 3dfx/voodoo support. also the kernel has drivers for 3dfx (may be on a chopping block soon enough); neither of these fixes a wine api unless you are running this with a 3dfx gpu

at this point someone would just have "THE AI" write a wine compatibility layer for them...sadly
which would still be better than whatever dgvoodoo creator thinks about OSS.

@epistulae-ad-infernum-pro-te commented on GitHub (Jul 2, 2026): GlideVK would be interesting, converting glide api calls to vulkan. while also not converting glide to directx to vulkan (3 steps) or glide to opengl to vulkan. mesa has 3dfx/voodoo support. also the kernel has drivers for 3dfx (may be on a chopping block soon enough); neither of these fixes a wine api unless you are running this with a 3dfx gpu at this point someone would just have "THE AI" write a wine compatibility layer for them...sadly which would still be better than whatever dgvoodoo creator thinks about OSS.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@strycore commented on GitHub (Jul 2, 2026):

someone would just have "THE AI" write a wine compatibility layer for them...sadly

on it

@strycore commented on GitHub (Jul 2, 2026): > someone would just have "THE AI" write a wine compatibility layer for them...sadly on it

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@placintaalexandru commented on GitHub (Sep 24, 2026):

Yeah, I'm telling you what represents the current state of the project from my PoV: "old games no longer works on newer versions".

If this is the intended state of the project, then 🤮

@placintaalexandru commented on GitHub (Sep 24, 2026): Yeah, I'm telling you what represents the current state of the project from my PoV: "old games no longer works on newer versions". If this is the intended state of the project, then 🤮

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@strycore commented on GitHub (Sep 25, 2026):

hehehehe

@strycore commented on GitHub (Sep 25, 2026): hehehehe <img width="2558" height="1438" alt="Image" src="https://github.com/user-attachments/assets/44b4ac6f-a4e0-455e-a0a7-dbd43c614afb" />

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@placintaalexandru commented on GitHub (Sep 25, 2026):

@strycore , may i know what version you use? I am trying to find an older version for Anno 1404 History Edition as I need it to simulate directx11 for dlss5.

@placintaalexandru commented on GitHub (Sep 25, 2026): @strycore , may i know what version you use? I am trying to find an older version for Anno 1404 History Edition as I need it to simulate directx11 for dlss5.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@legluondunet commented on GitHub (Sep 25, 2026):

GlideVK? name sounds good!

@legluondunet commented on GitHub (Sep 25, 2026): GlideVK? name sounds good!

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@strycore commented on GitHub (Sep 25, 2026):

@strycore , may i know what version you use? I am trying to find an older version for Anno 1404 History Edition as I need it to simulate directx11 for dlss5.

This is not dgvoodoo, it's a Linux native Glide to Vulkan wrapper. So in your case, I'm not sure it would work since it skips DirectX entirely.

@strycore commented on GitHub (Sep 25, 2026): > [@strycore](https://github.com/strycore) , may i know what version you use? I am trying to find an older version for Anno 1404 History Edition as I need it to simulate directx11 for dlss5. This is not dgvoodoo, it's a Linux native Glide to Vulkan wrapper. So in your case, I'm not sure it would work since it skips DirectX entirely.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@epistulae-ad-infernum-pro-te commented on GitHub (Sep 27, 2026):

plus side here too is:

kernel has 3dfx driver support & code
mesa driver supports 3dfx glide
previous windows opengl glide api compatiblity has been documented

those dont help unless you have a real 3DFX running a modern kernel +mesa. but the code examples are there for "how it works"

Vulkan is very GPU agnostic for many features "just works"
unless written exceptionally for nvidia features that which AMD cannot interpret

put GlideVK into proton/wine to add support all native 3dfx games
(face it, 3dfx glide api never had any linux games)
it can also be ported to windows more easily as a wine dll replacement similar to how dxvk is used on both systems.

@epistulae-ad-infernum-pro-te commented on GitHub (Sep 27, 2026): plus side here too is: * kernel has 3dfx driver support & code * mesa driver supports 3dfx glide * previous windows opengl glide api compatiblity has been documented those dont help unless you have a real 3DFX running a modern kernel +mesa. but the code examples are there for "how it works" Vulkan is very GPU agnostic for many features "just works" unless written exceptionally for nvidia features that which AMD cannot interpret put GlideVK into proton/wine to add support all native 3dfx games (face it, 3dfx glide api never had any linux games) it can also be ported to windows more easily as a wine dll replacement similar to how dxvk is used on both systems.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Sep 27, 2026):

This will support glide.dll, glide2x.dll and glide3x.dll ?

@Arucard1983 commented on GitHub (Sep 27, 2026): This will support glide.dll, glide2x.dll and glide3x.dll ?

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@legluondunet commented on GitHub (Sep 28, 2026):

FYI:
https://bugs.winehq.org/show_bug.cgi?id=58731#c17

@legluondunet commented on GitHub (Sep 28, 2026): FYI: https://bugs.winehq.org/show_bug.cgi?id=58731#c17

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@epistulae-ad-infernum-pro-te commented on GitHub (Sep 28, 2026):

FYI: https://bugs.winehq.org/show_bug.cgi?id=58731#c17

now its just malware and will continue to be marked as such.

@epistulae-ad-infernum-pro-te commented on GitHub (Sep 28, 2026): > FYI: https://bugs.winehq.org/show_bug.cgi?id=58731#c17 now its just malware and will continue to be marked as such.

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@Arucard1983 commented on GitHub (Oct 15, 2026):

Using AI to create dgvoodoo2 patches fixes helps to run the wrapper...

That's why I decided to use AI to fork Wine to implement a OS/2 Subsystem over it! But it needs my own intervention and one week to settle the OS/2 dll's templates. It even suggested a 286 CPU Ring 3 emulator, and I need to run AI again to fix their mistakes, where implementing block by block is more easy to learn to not make mistakes. LX booting still fails, but at least I could play with Hobbes Archive. Probably if small programs could work, excellent. Presentation Manager is easy, just map to to Wine API! The real hurdle is the LX binary and DOSCALLS!

@Arucard1983 commented on GitHub (Oct 15, 2026): Using AI to create dgvoodoo2 patches fixes helps to run the wrapper... That's why I decided to use AI to fork Wine to implement a OS/2 Subsystem over it! But it needs my own intervention and one week to settle the OS/2 dll's templates. It even suggested a 286 CPU Ring 3 emulator, and I need to run AI again to fix their mistakes, where implementing block by block is more easy to learn to not make mistakes. LX booting still fails, but at least I could play with Hobbes Archive. Probably if small programs could work, excellent. Presentation Manager is easy, just map to to Wine API! The real hurdle is the LX binary and DOSCALLS!

bsakaguchi commented

2026-10-31 13:05:42 +00:00

Author

Owner

@epistulae-ad-infernum-pro-te commented on GitHub (Oct 29, 2026):

https://github.com/CkNoSFeRaTU/gxvk

alternative to glidevk

@epistulae-ad-infernum-pro-te commented on GitHub (Oct 29, 2026): https://github.com/CkNoSFeRaTU/gxvk alternative to glidevk

Rows
Columns

[GH-ISSUE #5] It's time for dgvoodoo to be canned #4

time for dgvoodoo to be canned