QEMU 3Dfx Glide Pass-Through

Schedules and announcements about program releases.

QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-6-27 @ 23:01

Hi,

This opens another new possibility for those keen on getting ancient 3Dfx Glide games to run on Window 10 AS-IS, no fans' patches no-frills way of running the games under Win98/ME on QEMU. DOS pass-through is also possible but it is not implemented yet. DOSBox should be extremely good for 3Dfx Glide DOS games. I have tested several Win9x games/demos which are notoriously hard or impossible to run on Windows 10.
- Mechwarrior 2 31st 3Dfx-enhanced version
- Titanium Mechwarrior 2 Mercenaries
- Heavy Gear 1.2beta patch 3Dfx
- NFS 2 SE Demo. This one failed to run for DOSBox, I believe due to CPU instructions emulation issues. It runs beautifully on QEMU.

It also run Quake2/GLQuake and perhaps all its kinds and flavors, but there are always better ways to run those games natively. Simply tried out for fun.

Performance, well, on AMD FX8300, I would say it is about a P166MMX. A highly clocked, turbo capable Core-i7 may get you into the level of P200MMX or PII-266. Single thread performance is always dominant in emulation, hence Intel CPU would typically fare better than AMD at similar clock frequency.

The challenge, in order to play with this, you will have to build QEMU on your own for now. This used to be a daunting task, especially on Windows, but with MSYS2/mingw-w64 maturing today, it is not as difficult as it used to be. For hardcore Visual Studio fans, I am sorry, building QEMU with VS is unsupported.

Update:
- Linux support is done. Tested with OpenGlide and NVIDIA propriety driver on Ubuntu 16.04LTS. QEMU must use SDL1/SDL2 for display with "-display sdl". GTK display does not work. GTK display works, and it is currently the best option in Linux as OpenGlide does not steal input focus on spawning Glide rendering window.
- Windows NT/2k/XP pass-through is done. Guest wrapper DLLs use standard VXD on Win9x/ME and KMD on NT/2K/XP.
- Unfortunately, KVM does not work for Glide pass-through, even though Windows 2000 is perfectly accelerated by KVM. Perhaps, the Glide pass-through requires modification to prevent host from peeking into guest memory. This requires changes in both the guest wrappers and Glide pass-through such that the guest wrapper will be copying data instead of host.
Attachments
qemu64-3dfx-20180715.tar.gz
3Dfx glide pass-through
(24.55 KiB) Downloaded 2 times
Last edited by kjliew on 2018-7-15 @ 08:09, edited 3 times in total.
kjliew
Member
 
Posts: 158
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby t9999clint » 2018-6-28 @ 00:21

This sounds really interesting, I am very curious to see the performance of this on Linux when that bit is done.
GLIDE passthrough + KVM would be pretty epic.
User avatar
t9999clint
Newbie
 
Posts: 35
Joined: 2014-10-07 @ 14:08
Location: Edmonton, Canada

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-01 @ 14:33

BTW kjliew: due to this development, I've put a bug in the ear of Dege's "competitor" Zeus regarding a 64-bit build of nGlide (closed source), though time will tell if he'll actually do it. Surprised you haven't tested the 32-bit version of nGlide yet though.

If you're feeling really daring, kjliew, you could try making a 64-bit compile of dgVoodoo 1.40 or 1.50 Beta3:
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
But the build process sounds quite challenging to begin with, I don't want to think what would happen if you tried...

Even crazier/hilarious, you could try testing:
- Zeckensack 0.84c (OpenGL, glide2x/glide3x, closed source, 32-bit only): http://www.zeckensack.de/glide/
- SvensWrapper (OpenGL, glide2x through a special file/primarily glide3x, closed source, 32-bit only): http://www.svenswrapper.de/english/
- SvensWrapper glide3x-only with GlideXP's Glide2x->Glide3x translator (could possibly work, IDK, I've never tried: https://wenchy.net/old/glidexp/ )
- uGlide (Direct3D, glide2x, closed source, 32-bit only, but recently active: could request they make a 64-bit build tho): http://www.hedgehogeyes.com/uglide.html
- some version of Glitch64 (OpenGL, glide3x, open source, 32-bit only) combined with GlideXP: http://www.vogonsdrivers.com/wrappers/f ... /Glitch64/
- the final release of eVoodoo (Direct3D, glide2x/glide3x, closed source, 32-bit only): http://www.vogonsdrivers.com/wrappers/f ... D/evoodoo/
(for more from before the modern wrapper era, and more mirrors, see: http://www.vogonsdrivers.com/wrappers/files/Glide )
Crazy I know, but I think it'd be funny to see the compatibility testing, and among other things, would be funny to see someone build something new out of Glitch64... you could maybe even build a new different Glide wrapper out of its source, IDK.

PS. don't forget to check on your psVoodoo thread, I sent Glidos a PM about it.
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 3984
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-01 @ 19:51

Greetings Stiletto, my friend!

Stiletto wrote:BTW kjliew: due to this development, I've put a bug in the ear of Dege's "competitor" Zeus regarding a 64-bit build of nGlide (closed source), though time will tell if he'll actually do it. Surprised you haven't tested the 32-bit version of nGlide yet though.


I wanted to try out nGlide, but the current problem is - it doesn't support windowed mode, and I am having problem with QEMU SDL1/2 windowing code not allowing Glide wrappers to hijack its window :dead: OpenGlide, psVoodoo and dgVoodoo all are supporting windowed mode. When I started to have Glide wrapper rendered into the same QEMU window instead of spawning a new window, which I did initially to get around the problem so that I can focused on the pass-through implementation, only dgVoodoo2 is capable of managing its window sizing on its own, and I don't know what magics Dege had on dgVoodoo2. I have to remove the window sizing code from OpenGlide and PsVoodoo for them to work.

And, thanks for your kind attention on getting in touch with nGlide author, Zeus. I had thought of contacting him myself initially. I had worked with Dege in the past, so I started with him on dgVoodoo2. And there is still a lot to do before checking out other Glide wrappers, I decided to move on with dgVoodoo2.

Stiletto wrote:If you're feeling really daring, kjliew, you could try making a 64-bit compile of dgVoodoo 1.40 or 1.50 Beta3:
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
But the build process sounds quite challenging to begin with, I don't want to think what would happen if you tried...

Oh yeah, you read my mind. I was actually thinking of doing this, reviving only the Glide wrapper part of dgVoodoo1.50Beta3. The plan is to get modern GCC to build dgVoodoo1 with GNU Makefile instead of VS. I have already done this for PsVoodoo. DgVoodoo1 is of particular interest because of its accurate implementation of Glide APIs. I remembered I compared its rendering output side-by-side with a real Voodoo2 back then, and for the stuffs that I care, they were mostly indistinguishable.
kjliew
Member
 
Posts: 158
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-02 @ 01:06

For what it's worth, these guys seem to be collecting OpenGlide patches above and beyond what's contained in OpenGlide CVS (I may be mistaken): https://github.com/voyageur/openglide/commits/master

(This might be moot provided I prodded Glidos hard enough :D )
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 3984
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-06 @ 10:53

Updated patch for QEMU 3Dfx Glide pass-through in 1st post.

For 32-bit build, it is now possible to check out other closed source Glide wrappers (especially those that only support full screen rendering) by having Glide wrapper rendering into its own window. To enable this, create a CFG file from the startup location of QEMU.
Code: Select all
 $ echo "CreateWindow,1" > glide.cfg


So far, here's my own results on Windows 10 x64 with 32-bit QEMU:
- Zeckensack 0.84c - worked fine in full screen, no windowed mode. It stole input focus from QEMU, but can Alt-Tab for QEMU to regain inputs.
- nGlide 2.00 - worked fine in full screen on initial launch, crashed on shutting down Glide. It stole input focus from QEMU, but can Alt-Tab for QEMU to regain inputs.
- dgVoodoo1 - worked fine in its own window. Full screen stole input focus from QEMU and Alt-Tab returned to window mode. So full screen cannot be used due to lack of inputs.

Both full screen and own window rendering have issue with mouse clicks. This is a major problem in full screen mode because the clicks have no other place to go. For own window rendering, as long as the clicks stay within QEMU window, then it is fine, otherwise Glide render window will crash.

I am still looking for solution to these issues. Personally, I highly prefer Glide render into the same QEMU window. Mouse clicks on games just work, better shooting in games where mouse usage matters. And I always prefer to have my games in windowed mode, even though it is just 640x480.
kjliew
Member
 
Posts: 158
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-07 @ 22:10

Updated 1st post with new patch that support Linux on both SDL1/SDL2.
As native 64-bit binary, QEMU TCG is significantly faster than DOSBox dynrec CPU core.
kjliew
Member
 
Posts: 158
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-08 @ 23:47

Weird wrapper tricks suggestion - QEMU 3Dfx Glide pass-through compiled for Windows 2000, running on Win2K Host OS, with Rendition Verite V2200 and BigRRed. :D :D :D

Wish I had a decent desktop, I'd love to try my weirder wrapper suggestions (SvensWrapper+GlideXP, Glitch64+GlideXP, eVoodoo2+3, uGlide) and do some compatibility testing just to see how broken they are. I miss my old days of wrapper compatibility testing :)
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 3984
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby t9999clint » 2018-7-10 @ 22:04

kjliew wrote:Updated 1st post with new patch that support Linux on both SDL1/SDL2.
As native 64-bit binary, QEMU TCG is significantly faster than DOSBox dynrec CPU core.

Now that sounds like something for me to try this weekend... :happy:
User avatar
t9999clint
Newbie
 
Posts: 35
Joined: 2014-10-07 @ 14:08
Location: Edmonton, Canada

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-15 @ 08:14

Patch updated for more robust Linux support and better handling of QEMU window sizing when _grSstWinOpen and _grSstWinClose are called repeatedly without calling _grSstGlideShutdown (as in 3Dfx Glide TEST27 and TEST30).
kjliew
Member
 
Posts: 158
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-16 @ 05:48

One major advantage of QEMU is the networking support. Thanks to its enterprise grade virtualization, the networking support has to be solid. Quake2 multiplayer just work out-of-box within QEMU. If connecting to external server, even the simplest SLIRP user networking backend works. I also tried out older games, Mechwarrior 2 3Dfx NetMech works with winsock TCP for local LAN play, but this requires more complicated networking setup for QEMU to use tuntap networking. Wow! :happy: However, I couldn't get IPX/SPX to work. The protocol was installed correctly and the games could see it, but the VM could not see each other. I have yet to try hard enough, such as disabling firewall and messing around with router's configuration.

Head-to-head null-modem setup is a swift configuration for QEMU. The serial ports of 2 VMs can be virtually connected through TCP for local LAN play, as simple as that. That was how I tried out MercNet 3Dfx from the Titanium series. Too bad, MercNet does not support winsock TCP, its Internet play over TCP/IP requires connection to Battle.net. So that leaves null-modem as the only multiplayer option for head-to-head play.
kjliew
Member
 
Posts: 158
Joined: 2004-1-08 @ 03:03


Return to Release Announcements

Who is online

Users browsing this forum: No registered users and 2 guests