robertmo wrote:

geting this soon after starting (without boot image while qemu looks for boot disk) or with a simple "dir" when booted to dos w […]
Show full quote

geting this soon after starting (without boot image while qemu looks for boot disk)
or with a simple "dir" when booted to dos with no autoexec.bat
or lots of other cases at the exact same moment generally at the very beginning of different types of boot of windows
qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor

I got the same error on my Intel Core-i3 laptop, too. Apparently, my AMD FX-8300 desktop is fine and works with DOS4GW games such as Tomb Raider 1, Redguard and Extreme Assault. I always have the feeling that AMD-V is more matured than Intel VT.

robertmo wrote:

as for a previous problem I finally got glide working in qemu window using: SDL support yes (1.2.15) GTK support no […]
Show full quote

as for a previous problem I finally got glide working in qemu window using:
SDL support yes (1.2.15)
GTK support no
GTK GL support no

SDL2 should work, too. The culprit is GTK, but I thought GTK libraries are rarely installed on Windows. If you do have them installed on your MSYS2, then it is your problem. You should just configure QEMU with --disable-gtk or invoke QEMU with -display sdl to stay away from GTK code path.

sdl2 works too.

Environment = QEmu
fixes fullscreen mode
(it looks what it does is setting:
WindowedAttributes = borderless
for fullscreen mode, that fixes fullscreen too, but you are not able to drag the window 😉 )

ScaleWidth,
is needed if you want to control window resolution cause dgvoodoo sets the same res for both window and fullscreen.
ScaleWidth is just rescaling final picture, so best to set width matching dgvoodoo resolution if you want to use window.

you also have to start in a window and switch to fullscreen with ctrl-alt-f

robertmo wrote:

Environment = QEmu fixes fullscreen mode (it looks what it does is setting: WindowedAttributes […]
Show full quote

Environment = QEmu
fixes fullscreen mode
(it looks what it does is setting:
WindowedAttributes = borderless
for fullscreen mode, that fixes fullscreen too, but you are not able to drag the window 😉 )

Here's the historical discussion about the dgVoodoo2 Environment option for QEmu.
GLIDE.DLL LFB implementation issue + WIN64 DLL?

Usually, I don't care much for fullscreen rendering. I personally consider playing games in windowed has more fun than in fullscreen. If it is working, then good for you. I think this is the side-effect of Direct3D-based wrappers being able to stretch the rendering context into client area on-the-fly. Both dgVoodoo2 and psVoodoo are capable of this, but not OpenGL-based wrappers such as OpenGlide.

I don't think ScaleWidth is required. When you switched QEMU into fullscreen (Ctrl-Alt-F) *after* Glide rendering started, the wrapper would simply stretch the rendering context to fit into the fullscreen client area. The wrappers only receive Glide resolution to render (usually this is 640x480 for games that don't support anything else) QEMU decides the client area for rendering context to fit within. Without ScaleWidth, QEMU will make the client area the same as Glide resolution, otherwise the client area will be scaled to the width from ScaleWidth. Apparently, this does not work if you switched QEMU into fullscreen *before* Glide rendering started. Direct3D-based wrappers stretching into fullscreen client area does not maintain aspect ratio, so unless you are still using 4:3 display (which most Glide games are 4:3 native), the image will be distorted on 16:9 display.

In summary, windowed mode rules 😎 !

all you say is true

but without ScaleWidth qemu window is always in it's native resolution (640x480) if the game doesn't allow resolution change. You can enlarge it by dragging borders with a mouse but that does not preserve aspect ratio.

So if you want to use a larger window with proper aspect ratio you have to use ScaleWidth,1024 for example. And set 1024x768 in dege's wrapper settings too.

robertmo wrote:

And set 1024x768 in dege's wrapper settings too.

I believe this is not required. I think dgVoodoo2 explicit fullscreen and enforced resolution do not work with "Environment = QEmu" option, but you got to check with Dege on his implementation. QEMU tends to crash and misbehave when wrappers tried to modify the display context. ScaleWidth alone from QEMU should be enough to run 640x480 Glide games in 1024x768 windowed. However, it would not maintain the resolution to prevent image distortion if you toggled QEMU into fullscreen mode.

>I believe this is not required. I think dgVoodoo2 explicit fullscreen and enforced resolution do not work with >"Environment = QEmu" option, but you got to check with Dege on his implementation.
I tested and it works. "Environment = QEmu" removes window border in fullscreen mode (and does some "big pixels" stretching if you don't specify resolution in dgvoodoo settings).

>QEMU tends to crash and misbehave when wrappers tried to modify the display context.
was ok for me with dgvoodoo, but wasn't testing much

>ScaleWidth alone from QEMU should be enough to run 640x480 Glide games in 1024x768 windowed.
1024x768 window will have "big pixels" effect. It is a setting for having lower resolution in a bigger window so this possibility is actually logical. dgvoodoo in fullscreen ignores scalewidth setting.

Can you please share your dgvoodoo.conf?

I understand the "big pixel" stretching/effect but I thought that was inevitable if the game was only supporting 640x480, even if dgVoodoo2 was forced to rendered at higher resolution. Perhaps there is difference in technique used in stretching when dgVoodoo2 was rendering higher resolution versus that it was simply stretching the output. I am surprised that dgVoodoo2 would be able to change the display resolution without crashing QEMU while rendering within QEMU SDL display context.

Nevermind, I got it. Thanks for your tips. Yes, having dgVoodoo2 forced to the same resolution as ScaleWidth would produce better image than simply using ScaleWidth. This is interesting, I guess dgVoodoo2 must have better scaling algorithm than simply stretching the output to fit into client area. Perhaps, it would automatically employ the best anti-aliasing method supported by the driver during resolution scaling.

wrapper is a 3d card emulator that also uses virtualisation to speed up the emulation so it can do whatever you want.
Add/change many gfx effects. Even use new high resolution textures.

Patch updated in 1st post. No change to guest wrappers.

Minor bug fixes for shared memory LFB mode.

it is sdl2 that has no scaling problems

I finally got some time checking out QEMU/KVM on Linux, specifically Ubuntu 16.04LTS fully updated. QEMU/KVM on Linux is, again, markedly superior to anything on Windows. The accelerated KVM puts 3Dfx Glide into an unprecedented performance territory, and moreover this is with a petty thin-and-light laptop Core-i3-4010u and Intel HD Graphics, running either Windows 98SE or Windows 2000 SP4 as guest OS.

GLQuake 0.97 timedemo demo1
969 frames, 3.8 seconds, 252.7fps

Quake2 timedemo demo1
689 frames, 3.1 seconds, 223.4fps

Turok 1 Demo T1Mark over 250fps

NFS3 Hot Pursuit
QEMU console grBufferSwap stat 52~56fps average on "Home town", 1 opponent with traffics.

Titanium Mech2 Mercenaries
QEMU console grBufferSwap stat 50~60fps, no more slow down with targeting, particle trails and chunky explosion.

3Dfx demo "Valley of Ra" (fight)
"ShamelessPlug" enabled 78fps
"ShamelessPlug" disabled 186fps

This is undoubtedly the world highest performance 3Dfx Glide on emulation. No other 3Dfx emulation has ever been that fast. It is interesting to see if QEMU/KVM native virgil3D GPU with OpenGL/MESA pass-through would be equivalent in performance. Too bad, OpenGlide compatibility is not stellar, otherwise Linux would be the best modern emulation platform for 3Dfx Glide games.

Congratulations! This is awesome! I wanted to ask if you have used the Q35 Chipset for testing 3Dfx in Qemu ( -M q35)? I have win98SE Installed on Q35. Using an LSI Controller for hard drives and CDS is necessary as I cant find a working Sata Driver. This works well and is stable if installed using (setup.exe /p i from DOS). This seems to perform a fairbit better VS using the regular i440 system. I apologies if this is offtpopic. Thanks again for this patch!

wadrasil wrote:

I wanted to ask if you have used the Q35 Chipset for testing 3Dfx in Qemu ( -M q35)? I have win98SE Installed on Q35.

I used the Q35 machine model for my Win7 VM (not used for games). Though I have not tested it, I think it will work, the 3Dfx Glide pass-through is generic and does not depend on QEMU machine model. I don't see any advantage using Q35 machine model for ancient OS such as Win9x.

Let me know if it does not work.

Just throwing an idea of comparing WHPX vs KVM performance on the same pc.

Well, there is no comparison. WHPX is no match for KVM, period. Windows virtualization strategy is centered upon Hyper-V. I believe WHPX is something to stop Google/Intel from nagging that "Windows sucks for Android development" (indeed it is 😵 ). KVM has been on the center stage for Linux virtualization for years. The maturity is years ahead of WHPX.

I am actually thinking of building a small modern Celeron ITX with PCI slot and stuffs a Voodoo2 on it running Ubuntu with QEMU/KVM driving the real libglide2x/3x.so instead of OpenGlide wrapper. This could be the ultimate 3Dfx Glide retro gaming cube. 😎 It is interesting to see if driving real hardware would have the same performance as Glide wrapper.

the idea of a wrapper is it allows higher resolutions that makes distant objects clear (and we already got 8k monitors now), not mentioning multi-monitor systems, 3D monitors/solutions for feeling the distance, high anisotropic filtering that makes distant textures clear etc. ... direct input to your brain... Future opens up more and more possibilities.

no real multi voodoo 6 will cover that performance.

Can someone please tell me if there are install instructions for the Mechwarrior 2 games using this method on Windows 10? I have already tried installing the "MechWarrior Quadrology" version of Mechwarrior 2 and it runs poorly (through DOSBox). It also does not work with DGVoodoo.

there is also hvf on MacOS to be tried

HAX is also very fast, works on different Windows versions and works on Intel which is faster than AMD on a single core. Intel is also way more popular among users. Pyl being a very CPU demanding game works fluently in software mode with HAX.

I wonder why whole huge QEMU works with HAX and it is only that tiny piece of code of glide passthrough that doesn't.