It's time for dgvoodoo to be canned

[dege-diosg]

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.

[strycore]

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.

[Arucard1983]

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]

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.

[legluondunet]

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.

[Arucard1983]

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.

[legluondunet]

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.

[strycore]

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...

[Arucard1983]

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]

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]

WineHQ bug report made.

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

[dege-diosg]

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.

[legluondunet]

@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.

[Arucard1983]

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).

[arrowgent]

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

[legluondunet]

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.