Can you show "C:\WINDOWS> dir /s ddraw*.*" again after DirectX 9.0 installation?
You should cut down and remove unnecessary screenshots attachments. I only need the top that shows "ddraw*, d3d8 and d3d9".

BTW, what's your host system configuration, CPU & GPU?

Can you capture and show QEMU console logs when your start XvT from Win98 VM?
Here's the QEMU run scripts to capture the logs:

1#!/bin/bash
2
3GLIDE_DLL=./lib
4QEMU=./bin/qemu-system-i386
5
6$QEMU --version
7if [ ! -f $GLIDE_DLL/libglide2x.so ]; then
8    echo "Missing Glide2x library at $GLIDE_DLL"
9    exit 1
10fi
11echo "Host Glide DLL at LD_LIBRARY=$GLIDE_DLL"
12LD_LIBRARY_PATH=$GLIDE_DLL $QEMU -display sdl $@ 2>&1 | tee qemu.log

Here's a small Direct3D benchmark to test the Direct3D setup.
Unzip into a folder of its own, for eg. C:\DXTEST. Copy ddraw.dll, wined3d.dll & opengl32.dll into C:\DXTEST.
Run PCPD3DBN.EXE, you should be able to select "DirectDraw HAL" & "Direct3D HAL" and run the full-screen benchmark.

If you can't select both HAL, then it implies that Win98 has pinned its version of DDRAW.DLL into memory. This should not happen if DDTHRU ddraw.dll was correctly installed and the original Windows DDRAW.DLL had been renamed into DDRAWWQ.DLL.

**This is CRITICAL.**
The DDTHRU ddraw.dll was specifically devised to address this problem. You need to help me to verify that its mechanism was in place. Otherwise, Direct3D experience with QEMU is unpleasant and requires constant VM reboot to get rid of DDRAW pinning.

If I copy your ddraw.dll into C:\Windows\System and change name of original ddraw.dll to ddrawwq.dll I can't start neither Game, nor pcpd3dbn… I must did something wrong…
Log from QEMU give nothing…

WARNING: Image format was not specified for '/home/nemezis/myqemu/qemu-5.2.0-3dfx-6833fdf-ubuntu.tar/opt/qemu/bin/Win98SE.img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.

@OSH
You were not following exact instructions in several ways. Let me try to sort it out for you.

1. DDTHRU ddraw.dll is only meant to be in C:\WINDOWS\SYSTEM, together with the renamed DDRAWWQ.DLL.
2. There should *NOT* be any DDRAW* in C:\WINDOWS. Do not copy them into C:\WINDOWS, if this was what you had done as in screenshot #15.
3. For testing Direct3D setup with PCPD3DBN.EXE, you use *DDRAW.DLL* from [wine/*any version*/], never from DDTHRU. You were using *wrong DDRAW.DLL* from screenshot #17.

I wonder why your Win98 does not have *C:\WINDOWS\SYSBCKUP*
DDTHRU ddraw.dll installation is a one-time deal, it goes into C:\WINDOWS\SYSTEM together with the renamed DDRAWWQ.DLL. If you have C:\WINDOWS\SYSBCKUP, then it also goes there to prevent any games installation replacing it with their own copy. The original Windows version of DDRAW.DLL is also there in C:\WINDOWS\SYSBCKUP and should be renamed to DDRAWWQ.DLL for the sake of System Files Protection. You can see how it should look like on my Win98 VM.

For game or the Direct3D setup check with PCPD3DBN.EXE, you pick a WINE version and *copy the required DLLs into the game installed folder*.
* DirectX1~7 (ddraw.dll, wined3d.dll, opengl32.dll)
* DirectX8 (d3d8.dll, wined3d.dll, opengl32.dll)
* DirectX9 (d3d9.dll, wined3d.dll, opengl32.dll)

kjliew IT WORKS! But only in window, when I set full screen, I see the image in the left down corner… Anyway: big thanks for your help and patience! I was too tired lately, because I had too much work… this was the reason for these mistakes…

Ah, sorry. You gave me this registry file. I installed it, now it works in higher resolution.

But I can't understand this:

WxH are encoded as [30:16]x[15:0]. [31] will apply bi-linear filtering.

Can you tell me, what this means? When I want set for example 1920x1200, which values should I insert into these brackets?

Well done, glad to hear that it is finally working for you!

"ScaleWindow" defines the game's *original rendering dimension*. Many old Direct3D games only offer 640x480, some can do both 640x480 and 800x600 and only much later that the games would also support 1024x768. It is preferred not to use this if the games would allow different rendering resolutions. Otherwise, this option enables simple scaling of the game rendering.

WxH are encoded as [30:16]x[15:0]. [31] will apply bi-linear filtering.

Take X-Wing as an example, the game best resolution is 640x480, so you set "ScaleWindow"=dword:828001e0.

[31:31] = 1 (apply filtering)
[30:16] = 280 (640 in hex)
[15:00] = 1E0 (480 in hex)

And to play the game in 1920x1200, you just set Win98 VM desktop resolution to 1920x1200 and the game will be stretched/scaled accordingly. You don't have to touch the registry again if you want a different resolutions, the game will always fill up the Win98 VM desktop resolution. Over time, one would build up the game profiles in registry and simply play any games at the VM desktop resolution. A few more examples for other resolution. Remember, this is the game's *original rendering dimension*, not the resolution you wish to play on. The later is simply the VM desktop resolution.
800x600
"ScaleWindow"=dword:83200258
1024x768
"ScaleWindow"=dword:84000300

...when I set full screen, I see the image in the left down corner…

Nowadays, running games in fullscreen is simply uncool. 😉 Both Windows 10 and modern Linux DE/WM do not like fullscreen mode switching. So this is an aspect that I did not focus. Getting games run in windowed and free to multitask is much desired. For eg. I can have my browser open an RPG game walkthrough from GameFAQs while running the RPG game in QEMU windowed. If I got stuck in the puzzle, I just go to the walkthrough right away. This is my way of enjoying replaying old games ... 🤣

So when QEMU is in fullscreen, the image in the left down corner is normal, typical of OpenGL. Please use the "ScaleWindow" option and have QEMU desktop fill up the screen as much as possible instead of going into fullscreen mode.

kjliew wrote on 2021-04-29, 01:28:

...when I set full screen, I see the image in the left down corner…

Nowadays, running games in fullscreen is simply uncool. 😉

Allow me to be on the other side. I love playing in fullscreen, especially space-sims like X-Wing. It gives me more immersion. 😀
I understand, your goals are more compatibility and speed, but if you can make possibly to play in fullscreen, it will be great. But of course, it's your choice. I thank you for this great patch anyway. And one more question: can you tell me, how can I share directory between host and guest? After some corrections, I haven't problems with slirp so network should work.

OSH wrote on 2021-04-29, 11:50:

Allow me to be on the other side. I love playing in fullscreen, especially space-sims like X-Wing. It gives me more immersion. 😀
I understand, your goals are more compatibility and speed, but if you can make possibly to play in fullscreen, it will be great.

Sure, I fully realized that many still prefer fullscreen these days. What's the size of your screen? I am asking this because if QEMU Win98 VM can use the same desktop resolution as your screen size, then perhaps QEMU could be built with SDL2 borderless support and "ScaleWindow" option would scale/stretch accordingly, aka "fake fullscreen". This has the limitation of requiring VBEMP Win9x to support your screen resolution exactly. When I checked it on my Win98 VM, the max resolution VBEMP Win9x could do on Win98/ME is 1920x1200. VBEMP NT could do more up to 2560x1600 in Win2K/XP VM.

However, upstream QEMU removed borderless window support when SDL1.2 was deprecated because the initial production SDL2.0 was released without borderless support. Borderless support for SDL2.0 arrived at much later point releases but no QEMU devs had ever sought to bring back borderless support with SDL2.0. I had ported SDL1.2 borderless back to SDL2.0 for an old version of QEMU version 3.1.1.1. So, if you belong to group of luxury folks with HiDPI 4K/8K or Ultra-Wide panel, then this isn't going to work so well. Windows 10 display scaling can be applied on top of VM desktop resolution if that helps. I am not quite sure about display scaling on Linux if it would work the same way as Windows 10.

A 2nd option, but highly undesirable, is to go back to old QEMU version that support SDL1.2. QEMU starting at version 4.0.0 removed all SDL1.2 support. SDL1.2 will do real mode-switching on fullscreen. I had briefly tested this in the past on Windows 10 and Linux. However, SDL1.2 is already deprecated everywhere. There is no guaranteed that its mode-switching would continue to work in the future or how well mode-switching are being handled/emulated by future OSes.

OSH wrote on 2021-04-29, 11:50:

And one more question: can you tell me, how can I share directory between host and guest? After some corrections, I haven't problems with slirp so network should work.

You need configure SAMBA server on the host to allow NTLMv2 and Win98 VM requires additional install of Directory Service Client to support NTLMv2. For Linux host, it is also possible to mount the VM image with "qemu-nbd" and manipulate the image directly.

My resolution is 1920x1200. So it's the maximum which can handle VBEMP on 98/ME. It's interesting idea with this "fake fullscreen". I have to work on this SAMBA setting…

Then it may already work AS-IS. Use Ctrl-Alt-F to switch QEMU to fullscreen then set Win98 VM desktop resolution to 1920x1200. Run the game and it should be stretched/scaled accordingly. The image will be distorted though since you are stretching into different aspect ratio, it won't add black bars to the sides to maintain aspect ratio. I just checked with Moto Racer 1 stretched to 1920x1080 covering the entire screen on my FHD laptop.

You can also set Win98 VM desktop resolution to 1600x1200 and run the game. You will then play the game in fullscreen on the left part of the screen with black bar on the right, but at the correct aspect ratio with full screen height.

BTW, can you also post your system details for my own record? Just the CPU and GPU details are good enough. I hope that you can also add screenshot from X-Wing D3D graphics option for others to replicate your success in the future. Thanks!

Of course:
CPU: Intel i7700K 4,2 GHz
GFX: GTX 1060 OC 6 GB
RAM: 16 GB

Hmm, I have problem. Whan I add this registry settings for XvT, I can play in fullscreen, like you described or in full window. But If I modify this settings for playing X-Wing:

1REGEDIT4
2
3[-HKEY_CURRENT_USER\Software\Wine]
4[HKEY_CURRENT_USER\Software\Wine\AppDefaults\Xwing95.exe\Direct3D]
5"ScaleWindow"=dword:828001e0
6"UseGLSL"="disabled"
7
8[HKEY_CURRENT_USER\Software\Wine\Direct3D]
9"VideoMemorySize"="256"
10"SwapInterval"=dword:0

I see this:

From your generous donation, I have sourced my copy of X-Wing from The LucasArts Archives. Let me check it out and get back to you.

Thanks kjliew! I'll wait patiently. 😀

@OSH
OK, look like X-Wing 95 Collector CD (USA) re-release does not use the same engine as XvT ... sigh ...
This is the version I am testing

###############################
LucasArts Entertainment Co. LLC
X-Wing for Windows 95
Version 1.0
###############################

The good news is it still work, but with somewhat some restrictions compared to XvT 3D engine.
1. You *MUST* use Wine 1.9.7 for software cursor mode the launcher to launch the game for software cursor mode. For 3D Hardware rendering, only Wine 1.8.7 and 1.9.7 work. For 8-bit or 16-bit software rendering, any Wine version will do.
2. Outside of in-game flight, the game is basically doing 8bpp (256-color) DirectDraw rendering. It tried to switch to 640x480 8bpp mode. When "ScaleWindow" option was used, it inhibited the game mode switch to retain current desktop resolution but VBEMP Win9x 8bpp modes are limited to standard 4:3 and max at 1600x1200. So this the max resolution you can play the game.
3. You can't use filtering while scaling for 8-bit palettized colors. This is a limitation of WineD3D. So use "ScaleWindow"=dword:28001e0.

4. You still have to go to "Flight Option" to select "640x480 3D Hardware". The default is software rendering even though you already selected DirectDraw HAL from the launcher.

ArchLinux X-Wing 95 3D Hardware at 1600x1200

Alright, I hope you still enjoy the game. I played the DOS floppy version with keyboard & mouse. I finished the main campaign long back then on DOSBox. 😉

Thanks kjliew. When I set fullscreen, the image is moved slightly on the left but well, I think I can play in window… anyway big thanks for your help, I should now test other games which I have (over 500) 😁.
First time I completed X-Wing on my Amiga under Macintosh emulator Shapeshifter, then on PC. But it's something special: There's a website http://rebelsquadrons.org/missions/. Here you can download custom missions for X-Wing, TIE Fighter, X-Wing Vs. TIE Fighter and X-Wing Alliance. It's over 600 missions for X-wing and many for other games, so you can play really LONG. 😁

Look like Tie Fighter 95 uses the same 3D engine as X-Wing 95, so then both of these great 90's games from the LucasArts Star Wars series are fully restored with QEMU. No unofficial fan-made patch is required! Just run them with Win98 VM in pristine condition right from their ripped CD images. A perfect preservation! 😁

Games such as these are truly a challenge to get them running with 3D hardware acceleration. VMware/VirtualBox won't cut it. PCem can only run them in software rendering, so much for the so-called Voodoo whatever emulation, its Direct3D support isn't any better even though it does full device emulation, not to mention it would be so much slower even if they work at all, as it does not believe in hardware acceleration and prefer the CPU's brute force. I don't know if DOSBox voodoo chip emulation can run them, but DOSBox really has other issues on Windows 98 including joystick support that was mandatory for the games. If they had retained the old & good keyboard/mouse playability, I could have been more eager to acquire the re-releases with 3D Hardware rendering support to check them out with DOSBox.

Anyway, QEMU made it. 😀

Re: Why can't older 3D games be rendered at higher resolutions?

kjliew wrote on 2021-05-02, 09:34:

Look like Tie Fighter 95 uses the same 3D engine as X-Wing 95, so then both of these great 90's games from the LucasArts Star Wa […]
Show full quote

Look like Tie Fighter 95 uses the same 3D engine as X-Wing 95, so then both of these great 90's games from the LucasArts Star Wars series are fully restored with QEMU. No unofficial fan-made patch is required! Just run them with Win98 VM in pristine condition right from their ripped CD images. A perfect preservation! 😁
Tie953D.png
Games such as these are truly a challenge to get them running with 3D hardware acceleration. VMware/VirtualBox won't cut it. PCem can only run them in software rendering, so much for the so-called Voodoo whatever emulation, its Direct3D support isn't any better even though it does full device emulation, not to mention it would be so much slower even if they work at all, as it does not believe in hardware acceleration and prefer the CPU's brute force. I don't know if DOSBox voodoo chip emulation can run them, but DOSBox really has other issues on Windows 98 including joystick support that was mandatory for the games. If they had retained the old & good keyboard/mouse playability, I could have been more eager to acquire the re-releases with 3D Hardware rendering support to check them out with DOSBox.

Anyway, QEMU made it. 😀

The latest Wine runs it fine with 3d acceleration. I am really curious as to your personal distaste of pcem. Sarah walker has done amazing work on that project and yet every other post of yours has to diss pcem. Lack of class man

Please don't start new flamewar. This topic is strictly about QEMU and not about comparision with other VMs/emulators.