There are good 3dfx wrappers for Windows games.

I don't know if any of them are open sourced though.

It really would be best to have hardware passthrough to d3d for stuff like DosBox instead of complete
software emulation for 3d acceleration.

Complete software emulation would absolutely tank performance.

After thinking about this more, it would probably be easiest to:
1.Have DosBox pass the calls to a Glide wrapper. No need to re-invent the wheel.
2. Add some multithreading capability to DosBox. Why have everything be on only a single thread?
Why not split the load between different threads? Sure some things must be run serially, but
it would not hurt to break different tasks into separate threads.
3. Give a configuration option to enable/disable multithreading.

Perotin wrote on 2023-06-13, 15:02:

I'm just curious, what is/are the reason(s) for it still working very slow or simply unreliable in most cases (crashes, screen tearing, artifacts etc.)?

3dfx cards weren't the fastest nor the cleanest. Multithreaded 3dfx emulation's been a thing for years and so are the CPUs that can do it. There's just a couple things left out mutually between the software emulation of them and they're not features anyone talks about.

Also no one's emulated a Voodoo4/Voodoo5 because there really isn't much legally clear and publicly released (NOT LEAKED) tech documentation on that.

I thought 3dfx (glide) emulation was already in Dosbox and worked fairly good?

sofakng wrote on 2023-06-14, 00:57:

I thought 3dfx (glide) emulation was already in Dosbox and worked fairly good?

Looks like DosBox-pure and DosBox ECE support 3dfx emulation.

Haven't really looked into that as I haven't really played with any of the forks.

I also see mention of an alpha build of regular DosBox from 2017 with 3dfx support on the DosBox site.

I believe that a prerequisite for serious discussion about 3dfx in dosbox is official/stable support for win9x, otherwise it's limiting to dos games and therefore not a complete solution. Then again I'm not even sure it makes sense since it's, well, DOSbox. An integration of some software capable of running windows games (PCEm? 86Box? VM?) and an established glide wrapper like nGlide seems more suitable to me.

There are problems with both 3dfx and win9x emulation in DOSBox that both boil down to how floating point is handled, the only way it would ever be properly portable would be if someone wrote full x87 emulation code and I don't think that's ever been done for any project.

A question I've had many times is why does the CPU and GPU have to be emulated at all? It isn't like those functions have been dropped on modern processors.

The only problem I see with directly using the hardware would be that you would have to change the way the speed is regulated for speed sensitive software.

You can't exactly run a CPU in real mode (with full access to segment registers, page tables etc.) from within a program. Not to mention on systems that aren't x86...

Right, so what about using a type of hal instead of full-on software emulation?

If the system it is being run on is x86, then not everything should need to be emulated.

If it is non-x86, then it would be compiled as such anyway and the full software emulation would need to be there.

cyclone3d wrote on 2023-06-14, 14:00:

If the system it is being run on is x86, then not everything should need to be emulated.

This is what the "dynamic" core (dynamic recompilation) does in DOSBox-X, although it seems to be limited to 32-bit x86. The "modern" system you're running on most likely is x86_64 (aka amd64), which isn't the same as x86. Add to that real mode and stuff and things get tricky really fast (there's no Virtual 8086 Mode in Long Mode anymore).

There are also other approaches, like hooking on the library level (e.g. Box86) which can help performance, if you combine that with Wine, you get x86 Win32 apps running on ARM Wine using native OpenGL drivers, for example. Of course, if the app uses software rendering, the library-level hooking doesn't help much.

cyclone3d wrote on 2023-06-14, 14:00:

If it is non-x86, then it would be compiled as such anyway and the full software emulation would need to be there.

CPU code can be compiled "ahead of time" or "just in time" to other CPU architectures; non-x86 doesn't mean it can't be translated. This is what e.g. Apple's Rosetta2 (x86_64 binaries on arm64) or Microsoft's x86 (+ x86_64) emulation on Windows 11-on-ARM64 do. It's also what back in the day (Rosetta 1) Apple did (running PPC binaries on x86).

It always depends how "native" you want the environment to look and how accepting the content you want to run is of such a not-fully-native environment.

As an example, with Linux, Wine and nGlide, you can have quite good 3Dfx game support on modern x86_64 machines, with all code running "natively", without emulation (just wrapping) - IF the game itself runs under Wine and is happy with nGlide's implementation of the Glide API. Add Box86 into the mix, and you could probably run 3Dfx x86 games on a Raspberry Pi.

cyclone3d wrote on 2023-06-14, 14:00:

Right, so what about using a type of hal instead of full-on software emulation?

If the system it is being run on is x86, then not everything should need to be emulated.

dosemu's right there. Wonder why it never gained relevance in the 2000s 🤔

Where are the gaps in emulation? What still doesn't work?

nglide is high level emulation that translates API calls AFAIK. There are forks of dosbox, at least, that have a dependency on nglide to support glide games and use it for rendering. I played a few glide DOS using all the features that nglide provides (high resolution, extra filtering, ect).

nglide and dgvoodoo2 are also largely compatible with windows based glide games.

PCem supports voodoo emulation and I am pretty sure it is entirely emulated on the CPU.

Maybe I haven't explored it deeply enough, but I have yet to find an instance where glide emulation was much of a problem.

cyclone3d wrote on 2023-06-14, 14:00:

Right, so what about using a type of hal instead of full-on software emulation?

One does not simply "use a HAL." Especially if they want code to be portable.

If the system it is being run on is x86, then not everything should need to be emulated.

The problem is you can't selectively emulate some parts and not others.
DOS software expects to have complete control over the entire machine - all the protected CPU registers, ports, memory mappings, PIC...
Modern windows still doesn't even allow mapping memory with native 4KB granularity because some ancient CPU way back when win32 was born had 64KB granularity instead.

If it is non-x86, then it would be compiled as such anyway and the full software emulation would need to be there.

And then we end up with an even worse case of the current FPU problem, which is that non-x86 builds only get 64-bit floating point accuracy while x86 builds use the built-in x87 (80-bit accuracy) and forums get filled with arguments between people saying a game/demo works/doesn't work because they don't realize different hardware = completely different performance.