Thanks, I fixed it, see WIP79_1 that I 've just released.

I verified the issues that I reported were all fixed. Thanks.
But now the game shows the same "rainbow" discoloring for distant texture mapping, similar to Ultim@te Race Pro that I reported earlier. Check the screenshot below, on the race ground and distant iconic Moscow building.

I'm not sure if you're on windows, but what if you run it natively? You can copy dgVoodoo's ddraw.dll and d3dimm.dll for the menu part of the game.

Yes, I am on Windows 10.
Are you saying that dgVoodoo's Glide2x/3x in some cases will have dependencies on dgVoodoo's ddraw/d3dimm?

But running native would also only use the WIN32 version of Glide2x/3x DLLs instead of WIN64 version from QEMU VMs.

kjliew wrote on 2021-03-31, 20:35:

Are you saying that dgVoodoo's Glide2x/3x in some cases will have dependencies on dgVoodoo's ddraw/d3dimm?

No, there is no dependency but they can cooperate and the game is usable if it doesn't work with native ddraw.

kjliew wrote on 2021-03-31, 20:35:

But running native would also only use the WIN32 version of Glide2x/3x DLLs instead of WIN64 version from QEMU VMs.

Yes, it's true. It'd reveal if this problem is x64 specific.

OK, the game ran fine on native with WIN32 version of Glide3x DLL.

The game also worked fine with nGlide 64-bit Glide3x DLL on QEMU. so I doubted if the ball was on QEMU Glide passthrough.
DOSBox SVN does not have Glide3x passthrough, so I can't check over there, but Ultim@te Race Pro showed exactly the same "rainbow" discoloring for distant texture mapping with WIN64 version of Glide2x from either DOSBox SVN or QEMU.

Let me know how you would like to proceed on this, if you wish to troubleshoot on QEMU x64.

Yes, I too think the bug is somewhere in dgVoodoo.

I'm trying to run the game in QEmu.
What I don't understand, is why Glide passthrough doesn't work with TD5.
When I try to start VOODOO2.EXE I get 'The file Glide3x.dll cannot start. Check the file to determine the problem' error message.
(The SDK samples with Glide2x work.)

Also, I don't know if I need the DDraw passthrough layer for this game.

Dege wrote on 2021-04-01, 11:59:

When I try to start VOODOO2.EXE I get 'The file Glide3x.dll cannot start. Check the file to determine the problem' error message.
(The SDK samples with Glide2x work.)
Also, I don't know if I need the DDraw passthrough layer for this game.

Possible causes:
1. QEMU rejected guest wrapper request because they weren't signed & built with the same GIT commit id.
2. QEMU couldn't load Glide3x.dll at host, likely due to pointing to Win32 version of DLL instead of Win64.

For VOODOO2.EXE, the game works with ddraw.dll from the OS just fine.

I tried dgVoodoo2 WIN32 Glide3x with QEMU x32 and it was the same. So that likely ruled out any 64-bit pointers discrepancies.

Since the "rainbow" discoloration slowly faded and turn into good rendering, perhaps there is something to do with how MIPMAP works in the dgVoodoo2, if you had dependencies for the shader language on addressing. Otherwise, the corruption would have been persistent regardless of distance from viewpoint. This is what I can think of why it worked native but not from DOSBox and QEMU as the data marshalling during pass-through is likely reusing the same address over and over again.

Let me know if I should check out other older versions of dgVoodoo2, if you could recall the changes in MIPMAP implementation.

isn't that caused by forcing point sampled filtering?

Oh, so it's not 64 bit.
Yes, the problem is inevitably about mipmapping. The first mipmaplevel is good but all the others are trash. That's why it turns into good when looked from a close viewpoint.

But, I checked out the Glide log for this game and the only texture upload call is grTexDownloadMipmap. It has only one pointer parameter, the mipmap data.
dgVoodoo doesn't store that pointer internally, the bitmap data is copied to the texture memory before returning from the call, so the pointer itself can't be the problem.
(I didn't change the mipmapping implementation across versions.)

It's strange. Are you sure you provide (copy) the right amount of bytes when marshalling the bitmap data from the application to the wrapper?
Like, calculating the required size from the LOD parameters can be tricky because those are numerically different between Glide 2 and 3. Or sg like that.

Well, the Host Glide3x wrapper 😉 tells the size of MIPMAP to the guest stub (grTexTextureMemRequired()) and the guest stub will push the MIPMAP into FIFO. Upon FIFO flush, QEMU reconstructs the GrTexInfo pointer and sends to Host Glide3x wrapper. You should be able to check the size of MIPMAP dgVoodoo2 returned with grTexTextureMemRequired() prior to each grTexDownloadMipMap() call.

Attached the trace logs for grTexDownloadMipMap() between nGlide and dgVoodoo2.
My dgVoodoo2 was configured as Voodoo2, OnboardRAM=8192, NumOfTMU=2, MemSizeOfTMU=4096.
No configuration was used for nGlide.

DgVoodoo2 trace showed 2 addition blocks of grTexDownloadMipMap() with format=0c.
NGlide trace showed 1 addition block of grTexDownloadMipMap() with format=0a.
The difference could likely be due to how nGlide and dgVoodoo2 implementation differ in presenting multi-TMU and multi-texturing.
The size of MIPMAP matched on both.

Perhaps dgVoodoo2 was corrupting its own texture memory somehow with additional MIPMAP downloads.

shouldn't this be kind of "fixed" by disabling mipmapping in dgvoodoo2's control panel?

Bingo 👍 You're right! "DisableMipmapping = true" in "[Glide]" fixed the issue in TD5.

Now, Dege can look into why MipMapping failed, or nGlide simply had MipMapping disabled ?!!

Spoke too soon 🙁, it didn't fix Ultim@te Race Pro and I tested with both DOSBox SVN and QEMU.

With "DisableMipmapping = true", Ultim@te Race Pro suffered persistent corruption.
With "DisableMipmapping = false", Ultim@te Race Pro behaved the same as TD5 that the corruption faded away as it moved closer to viewpoint.
Perhaps there is still somewhere in dgVoodoo2 that MIPMAP download is getting corrupted somehow.

it looks either Ultimate Race Pro doesn't allow disabling mipmapping (most probable) or the setting doesn't work for glide2x and works only for glide3x (less probable)
---------
just in case:
there are two "DisableMipmapping = true" settings
in [glide] and in [direct3d] sections and you confused them (least probable) 😉 (but just to be safe)

i guess trying some random very old dgvoodoo2 may help finding how it behaved before

Apparently, both OpenGlide and psVoodoo have mipmaps disabled as default. Even when mipmaps was enabled, there was no corruption in Ultim@te Race Pro, but they could just be using OpenGL/Direct3D auto mipmaps generation from level 0 instead of the level n mipmaps really being downloaded through grTexDownloadMipMap(). Perhaps nGlide could also be doing the same, but then it could break if any game ever played tricks with mipmaps and downloaded level n mipmaps that were not really the same as level 0. I don't know if such trick is even possible ...

Does dgVoodoo2 really make use of level n mipmaps downloaded from Glide calls?

Dege, while you are in QEmu, Pył is having heavy performance slowdown (like many times slower) in DX12 when compared to DX11