Maybe a silly question

[Mzed3D]

Hi, I don't know if this a stupid question but, anyway.. does DirectX native driver work on Linux hosts or only on Windows hosts?

[JHRobotics]

Hi, native DirectX driver work on every host platform - it works as transform DDI api calls to Mesa3D and by it's drivers to virtual screen - it can be done even pure software if there aren't any acceleration avaible. It also works on host machines without graphical output at all :-)

(don't worry, the question is relevant)

[Mzed3D]

I'm not sure I understand correctly, is there a DirectX to OpenGL translation happening like in the old wine wrappers version? What are the advantages of the native DirectX driver?

[JHRobotics]

It still translation from something to OpenGL (or OpenGL like) but difference is that Wine replacing high level of API and needs some hacks to replace original calls (replace DLL or hotpatch DLL). Also, Wine cannot handle all things - for example if application directly manipulating with frame buffer or texture memory Wine cannot simply trace that changes. Another problem is that DirectX runtime does some calculation and do some quirks (like software T&L) which Wine simply don’t implement, and final problem is that DirectX API can be called many ways (including from 16-bit applications) and for these situations hack didn’t work. I don't do direct translation DDI to SVGA3D commands because I can simply use another Mesa3D driver and I don't have to rewrite whole driver from beginning. I call it native HAL because it is regular native driver not wrapper.

My motivation for write this driver was:

1. Remove the hack, because it collides with another wrappers, caused call loop and when you replace DDRAW.DLL system become very unstable.
2. Handle situations where are out of reach Wine.

Performance is currently relatively poor but main problem is missing multiple buffering support (DDI[^1] was directly linked to video RAM memory surfaces which perfectly following GPU architecture at the time, but this is very hard to simulate with Virtual GPU API). Also I'm also currently focusing on compatibility and stability, aggressive optimizations can wait.

[^1]: DDI up to 9 (Win9x, XP) or 10 (Vista), newer DDI 11 and 12 are completly different.

[Mzed3D]

Thanks for the detailed explanation! I've tested the latest gpu version on qemu 3dfx and the potential is amazing. With the exception of some games crashing (thief 1, for example) the others work perfectly, correctly and they do not need any tweak as in qemu-3dfx. On the other hand, games on the softgpu virtual machine are much slower than in qemu-3dfx. I understand other work needs to be done. My question now is: when a newer qemu-3dfx will be released can we just overwrite the drivers using the installation app?

[JHRobotics]

I'm glad you enjoy it!

Probably best way to update QEMU-3dfx, is using my ICD patch and apply it to original repository. So download update from qemu-3dfx repo and download my patch:

https://github.com/JHRobotics/qemu-3dfx/raw/refs/heads/master/icd.patch

Navigate to base qemu-3dfx folder and the patch apply it with command like:

patch -p1 < /path/to/icd.patch

Now you can build QEMU and Mesa wrapper. When you build mesa wrapper, file OpenGL ICD driver qmfxgl32.dll will be also build. This only one file needs to be updated in guest system. So copy this file to virtual Windows 9x machine to C:\WINDOWS\system and replace old one.

Last step is open regedit.exe (in virtual machine -- only to make it perfectly clear), navigate to HKEY_LOCAL_MACHINE\Software\vmdisp9x\driver and remove REV_QEMU3DFX key (or rewrite to current hash, but when you build qmfxgl32.dll together with QEMU, you don't need it.

This was right way, there is also fast way - just open regedit.exe (still in virtual machine) and update REV_QEMU3DFX key to current hash. But but you risk that the old library will not be compatible and new features in QEMU-3dfx won't be available.