VOGONS


Test Drive 5 Glide3x not working

Topic actions

First post, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Test Drive 5 Glide3x renderer is not working with dgVoodoo2. Using VOODOO2.EXE, the game started and going into "Graphics option" to select resolution crashed. If I went directly into "Single Race", then the race rendered into black screen. Audio could be heard and frame rate stats was available, so I knew the game was alive and actively calling grBufferSwap(). The Glide3x renderer worked with nGlide or Zeckensack GlideWrapper (from guest).
Here's the Glide3x API trace from start of the game, enter "Graphics options" select 1024x768, start "Single Race", end "Single Race" and exit the game to desktop, captured with nGlide. Tested on QEMU and Glide3x WIN64.

glidept: DLL loaded - glide3x.dll
trace: _grGlideInit@0 called
glidept: 82ee020-14:22:44 Mar 29 2021 build WRAPFX32
glidept:
Extension: CHROMARANGE TEXCHROMA TEXMIRROR TEXUMA PALETTE6666 FOGCOORD PIXEXT COMBINE TEXFMT TEXTUREBUFFER GETGAMMA
Hardware: Voodoo5 (tm)
Version: 3.10.00.0658
wr2x_trace: _grGet@12
wr2x_trace: _grSstSelect@4
wr2x_trace: _grQueryResolutions@8
wr2x_trace: _grTexTextureMemRequired@8
glidept: grSstWinOpen called, fmt 0 org 0 buf 2 aux 1 gLfb 0xead15000
wr2x_trace: _grSstWinOpen@28
glidept: LFB mode is Shared Memory (fast), One-copy
window 1024x768
wr2x_trace: _grCoordinateSpace@4
wr2x_trace: _grVertexLayout@12
wr2x_trace: _grGlideGetVertexLayout@4
wr2x_trace: _grGlideSetVertexLayout@4
wr2x_trace: _grCullMode@4
wr2x_trace: _grTexClampMode@12
wr2x_trace: _grTexFilterMode@12
wr2x_trace: _grTexMipMapMode@12
wr2x_trace: _grDepthBufferMode@4
wr2x_trace: _grDepthBufferFunction@4
wr2x_trace: _grDepthMask@4
wr2x_trace: _grAlphaTestFunction@4
wr2x_trace: _grAlphaTestReferenceValue@4
wr2x_trace: _grBufferSwap@4
wr2x_trace: _grBufferClear@12
wr2x_trace: _grFogMode@4
wr2x_trace: _grFogColorValue@4
wr2x_trace: _guFogGenerateExp@8
wr2x_trace: _grFogTable@4
wr2x_trace: _grTexMaxAddress@4
wr2x_trace: _grTexDownloadMipMap@16
wr2x_trace: _grAlphaCombine@20
wr2x_trace: _grAlphaBlendFunction@16
wr2x_trace: _grTexSource@16
wr2x_trace: _grColorCombine@20
wr2x_trace: _grTexCombine@28
wr2x_trace: _grDrawVertexArray@12
wr2x_trace: _grSstWinClose@4
glidept: grSstWinClose called
glidept: grGlideShutdown called, fifo 0x122f data 0x13622 shm 0x008d888 lfb 0xfb000000
glidept: GrState 0 VtxLayout 2
glidept: DLL unloaded

Reply 2 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

TD5.png
Filename
TD5.png
File size
1.02 MiB
Views
1104 views
File comment
dgv2-TD5
File license
Fair use/fair dealing exception

Reply 4 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 5 of 32, by Dege

User metadata
Rank l33t
Rank
l33t
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.

Reply 6 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 7 of 32, by Dege

User metadata
Rank l33t
Rank
l33t

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.

Reply 8 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 9 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 11 of 32, by Dege

User metadata
Rank l33t
Rank
l33t

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.

Reply 12 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 13 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Attachments

  • Filename
    nglide.log
    File size
    28.39 KiB
    Downloads
    40 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    dgv.log
    File size
    42.16 KiB
    Downloads
    41 downloads
    File license
    Fair use/fair dealing exception

Reply 15 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 16 of 32, by robertmo

User metadata
Rank l33t++
Rank
l33t++

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)

Reply 18 of 32, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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?