Is it possible to support DirectX 9 32bit in the future

[Moxnatiy]

wine works very badly with 32bit dx9 on macOS, I did some tests in VMware (Ubuntu aarch64), (Intel PC with wow64 wine) and it turned out that it's a problem with WOW64 and openGL

I got a reply from the box64 developer about this problem.

So, you are running a 32bits games using new Wow64 on wine I guess? If that game use OpenGL (or WineD3D) the slowdowns are probably becasue of the new Wow64 support: openGL can be slow on 32bits apps as some buffers needs to be copied into lower memory space.

But with box64 + wine wow64 + Vulkan tests, the problem was solved

Is it possible to implement in future dx 9 -> DXMT? Are there any restrictions? Thanks !

[3Shain]

To support x86 is really tricky, because we don't have a x86 Metal API at all! Not saying this is impossible but I don't think it will happen in near future. My priority at present: DX11 > DX12 (with Shader Model 5.1) = DX10 > DX9 > DX12 (with Shader Model 6.0+) > x86 support.

Now we already have WoW64 support.

[K0bin]

I just mean that D3D9 support without 32bit support would still be a LOT of work and essentially just create false expectations because pretty much every single d3d9 game is 32bit.

[Spidy123222]

I just mean that D3D9 support without 32bit support would still be a LOT of work and essentially just create false expectations because pretty much every single d3d9 game is 32bit.

It would atleast be one less variable for when wow64 to improve in wine for macOS.

[K0bin]

@Spidy123222 Unless I'm mistaken, Wines WOW64 is only done for lower level libraries (like winevulkan) and DXMT would have to implement something similar itself.

[athei]

I think it is not a huge problem that there is no 32bit API for Metal. I am currently experimenting with my own metal renderer for World of Warcraft Vanilla which is 32bit DX9. Calling from a 32bit PE binary into a 64bit mach-o works well with the UNIX_CALL mechanism you are using.

So you could keep the 64bit winemetal.so. There is just some added complexity since we are calling the same API from both 32bit and 64bit programs. But I think it can be managed.

The earlier some abstraction is introduced to support both 32bit and 64bit PE binaries the better. Otherwise there would be a huge refactoring later.

I suppose starting with 32bit DX11 support would be the logical step. DX9 would require more work.

[3Shain]

An upcoming Wine MR will break DXMT as direct call to unix API from PE will be no longer possible. So yes very likely we will have 32-bit in the short term given we have to migrate everything to proper UNIX_CALL.

[KingVulpes]

To support x86 is really tricky, because we don't have a x86 Metal API at all! Not saying this is impossible but I don't think it will happen in near future. My priority at present: DX11 > DX12 (with Shader Model 5.1) = DX10 > DX9 > DX12 (with Shader Model 6.0+) > x86 support.

What about DX9 and 64bit? Some DX9 games do support 64bit

[conneath]

yes, especially Source games (TF2, CSS, DODS, HL2DM, GMOD are all 64 bit Direct3D 9 games)

[athei]

I see no reason why it won't support DX9 64bit. 32bit support was the hard part. But now that we have wow64 support both bitnesses should be possible.

[arthrfrts]

Just a heads-up for anyone wanting to play some DirectX 9 games on macOS: I tested a few games using dgVoodoo 2.79.3 on a Sikarugir wrapper with DXMT enabled and I had some great results. Mirror's Edge and The Sims 2 Legacy Collection performed better than with DXVK/D9VK, Spore has fewer terrain glitches than WineD3D (D9VK fixes all of those).

SimCity 4 (DX7) works if windowed. SimCity 2013 (DX9) doesn't launch.