QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Schedules and announcements about program releases.

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-28 @ 18:13

Hi, I think you're coming along pretty well. :happy:

Check your OpenGlide build. If you also use it with DOSBox, then I guess you could have the OpenGlide built with SDL support. For QEMU glide pass-through, it currently only works with OpenGlide built natively, so for Linux it is X11. You may want to configure and rebuild OpenGlide for QEMU.
Code: Select all
$ tar xf openglide-cvs.tar.gz
$ mkdir buildx11
$ cd buildx11
$ ../openglide-cvs/configure --disable-sdl
$ make

If your QEMU was built with GTK/SDL2 support, then I think in theory OpenGlide/SDL1.2 would have worked. If your QEMU was built with SDL1.2 support, then OpenGlide/SDL1.2 would render into black screen. That was what I got from Ubuntu 16.04LTS. QEMU has number of display options under Linux (GTK2, GTK3, GTK3GL, SDL1.2, SDL2, SDL2-GL) that I have yet to check out all the combination. I had only checked out GTK3, SDL2 and SDL1.2.

It would be helpful if you can provide more information such as what game you are trying to get into. When you run configure for QEMU, it will display its configured options list in the end. If you can provide this info, then it will help to get to know how QEMU is configured on your end.
TomB wrote:Do I need a different VGA setting for the 3dfx passthrough to work?

I don't think so, but for Win98 guest "-vga cirrus" will give you a better emulated graphic card.
TomB wrote:if CONFIG_WIN32 isn't set, init_window doesn't create the window and hwnd is always zero. Should there be a linux version of the call to glide_prepare_window here?

No. OpenGlide/X11 will spawn a new Glide rendering window by itself.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby TomB » 2018-7-29 @ 14:32

Thanks for your help.

kjliew wrote:It would be helpful if you can provide more information such as what game you are trying to get into.


I'm trying to run Carmageddon 1's 3dfx.exe or voodo2c.exe. It works with DosBox and openglide but fairly slowly, I was hoping qemu would give better performance.

Just to check I've set up the wrapper correctly, I copied your wrapper's glide2x.ovl and glide2x.dll into the carmageddon directory.

kjliew wrote:When you run configure for QEMU, it will display its configured options list in the end. If you can provide this info, then it will help to get to know how QEMU is configured on your end.


The SDL version being used is 2.0.8 as provided by the Arch sdl2 package. I also have the sdl package installed providing sdl 1.2.

Here's the complete bottom part of configure's output:


Code: Select all
make              make
install           install
python            python -B
smbd              /usr/sbin/smbd
module support    no
host CPU          x86_64
host big endian   no
target list       i386-softmmu
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
SDL support       yes (2.0.8)
GTK support       yes (3.22.30)
GTK GL support    yes
VTE support       yes (0.52.2)
TLS priority      NORMAL
GNUTLS support    yes
GNUTLS rnd        yes
libgcrypt         no
libgcrypt kdf     no
nettle            yes (3.4)
nettle kdf        yes
libtasn1          yes
curses support    yes
virgl support     yes
curl support      yes
mingw32 support   no
Audio drivers     oss
Block whitelist (rw)
Block whitelist (ro)
VirtFS support    yes
Multipath support yes
VNC support       yes
VNC SASL support  yes
VNC JPEG support  yes
VNC PNG support   yes
xen support       no
brlapi support    no
bluez  support    yes
Documentation     yes
PIE               yes
vde support       yes
netmap support    no
Linux AIO support yes
ATTR/XATTR support yes
Install blobs     yes
KVM support       yes
HAX support       no
HVF support       no
WHPX support      no
TCG support       yes
TCG debug enabled no
TCG interpreter   no
malloc trim support yes
RDMA support      no
fdt support       yes
membarrier        no
preadv support    yes
fdatasync         yes
madvise           yes
posix_madvise     yes
posix_memalign    yes
libcap-ng support yes
vhost-net support yes
vhost-crypto support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backends    log
spice support     no
rbd support       yes
xfsctl support    yes
smartcard support yes
libusb            yes
usb net redir     yes
OpenGL support    yes
OpenGL dmabufs    yes
libiscsi support  no
libnfs support    yes
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   yes
coroutine backend ucontext
coroutine pool    yes
debug stack usage no
crypto afalg      no
GlusterFS support yes
gcov              gcov
gcov enabled      no
TPM support       yes
libssh2 support   yes
TPM passthrough   yes
TPM emulator      yes
QOM debugging     yes
Live block migration yes
lzo support       yes
snappy support    yes
bzip2 support     yes
NUMA host support yes
libxml2           yes
tcmalloc support  no
jemalloc support  no
avx2 optimization yes
replication support yes
VxHS block device no
capstone          internal



qemu defaults to gtk but forcing it with qemu-system-i386 -display gtk has no effect, even when using openglide with --disable-sdl set, I still get the segfault at the same point. I also tried compiling openglide with sdl support and using -display sdl in qemu, the segfault happens at the same point.

I know that openglide is being executed because OpenGLid.ini and OpenGLid.log are created. The contents of the log file don't give any insight into the crash:

Code: Select all
--------------------------------------------------------
OpenGLide Log File
--------------------------------------------------------
***** OpenGLide 0.09rc9 *****
--------------------------------------------------------
Date: 29 Jul 2018
Time: 15:18:17
--------------------------------------------------------
--------------------------------------------------------
Clock Frequency: 2583.69 Mhz
--------------------------------------------------------
--------------------------------------------------------
Configuration file is OpenGLid.ini
Configuration file is OpenGLid.ini



I am using the version of OpenGlide from here: https://github.com/voyageur/openglide which has a few additional patches. And gulikoza's openglide carmageddon patch from here: viewtopic.php?t=26356 which, when not applied, gives a black openglide window under DosBox. I tried the cvs release with no patches applied and got the segfault at the same point.

kjliew wrote:No. OpenGlide/X11 will spawn a new Glide rendering window by itself.


Thanks for the clarification, I asked because the segfault stops the qemu process before a new window is displayed on the screen.


To narrow down the problem where would you recommend adding DPRINTFs? "grSstWinOpen start" is being printed so it's happening after that, what would you expect the next call to be?

edit: If it matters, I'm using Arch Linux with KDE on Xorg.
TomB
Newbie
 
Posts: 23
Joined: 2005-7-02 @ 19:14

Re: QEMU 3Dfx Glide Pass-Through

Postby t9999clint » 2018-7-29 @ 19:13

OK, here's a crazy idea for the Linux side of things. (I'm not actually asking you do this, I'm just saying it'd be neat)
Dosemu2 also uses qemu and could benefit greatly from glide passthrough. They're working on KVM as well, I think this would be a killer way to emulate faster MS-DOS games.
https://github.com/stsp/dosemu2/issues/401

Kind of makes me wish I was better at coding...
User avatar
t9999clint
Member
 
Posts: 163
Joined: 2014-10-07 @ 14:08
Location: Edmonton, Canada

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-30 @ 17:14

TomB wrote:I'm trying to run Carmageddon 1's 3dfx.exe or voodo2c.exe. It works with DosBox and openglide but fairly slowly, I was hoping qemu would give better performance.

If your current Linux distro support multi-lib, building DOSBox/OpenGlide as 32-bit binary will give you a big boost in performance. QEMU is not going to get you better performance if you have the right DOSBox/OpenGlide build. You are probably using DOSBox/OpenGlide in native 64-bit build.

I got Carmagenddon 1 running on Windows 10 with QEMU. Haven't got a chance to check it out on Ubuntu.

I think you have got your setup mostly correct. It's just more complicated for Linux because there could be slight differences in every distro. I need to see if I can get Carmageddon 1 work on my side on Ubuntu. I will get back to you.

For the meantime, can you run the attached TEST04 from Glide2 SDK DOS just to make sure this simple check works on your QEMU setup without segmentation fault? You should get a colored triangle on a spawned window.

BTW, what's your GPU type/driver?
Attachments
test04.exe
Glide2 SDK DOS TEST04
(89.4 KiB) Downloaded 19 times
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-31 @ 04:26

TomB wrote:Thanks for the clarification, I asked because the segfault stops the qemu process before a new window is displayed on the screen.

Hi, I was able to nail down the issue on Ubuntu. It looks like the issue with Carmageddon 1 Glide programming. It called _grCullMode(GR_CULL_DISABLED) before _grGlideInit(). This is against 3Dfx Glide programming specification. DOSBox pass-through must have workaround this, or the Linux GL driver must be tolerant to OpenGlide pre-mature GL calls. And it seems NVIDIA Windows GL driver handles such scenario just fine but not the Linux GL drivers.

Fixing this in OpenGlide is simple, and I will see if I need to workaround this on QEMU pass-through.
Update: No need to fix OpenGlide. I think fixing this with the guest wrapper OVL is better to ensure consistant behavior across all the DOS Glide games. I will update the patch to include this.

QEMU with GTK display seems to have problem with CDROM, This applies to both cases where ISO image is passed directly to QEMU in "-cdrom cdimg.iso" or mounted locally in host with QEMU accessing host media in "-cdrom /dev/loop0". I got the following error message and QEMU would hang.
Code: Select all
qemu-system-i386: warning: I/O thread spun for 1000 iterations

I have the same issue with Tomb Raider 1, too. So use "-display sdl" for QEMU when a game requires its CD. If you insist and prefer GTK display for QEMU, then you would probably need to find ways to run the game without CD.
TomB wrote:And gulikoza's openglide carmageddon patch from here: viewtopic.php?t=26356 which, when not applied, gives a black openglide window under DosBox.

If you start Carmageddon 1 with "voodo2c -vrush", then gulikoza's patch is not required. Apparently, Voodoo Rush compatibility enforces stricter discipline for the game programmers to follow sane LFB practices.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-8-03 @ 02:09

Patch and guest wrappers prebuilt binaries updated in 1st post.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-9-08 @ 19:18

Patch and guest wrappers prebuilt binaries updated in 1st post.
- Glide3x wrapping works for 3Dfx OGL (Quake3, Homeworld)
- Glide3x wrapping works for Turok 2, NFS3/4/Porshe2000 using the Glide3x thrash drivers
- Fixed GPF in Unreal 1

The patch was tested on the recent QEMU 3.0.0 release. This version would be final. All the 3Dfx Glide games/demos at my disposal were tested. Unless others are reporting issues, I will no longer be actively working on this. Hopefully this would remain useful in the future for playing 3Dfx Glide legacy games on QEMU.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-10-06 @ 03:38

Patch updated to show frame per second on the console. It timed the freq of grBufferSwap called at the host. This may not always match the in-game FPS display if the game supports benchmarking, but so far it matches 3Dfx Valley-of-Ra and Racing demos.
No change to guest wrappers.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-10-14 @ 05:08

Patch and guest wrappers prebuilt binaries updated in 1st post. Mostly improvements for Linux side.

QEMU can now have Glide rendered in the same window, providing the same experience as its Windows build and fixing the annoying issue of losing inputs focus. However, this breaks QEMU GTK display option because the Glide window hooks are only implemented in the QEMU SDL1 and SDL2 UI handling. This is not a problem for SDL versions because they are mutually exclusive build time options for both Linux and Windows. GTK and one of the two SDL versions are runtime options for QEMU Linux build. I could have made GTK display work but decided to dropped it as GTK display is not an option for Windows build, and I prefer to share as much codes as possible between Windows and Linux builds.

Patched OpenGlide is required that fixes its X11 window init to bypass XCreateWindow() when a valid window handle is provided.
Update 11/10/2018: Fixed XWindow leak in FinaliseOpenGLWindow()

Again, Linux check-outs were done on Ubuntu 16.04LTS with NVIDIA propriety blobs and Intel HD Graphics on laptops at my disposal.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby ferus » 2018-11-14 @ 10:09

kjliew-

I came across this forum and this thread while searching for a way to play Mech 2 Mercs 3dfx under Windows 10. Unfortunately after several hours, I'm running into several issues which even Google has not been able to help with. I have compiled applications from source once or twice before, though it's been at least a decade or more, and never on Windows.

What I've done:
1. I installed msys2-x86_64-20180531.exe to D:\msys64\, on a PC running Windows 10 v1803.
2. Although your last post mentions QEMU 3.0.0, the code for the 3dfx patch for QEMU in the original post still references QEMU 2.12, so I grabbed the source for that instead.
3. The QEMU source was extracted to D:\msys64\qemu-2.12.0\
4. I installed QEMU's dependencies per the instructions at: https://wiki.qemu.org/Hosts/W32#Native_ ... with_MSYS2
5. I created D:\msys64\build\ and run configure and make commands from that directory.

With this set up, running ../qemu-2.12.0/configure --target-list=i386-softmmu results in the following:
Code: Select all
$ ../qemu-2.12.0/configure --target-list=i386-softmmu
Install prefix    c:/Program Files/QEMU
BIOS directory    c:/Program Files/QEMU
firmware path     c:/Program Files/QEMU/share/qemu-firmware
binary directory  c:/Program Files/QEMU
library directory c:/Program Files/QEMU/lib
module directory  c:/Program Files/QEMU/lib
libexec directory c:/Program Files/QEMU/libexec
include directory c:/Program Files/QEMU/include
config directory  c:/Program Files/QEMU
local state directory   queried at runtime
Windows SDK       no
Source path       /qemu-2.12.0
GIT binary        git
GIT submodules
C compiler        cc
Host C compiler   cc
C++ compiler      c++
Objective-C compiler cc
ARFLAGS           rv
CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS       -ID:/msys64/mingw64/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt -pthread -mms-bitfields -ID:/msys64/mingw64/include -ID:/msys64/mingw64/include/glib-2.0 -ID:/msys64/mingw64/lib/glib-2.0/include -ID:/msys64/mingw64/include -m64 -mcx16 -mthreads -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv  -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong  -ID:/msys64/mingw64/include/libpng16 -ID:/msys64/mingw64/include -I$(SRC_PATH)/capstone/include
LDFLAGS           -Wl,--nxcompat -Wl,--no-seh -Wl,--dynamicbase -Wl,--warn-common -m64 -g
make              make
install           install
python            python -B
smbd              /usr/sbin/smbd
module support    no
host CPU          x86_64
host big endian   no
target list       i386-softmmu
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
SDL support       yes (2.0.9)
GTK support       yes (3.24.1)
GTK GL support    no
VTE support       no
TLS priority      NORMAL
GNUTLS support    no
GNUTLS rnd        no
libgcrypt         no
libgcrypt kdf     no
nettle            no
nettle kdf        no
libtasn1          yes
curses support    no
virgl support     no
curl support      no
mingw32 support   yes
Audio drivers     dsound
Block whitelist (rw)
Block whitelist (ro)
VirtFS support    no
Multipath support no
VNC support       yes
VNC SASL support  no
VNC JPEG support  yes
VNC PNG support   yes
xen support       no
brlapi support    no
bluez  support    no
Documentation     yes
PIE               no
vde support       no
netmap support    no
Linux AIO support no
ATTR/XATTR support no
Install blobs     yes
KVM support       no
HAX support       yes
HVF support       no
WHPX support      no
TCG support       yes
TCG debug enabled no
TCG interpreter   no
malloc trim support no
RDMA support      no
fdt support       yes
membarrier        no
preadv support    no
fdatasync         no
madvise           no
posix_madvise     no
posix_memalign    no
libcap-ng support no
vhost-net support no
vhost-crypto support no
vhost-scsi support no
vhost-vsock support no
vhost-user support no
Trace backends    log
spice support     no
rbd support       no
xfsctl support    no
smartcard support no
libusb            no
usb net redir     no
OpenGL support    no
OpenGL dmabufs    no
libiscsi support  no
libnfs support    no
build guest agent yes
QGA VSS support   no
QGA w32 disk info yes
QGA MSI support   no
seccomp support   no
coroutine backend win32
coroutine pool    yes
debug stack usage no
crypto afalg      no
GlusterFS support no
gcov              gcov
gcov enabled      no
TPM support       yes
libssh2 support   no
TPM passthrough   no
TPM emulator      no
QOM debugging     yes
Live block migration yes
lzo support       yes
snappy support    no
bzip2 support     yes
NUMA host support no
libxml2           yes
tcmalloc support  no
jemalloc support  no
avx2 optimization yes
replication support yes
VxHS block device no
capstone          internal


If I run make, it terminates with the following error:
Code: Select all
a - libfdt/fdt_strerror.o
a - libfdt/fdt_empty_tree.o
a - libfdt/fdt_addresses.o
a - libfdt/fdt_overlay.o
D:\msys64\mingw64\bin\ar.exe: creating libfdt/libfdt.a
make[1]: *** No rule to make target '/build/capstone/capstone.lib'.  Stop.
make: *** [Makefile:503: subdir-capstone] Error 2


If I use --disable-capstone in the configure string, the build will finish, but launching QEMU gives various errors about missing DLLs, likely from the missing OpenGL support.

For giggles, I tried running ../qemu-2.12.0/configure --enable-gtk --enable-sdl --enable-opengl --disable-capstone --target-list=i386-softmmu but it results in the following:
Code: Select all
ERROR: User requested feature opengl
       configure was not able to find it.
       Please install opengl (mesa) devel pkgs: epoxy libdrm gbm


I've tried using pacman to install various opengl related packages using the switch -Ss "opengl", but so far I continue to get the above error when trying configure.

For my currently installed MSYS2 packages, here's the output of pacman -Qi | grep "Name":
Code: Select all
asciidoc
autoconf
autoconf2.13
autogen
automake-wrapper
automake1.10
automake1.11
automake1.12
automake1.13
automake1.14
automake1.15
automake1.16
automake1.6
automake1.7
automake1.8
automake1.9
bash
bash-completion
bison
brotli
bsdcpio
bsdtar
bzip2
ca-certificates
coreutils
curl
dash
db
diffstat
diffutils
docbook-xml
docbook-xsl
dos2unix
dtc
expat
file
filesystem
findutils
flex
gawk
gcc-libs
gdb
gdbm
getent
gettext
gettext-devel
git
glib2
gmp
gnupg
gperf
grep
groff
gzip
heimdal
heimdal-libs
help2man
icu
inetutils
info
intltool
lemon
less
libarchive
libargp
libasprintf
libassuan
libbz2
libcrypt
libcurl
libdb
libedit
libexpat
libffi
libgc
libgcrypt
libgdbm
libgettextpo
libgnutls
libgpg-error
libgpgme
libguile
libhogweed
libiconv
libiconv-devel
libidn2
libintl
libksba
libltdl
liblz4
liblzma
liblzo2
libmetalink
libnettle
libnghttp2
libnpth
libopenssl
libp11-kit
libpcre
libpcre16
libpcre2_8
libpcre32
libpcrecpp
libpcreposix
libpipeline
libpsl
libreadline
libsqlite
libssh2
libtasn1
libtool
libunistring
libunrar
libunrar-devel
libutil-linux
libxml2
libxslt
lndir
m4
make
man-db
mingw-w64-i686-drmingw
mingw-w64-i686-freeglut
mingw-w64-i686-gcc-libs
mingw-w64-i686-glew
mingw-w64-i686-glfw
mingw-w64-i686-gmp
mingw-w64-i686-libepoxy
mingw-w64-i686-libwinpthread-git
mingw-w64-i686-mesa
mingw-w64-i686-mpc
mingw-w64-i686-mpfr
mingw-w64-i686-nanovg-git
mingw-w64-x86_64-SDL2
mingw-w64-x86_64-adwaita-icon-theme
mingw-w64-x86_64-atk
mingw-w64-x86_64-binutils
mingw-w64-x86_64-bzip2
mingw-w64-x86_64-ca-certificates
mingw-w64-x86_64-cairo
mingw-w64-x86_64-crt-git
mingw-w64-x86_64-drmingw
mingw-w64-x86_64-expat
mingw-w64-x86_64-fontconfig
mingw-w64-x86_64-freeglut
mingw-w64-x86_64-freetype
mingw-w64-x86_64-fribidi
mingw-w64-x86_64-gcc
mingw-w64-x86_64-gcc-ada
mingw-w64-x86_64-gcc-fortran
mingw-w64-x86_64-gcc-libgfortran
mingw-w64-x86_64-gcc-libs
mingw-w64-x86_64-gcc-objc
mingw-w64-x86_64-gdb
mingw-w64-x86_64-gdk-pixbuf2
mingw-w64-x86_64-gettext
mingw-w64-x86_64-glew
mingw-w64-x86_64-glfw
mingw-w64-x86_64-glib2
mingw-w64-x86_64-gmp
mingw-w64-x86_64-graphite2
mingw-w64-x86_64-gtk2
mingw-w64-x86_64-gtk3
mingw-w64-x86_64-gtkglext
mingw-w64-x86_64-harfbuzz
mingw-w64-x86_64-headers-git
mingw-w64-x86_64-hicolor-icon-theme
mingw-w64-x86_64-isl
mingw-w64-x86_64-jasper
mingw-w64-x86_64-json-glib
mingw-w64-x86_64-libcroco
mingw-w64-x86_64-libdatrie
mingw-w64-x86_64-libepoxy
mingw-w64-x86_64-libffi
mingw-w64-x86_64-libiconv
mingw-w64-x86_64-libjpeg-turbo
mingw-w64-x86_64-libmangle-git
mingw-w64-x86_64-libpng
mingw-w64-x86_64-librsvg
mingw-w64-x86_64-libsystre
mingw-w64-x86_64-libtasn1
mingw-w64-x86_64-libthai
mingw-w64-x86_64-libtiff
mingw-w64-x86_64-libtre-git
mingw-w64-x86_64-libwinpthread-git
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-lzo2
mingw-w64-x86_64-make
mingw-w64-x86_64-mesa
mingw-w64-x86_64-mpc
mingw-w64-x86_64-mpdecimal
mingw-w64-x86_64-mpfr
mingw-w64-x86_64-nanovg-git
mingw-w64-x86_64-ncurses
mingw-w64-x86_64-openssl
mingw-w64-x86_64-p11-kit
mingw-w64-x86_64-pango
mingw-w64-x86_64-pcre
mingw-w64-x86_64-pixman
mingw-w64-x86_64-pkg-config
mingw-w64-x86_64-python3
mingw-w64-x86_64-python3-PyOpenGL
mingw-w64-x86_64-readline
mingw-w64-x86_64-shared-mime-info
mingw-w64-x86_64-sqlite3
mingw-w64-x86_64-tcl
mingw-w64-x86_64-termcap
mingw-w64-x86_64-tk
mingw-w64-x86_64-tools-git
mingw-w64-x86_64-vulkan
mingw-w64-x86_64-windows-default-manifest
mingw-w64-x86_64-wineditline
mingw-w64-x86_64-winpthreads-git
mingw-w64-x86_64-winstorecompat-git
mingw-w64-x86_64-xz
mingw-w64-x86_64-zlib
mintty
mpdecimal
mpfr
msys2-keyring
msys2-launcher-git
msys2-runtime
ncurses
nettle
openssh
openssl
p11-kit
pacman
pacman-mirrors
pactoys-git
patch
patchutils
pax-git
pcre
perl
perl-Authen-SASL
perl-Convert-BinHex
perl-Encode-Locale
perl-Error
perl-File-Listing
perl-HTML-Parser
perl-HTML-Tagset
perl-HTTP-Cookies
perl-HTTP-Daemon
perl-HTTP-Date
perl-HTTP-Message
perl-HTTP-Negotiate
perl-IO-Socket-SSL
perl-IO-stringy
perl-LWP-MediaTypes
perl-Locale-Gettext
perl-MIME-tools
perl-MailTools
perl-Module-Build
perl-Net-HTTP
perl-Net-SMTP-SSL
perl-Net-SSLeay
perl-TermReadKey
perl-Test-Pod
perl-TimeDate
perl-Try-Tiny
perl-URI
perl-WWW-RobotRules
perl-XML-Parser
perl-YAML-Syck
perl-inc-latest
perl-libwww
pinentry
pkg-config
pkgfile
python
python2
quilt
rcs
rebase
scons
sed
swig
tar
texinfo
texinfo-tex
tftp-hpa
time
ttyrec
tzcode
unrar
util-linux
vim
wget
which
xmlto
xz
zlib

I'm not sure where to go from here. :( Would you be willing to throw an archive onto Google Drive or OneDrive with your compiled copy of QEMU with 3DFX support for us plebs?
ferus
Newbie
 
Posts: 3
Joined: 2018-11-14 @ 08:27

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-11-14 @ 17:43

ferus wrote:I came across this forum and this thread while searching for a way to play Mech 2 Mercs 3dfx under Windows 10.

Before we dwell into QEMU build issue, I would like to make sure the version of Mech2 Mercs 3Dfx you plan to play. There are several versions of Mech2 Mercs and their naming was an utter confusion mess.
1. Mech2 Mercs Retailed 1.0
This is the 1st release and only support software rendering under DOS and Windows 95. There are patches to patch it to 1.06->1.08b->1.1. Patch 1.08b onwards support Direct3D HW acceleration on Windows 9x.
2. Mech2 Mercs 3Dfx 1.05
Contrary to the word "3Dfx", this is a special release that support Direct3D HW acceleration. It can be patched to version 1.1.
3. Titanium edition (Mech2/GBL/Mercs)
This is the *ONLY* version of Mercs that support 3Dfx Glide API. I don't think it was sold separately. It was sold as the collector's bundle which includes all past Mech2 games with the new 3D engine.

Only #3 would work from QEMU 3Dfx. If you got #1 or #2 patched up to the latest version, then the only way to play them is from DOSBox/Win98 using the voodoo1 chip emulation, which provides the Direct3D acceleration in Windows 98. Check out viewtopic.php?f=8&t=53383#p576348

If you have #1 and don't mind playing on software rendering, then just patch it up to 1.06 and play with DOSBox. With a decent modern PC, 640x480 or 800x600 should be playable.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby ferus » 2018-11-14 @ 19:05

I'm looking for the best 3D graphics. I'm not interested in running 3DFX just for the sake of it unless it looks better. Getting the Titanium Edition would not be my first choice. It is my understanding that Mercs Titanium has the same issues with the music tracks being cut short or rearranged as with the Titanium versions of 31CC and GBL. I can only imagine what kind of carnage they inflicted on the textures, weapon balance, or missions in Titanium Mercs, but I've actually not found any comparisons between Titanium and retail Mercs. I would be more than willing to get Titanium if that version of Mercs is improved.

While I played through 31CC and GBL on DOSbox, I've read posts which described the DOS version of Mercs as a "buggy mess". So, unless the Titanium version of Mercs is actually improved, It looks like I need to just find a VM (QEMU, VirtualBox, etc) which offers decent legacy Direct3D support and patch up my retail copy. The last time I played Mercs was on Windows, though I don't recall if it was software or Direct3D.

I'm open to any suggestions or alternatives. :)
ferus
Newbie
 
Posts: 3
Joined: 2018-11-14 @ 08:27

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-11-15 @ 01:02

ferus wrote:While I played through 31CC and GBL on DOSbox, I've read posts which described the DOS version of Mercs as a "buggy mess".

If you don't mind a similar (OK, slightly improved) vanilla graphic as 31CC/GBL on DOSBox for Mercs, then DOS version of Mercs should work for you. As long as you patched it to version 1.06, I would consider the game pretty stable. Look OK, and play well on DOSBox. If you got a fast modern PC, then 1024x768 would remain fluid. However, at version 1.06 Mercs game play salvage system is scripted.

The 3D accelerated version, both Direct3D and Titanium/Glide, from my personal assessment, they look good, but play poorly. Frame rate is inconsistent and suffer a huge penalty with particles and explosions (which you can disabled in combat variables), even it was played natively on WinXP and Win7 machine through unofficial patches. For instance, at start of mission 50-60fps, target and move towards an enemy 30-40fps, fire one salvo of LRM 10-15fps.... The SRM and LRM are causing tremendous frame drop because they have particles trails and chunky explosions. I don't know the game would play any better if one had retain its pristine operating condition and played on very fast Win9x machine, such as Win9x with Core2 3GHz class CPU.

Check out http://www.mech2.org/. Although it is no longer an active forum, it is the most resourceful forums for Mech2 olddies.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby ferus » 2018-11-16 @ 06:07

Thank you very much!
ferus
Newbie
 
Posts: 3
Joined: 2018-11-14 @ 08:27

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-12-23 @ 18:22

Patch and guest wrappers prebuilt binaries updated in 1st post.

- Fixed _grTexDownloadMipMapLevelPartial data copy from guest
- Optimize Glide arguments passing into host.
- No copy for _grGlide{Get/Set}State between host and guest. Guest should not need to know Glide state. The state will always be contained within host.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Postby kjliew » 2019-1-01 @ 03:16

Patch and guest wrappers prebuilt binaries updated in 1st post.

This is a significant update. I rewrite the entire 1st post for details.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Postby kjliew » 2019-1-07 @ 08:11

Patch and guest wrappers prebuilt binaries updated in 1st post.

Fixed game intro/cut-scene/briefing/in-game menu rendered with LFB and make them work with accelerated VM.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Postby robertmo » 2019-1-10 @ 16:23

ferus
you got all dlls in
msys64\mingw64\bin\

but i think even plain qemu.exe will crush when compiling with mingw64

compiling plain qemu with mingw32 works

but patched qemu when used with mingw32 complains about __int128 and stops compilation
Code: Select all
glidept_mm.c:308:17: error: expected expression before '__int1
User avatar
robertmo
l33t
 
Posts: 4745
Joined: 2003-6-18 @ 10:35

Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Postby kjliew » 2019-1-10 @ 20:19

I just realized later that MinGW.org i686 GCC does not support the __int128 type. My latest code has it rewritten to remove __int128. I will re-upload the latest code shortly. My main development environment is MinGW-w64 and x86_64 build.

You really want x86_64 build for QEMU, it is 20~25% faster than i686 build and support the latest version such as version 3.1.0. The last buildable QEMU version on MinGW.org i686 GCC (without going through too many hassles) I can get is version 2.9.1. The w32api in MinGW.org distribution is too old for later version of QEMU. For Windows 10, WHPX acceleration only works for x86_64 build. Intel HAXM acceleration claims to work for 32-bit QEMU running 32-bit guests, but I have never tried that.

I don't have any problem building and running QEMU from MSYS2/MinGW-w64-x86_64. In fact, it has been working for me amazingly well. For MinGW.org i686 GCC, the best version of QEMU I found is version 2.5.1.1.
Last edited by kjliew on 2019-1-11 @ 16:33, edited 1 time in total.
kjliew
Member
 
Posts: 477
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Postby DosFreak » 2019-1-10 @ 21:16

Mingw is still being updated. Assuming you're using the latest code downloaded from the mingw site (Linux repos usually have older version) then I'd submit a bug report to the mingw site.
User avatar
DosFreak
l33t++
 
Posts: 10423
Joined: 2002-6-30 @ 16:35
Location: Your Head

PreviousNext

Return to Release Announcements

Who is online

Users browsing this forum: No registered users and 2 guests