kekko wrote on 2022-09-03, 13:34:

Nice work, congrats! at the time I did the porting, I didn't care of a multithreaded software renderer, I was going to use open […]
Show full quote

Psyraven wrote on 2022-09-02, 17:05:

...

Nice work, congrats!
at the time I did the porting, I didn't care of a multithreaded software renderer, I was going to use opengl anyways afterall. Later I regretted it.
The opengl renderer provided higher performance and nice video quality, but later I realized my opengl code is quite messy and hard to make portable.
Your implementation seem stable and quite fast, and a pure software renderer is much easier to port; probably it would have had a better chance to make it to the official svn (12 years ago 😀 ).

If you add features or fix things, please let me know 😀 I don't actively work on dosbox anymore, but I like to have a look at any new features still being worked on.
Btw if you have this code in a version that patches against svn (i.e. for internal testing) I would be very interested to give it a look!

Thanks and keep it up!

I try to keep my code as close to SVN as possible so this wasn't too hard.
Here's a patch that adds multi-threaded software 3dfx voodoo emulation to current SVN.
I only tried the Tomb Raider 3dfx demo (from https://www.dosgamesarchive.com/download/tomb-raider/) and only on 32bit Windows.
The threading code for pthread (Linux, macOS, etc.) is in there so it hopefully builds and works everywhere DOSBox works.

leileilol posted about issues related to CLUT emulation and I have received issue reports about sometimes inaccurate colors and textures sometimes being blurrier than they should be. Do you think I broke that during my refactoring work or are these otherwise known issues? If possible, would appreciate any help with any of that, thanks!

Edit 20220905: Added modifications to src/hardware/Makefile.am and visualc_net/dosbox.vcproj to the patch.
Edit 20220906: Removed custom thread primitives and updated configure.ac to hopefully get non-Windows builds to work out of the box.

Thank you for the patch!
Unfortunately there are some known issues, it's not your fault.
Blurred textures issue seems to affect only the software renderer, while same games seem okay with opengl; I remember I suspected there is a bug with LOD calculation in the software renderer. It's probably something trivial.

I've seen the bad LOD calcs on MAME with some 3dfx-based arcade games emulated there like warfa so don't blame yourself for that.

PCem's a little better but not perfect on that either. Like on Quake3, check with r_colorMipLevels 1 to get a colorful view on the mipmaps (the RL area on q3dm1 is excellent). A real Voodoo2+* would show a curve there. On either emulation, no curve, and the sky would be showing mipmaps it shouldn't dare to show.

* - I don't posess a Voodoo1Voodoo Graphics to know if that produces a curve.

Quake2 seems affected by the textures issue; if you disable mipmaps in the console, running the command:
set gl_texturemode gl_linear
The issue disappears. There might be some wrong LOD calculation, i.e. in the TEXTURE_PIPELINE macro.
I tried to fiddle with the calculation and got some results, but not a proper fix to this.

I have successfully applied the patch to SVN and the binary runs normally. However, I am having trouble getting a Voodoo card to detect.

What parameters should I be using to enable the card in the configuration file? I was previously using these settings with kekko's 3dfx patch:

1[pci]
2#    voodoo: Enable VOODOO support.
3#              Possible values: false, software, opengl, auto.
4# voodoomem: Specify VOODOO card memory size.
5#                'standard'      4MB card (2MB front buffer + 1x2MB texture unit)
6#                'max'           12MB card (4MB front buffer + 2x4MB texture units)
7#              Possible values: standard, max.
8
9voodoo    = auto
10voodoomem = max

These seem to have no effect with Psyraven's patch.

almeath wrote on 2022-09-05, 13:40:

I have successfully applied the patch to SVN and the binary runs normally. However, I am having trouble getting a Voodoo card to detect.

What parameters should I be using to enable the card in the configuration file? I was previously using these settings with kekko's 3dfx patch

Oh sorry I have completely ignored how that worked in the original patch and just copied what I did in dosbox-pure.

In my version there are two config variables, both under [pci].
voodoo= is a string that can be set to 12mb, 4mb or disabled. Default is set to 12mb.
voodoo_perf= is a numeric value that can toggles performance optimizations for Vodooo 3dfx emulation (0 = none, 1 = use multi-threading, 2 = disable bilinear filter, 3 = both). Default is 1.

Though, now that I look at things, my patch did add "voodoo.cpp" but it didn't modify Makefile.am or the Visual Studio project. It might not compile correctly just out of the box without fiddling with that...
I just updated my post with the patch and uploaded a 20220905 version which does change the build files as needed. Hope it works, haven't tested it 😀

So by default the card should be enabled with 12MB. As long as machine=svga_s3 is set it should work. I only tried that Tomb Raider 3dfx demo version I linked in my post, maybe try that first if there's still issues.

Psyraven wrote on 2022-09-03, 16:31:

The threading code for pthread (Linux, macOS, etc.) is in there so it hopefully builds and works everywhere DOSBox works.

I think using SDL thread primitives would be a better choice than creating new Voodoo* primitives based solely on building for win32/non-win32.

Psyraven wrote on 2022-09-05, 14:48:

In my version there are two config variables, both under [pci].
voodoo= is a string that can be set to 12mb, 4mb or disabled. Default is set to 12mb.
voodoo_perf= is a numeric value that can toggles performance optimizations for Vodooo 3dfx emulation (0 = none, 1 = use multi-threading, 2 = disable bilinear filter, 3 = both). Default is 1.

Thanks. I recompiled using the new patch and that went fine, in terms of no compilation errors and a working binary.

I tried the following config settings:

1[pci]
2voodoo = 12mb
3voodoo_perf = 1

Unfortunately, no luck there either. I tried DOS, as well as Win95 and Win98 installs that I already had working with kekko's patch, all the drivers are correct etc.

When I load up your patch, I look in device manager (in both Win9x installs) and under PCI bus there is an exclamation mark. It says the BIOS for the hardware is not providing any resources.

Is this code 64-bit compatible? I compiled in macOS.

jmarsh wrote on 2022-09-06, 11:37:

I think using SDL thread primitives would be a better choice than creating new Voodoo* primitives based solely on building for win32/non-win32.

Ah, yes that makes much more sense for a DOSBox which has SDL 😀
I updated the patch and removed the custom thread primitives.

almeath wrote on 2022-09-06, 13:00:

Is this code 64-bit compatible? I compiled in macOS.

Looks like there was more stuff that needed to be done to facilitate non-Windows builds.
The newest 20220906 version of the patch now modifies "configure.ac" with some stuff I cobbled together. No idea if it works but please try it out!

Psyraven wrote on 2022-09-06, 17:47:

Looks like there was more stuff that needed to be done to facilitate non-Windows builds.
The newest 20220906 version of the patch now modifies "configure.ac" with some stuff I cobbled together. No idea if it works but please try it out!

Those changes appear to have done the trick, thanks. It compiled and works with my macOS SVN build.

Although a Voodoo device will not detect within a Win95 environment (i.e. it does not show up in the device manager), it definitely works within Windows 3DFX compatible games when the machine is set to svga_s3. Under Win98 everything seems to auto-detect fine.

I just tried it with King's Quest Mask of Eternity, which I could never get working with 3DFX within DOSBox (either SVN or X). I will move onto some other games that never worked right and see how it goes. Thanks again for your work on this! 😀

I really wouldn't trust any sort of test with DOSBox (nor DOSBox-X) under win95/98, there are major issues with the FPU emulation which can often break 3D games.

jmarsh wrote on 2022-09-10, 11:28:

I really wouldn't trust any sort of test with DOSBox (nor DOSBox-X) under win95/98, there are major issues with the FPU emulation which can often break 3D games.

Well, I can only judge it based on my own subjective experience. I just got Mask of Eternity, Lands of Lore 2 and F/A-18 Hornet all working properly for the first time in my SVN build. With the original 3dfx patch, these games either crashed or displayed major graphical distortions (i.e. striped lines across the screen) and were therefore unplayable in 3dfx mode. With this version of the patch, I have all three working under Win95/98, with no apparent issues. I am not sure why this is the case, I can only report that it is working for me. I do not know how this compares to original hardware, but it is definitely what I would class as playable.

DOSBox-X actually passes Intel's MCPDIAG.EXE tests... And it supports different FPU generations.
https://github.com/joncampbell123/dosbox-x/pull/3415

Regarding 3dfx, DOSBox-X implements enough of PnP, such that the 3dfx voodoo is properly detected in Win9x and works. Either in OpenGL mode, or with an external Glide wrapper using a custom GLIDE2X.OVL for DOS or a custom GLIDE2X.DLL for Win9x.

_Rob wrote on 2022-09-10, 18:46:

DOSBox-X actually passes Intel's MCPDIAG.EXE tests... And it supports different FPU generations.
https://github.com/joncampbell123/dosbox-x/pull/3415

Regarding 3dfx, DOSBox-X implements enough of PnP, such that the 3dfx voodoo is properly detected in Win9x and works. Either in OpenGL mode, or with an external Glide wrapper using a custom GLIDE2X.OVL for DOS or a custom GLIDE2X.DLL for Win9x.

I understand that one of the aims of DOSBox-X is to be more accurate/compatible in the emulation of hardware, which sometimes translates to better results within a Win9x environment. I cannot speak to DOSBox-X (or SVN) running in Windows as opposed to macOS. I can, however, say that my experience in tinkering with both versions (under macOS) over 5+ years has been that at least within macOS, the cost of all of the customizations in DOSBox-X is a loss of performance in the dynamic core, quite noticeable - around 30% or so. That is why my preference has been to patch SVN as opposed to using an out of the box solution so to speak. That being said, my only wish is there was an SVN patch to provide the IDE emulation that allows for emulation of physical CD-ROM drives within Win9x, as opposed to relying upon virtual CD-ROM software. But I digress ..

The point I want to make is that despite all the DOSBox-X improvements in supporting 3dfx/Glide wrappers, I found it usually resulted in the same crashes and graphical glitches as with kekko's SVN patch, at least within macOS. This may simply be something to do with incompatibilities in the code with core aspects of the macOS as opposed to Windows. I certainly made an effort to use the Glide wrapper and did make some progress, reported on the DOSBox-X forum (even patching and building a macOS compatible branch of OpenGlide for the first time since Dominus worked on it over a decade ago). However, it still ended up being quite unstable and glitchy, not at all what I could call playable performance. My experience so far, with this patch from Psyraven, is that, at least within macOS, it offers a far superior result to anything I have attempted with 3dfx emulation to date (outside of PCem/86Box, which apparently uses entirely different code).

_Rob wrote on 2022-09-10, 18:46:

DOSBox-X actually passes Intel's MCPDIAG.EXE tests... And it supports different FPU generations.
https://github.com/joncampbell123/dosbox-x/pull/3415

That has nothing to do with the issues I was talking about.
The problem is that the emulated machine's FPU state is not preserved between different threads in the emulated OS (which affects both x87 and MMX). Examples:
https://github.com/joncampbell123/dosbox-x/issues/3691
https://github.com/joncampbell123/dosbox-x/issues/1784

This doesn't have anything to do with FPU precision nor paging, which are the usually scapegoats that get blamed for unknown/random bugs. It's an underlying flaw in DOSBox (regardless of the host machine architecture or cputype setting) that makes it unsuitable for win95/98.

almeath wrote on 2022-09-10, 22:37:

I understand that one of the aims of DOSBox-X is to be more accurate/compatible in the emulation of hardware

No, the aim of DOSBox-X is to run demos (that are known to access strangest hardware directly using strangest features of the strangest hardware) 😀
3dfx is there by a coincident, cause the author started his work not on the official dosbox, but on ykhwong's dosbox-daum - abandoned Korean buggy quickly patched latest dosbox code with all available patches not necessarily compatible with dosbox/each other. ykhwong's dosbox-daum was suddenly abandoned hence it's latest version has more bugs than it used to have in the past. 🙁

DOSBox-X aim is not only to run demos, but also Windows 9X, and PC-98 games, and be accurate when doing it.

robertmo wrote on 2022-09-14, 09:48:

almeath wrote on 2022-09-10, 22:37:

I understand that one of the aims of DOSBox-X is to be more accurate/compatible in the emulation of hardware

No, the aim of DOSBox-X is to run demos (that are known to access strangest hardware directly using strangest features of the strangest hardware) 😀
3dfx is there by a coincident, cause the author started his work not on the official dosbox, but on ykhwong's dosbox-daum - abandoned Korean buggy quickly patched latest dosbox code with all available patches not necessarily compatible with dosbox/each other. ykhwong's dosbox-daum was suddenly abandoned hence it's latest version has more bugs than it used to have in the past. 🙁

AFAIK you are mistaken. Daum implemented an early version of DOSBox-X's code which wasn't even complete, not the other way around.

I noticed there are Voodoo Banshee and Voodoo 3 added to MAME. Would it make (visible) improvement when imported to DosBox code? Of course, it would require tweaking 2D code as well.

Banshee/V3 don't have the same DOS Glide compatibility and thus aren't relevant for DOSBox's scope. They also work differently (they're whole video cards) and they also had issues with many non-3D DOS games to boot. Banshee/V3's advantages over V1 (and V2) only really come into play for Windows games.

The only other card that could be added would be a Voodoo2 and even then the point would still be nil, as the extra TMU goes unused by just about every DOS glide game and V2's prime was in an era when only Bethesda were making DOS games and they don't use the TMU either. 😀