VOGONS


First post, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Follow up from Guide to Windows 98 VM Setup on QEMU
It seems that binding Windows Guest 3D acceleration with Virtualization has really pissed off "the other camp" and renders those "in the camp" completely losing the slightest sense of humor 🤣. So let's keep on topic now, and stop all discussion not related to QEMU.

A diagram tells a thousand words, so I cooked up simple ASCII art to describe the essential of API pass-through in general. Hopefully, this gives clear answers to those in doubts of how API pass-through works between Host and Guest.

  • First Party API Pass-Through
      Host OS
    \-------------------------\
    | QEMU |
    | \-------------------\ |
    | | Windows Guest | |
    | | | |
    | | ( stubs ) | |
    | | |- glide.dll | |
    | | |- glide2x.dll | |
    | | |- glide3x.dll | |
    | | |- opengl32.dll | |
    | | \- d3d9.dll | |
    | | | |
    | \--|----------------\ \---------------------------------\
    | V |
    | \--------------\ \--------------\ \---------------\ |
    | | Glide |--| MESA GL |--| MESA Gallium9 | |
    | | Pass-Through | | Pass-Through | | Pass-Through | |
    | \---|----------\ \---|----------\ \---|-----------\ |
    | V V V |
    | dgVoodoo2 Host Gallium |
    | nGlide OpenGL d3dadapter9 |
    | OpenGlide |
    | psVoodoo |
    \-----------------------------------------------------------\
  • Third Party API Pass-Through
      Host OS
    \----------------------------------\
    | QEMU |
    | \----------------------------\ |
    | | Windows Guest | |
    | | | |
    | | + WineD3D | |
    | | + OpenGlide | |
    | | + Zeckensack GlideWrapper | |
    | | + Svens Glide3-to-OpenGL | |
    | | | | |
    | | ( stubs ) | |
    | | \- opengl32.dll | |
    | | | |
    | \--|-------------------------\ |
    | V |
    | \--------------\ |
    | | MESA GL | |
    | | Pass-Through | |
    | \---|----------\ |
    | V |
    | Host |
    | OpenGL |
    \----------------------------------\

Have fun and hope everyone starts to enjoy your collection of Windows games since the era of dawning 3D acceleration in the late 90's.

Reply 1 of 14, by digger

User metadata
Rank Oldbie
Rank
Oldbie

In case of the First Party API Pass-Through option, could the D3D9 calls be passed through to vkd3d instead of MESA Gallium9? With the increasing uptake of Vulkan, and the fact that it's more lightweight than Gallium3D, that might become an increasingly desirable option, right? Also, Vulkan is cross-platform (including macOS, thanks to MoltenVK), unlike MESA/Gallium.

Reply 2 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

In theory, it is possible but that is an area of significant research efforts. I have reasons to believe that Microsoft is already doing d3d9-over-d3d12 on Windows 10 and Vulkan has indeed supported a low-overhead function mapping between D3D12 and Vulkan APIs. Yeah, MESA Gallium9 could be Linux-only, but for Windows 10, it could also be possible to just use the Host native D3D9. Vulkan may make everyone happy but it could be the most challenging undertaking.

Reply 3 of 14, by digger

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for explaining. What is the most challenging part of such an undertaking? Wouldn't it still simply be passing through the same D3D9 calls from the guest to the host, something that's already happening in the case of Gallium9? The really hard stuff (implementing D3D9 on top of Vulkan) has already been taken care of by the vkd3d and Proton developers, right?

Reply 4 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Well, a simple search from Google only said vkd3d is an Direct3D12 implementation. If it was also bundled with something like d3d9-over-d3d12.dll, then it could be simpler. That makes it similar as using Host D3D9 implementation on Windows 10. Otherwise, the translation will have to be done inside QEMU, which can be non-trivial.

Reply 5 of 14, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

@kjliew: Lets see, if I understood well the diagram (just to check out how I saw it)...

Starting from the principle, that the QEMU and stubs used here are the ones compiled from your github source repo...

- Glide passthrough would require the host OS using any of the four provided Glide wrappers;
- Mesa Gallium 9 passthrough is new to me, I have never heard of this version. I know Mesa 3D though;
- Mesa GL passthrough would require the host OS to have OpenGL installed;

The second option - third party API - would require:

- Any of the above mentioned glide wrappers, using one of the provided stubs, inside the Guest OS, and the host OS having an OpenGL library to support it.

Is that correct? Did I understood it well?

I know that we've had this discussion before, hence why you gave up on giving macOS support for this, but I have some news on this matter, @almeath is doing some work to get OpenGlide working on macOS, he's using Mojave/Catalina, but he has had progress getting OpenGlide working there for DOSBox-X and testing with Lands of Lore 2, a DOS game. Once he gets into a stable OpenGlide build for macOS up to Big Sur, I would like to try it out again with your QEMU build if you were interested in giving macOS support again, at least an initial support. almeath and kyr0 are already working on getting PCem working better on MacOS, fixing some minor bugs from this linux port, and almeath is also trying out OpenGlide for his DOSBox-X games. We would like to include your QEMU build in our tests for the OpenGlide macOS build.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

List of ALL Android vulnerabilities

Reply 6 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Yes, your understanding is correct 👍

AFAIK, OpenGlide does not render Land of Lore 2 correctly. It has issues with transparency and chroma-key operations. On Windows, dgVoodoo2 solves all the rendering issues, being a more advanced Glide wrapper. That's the sad story about Glide support for non-Windows, and only First Party Glide pass-through works for DOS Glide games.

I don't how OpenGlide was brought up to work on recent MacOS, in the past I think it used SDL1.2 and depended on it for native window handling. While this had worked for DOSBox, it didn't for QEMU, even with old versions of QEMU that compiled with SDL1.2. Maybe someone could hack a version of SDL1.2 that worked but this wasn't something I was looking forward to. OpenGlide supports native window handling for OpenGL context creation for WIN32 and X11, in addition to SDL1.2 which works for all platforms supported by SDL1.2.

OpenGL context creation is outside the scope of OpenGL and platform implementation dependent. This is the challenging part. I didn't find an easy way to use SDL2 or SDL1.2 for MESA GL pass-through, hence it only supported native window handling in WIN32 and X11. I was hoping that X11 implementation could be reused for MacOS through XQuartz similar to that being reused in Linux/Wayland through XWayland. I don't know how difficult Apple had made it to bring back XQuartz on modern MacOS, but I think this is an easier route for bringing Linux/X11 software to MacOS rather than rewriting codes that were proven to work on X11.

Reply 7 of 14, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

Founds something interesting. According to the dgvoodoo 2 documentation, it supports paletted textures and pixel fog in virtual 3D emulation mode and Ti 4800 emulation mode:

http://dege.freeweb.hu/dgVoodoo2/ReadmeDirectX/

Reply 8 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

For 3Dfx Glide, table fog and 8-bit texture (palettized/RGB332) are Glide specification. When the games supported Glide renderer, they just worked simply because most modern Glide wrappers supported those features as part of the specification without requiring GPUs that actually support them. And for Glide, there is no query for capabilities, they are always available.

Direct3D was a mess, especially for anything below DirectX 6, because it allowed games to query for 3D capabilities and decide on the features to be enabled by renderers. IMHO, it is trivial to emulate table fog and 8-bit texture without support from GPU, the real challenge is to figure out the proper ways to expose them inline with the games expectation. There are several places where DDCAPS can be queried that leaves considerable ambiguity of how games could be written. AFAIK, WineD3D stumbled over DDCAPS reporting and simply by flipping the bits would sometimes turn a "Garbage" into "Platinum" or "Gold" in the Wine AppDB.

Reply 9 of 14, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

Interesting. I am trying to setup some test cases... would be nice to compare. I am pretty sure that Serious Sam FE has table fog in the test level, and Thief 2 uses 8 bit textures for the sky on it's first stage. Both support glide mode, so it is just a matter of getting both to install in windows 10 so I can use dgvoodoo 2 and nglide.

Reply 10 of 14, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

As it turns out, Serious Sam First Encounters test level uses pixel shaders for fog, not pixel fog/table fog. So that works on even modern GPUs through the compatibility later. dgvoodoo2 does seem to have slightly better performance though than windows compatibility layer. I get dips to as low as 50fps with dgvoodoo 2 compared to maybe 30fps without it. In windows XP on the same hardware it never gets below around 100fps.

I was able to get thief 2 running in windows 10 and windows XP. I have attached some screenshots. Running just the base game the sky is pixelated and a bit off from what it should be. From what I have read there is an 8 bit texture layer on top of a normal 16 bit texture which is a cool way to simulate a night sky with a cloud layer.

In the GOG version of the game the sky is fixed using an older version of a community patch. No dgvoodoo2 required.

I know that thief 2 has fog later in the game, so maybe I can source a save file at that part and see what it looks like.

Attachments

Reply 11 of 14, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

Thief 2 levels "Precious Cargo" and "Life of the Party" both have fog. The GoG version and the original CD version + dgvoodoo 2 look the same. Without dgvoodoo2 the fog is just missing.

For whatever reason, the fog is back if I play the game in XP. Maybe nvidia drivers added pixel fog emulation into later drivers? Or maybe it isn't pixel fog and is just a bug in the windows compatability layer. No idea.

I can't seem to get FRAPs to take screenshots in windows 10 properly without dgvoodoo2, so I only included pictures of what it should look like. In windows 10 without dgvoodoo 2 the fog is missing.

In general, thief 2 is extremely buggy in windows 10 and XP, so it seems like GoG is the way to go. I'll have to test it in windows 98 when I get a chance.

Attachments

Reply 12 of 14, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

No reason to use the gog version since it just uses newdark. The unofficial thief 1 and 2 patches at ttlg include that as well as other fixes. For windows xp you'll need to use older versions since the newest versions dropped xp.

For Thief 2 for XP T2Fix_1.27b.exe should work.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 13 of 14, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote on 2021-03-05, 10:51:

No reason to use the gog version since it just uses newdark. The unofficial thief 1 and 2 patches at ttlg include that as well as other fixes. For windows xp you'll need to use older versions since the newest versions dropped xp.

For Thief 2 for XP T2Fix_1.27b.exe should work.

Oh right, good point. I have been trying to use the earliest version I can because I suspect that legacy features may have been patched out of the game by the community. But certainly that is a good way to play.

The GoG version works just fine in XP, btw, but I believe it doesn't use the latest version of newdark.

Reply 14 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

There is an 11 years old bug on WineD3D specifically for Thief II The Metal Age fog issue.
https://bugs.winehq.org/show_bug.cgi?id=10570

I checked out the playable demo "The Unwelcome Guest" (Thief II 1.01 Alpha) and the fog is still not rendered with Wine-5.0.3. I don't know if the latest official patch or the fan-made patch 1.19 for the retailed full game would have fix that. The fog rendering of this game seems to be notorious that only certain GPUs with specific drivers at specific time that it would render properly. A sign of likely poor interpretation or making use of the last-breath DirectX 7 fixed-function pipeline in an awkward way. There used to be a similar bug on DirectX 7 FFP lighting for Tomb Raider IV The Last Revelation. It dragged for many years until finally fixed in Wine 4.12. That was perhaps the "magic" of games with female protagonist. 🤣

The support for table fog is definitely there in WineD3D, it is unknown why it wasn't activated by the game.

Both Serious Sam FE and Thief II TMA do not support Glide. Serious Sam FE has the option of using 3Dfx OpenGL which wraps to Glide3x and Thief II TMA is Direct3D7.