Capcom Resident Evil 1 PC (Direct3D) WineD3D over QEMU MESAGL pass-through.

Running from Win98/ME guest. Game speed seemed normal. In-game cinematic videos, character movements, action and item menu all looked perfect. No patch, just install from CD, select any of the Redition Verite option and play. 3Dfx option failed with invalid pagefault with WineD3D. And, with KVM/WHPX, it can be played perfectly from laptops. There wasn't any slow-down on a Core i3-4010U laptop with Intel HD Graphics.

Another masterpiece restored through QEMU and playable across Linux and Windows 10. Though 640x480 could be a let-down in modern days, it was a luxury to be able to play at *SVGA* with full 3D glory.

😁 Resident Evil 2 PC works, too 😁

You technological wizard you!

QEMU MESAGL with WineD3D can scale!! 😁
Moto Racer 1 scaled at 1400x1050, Wow!

An enhancement for WineD3D specifically target for QEMU, it scales the final output to any QEMU desktop resolution with additional registry key for configuration, similar to the rest of Wine registry keys. No special QEMU plumbing is required. VBE9x MP driver in QEMU supports many resolutions up to 2560x1600. So, it is as simple as setting the registry key to define the rectangular area to scale (typically 640x480), set Win9x guest desktop resolution to something high-res and run the game. WineD3D then scales the defined area to fill up entire screen of QEMU window. The addition now makes QEMU the superior option for running legacy Win9x Direct3D games that were not possible or cumbersome to run on native OS.

Full-screen QEMU works a little awkward with SDL2 because SDL2 always uses "fake" full-screen and OpenGL rendering always start at lower-left corner as origin. As usual, windowed mode rules!! 😁.

i guess if used TitaniumGL (or QindieGL or GLDirect) with dgvoodoo2 you may have real resolution upscaling 😉

robertmo wrote on 2020-07-10, 23:33:

i guess if used TitaniumGL (or QindieGL or GLDirect) with dgvoodoo2 you may have real resolution upscaling 😉

I guess they will be more useful for VMWare 😉

I tried real resolution upscaling for Moto Racer 1, it is possible for this game because the race scene is fully polygonal. However, I noticed minor depth fighting issues after scaling, I am not sure if this is due to the low-poly models in the game. I currently do not have any idea if depth range should also be scaled after viewport. The intro UI and menu are unfortunately broken because they are just 2D elements. I opt for simple solution that works universally for games of that era. The interesting part is that I see the same depth fighting issue scaling an OpenGL FBO, so I guess that it may not be just a simple stretching at 2D space. For those experienced with OpenGL programming, feel free to enlighten me. The current scaling mechanisim that I devised for QEMU scales with texture quad for 2D elements and FBO for 3D elements.

The depth fighting after scaling regardless of which methods are more protruding in games such as PC version of SEGA The House of the Dead, Capcom Residential Evil 1 & 2. Can dgVoodoo2 upscale them perfectly? Post some screenshots if you will....

Expendable (by Rage) Matrox G400 EMBM version runs on QEMU.
This is a good example of how QEMU KVM/WHPX would bring out the best for running legacy DirectX games that even Matrox G400 won't be able or fast enough to run its own specially optimized title at:

1Expendable Timedemo Report
2--------------------------
3Running at  - 1400 x 1050 x 32
4Total Time  - 133 Seconds
5Gameframes  - 11226
6Lowest FPS  - 49 fps
7Highest FPS - 125 fps
8Average FPS - 84.135338 fps

A smaller screenshot from gameplay at 1024x768

When I can set aside the time for it, I'm going to try these patches out for myself to beable to run some games that I can't do properly under Wine without severely breaking Wine in the process.

Namely Unreal 2, but also pretty much the few other titles that heavily depended on DirectMusic's scripting runtime for dynamic event handling.
(I have literally zero idea why Unreal 2 needs it so much when they could of just written their own native code to hook into the engine with)

Really fantastic work you're doing here. I was practically only going to try to use QEMU for MS-DOS, because VirtualBox's sound support is broken beyond repair now.

Halo CE 1.00.578 PC demo on QEMU, a true Direct3D9 reference game from Microsoft Game Studios. PC version was released in year 2003. Depend on in-game view distance, the frame rate can go from sub-20FPS to 60FPS locked. Not really need to play in QEMU as the game still works perfectly on Windows 10 x64 with modern GPUs even with windowed mode. I think QEMU is the only emulator on earth to be able to run Halo CE at somewhat-still-playable frame rate 😁.

Unreal 2 The Awakening PC demo on QEMU with WineD3D
The demo does not have OpenGL driver, extracting the UT2003 OpenGL driver does not work for Unreal 2. Otherwise, the frame rate would have doubled as UT2003 BotMatch benchmark runs at over 70FPS. I hope this is not the case for the full game. Let me know if anyone has any clues of getting OpenGL renderer for Unreal 2.

kjliew wrote on 2020-07-31, 05:51:

Unreal 2 The Awakening PC demo on QEMU with WineD3D
The demo does not have OpenGL driver, extracting the UT2003 OpenGL driver does not work for Unreal 2.

Nor would it, Unreal 2 is not binary compatible at all to anything in UT200x, it's Legend Entertainment's own spinoff of the UE2 engine.

The performance looks acceptable enough for me anyways, thanks for testing the demo atleast.

DracoNihil wrote on 2020-07-31, 06:06:

Nor would it, Unreal 2 is not binary compatible at all to anything in UT200x, it's Legend Entertainment's own spinoff of the UE2 engine.

It is indeed a let-down to know that Unreal 2 does not support OpenGL. Another Clive Barker Undying sort of mishap where OpenGL was left out in the cold while the engine actually support it. Having OpenGL would have made the game more attractive to "run virtually & play anywhere" of modern retro gaming with QEMU.

What would of really been useful is public headers. But Epic was adamant in not releasing any such headers for both UT200x games, and Legend obviously didn't care to do any of that either.

Public headers would of enabled development of a working OpenGL subsystem.

Wine 4.12 fixed D3D7 lighting issues with Tomb Raider Last Revelation. Thread updated with correctly rendered image from QEMU with WineD3D.

All Tomb Raider PC series (I, II, III, IV and V) from the early years run perfectly on QEMU with 32bpp full details and high resolution, including FMVs and in-game 3D cutscenes. A wonderful past time to remember the games from anywhere, Windows 10, modern Linux and into the future where QEMU lives 😁.

Hi!
I really appreciate your efforts to get it working... could you please share with us the info on how to get it working? e.g. how to get the right ddraw.dll and etc to working in windows 98 in qemu
Many Thanks!

Heavy Gear 2, 1024x768 32bpp and all graphics settings at max, running at 55FPS. This game can go up as high as 1600x1200 32bpp. This is one of my favorite with some missions focusing on stealth, not just always fire-power. 😁
Everything works as in pristine condition, no ACT, no DxWnd and no patch. Just rip the retailed CD, install and play.

kjliew wrote on 2020-09-02, 23:44:

Everything works as in pristine condition, no ACT, no DxWnd and no patch. Just rip the retailed CD, install and play.

I remember trying to play this game on modern (at the time) Windows XP and, it would just suddenly crash for seemingly no reason after several minutes of gameplay despite everything seemingly working okay.

I believe it still requires you to set the compatibility option to play it in Windows XP. The game works best on Win98/ME, so it just makes more sense to use VM. Let see if I can complete the 1st mission. The 1st mission already has lots of actions, crouch, snip and a final gear duet. 😁 And now , it can also be played on Linux with QEMU KVM without hunting for the Linux version.

I finished 1st mission the game was rock solid on QEMU VM. Sound effects, background music, speech and pre-mission videos were all good.

Both Resident Evil 2 & Resident Evil 3 Nemesis PC also work on QEMU, including in-game video and 3D cinematic.
Resident Evil 2 only offers 640x480, so it got WineD3D upscaled.

Resident Evil 3 and the beautiful, gorgeous Jill is back... 😜 This one support more resolution options up to 1600x1200 32bpp. However, the graphics assets seem to be fixed at 640x480 perhaps.

All past 3 releases of Resident Evil PC now play perfectly on QEMU. It took me some research to solve the movie playback issues with DirectX Media's ActiveMovie/DirectShow used in 2 and 3. There were issues with DDRAW re-entrant, choppy video and audio break-up if the movies were played through Wine DDRAW with OpenGL backend. DDRAW surface operation was always troublesome and costly pixels moves. It is faster to use QEMU emulated VBE adapter than move pixels between host and guest. So I added caller filtering into WIne DDRAW to be able to pass-through the calls to the OS's copy of DDRAW and let QEMU's 2D driver play the movies, which it handled the task handsomely, thanks to WHPX/KVM.

Both games offers a "Movie Off" option but I consider that a let-down without being able to enjoy the game's movies at the same time. Sure, one can still buy the remake versions with vastly improved graphics and modernization. Anyway for retro-lovers, welcome back to year 1999! 😁

NoLF2 on QEMU WineD3D from the current stable Wine-5.0.2 with OpenGL 4.4 core profile backend. No insane FPS, but stable and smooth.
All LithTech engine games (Shogo MAD, NoLF and NoLF2) are now a piece of cake to run on QEMU.

Konami Silent Hill 2 PC at stable near 30FPS play. Adapting Wine-5 to run on QEMU Windows VMs pays off. This is right off the NA release 3-CD version with 1.1 patch, nothing more.