HI Dege,
Attached the patch for QEMU 3Dfx Glide pass-through. It should work with any recent version of QEMU. I am testing with the following version:
QEMU 2.12.0 (sdl2)
QEMU 2.9.1 (sdl1/sdl2)
QEMU 1.6.2 (sdl1)(patch failed for 1 hunk, but manual merge is easy)
You will need MSYS2/mingw-w64 GCC toolchain build environment & bash shell. Here's a brief instruction on how to apply the patch assuming you are familiar with bash shell.
- Code: Select all
$ mkdir ~/myqemu4fun
$ cp qemu64-3dfx-20180627.tar.gz ~/myqemu4fun
$ cd ~/myqemu4fun
$ wget https://download.qemu.org/qemu-2.12.0.tar.xz
$ tar xf qemu-2.12.0.tar.xz
$ mv -v qemu-2.12.0 devel
$ tar xf qemu64-3dfx-20180627.tar.gz
$ patch -p0 < ./hw/3dfx/3dfx.patch
$ mkdir build
$ cd build
$ ../devel/configure
$ make
I added window resizing helper code in QEMU for OpenGlide & PsVoodoo to render into the same QEMU window. (See glide_prepare_window() in sdl.c/sdl2.c) Somehow, dgVoodoo2 is capable of rendering into QEMU window without the helper code,
but with the 1-pixel off in width and height. Unfortunately, dgVoodoo1 just hung, similar to OpenGlide & PsVoodoo before I took out their window resizing code. Not sure if you would still be interesting to fix this issue for dgVoodoo1 or we will just retire it.
I am having hard time to figure out why window resizing cannot be done by Glide wrappers, as they can be done in DOSBox. Any call to MoveWindow() or SDL_SetVideoMode() simply crashed QEMU, or required QEMU to create a separate window for Glide rendering. I also have the code for Glide wrapper to render into its own window, but I removed it in favor of rendering into the same QEMU window.
Unfortunately, while the helper code works for OpenGlide & PsVoodoo, it broke dgVoodoo2 for QEMU on SDL2. QEMU on SDL1.2 is fine. I think this has to do with the off by 1-pixel from dgVoodoo2. Glide session worked once and upon exited, QEMU window shrunk into just the title bar. I am still debugging this from QEMU side.Dege wrote:Say, when the game is running at 640x480 then it's window client size is 639x479? I'll check it out.
I think it is more likely 641x481, since it overlapped the right & bottom border, which have the thickness of 1 pixel. Or perhaps, something more serious, as once dgVoodoo2 is done, it seems to corrupt the rendering context of QEMU and switching out dgVoodoo2 with OpenGlide or PsVoodoo does not change anything. QEMU has to be restarted to fix this.Looking forward to more good news from you, especially on fixing the 64-bit fogging issue.

Update: It turned out that the window resizing helper code was the problem, not dgVoodoo2. So considered this resolved, as now I have dgVoodoo2 rendered correctly with all the borders. I updated the new patch in the OP.