nGlide and QEMU

General discussion about nGlide.
User avatar
Zeus
Site Admin
Posts: 1712
Joined: Sun Sep 21, 2008 2:51 pm
Contact:

Re: nGlide and QEMU

Post by Zeus »

kjliew wrote: Thu Oct 31, 2019 9:53 pm 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?
kjliew wrote: Thu Oct 31, 2019 9:53 pm 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.
kjliew wrote: Thu Oct 31, 2019 9:53 pm 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.
kjliew wrote: Thu Oct 31, 2019 9:53 pm 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
Posts: 24
Joined: Sat Sep 21, 2019 4:06 am

Re: nGlide and QEMU

Post by kjliew »

Zeus wrote: Sun Nov 03, 2019 2:51 am
kjliew wrote: Thu Oct 31, 2019 9:53 pm 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.
User avatar
Zeus
Site Admin
Posts: 1712
Joined: Sun Sep 21, 2008 2:51 pm
Contact:

Re: nGlide and QEMU

Post by 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
sw.jpg (71.84 KiB) Viewed 3690 times
kjliew
Posts: 24
Joined: Sat Sep 21, 2019 4:06 am

Re: nGlide and QEMU

Post by kjliew »

Zeus wrote: Wed Apr 15, 2020 9:13 pm 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
Posts: 24
Joined: Sat Sep 21, 2019 4:06 am

Re: nGlide and QEMU

Post by kjliew »

Zeus wrote: Wed Apr 15, 2020 9:13 pm 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 :shock: . 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.
Zeus wrote: Wed Apr 15, 2020 9:13 pm 17) Broken texturing in Montezuma's Return (Demo or Full)
Fixed and thanks for the hint. :D
Zeus wrote: Wed Apr 15, 2020 9:13 pm 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 OpenGlide
mgpr2_.png (615.79 KiB) Viewed 3473 times
Zeus wrote: Wed Apr 15, 2020 9:13 pm 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.
Zeus wrote: Wed Apr 15, 2020 9:13 pm 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.
User avatar
Zeus
Site Admin
Posts: 1712
Joined: Sun Sep 21, 2008 2:51 pm
Contact:

Re: nGlide and QEMU

Post by Zeus »

kjliew wrote: Mon May 11, 2020 9:17 pm this is either bug in QEMU CPU emulation or the BUILD engine.
Oh, well. Thank you for the update. And for fixing Montezuma. :)
kjliew wrote: Mon May 11, 2020 9:17 pm 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.
kjliew wrote: Mon May 11, 2020 9:17 pm 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.
kjliew wrote: Mon May 11, 2020 9:17 pm 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.
Post Reply