I still don't understand what the actual problem is? Do games crash with dgVoodoo 2 on top of DXVK?
I still don't understand what the actual problem is? Do games crash with dgVoodoo 2 on top of DXVK?
The games fail to start when a new version of dgVoodoo2 (Higher than 2.81) is used. Normally dgVoodoo2 was used on top of DXVK due to be the fastest DirectX wrapper on Linux.
Older dgVoodoo2 worked fine with the dgVoodoo2 on top of DXVK, since it provided a Faster environment to play old Windows games on Linux with much Faster performance that the Vanilla Wine implementation.
The only Change on dgVoodoo2 was a new initialization code.
The question is, what regression or not proper implementation on DXVK or Wine was the cause of this bug ?
Edit: A deeper analysis reveals that is more on Wine's code fault. It appears that on newer dgVoodoo2 versions, the Wine code responsible to enumerate the video devices it fails to recognize the wrapper and switch to safemode (Direct3D HAL and this causes to use the software renderer or crashes.)
Linking the created Wine issue for visibility https://bugs.winehq.org/show_bug.cgi?id=58731
A deeper analysis reveals that is more on Wine's code fault. It appears that on newer dgVoodoo2 versions, the Wine code responsible to enumerate the video devices it fails to recognize the wrapper and switch to safemode
What does that mean? How does dgVoodoo enumerate GPUs? Normally that's done through DXGI and that's part of DXVK.
(Direct3D HAL and this causes to use the software renderer or crashes.)
The D3D HAL isn't involved when you're using DXVK.
Linking the created Wine issue for visibility https://bugs.winehq.org/show_bug.cgi?id=58731
Validated. It is more a Wine bug than DXVK fault.
A deeper analysis reveals that is more on Wine's code fault. It appears that on newer dgVoodoo2 versions, the Wine code responsible to enumerate the video devices it fails to recognize the wrapper and switch to safemode
What does that mean? How does dgVoodoo enumerate GPUs? Normally that's done through DXGI and that's part of DXVK.
(Direct3D HAL and this causes to use the software renderer or crashes.)
The D3D HAL isn't involved when you're using DXVK.
The bug report was already sent to WineHQ.
The wrapper when initialize, either with or without DXVK, should create a virtual devices called dgVoodoo2 DirectX wrapper, if not detected defaults to DirectDraw HAL and the game either crashes or runs on software Mode.
Later versions of dgVoodoo2 are failing to initialize, and this bug is an Open issue on Lutris.
I guess given that you're certain it's a Wine bug (and the response on the Wine bug about the attitude of the dgVoodoo developer), I'll just close this.
Much recently Dege is aware of Lutris had one-click enable of his own wrapper to play old games on Linux, since dgVoodoo2 supports older wrapping the old DirectX and Glide to the newer DirectX 11 (and 12) for which DXVK handle to Vulkan and Linux graphic drivers.
Basically, Deve wanted to Lutris use the very last version as default to streamline the bug management, the problem is the last versions of dgVoodoo2 do not work on Wine, no matter the versions of DXVK.
Then I managed to set a sequence of tests, using Lutris, to figure out the issue. The main symptoms are game Crash ou Blank screen.
However on two old games (The GOG version of Omikron and the game Montezuma Returns) some thing had worked, and this lead to the main issue is some improper implementation of the DXGI or Direct3D enumeration devices, meaning that new initialization code of dgVoodoo2 2.81 and Higher was not getting the correct information.
Omikron is Tricky on Wine versions, and the highly patched Wine-GE 8.26 from Lutris could work if you use the following hack. With a fresh wineprefix, start the game with a working version of dgVoodoo2 (2.8.2) while selecting the last DXVK and friends from the list.
Save your favorite screen settings in game and close the game. Update dgVoodoo2 to the last versions, and now runs without issues. (Using Proton versions Will fail with recent dgVoodoo2 versions, even using this Trick). If you use the newer version at first time, it Will fail to work, or load a wrong Direct3D profile.
This hack means that the game try to use the best Direct3D renderer, but newer dgVoodoo2 is not been correctly detected, unless some hacky tricks that works ar certain cases. When the game Store the dgVoodoo2 virtual GPU profiles, it loads correctly.
By other hand, the Montezuma Returns that uses a VGA version and a 3DFX version detect the dgVoodoo2 wrapper correctly at first try no matter the wrapper versions because older Glide games bypass the DirectX and calls the Glide directly. And this correct initialization happens on Vanilla Wine.
This is a bug that is known about a Year, and need to be fixed, since dgVoodoo2 is a choice of some Linux gamers for Glide and DirectDraw old games.
Also this bug either on Wine or DXVK code could trigger at another application.