VOGONS


Reply 20 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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

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.

$ 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.

Reply 21 of 225, by TomB

User metadata
Rank Newbie
Rank
Newbie

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:

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
Show last 51 lines
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:

--------------------------------------------------------
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: Carmageddon fix 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.

Reply 22 of 225, by t9999clint

User metadata
Rank Member
Rank
Member

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...

My Youtube Channel: https://www.kor.ninja/
My Soundfont Project: K.O.R. Soundfont Project V.5.0
My Soundcloud Page: https://soundcloud.com/clint-theriault

Reply 23 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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

  • Filename
    test04.exe
    File size
    89.4 KiB
    Downloads
    26 downloads
    File comment
    Glide2 SDK DOS TEST04
    File license
    Fair use/fair dealing exception

Reply 24 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.

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.

Reply 26 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 27 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 28 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 29 of 225, by ferus

User metadata
Rank Newbie
Rank
Newbie

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_builds_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:

$ ../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
Show last 74 lines
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:

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:

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":

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
Show last 234 lines
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?

Reply 30 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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 MechWarrior 2: Titanium on Windows 10 (with MechVM) does not work?

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.

Reply 31 of 225, by ferus

User metadata
Rank Newbie
Rank
Newbie

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. 😀

Reply 32 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 34 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 37 of 225, by robertmo

User metadata
Rank l33t
Rank
l33t

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

glidept_mm.c:308:17: error: expected expression before '__int1

Reply 38 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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-01-11, 16:33. Edited 1 time in total.

Reply 39 of 225, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline