Have you checked the clock frequency too? I haven't tested all the specific branded drivers but I won't be surprised if they overclock by a small margin (by 3MHz?) to get on top of the charts.

i only recall the gainward V2 drivers overclocking to 100mhz, but no, i didn't check the clocks for these drivers. it's so CPU limited on this setup that along with running in the smaller resolution, i don't think it would show much in the results. i am looking for earlier drivers though, even the earliest drivers in this comparison mention being "tuned for pentium pro", and p2 later on. i'm not sure if glquake needed a driver or just ran on the included .dll.

i updated from dx 5.0 to 5.2, not updating any driver and using the 2.16 reference for the voodoo, and saw a decrease in performance - 20.5 fps in turok and 18.6 in PCP. a comprehensive test of DX versions in win95 is something i thought about, but for now it seems pentium machines might be better off just staying on dx5.

testing this further, i've had some weird things happen. being on dx 6.1 now, i installed the final 3.01.00 driver. this is after deleting the previous driver .inf in the windows folder and running DCpro 1.5 in safe mode. now with this driver that previously (mostly) worked, nothing will recognize the card and D3D programs freeze, then a bluescreen comes up and warns about not being able to write to C: and probable data loss. i have also tried simply updating from the other driver without prior deinstallation, same result. uninstalling this driver and installing 3.00.01, everything works again.

the difference to before is being on dx6.1 rather than dx5 now, and having had the dx6 voodoo drivers installed at one point. in fact, this dx6 driver is what windows tries to install by default upon every boot, despite no .inf for that being present in the inf/other folder. i might just go up to dx7 and see if that comes with another driver, and/or if that makes the problems with 3.01.00 go away.

auron wrote on 2025-01-19, 13:18:

the difference to before is being on dx6.1 rather than dx5 now, and having had the dx6 voodoo drivers installed at one point. in fact, this dx6 driver is what windows tries to install by default upon every boot, despite no .inf for that being present in the inf/other folder. i might just go up to dx7 and see if that comes with another driver, and/or if that makes the problems with 3.01.00 go away.

IIRC, the last official Voodoo 1 driver needs DX7.

that doesn't make sense, because a) the final driver only mentions requiring dx5 and b) the driver is dated may 1999, while dx7 only first released in september 1999.

i also think that directx updates aren't as unproblematic as some make them out to be and wouldn't recommend just going with the latest version straight away, on windows 95 at least. digging through old sources, there were some issues reported with those updates in that time frame. though ddraw refresh rate overriding is a useful feature later exposed in dxdiag, but it seems to depend on a supported graphics driver rather than simply having a new enough directx version installed.

auron wrote on 2025-01-19, 13:44:

that doesn't make sense, because a) the final driver only mentions requiring dx5 and b) the driver is dated may 1999, while dx7 only first released in september 1999.

I may have confused it with the latest Voodoo 3 driver. That one was definitively acting up unless DX7 was installed.

hmm, i usually go with that driver on V3 and don't recall any issue on a stock 98se (should be 6.1a). what problems did you encounter?

by the way, before those issues i had also tried the turok 2 D3D6 renderer on the V1, with the 3.00.01 driver the game comes with, and it would render half of the world missing. so that might mean these drivers indeed only support D3D5 renderers as indicated by falconfly, though couldn't check if 3.01.00 fixed that. obviously more of a theoretical issue because one would use glide here anyway.

auron wrote on 2025-01-19, 13:57:

hmm, i usually go with that driver on V3 and don't recall any issue on a stock 98se (should be 6.1a). what problems did you encounter?

It's been a while since I experienced that, but from what I recall, the card was stuck at 640x480 desktop resolution.

The readme file for that Voodoo 3 driver suggests that DX7 should be used with it.

so i went up to dx8.0a, the final version supported for win95, which might as well be 8.0 (there is no version difference between these in dxdiag). i then noticed that when it tries to install this dx6-included driver upon boot, which by the way is a pure direct3d driver and should totally be avoided, a few files will already have been copied to windows/system despite cancelling - in my case, mm3dfx16.dll and mm3dfx32.dll. that's some really crappy behavior in win95.

i'm not sure if deleting this before installing 3.01.00 changed anything, but i did get eventually get direct3d working with that driver to the point of running PCP D3D (18.3 fps). but the only other thing i was able to run is pandemonium. GTA 2 (which ran on 3.00.01, but frequently locked up, at least under dx6 or 6.1), turok/turok2, quake2 in both minigl/opengl will all either error out with a "glide2x expected voodoo graphics, none found" error or simply freeze the machine. don't know what's different about pandemonium, maybe it's using a .dll the game comes with and the glide2/3 from that driver don't run on a p54c pentium. either way the compatibility and issues are so bad that i think it's something with this setup, the driver should hopefully work on something more expected for its release date, like a p2/p3 on windows 98.

since i dug these up, might as well post them here - original links for dx8.0a and DCOM95 1.3 (download), the latter of which is needed from dx8 upwards, or it will throw an error message on every boot. with this i've noticed windows using as much as 16mb right after boot, with a 4mb vcache, so 12mb for a win95 osr2 with nothing loaded - need to check vs. a freshly installed setup, but that seems a little high.

edit: reverting back to the working 3.00.01 driver, GTA2 ran stable now, the crashes might have been due to being on while the game requires 6.1. i was actually surprised by the performance on this hardware, as while it did run in slow motion while driving around, it wasn't a world apart from being playable. that's somewhat impressive for less than 50% of the minimum CPU spec (p200), maxed out RAM and accessing two drives in pio mode during gameplay.

Re: DaemonTools No CD Audio
To not go off-topic there, I'll post here.

auron wrote on 2025-01-20, 22:28:

for the fallout issue i didn't touch anything other than updating to DX5 from the disc and refused all the driver updates at first.

I don't have the hardware but tested in 86box with a PMMX 233, Matrox Millennium, SB16, and Win 95 OSR2.1 (with the USB update 1 and 2 installed from the OSR2.5). I used the built-in windows drivers.

Using the first US release of Fallout 1, I installed DX3.0a, restarted and then installed the game. Got into a new game and it works fine. I then updated to the included DX5.0 and declined the driver updates and restarted. I then got into new game again and it still works fine. Of course this is emulation but the results on 86box usually tend to match real hardware. Tests by other members on real hardware would be helpful.

auron wrote on 2025-01-20, 22:28:

i understand the very first post in that thread as the existing drivers not supporting an updated DX version (i.e. the case with fallout i described), not installing drivers that come with DX, because that quoted readme suggests to request updated drivers from the vendor that work with DX3.0. or would microsoft ship drivers with DX3 that don't support DX3? in the same vein, later in that thread there is a post referencing homm2 and updating to dx3 from that disc, which resulted in no sound in the game with the then-newest creative drivers, requiring the install of sound drivers that DX3 came with.

A display driver doesn't need to explicitly support a newer DX to function. For example Voodoo 1 doesn't have drivers that support higher than DirectX 5 features, but you can still use it on a Windows installation with a much higher DX version. Even the readme says "DirectX 5.0 or higher".

When a video driver doesn't support a higher DX, what happens is that the programs that need a higher DirectDraw or Direct3D to function (and don't have a render path for older ones) won't work with the video card.

We don't know what those people exactly did back then and what the condition of their setup was. All of this requires new testing.

auron wrote on 2025-01-20, 22:28:

a game can still use other DX APIs even when not using D3D for rendering and later glide games can require 6.1 for instance. i thought maybe post-5.0 they introduced something using P6 or MMX instructions that's running a slow code path on a vanilla P5, but that would need testing to see if the same performance difference is present on a pentium ii or not. or maybe some old DX SDK docs have a hint at what is going on here.

Yes but not graphics APIs, at least AFAIK. Need to check exactly which DLLs a glide game loads. MS did fix some bugs with newer dll files which might explain the performance differences if the tests are accurate. I still don't see any of this making a DX "bad" though, considering other variables like drivers, etc.

This needs more testing and a sample of 1 or 2 people isn't enough. Probably clean windows installations should be used to avoid any oddities.

eddman wrote on 2025-01-21, 00:55:

Yes but not graphics APIs, at least AFAIK. Need to check exactly which DLLs a glide game loads. MS did fix some bugs with newer dll files which might explain the performance differences if the tests are accurate. I still don't see any of this making a DX "bad" though, considering other variables like drivers, etc.

if i install a new DX version, don't touch any drivers and see reduced performance on old software that predated that DX version, it's bad in the same sense that later graphics driver versions are frequently considered bad, because they tend to reduce performance and increase overhead on old CPUs, instead of improving performance. for instance, nvidia often had years of support for their products, but early driver releases are often recommended for best performance.

now, few people would test on such outdated hardware for the time as i did here, but it hints at DX5.0 performing best on that spec, unless the goal is to play some DX6.0-6.1 level titles that wouldn't run well anyway. there is also still the question whether these newer DX versions use up more RAM.

about that emulator: i'm not familiar with it, but i'm not aware of any efforts on low-level emulation of that matrox IS-STORM chip with all the quirks it probably has, and there was also an R3 revision of the chip, while mine is R2. the garbled output was a zoomed in fallout title screen with lines going through it, IIRC.

auron wrote on 2025-01-21, 13:11:

about that emulator: i'm not familiar with it, but i'm not aware of any efforts on low-level emulation of that matrox IS-STORM chip with all the quirks it probably has, and there was also an R3 revision of the chip, while mine is R2. the garbled output was a zoomed in fallout title screen with lines going through it, IIRC.

It's low-level in the sense that it's based on the matrox chip documentation and works on the vbios and driver level. I'm not saying it's an absolute, 100% conclusive result (since there might still be things to change in the emulation code), but simply another data point. It's been quite reliable in a lot of cases though. I'd say check it out.

auron wrote on 2025-01-17, 22:58:

i updated from dx 5.0 to 5.2, not updating any driver and using the 2.16 reference for the voodoo, and saw a decrease in performance - 20.5 fps in turok and 18.6 in PCP. a comprehensive test of DX versions in win95 is something i thought about, but for now it seems pentium machines might be better off just staying on dx5.

Which exact DX versions did you use? Can you check the Version and RC number in the "dxver.inf" files?

P.S. The actual version number of that 2.16 driver is 3.00.00.

auron wrote on 2025-01-19, 13:18:

testing this further, i've had some weird things happen. being on dx 6.1 now, i installed the final 3.01.00 driver. this is after deleting the previous driver .inf in the windows folder and running DCpro 1.5 in safe mode. now with this driver that previously (mostly) worked, nothing will recognize the card and D3D programs freeze, then a bluescreen comes up and warns about not being able to write to C: and probable data loss. i have also tried simply updating from the other driver without prior deinstallation, same result. uninstalling this driver and installing 3.00.01, everything works again.

the difference to before is being on dx6.1 rather than dx5 now,

I tested a V1 & Trio64 setup with the win 95 edition I mentioned before. I installed DX6.1 and then the 3.01.00 Q3 driver. After installing Turok and launching it with "-alldrivers" the Direct3D option was missing, but after I ran dxdiag and then the game, the Direct3D option was back and the game worked.

(EDIT: Actually the option would also appear after I run another Direct3D game first; in this case it was MDK.)

This doesn't seem to have anything to do with DX6 and/or the driver not being compatible.

I don't think constantly installing and uninstalling different drivers is a good idea for testing purposes, especially with older windows that don't really like going back and forth with drivers and such. Having two Direct3D capable cards on one system might also be having adverse effects and causing conflicts.

auron wrote on 2025-01-21, 13:11:

and having had the dx6 voodoo drivers installed at one point. in fact, this dx6 driver is what windows tries to install by default upon every boot, despite no .inf for that being present in the inf/other folder.

Which driver is that? I only know about DX5 Voodoo 1 drivers.

eddman wrote on 2025-01-21, 16:20:

Which exact DX versions did you use? Can you check the Version and RC number in the "dxver.inf" files?

not sure as i've upgraded away from that version. imaging the drive before every change isn't exactly as convenient on real hardware as it would be on an emulator. the files were all from falconfly.

eddman wrote on 2025-01-21, 16:20:

I tested a V1 & Trio64 setup with the win 95 edition I mentioned before. I installed DX6.1 and then the 3.01.00 Q3 driver. After installing Turok and launching it with "-alldrivers" the Direct3D option was missing, but after I ran dxdiag and then the game, the Direct3D option was back and the game worked.

(EDIT: Actually the option would also appear after I run another Direct3D game first; in this case it was MDK.)

This doesn't seem to have anything to do with DX6 and/or the driver not being compatible.

if you read further, i did get D3D to work again with 3.01.00, but never got glide, minigl or opengl to work - only in pandemonium. can you set it to emulate a non-MMX CPU (P54C 90mhz to match mine, ideally) and try that driver again?

eddman wrote on 2025-01-21, 16:20:

I don't think constantly installing and uninstalling different drivers is a good idea for testing purposes, especially with older windows that don't really like going back and forth with drivers and such. Having two Direct3D capable cards on one system might also be having adverse effects and causing conflicts.

well, i basically recreated the experience that such a system might have gone through back in the day. though i had driver cleaner pro 1.5 at my disposal and kept deleting the .inf files, which seems to mitigate the issues a bit. there is something else needed to make it forget about that dx6 included driver though.

eddman wrote on 2025-01-21, 16:20:

Which driver is that? I only know about DX5 Voodoo 1 drivers.

i'm not sure about the version, but it's the only one i've seen that spells it "VooDoo", so i always recognized it by that. it's in the DX6 package, but the DX6.1 package also has one with the same date, apr 8 1998.

looking at my notes, i did a bit of benchmarking of turok2 in glide, and have a result for that driver. the results were all extremely close, averaging around 11.8 FPS, 640x480 this time with the normal texture setting. anyway, i think i must have just let it install over the other one in this particular instance, because i'm not seeing any glide files in those dx6 or 6.1 packages. so it must have simply used the already existing files from the previous driver, along with the control panel. every driver that they shipped with directx or windows seems to be as barebones as possible.

with dx7 they stopped including these drivers and the package size went way down, however in dx8 it went up again, not sure why that is.

auron wrote on 2025-01-21, 19:17:

not sure as i've upgraded away from that version. imaging the drive before every change isn't exactly as convenient on real hardware as it would be on an emulator. the files were all from falconfly.

You don't need to have the installation to check. Just open the 5.0 and 5.2 packages that you used and look for the "dxver.inf" file.

auron wrote on 2025-01-21, 19:17:

if you read further, i did get D3D to work again with 3.01.00, but never got glide, minigl or opengl to work - only in pandemonium. can you set it to emulate a non-MMX CPU (P54C 90mhz to match mine, ideally) and try that driver again?

Tested with P90, DX6.1, 3.01.00 q3; Turok 2 Glide, Quake 2 MiniGL and Unreal Gold Glide work.

What do you use to test proper OpenGL? Quake 2 doesn't work and switches to Software mode, and forcing it in Unreal Gold ends up in a black screen. V1's OGL support is not that great though, so I won't say that's unexpected.
This is actually caused by the games ignoring the 3dfx OpenGL and attempt to use the windows "opengl32.dll" file. I renamed "3dfxogl.dll" to "opengl32.dll", copied it into the game folder and now Quake 2 works with OpenGL. Unreal still doesn't though, which might just be a renderer compatibility issue.

auron wrote on 2025-01-21, 19:17:

well, i basically recreated the experience that such a system might have gone through back in the day. though i had driver cleaner pro 1.5 at my disposal and kept deleting the .inf files, which seems to mitigate the issues a bit. there is something else needed to make it forget about that dx6 included driver though.

What I mean to say is that testing on such a setup would not yield reliable results and you cannot say with certainty DX is the cause. Even today with modern hardware and windows, reviewers tend to use fresh setups to benchmark new hardware or games.

auron wrote on 2025-01-21, 19:17:

i'm not sure about the version, but it's the only one i've seen that spells it "VooDoo", so i always recognized it by that. it's in the DX6 package, but the DX6.1 package also has one with the same date, apr 8 1998.

There's no way that's a D3D6 driver when 3dfx's later 3.x drivers still say DX5 minimum.

auron wrote on 2025-01-21, 19:17:

with dx7 they stopped including these drivers and the package size went way down

There are actually driver-less DX5 and 6 installers. Look for "dx5core.exe", "dx6core.exe" and "dx61core.exe". Also found one for DX3 in the form of "dvideo3.exe". It has the same dlls as DX3, plus a few for DirectVideo.

auron wrote on 2025-01-21, 19:17:

however in dx8 it went up again, not sure why that is.

Just look inside the DX setup package. You'd see that starting with DX8 the previously separate "DirectX Media" files are now included. It also seems to include some controller related files.

eddman wrote on 2025-01-21, 21:06:

You don't need to have the installation to check. Just open the 5.0 and 5.2 packages that you used and look for the "dxver.inf" file.

4.05.00.0155 and 4.05.01.1600.

eddman wrote on 2025-01-21, 21:06:

Tested with P90, DX6.1, 3.01.00 q3; Turok 2 Glide, Quake 2 MiniGL and Unreal Gold Glide work.

What do you use to test proper OpenGL? Quake 2 doesn't work and switches to Software mode, and forcing it in Unreal Gold ends up in a black screen. V1's OGL support is not that great though, so I won't say that's unexpected.
This is actually caused by the games ignoring the 3dfx OpenGL and attempt to use the windows "opengl32.dll" file. I renamed "3dfxogl.dll" to "opengl32.dll", copied it into the game folder and now Quake 2 works with OpenGL. Unreal still doesn't though, which might just be a renderer compatibility issue.

i used the Q2 demo with renaming the ICD, but got a grey screen with the same glide2x error message. the ICD is actually said to be a wrapper to glide3x, so if glide 2x/3x don't work with that driver, it's expected that minigl (said to wrap to glide2x) and the ICD wouldn't work either.

i also found out that pandemonium is a glide1x/glide 2.1.1 game which indeed uses a file from its folder (should be glide.dll IIRC), which explains why this one works regardless of installed driver. by the way, did you get the croc demo to work? and what are your benchmark numbers? i've posted a lot of numbers in this thread along with the used settings.

eddman wrote on 2025-01-21, 21:06:

There's no way that's a D3D6 driver when 3dfx's later 3.x drivers still say DX5 minimum.

i'm not sure what point you are making here, but i didn't state that the driver necessarily had to support D3D6, only that the full DX6 package will try to install this driver. on the contrary i said that the 3.00.01 driver, which is dated later than that DX6 "VooDoo" driver is not able to render turok 2 correctly using the D3D6 renderer option.

auron wrote on 2025-01-22, 19:19:

4.05.00.0155 and 4.05.01.1600.

and the RC number for the 155? Is it RC55 or RC66?

auron wrote on 2025-01-22, 19:19:

the ICD is actually said to be a wrapper to glide3x, so if glide 2x/3x don't work with that driver, it's expected that minigl (said to wrap to glide2x) and the ICD wouldn't work either.

No, an ICD is a proper OpenGL driver and has no connection to Glide (EDIT: It does talk to the card through Glide 3, but it's still a full OGL driver) . MiniGLs are not referred to as ICDs. A 3dfx MiniGL is about 120-140 KB in size and in the file properties it says "MiniGL". A 3dfx ICD is about 1 MB is size and in its properties it says "OpenGL 1.1 Client Driver".

Voodoo 1 driver packages didn't have an ICD until it was added with 3.01.00 Q3; 3dfxOGL.dll, 1.0.0.438. There's an slightly newer 3.01.00 that comes with 3dfxVGL.dll, 1.0.0.439.

auron wrote on 2025-01-22, 19:19:

by the way, did you get the croc demo to work?

It wasn't mentioned, so no. I'll see if I can test it. You can test with 86box yourself though.

auron wrote on 2025-01-22, 19:19:

and what are your benchmark numbers? i've posted a lot of numbers in this thread along with the used settings.

I haven't benched anything and I don't think it'd be useful for comparing to real hardware, since cache and memory behavior isn't emulated. It wouldn't be TOO different but enough to skew the results.

auron wrote on 2025-01-22, 19:19:

i'm not sure what point you are making here, but i didn't state that the driver necessarily had to support D3D6, only that the full DX6 package will try to install this driver. on the contrary i said that the 3.00.01 driver, which is dated later than that DX6 "VooDoo" driver is not able to render turok 2 correctly using the D3D6 renderer option.

Ah, you meant to say "the driver that comes with the DX6 installer".

I haven't tested Turok 2's D3D6 renderer with 3.00, but did with 3.01 and it ends up in a black screen. This could very well be a driver problem. 3dfx wasn't immune to breaking games with later drivers either.

eddman wrote on 2025-01-22, 20:27:

and the RC number for the 155? Is it RC55 or RC66?

it's RC55, so this could mean that the performance downgrade was already introduced in the RC66 build which should be on the OSR 2.5 CD instead of in DX 5.2.

eddman wrote on 2025-01-22, 20:27:

No, an ICD is a proper OpenGL driver and has no connection to Glide. MiniGLs are not referred to as ICDs. A 3dfx MiniGL is about 120-140 KB in size and in the file properties it says "MiniGL". A 3dfx ICD is about 1 MB is size and in its properties it says "OpenGL 1.1 Client Driver".

well, using the 3.01.00 driver it threw a glide related error when renaming the file to opengl32.dll and selecting the regular non-3dfx OGL option in quake2, that's a hint at a glide dependency. it presenting itself to software as a full ICD isn't saying anything about how the driver works internally. and i think my post was clear on distinguishing the minigl and icd, don't know why you seem to think i conflated those.

eddman wrote on 2025-01-22, 20:27:

It wasn't mentioned, so no. I'll see if I can test it. You can test with 86box yourself though.

my bad, i only mentioned the game in other topics as something i was never able to get running on any driver - get a black screen and some directx 5 related error after 30 seconds or so. feel free to test it if you want or not.

Interesting test. Is there a particular reason that such a slow CPU was used? You may see some tiny variations because of changes in driver CPU overhead, but the differences there are going to be minuscule when the system is already barely managing 20fps.

The Pentium 90 was 2 1/2 years old by the time the Voodoo was released, and was ancient with respect to games like Turok (November 1997).

Something at least in the Pentium 133-166 range would be a huge improvement, and realistically even a Pentium 200 was available for months when the Voodoo was released.