Error in emulating DirectX6-9's software renderer in Windows 9x.

[ChrisNonyminus]

Describe the bug This is a bug I've noticed in Dosbox-x a lot. Any 3D Windows 9x game (well, in Direct3D) has this weird thing where the polygons stretch and get spiky for a second. I've tried all output modes and in both sdl and sdl2 and the issue still arises.

To Reproduce Steps to reproduce the behavior:

1. Run Windows 98 on DOSBox-x
2. Run game that uses Direct3D
3. Play it

Expected behavior I expected for the polygons to not stretch or spike.

Screenshots

Environment (please complete the following information):

• Windows 10 (Version 2004)
• DOSBox-X 0.83.4
• Used configuration: https://pastebin.com/00ttNr26

Additional context This seems to be a problem with emulating hardware acceleration in general; I've had some issues with the 3dfx version of Tomb Raider 1 on DOS, such as fonts being missing.

[rderooy]

Tomb raider font issue: https://github.com/joncampbell123/dosbox-x/issues/1713

[ChrisNonyminus]

Yeah, that. Like I said, I think DOSBox-x has trouble emulating hardware acceleration.

[joncampbell123]

The 3DFx code as-is was taken from Daum's branch in 2015. It's possible DOSBox SVN or others might have improved it since. Some modifications were made to try to avoid conflicts with DOSBox'X own OpenGL use since both DOSBox-X and 3DFx emulation are using the exact same OpenGL context :facepalm:

[ChrisNonyminus]

Maybe you could import the code from DOSBox ECE? That also has code for emulating Glide.

[joncampbell123]

That might help. Has ECE improved on the code since?

[ChrisNonyminus]

dosboxECEImport.zip ece.zip Perhaps. Here's the code for the voodoo emulation (and glide emulation), I think. dosboxECEImport.zip is the src files, and ece is the header files

[ChrisNonyminus]

voodoo.zip I forgot to also upload the voodoo.cpp file from ECE. Oops.

[ChrisNonyminus]

You know what, I'll just link their entire source code since that'll be easier. 🙃 https://dosboxece.yesterplay.net/download/DOSBox%20ECE%20r4356%20(source).7z

[ChrisNonyminus]

By the way, when a savestate of 3dfx tombraider is loaded, the screen goes black.

[ChrisNonyminus]

Well this is weird... The issues regarding Tomb-Raider 3DFX on DOS go away if you use/compile an SDL1 build and use opengl as an output. However, the issues with Win9x games still come up.

[ChrisNonyminus]

However, when you load a savestate in sdl1 opengl, polygons will look weird... and stretchy.

[Wengier]

I have already added the code to emulate Glide in my latest pull request. The file GLIDE2X.OVL file is built into DOSBox-X, but the DLL file glide2x.dll/libglide2x.so/libglide2x.dylib will be required for Glide to work. Tested with 3dfx version of Tomb Raider and seems to work.

[ChrisNonyminus]

Where do I put the dll? I compiled a build with your commit and it's not detecting glide2x.dll even though it's in the exe's folder.

[Wengier]

@ChrisNonyminus Since you are using Windows, you probably want to install nGlide for this, which will automatically install the required Glide DLL files for the Windows platform:

https://www.zeus-software.com/downloads/nglide

Tested with at least 32-bit DOSBox-X, either SDL1 or SDL2 version. Set “glide=true” in the [pci] section of the dosbox-x.conf file.

[ChrisNonyminus]

I installed nGlide and did all of that and so far everything seems to be the same, from the spiky polygons in Win9x games to Tomb Raider 3DFX only working in sdl1.

[Wengier]

@ChrisNonyminus I don't have 3D Win9x games at this time, so I can only test Tomb Raider 3DFX as you mentioned. What do you mean Tomb Raider 3DFX only working in SDL1? Do you mean that it does not run on SDL2, or you have specific issue(s) with Tomb Raider 3DFX in SDL2, even if you don't use the save state feature? I did note the font issue mentioned in the another thread with a certain version of Tomb Raider, which I have not yet been able to reproduce on my computer. If you have specific issue(s) with Tomb Raider 3DFX that is not save-state related, could you please list the steps to reproduce the issue(s)? Thanks!

P.S. If I don't use the code in the latest commit or if I set “glide=false”, then Tomb Raider 3DFX won't even run in DOSBox-X here, failing with the error "Fatal error: unable to load DLL" at start. Setting “glide=true” will let me properly run Tomb Raider 3DFX in DOSBox-X.

[ChrisNonyminus]

I have the pci settings set to

# voodoo: Enable VOODOO support.
#           Possible values: false, software, opengl, auto.
voodoo = auto
glide  = true
lfb    = full_noaux
splash  = false

and Tomb Raider 3dfx still requires the ovl IN the game's folder AND the font still is a bunch of blocks on sdl2's surface output.

[rderooy]

There is more than one TR1 release with different menu options (in addition to patches) as mentioned in the other bug report which can mean that something works for one and fails for another.

[Wengier]

@rderooy That can indeed be the case. Perhaps I should just upload a zip package containing the files I am using for testing, and @ChrisNonyminus can also do this if it is possible.

[Wengier]

@ChrisNonyminus and @rderooy I have already uploaded a zip package with the files I am using to test Tomb Raider 3dfx. Everything needed is already inside the package, including dosbox-x.exe (SDL2), dosbox-x.conf and glide2x.dll, so you can just type dosbox-x.exe to run Tomb Raider 3dfx:

Download: tomb3d.zip

[ChrisNonyminus]

It works. Weirdly, the setup doesn't work on the exe I've compiled (which uses the same code albeit with some modding to remove the savestate compression but that shouldn't affect the glide emulation), but it works on yours.

[ChrisNonyminus]

Ah, I see. @Wengier your code only works on Win32. When I compiled for x64, the glide code did nothing. By the way, it forces fullscreen.

[Wengier]

@ChrisNonyminus It is not the code, but the glide2x.dll library file for the Glide emulation. 32-bit DOSBox-X requires 32-bit glide2x.dll file, and 64-bit DOSBox-X requires 64-bit glide2x.dll file (you cannot mix them up). As I have already suggested in my earlier post, the 32-bit glide2x.dll file as provided by nGlide only works with 32-bit DOSBox-X (either SDL1 or SDL2). You will need 64-bit glide2x.dll file if you use 64-bit DOSBox-X, or it will not work.

[ChrisNonyminus]

Ah, I see. Sorry for misunderstanding. Is dgvoodoo compatible with your glide code?

[Wengier]

Ah, I see. Sorry for misunderstanding. Is dgvoodoo compatible with your glide code?

The main portion of the new Glide code is ported from DOSBox ECE, but I have not tried dgvoodoo support myself yet. You can certainly try dgvoodoo yourself and see how it works.

[ChrisNonyminus]

Do you know any 64-bit glide2x.dlls that exist, by the way? Other than dgVoodoo 2, as it seems that doesn't work.

[Wengier]

@ChrisNonyminus I can find 64-bit glide2x.dll and dgVoodoo-related downloads from the following page:

http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2.html

SDL2 build seems to work better with this download.

[ChrisNonyminus]

Thanks! It works now (savestates also work with it, surprisingly!). Although Win9x games still have spiky and stretchy polygons, and it seems they aren't being detected by dgvoodoo.

[Wengier]

@ChrisNonyminus Great to hear that it works. On the other hand, I don’t have any 3D Win9x games to test at this time, so that is probably it for now.

[ChrisNonyminus]

I think the problem going on with Win9x has something to do with DirectX. Maybe there's some issues regarding DirectX emulation in Dosbox-x.

[joncampbell123]

I have a theory. Direct3D in DirectX as far as I know likes to use the FPU, even in kernel mode at times (and therefore require a 486 or higher). There is a known issue where Windows builds built with Microsoft's compiler have floating point precision issues because it only offers the "double" data type where proper FPU emulation requires "long double" for the full 80-bit precision. The only way to get full 80-bit precision on these builds is to select the dynamic core. GCC however is perfectly happy to offer "long double" as the full 80-bit precision data type which might allow the Windows MinGW and Linux builds to possibly render without glitches using normal or dynamic core.

The "double" precision issue is also known to affect certain demoscene productions and their 3D polygon rasterizing engines, causing missing or extended lines in the output.

[joncampbell123]

This is why DOSBox-X's FPU emulation was modified to use long double if possible, so that normal core can improve precision if possible.

In the original DOSBox codebase, the only way you'd get the full 80-bit precision is with dynamic core, else their normal core would use 64-bit double and cause the same issues.

[ChrisNonyminus]

If I set the cpu core to dynamic, Windows 9x won't boot or run.

[joncampbell123]

Try using the MinGW build with normal core.

[ChrisNonyminus]

I'm still getting spiky polygons in the MinGW build.

[ChrisNonyminus]

Guess what. I made a Windows 95 setup, installed Tomb Raider 2 (which came with DirectX 5, and not DirectX 9.0c, which is what the Windows 98 setup had), and ran it, and lo and behold, no spiky or stretchy polygons.

[ChrisNonyminus]

I'm not sure if it's the Windows version or the DirectX version that changed things.

[ChrisNonyminus]

I've figured out what the problem is. DirectX 6+ being installed along with the 3DFX driver (which is for DirectX 5). Turns out the latest Voodoo driver only goes up to DirectX 5.0, and there are no known drivers that support DirectX 7. When DirectX 7 or 9 are combined with the Voodoo drivers, all Direct3D games, even ones for DX5, are affected, resulting in the polygon issue.

[ChrisNonyminus]

This is getting even weirder. I tested Direct3D in the Windows 98 VM's dxdiag, and the software rendering test had the polygon issue while the hardware rendering did not.

[ChrisNonyminus]

I know what's wrong. Every app is either using the voodoo chip's borked software renderer, or the main svga, which also has a borked renderer, instead of the voodoo's hardware renderer..

[ChrisNonyminus]

And the borked software renderer is probably an error somewhere in emulating D3D6+'s software renderer. As seen in the Direct3D test, it can emulate the voodoo's hardware renderer just fine, but no app will use the hardware renderer for some reason.

[ChrisNonyminus]

There's a solution here: Implement Direct3D emulation similar to Glide emulation, or have the pool of graphics machines to emulate include the better 3D accelerated graphics adapters, like the Voodoo2, Voodoo3, NV1, Riva, S3 Stealth, etc.

[Wengier]

@ChrisNonyminus The internal 3dfx Voodo emulation has been improved in the latest DOSBox-X version 0.83.6. Please check it out (downloadable from: https://dosbox-x.com). Also, now I would like to test Windows 9x games for improvements. Could you please post the names of the Windows 9x games you played that have issues? Thanks!

[ChrisNonyminus]

Pretty much any game on Windows 9x that uses Direct3D is affected, if the Windows 9x guest os has directx 6 or higher installed. The games in particular I tried were The Sims 1 and Tomb Raider 2.

[Wengier]

@ChrisNonyminus So I suppose the screenshots in your first post are from The Sims 1 and Tomb Raider 2 respectively? I will check them.

[Wengier]

@ChrisNonyminus By the way, the font issue in the 3dfx version of DOS Tomb Raider for the internal Voodoo emulation is already fixed in DOSBox-X 0.83.6.

[Wengier]

I just tried Tomb Raider 2 demo and the dxdiag program on a guest Windows 98, and I think the main problem is still the performance for the software rendering. Apparently, the hardware rendering is significantly faster. On the other hand, the software rendering does not run very smoothly, and the said polygon issue is likely associated with this as well. Clearly, the software renderer needs some major improvements, especially about its performance.