nGlide and QEMU

[Zeus]

I also found that I was losing keyboard controls with nGlide-dev on MDK, which did not happen with others. Mouse was fine. I am not sure if you were doing Windows inputs hooking in nGlide-dev.

Can you exactly tell when does this happen? After pressing Alt+Enter?

I also noticed that nGlide-dev override Windows 10 native display scaling.

Yes, DPI scaling needs to be disabled for exclusive fullscreen, otherwise you'll see a quarter of the image with DPI scale = 200% (and proportionally less or more with different scale factors). Windows does this automatically for DirectX apps, but for other APIs like Vulkan you have to do this manually. Anyway, I accidentally left the line unconditional, so it executes also for windowed mode, this will be fixed with the next build.

Alright, I double checked with nGlide-dev version, and you were right, it did not work. But, dgVoodoo2, OpenGlide and even psVoodoo all are fine with shared memory LFB and hence does not hinder VM acceleration.

Another game in trouble is Mechwarrior 2 31st. With LFB handler, nGlide-dev is fine. With shared memory LFB, it has weird colors which I believe this is due to 1555 vs 565 LFB writes.

Nice catch, thanks. I'll check what's going on.

[kjliew]

I also found that I was losing keyboard controls with nGlide-dev on MDK, which did not happen with others. Mouse was fine. I am not sure if you were doing Windows inputs hooking in nGlide-dev.

Can you exactly tell when does this happen? After pressing Alt+Enter?

Nevermind, figured out the problem was my old copy of 32-bit QEMU w/ SDL1.2. It is not nGlide-dev.

[Zeus]

Some update from my side. Sorry for the long pause.

Issue 15)
Yes, it's fixed now. Excellent job.

Issue 16)
I forgot it's one of the very few Glide titles that requires 1 TMU configuration and will fail with nGlide's default 2 TMUs config. Could you provide such info like process name to setConfig@4 and call it before grGlideInit, so nGlide can autoconfigure itself?

Issue 17)
I found the reason is guTexDownloadMipMapLevel doesn't pass proper pointer to "src" param. If you need a link to game demo please let me know.

Issue 19)
I can confirm it's fixed now, but I have one small suggestion. Could you write 3df files into "temp" or "3df" subfolder instead of dropping them to root?

I also fixed MDK with LfbHandler=0. What I wasn't able to reproduce was Mechwarrior 2. Colors were ok for me with both handler modes, but I noticed something strange. The HUD weren't being rendered every time you launch the mission (happens even with lfb handler on). Is grLfbBegin called every frame just before grBufferSwap?

I updated nGlide's QEMU test package (check your PM). Now it includes a native x64 nGlide build for Windows and updated QEMU executables.

For the new issues I only found one so far:

20) Broken palette in Shadow Warrior (DOS)

Incorrect palette data for grTexDownloadTable() in DOS.

sw.jpg (71.84 KiB) Viewed 7427 times

[kjliew]

20) Broken palette in Shadow Warrior (DOS)
Incorrect palette data for grTexDownloadTable() in DOS.

I could reproduce the error, but I could not find any issue with the function. It was not the "partial" version and data was predictable by simply using sizeof(GuNccTable) or sizeof(GuTexPalette). DOSBox did the same and it produced the results correctly.

Code: Select all

sizeof(GuNccTable) = 112
sizeof(GuTexPalette) = 1024

I got the same error with dgVoodoo2, too, so I guess the ball was still on my side.

I did found an issue with gu3df* handling. The game called gu3dfLoad() without calling gu3dfGetInfo(). The 3df file push takes place during the GetInfo() call. I quickly did some experiment but the error remained. I will double check the 3df handling implementation.

DOS debugging with OVL is hard as Watcom does not produce debug info that I can use in GDB. Everything is done at assembly level with the map file.

[kjliew]

20) Broken palette in Shadow Warrior (DOS)
Incorrect palette data for grTexDownloadTable() in DOS.

Alright, got some updates. You were indeed right about something wrong with grTexDownloadTable() but the wrong data were handed in by the game . I proved this by debug prints at the DOS OVL guest wrapper. Later, I also verified with OpenGlide and having DOSBox and QEMU TCG running side-by-side on 2 GDB sessions dumping out the entire 1KB palette data from the pointer. The 9th call to grTexDownloadTable() (or the 1st call after displaying 3DRealm logo) the pointer pointed to palette data with roughly 1st half of the table values as '0'. It seems that the game generated palette data at runtime, the very 1st 8 calls to grTexDownloadTable() the data were not always the same (though the patterns were similar with some variations), but anyway 3DRealm logo were shown correctly. Tried TCG, KVM (on Linux) and they produced consistent results. The incorrect palette data handed in by the game was not random, the results were consistent with the same incorrect palette table patterns.

Apparently, Shadow Warrior DOS software render with VESA 2.0 on QEMU (TCG, WHPX, KVM) also shows a similar incorrect palette data right at the 3DRealm logo display. Software render with 320x200 (VGA) is OK. So I guess this is either bug in QEMU CPU emulation or the BUILD engine. I hope the engine does not render into 2D framebuffer and then uses the results to generate the palette data. If this is the case, then it will not work.

17) Broken texturing in Montezuma's Return (Demo or Full)

Fixed and thanks for the hint.

16) Texturing problem in Monaco 2 Grand Prix (Demo or Full)

No problem with dgVoodoo2 and OpenGlide, the later requires LfbNoAux=1 and the only artifact is the CAR overlay "HUD". OpenGlide does not advertise 2 TMU but dgVoodoo2 does. The shot below was from OpenGlide, noticed the corrupted CAR overlay, but both rear-view mirrors and necessary stats were still OK.

MGPR2 OpenGlide

mgpr2_.png (615.79 KiB) Viewed 7210 times

Could you provide such info like process name to setConfig@4 and call it before grGlideInit, so nGlide can autoconfigure itself?

I am afraid that I cannot do process identification at QEMU since it is a machine emulator rather than OS emulator. This would be very hack-ish and go beyond the scope of device model. I think DOSBox cannot do that, too, if booting off a disk image for DOS and Win9x. DOSBox can only do this when it also provides its own internal DOS emulation.

What I wasn't able to reproduce was Mechwarrior 2. Colors were ok for me with both handler modes, but I noticed something strange. The HUD weren't being rendered every time you launch the mission (happens even with lfb handler on). Is grLfbBegin called every frame just before grBufferSwap?

Nevermind of it, I knew the problem now, it was not nGlide, but dgVoodoo2 LFB mechanism somehow was able to tolerate it. It depends if you let QEMU find the real Glide.dll at host or use its internal emulation and only requires Glide2x.dll at host. If QEMU finds a real glide.dll at host, then it will just pass-through the APIs and LfbHandler will also be in-placed (which kills VM acceleration). If no Glide.dll was found, QEMU automatically enables the internal emulation then the option of LfbHandler comes into play and the default of LFB as shared memory supports VM acceleration. QEMU outputs the message to console when using internal emulation for Glide 2.11

Code: Select all

 glidept: DLL loaded - glide2x.dll, emulating API 2.11

I did not bother to port LFB as shared memory for Glide 2.11 pass-through, no Glide 2.11 games would need the additional speed from VM acceleration and not many Glide wrappers support Glide 2.11 with its awkward LFB semantics. Now, I also have Glide 2.11->Glide 2.43 wrapper implemented in its own DLL.

[Zeus]

this is either bug in QEMU CPU emulation or the BUILD engine.

Oh, well. Thank you for the update. And for fixing Montezuma.

OpenGlide does not advertise 2 TMU but dgVoodoo2 does.

Are you sure about that? Then I need to do some further research. I was always convinced there was no way to run it properly with 2 TMUs config.

The shot below was from OpenGlide, noticed the corrupted CAR overlay, but both rear-view mirrors and necessary stats were still OK.

Yes, car overlay and lens flare effect require depth buffer readback emulation, otherwise they will fail to render correctly.

I am afraid that I cannot do process identification at QEMU since it is a machine emulator rather than OS emulator. This would be very hack-ish and go beyond the scope of device model.

Not a problem. There are only few titles with such odd requirement. And if Monaco2 also works as you say then it's only better.

[bikhargaya]

I also tried installing AC97 with W98SE. It won't detect it no matter what. Any ideas? Does it need to be a specific driver? vidmate mobdro