elishacloud
Would you consider releasing a 64bit dxwrapper for 64bit XP era games?
On rare occasion, there are 64bit games made for Windows XP 64bit that actually use ddraw and d3d8/d3d9. Unreal Tournament 2004, Chronicles of Riddick: Escape from Butcher Bay and Shadow Ops: Red Mercury fit this profile. Each of these were released around 2004 and they eventually had optional 64bit executables via online patches/updates.
While not a huge catalog of games, it would be nice to have dxwrapper for these early 64bit games using (parts of) ddraw and d3d8 and later XP/Vista games with d3d9 that might not work well with newer versions of Windows or not offer knobs for anti-aliasing or anisotropic filtering.
In all these cases, it's preferable to use the 32-bit versions of these games. They all have them. There's no reason for such old games to use 64-bit versions. Typically, this is "homework" for developers, who were simply testing their skills for future projects by converting their current ones to 64-bit. This means that these games didn't require it and won't for a very long time (even games like ARMA 2 and Skyrim LE are 32-bit). These are just test versions. I remember the hype surrounding the release of 64-bit XP. A lot was written and said back then... 20 years ago. That it would provide unprecedented performance gains, etc. But it turned out to be more mundane. In most cases, this actually led to a drop in the performance of weak systems.
I thought about doing a 64bit version of dxwrapper. However, I doubt I will every get around to it. And as @Mitradis mentioned, I don't know how much value it will have.
In all these cases, it's preferable to use the 32-bit versions of these games. They all have them. There's no reason for such old games to use 64-bit versions.
On Windows, I would agree with you. However, on Linux, Wine's WoW64 can sometimes perform poorly, so using the 64bit binary can actually fix problems (mainly memory mapping with WineD3D DDraw/D3D to OpenGL32 wrapper but also native OpenGL games too). And for some ARM architectures (Like Apple Silicon), it is preferable to translate x86_64 instead of x86_32 for performance reasons.
DXVK provides 64bit D3D8 and D3D9 DLLs. dgVoodoo also provides a 64bit D3D9 DLL. So it's not like no one provides support for these older 64bit titles. The scope of dxwrapper focusing on DDraw, D3D8 and D3D9/EX seemed like a good fit for keeping these 64bit versions working.
I thought about doing a 64bit version of dxwrapper. However, I doubt I will every get around to it. And as @Mitradis mentioned, I don't know how much value it will have.
That's fair. There are probably enough 64bit D3D9 titles to make it worth while, but it's not a big deal either way. I appreciate all the work you've put into dxwrapper so far. It's a great project that has helped me get a lot of older games working again.
If you're having trouble running these games (32-bit versions with 64-bit variants) on the systems or operating systems listed above, it means you're potentially also having problems with all 32-bit games, even those that don't have 64-bit versions. In that case, the problem lies elsewhere and needs to be addressed differently.
If you're having trouble running these games (32-bit versions with 64-bit variants) on the systems or operating systems listed above, it means you're potentially also having problems with all 32-bit games, even those that don't have 64-bit versions. In that case, the problem lies elsewhere and needs to be addressed differently.
Not always. Currently, although it is being addressed with Vulkan memory mapping, WineD3D through WoW64 mainly has issues with 3D DDraw games. 2D DDraw games have not been affected. Native OpenGL32 games also work fine (e.g., Warcraft III with -opengl launch argument). Most D3D games also seem to work fine.
Using dxwrapper to wrap ddraw to d3d9 and then dxvk to wrap d3d9 to vulkan restores performance. So, while I agree with you in principle, "addressing" this issue is not something end-users of Wine are going to do outside of submitting a bug report or using dxwrapper (or dgvoodoo) with dxvk. The Wine developers have been aware of this issue for years and only recently (as per the linked patch) have begun addressing it.
Edit: In general, I'm not even arguing about performance issues. dxwrapper is a great tool to enable AA and AF when a game doesn't offer those features and the DDraw to D3D9 feature allows using DXVK. For native D3D8 and d3D9 games, DXVK can be used directly, but again, if AA or AF are not available with in-game knobs, dxwrapper helps fix that. This is important since, unlike AMD/ATI and nvidia, Intel drivers on Windows do not offer forced AA or AF, so dxwrapper is an agnostic way to force these regardless of OS or GPU HW vendor. In addition, dxwrapper also offers fixes for stencil format selection, forcing vsync and a few other options that would be needed for some games regardless of OS or CPU architecture.