Before I forget everything, that was happening for the last 3 months 😁. And to make it more readable I will split it into a couple of posts.

To get started... I wanted to do this for a long time, when using the first version of the driver, manly was fine, but I did notice some issues with it over time. As mentioned before, Sin wasnt working, I used WickedGl. Daikatana had some random lockups, Heretic II had lockups, Voyager didnt work, SOF ofc completly out of the question. Oni wasnt working (and I know I played it once on MesaFx, cus I had a video of it, but it wouldnt work and so on... OpenGl felts like unfinished business to me, was lurking in my mind that one day when I had time Im gonna look into it.

I tried a couple of times and didnt get anywhere.
There are no sources(or I dont have them) for the 3dfx ICD, so Mesa is the only option, because I added those additional resolutions, so I can play on my 21:9 monitor.
You can somewhat "hack" your way around it, since I also added that resolution force to glide, and WickedGl will work fine with the forced resolution. Pre-built MesaFx also, but then you dont have the ability to go to 16bi px for games that default to 32bit in Mesa, which are Quake engine games. And WickedGL is hit or miss with image quality, also performance.

MesaFx. Is a combination of two parts. Mesa3d, an open OpenGL api implementation (thats still in active development and is currently at ver 25.2.)
And then you can write a vendor specific implementation that uses it and communicates with the hardware. As Daniel Borca(among others) did, so Mesa for 3dfx... MesaFX.

The issue was the last updated version, that you can build, is MesaFx6.2. There is a built version 6.3, but code was never updated.
And going from 6.2->6.3 there were some internal changes, mainly the framebuffer/renderbuffer handling.

So they needed to be adapted. They were in the dri/linux driver. But that can server as a refference, the way it accesses hardware in linux is a bit different, the structure is also a lot different. So you have the glide version and dri version.

And I saw with the prebuilt 6.3 that Sin now works, that didnt in the previous version. So... Even that... Worth doing! Maybe solves some other problems.

So with the advancement of our future overloards help (mainly Claude and chatGpt) and using dri driver as a refference... and a lot of time 😁... I manage to adapt the changes for glide. Its all on github and will put all the link again in a later post. Not really that interesting to discuss. But nice to have!

Buffer changes got solved, paletted textures also broke, core-mesa changed table type handling from GL_UNSIGNED_BYTE to GL_FLOAT (just one sentence, but took a while to figure out ).

And that was it. Thats all I wanted to do. Driver worked, probably buffers could use some more checking, probably forgot something in initialization. Sin worked!

Well then it started 😁....
- Testing the buffers, there were some incorrectness with far mipmaps. Ofc I might have done something wrong, but no(well)... Glide that I was using didnt work all that well with MesaFx. So I switched to the one from the sourcforge glide project. Which had its own problems, the first time I used it. But now it worked fine.
Mipmaps looked correct. I remember someone once told me forcing 32bit for glide doesnt work in this glide3x.dll. And I removed one check from it, that expect the value is either 16 or 32. But you can have it in the driver ini as whatever or 32, which is fine, I have it like this too. So that worked.
Probably most of the problems I had with Wide driver v1.1 came from this pairing of MesaFx and previous glide.
- Oni still didnt work. Later found out theres a cpu test for supported instruction sets. Followed by os test. And os test crashes the game, I checked how this was handled, they removed the os test (were targeting windows anyway), so I did the same, Oni worked!
- Then one issue with mesa was that it only ran on 60hz refresh rate. So I added that, now you can use 3dfx tools setting and it will try to get the highest one.
This sound small... But it really makes a huge change to feel how responsive the game feel. It finally feels like it does on a modern machine, nice and snappy. Not, yea Im still on win98.
- then I tried Soldier of fortune ...

Soldier of fortune

This is where it all started... Some textures missing, some incorrect, some correct.

If you google soldier of fortune texture problems, you will get identical images. Since its still a Mesa problem. Well its this games problem...

And this is a video of it running
MesaFx Soldier of fortune fun

After more googling, I found out, that you can open the games console, during new level load and all the textures will load correctly! Success atleast I had something to get me started.
I couldnt solve it, but later I also found a console command set gl_gentextures_broken "1", that fixed the texture problem!
After a lot of ping-pong with ai chats I was getting nowhere.

So I did a an opengl trace what commands is the game even sending and the difference betwen standard and gentextures_broken.
Cleaned the log, so I only got texture operations.

And theres the problem. It keeps trying to rebind textures. Something goes wrong and it gets completly out of wack.
Basicly (part1) when textures are uploaded into memory it uses mesas glGenTextures() to assign ids.
When you do gl_gentextures_broken "1", the game handles ids.

Basicly(part2) this game does texture loading so blazing fast, cpu/memory side (so mesa) and hardware side (whats actually in the card) get out of sync.
And its want to rebind textures to IDs that were already deleted or somethign else is there or ...(simplified)

Or as chatgpt would say, after weeks of trying to figure it out.
"The underlying bug is in Mesa’s core texture object lifecycle: IDs are recycled too early, and driver-specific data isn’t cleared, causing corruption. The MesaFX driver code is otherwise correct — it’s just exposed by Mesa’s mismanagement."

So I added a bit of padding for ids.

This is not really a propper fix. But seem to work. So for now, it stays and if I ever get smarter, Ill do it the propper way. (I tried more times 😁).
It can still happen that some textures get corrupted on new level loads. But, you need to get lucky.

Then when the textures were fixed. I noticed. The stutter!!!
Oh jesus. It can be seen from the video. I thought the texture corruption is whats causing the problem. But no.

This game is really good to test how the driver handles textures, since it trashes the tmus(no sarcasm, it really is).
I got like 40-50fps. But the problem were the stutter, fps was high, but then it crashed, then high again, then crashed when shooting the weapon.

Then I tried running on single TMU. 60fps! How 😁...
So the issue was how load was spreading between both TMUs when using multitexturing. Ofc handling just one is easy.

So I randomly tried different thing:
- Bunch of check to avoid trashing
- Deffered texture uppload to next frames, if we already did a lot
- tmu affinity and pinning
- choosing best tmu
- tmu state caching
- streaming detection
- bla bla

Anyway at one point everything connected and the performance was great, was getting 70fps! But there was some texture corruption.
So I reverted and slowly implemented one by one... And got it working without any strange texture corruption!

Wohooo....
Then I opened quake 2 and fk, menu all corrupted, intro video missing... 😁
Also main menu being smudged can be seen on that Sof running at 1080p video, I posted on the previous page.

Ok another go. Ive done this a couple of times, so I got a feel for what worked.
Im just gonna post a picture, bunch of reverts, than slow implementation and testing everything.

I ended with 69.x fps. I could have done a bit more, but this works and the code is kept simpl. For another 1fps would be way to complex if I ever want to figure it out what it does.

So there we go SOF in great shape! And it really is a good test to see if your TMU mannagement is good.

Benchmarks

All done with a fresh install (have an image prepared).
All games prepared before, same settings.

Resolution for all 1280x960. Since now I know refresh rate also affects fps, all set on 60hz.
To get 3dfx not to blank my screen at that resolution, I used that registry timing fix.
Left all settings as they come, except for vsync.

To switch from 32bit to 16bit on 3dfx drivers I changed the desktop colors.
For Wide drivers I used that Force 16bit toggle.
If a game had a 16/32 I changed that too.

NOTE
Just to mention it. Glide3x.dll speed also affects fps, since OpenGL uses parts of it to talk to the hardware.
The fastest is in wide1.1 driver(koolsmoky), wide1.2 comes close about 0.2fps difference in q3(sourceforge glide), original 3dfx is the slowest.
Why am I mentioning this? While this is a AtoBtoC comparison of drivers. For example if you see a result between 3dfx and wide driver even. That means, just the OpenGl driver is still faster on 3dfx and if you would pair it with a faster glide it would show.

PART1
16bit

32bit

MDK2
Nothing special.

Quake 1 - QuakeSpasm 0.85.9
This is the one I play, since it works fine on win98.
3dfx couldnt start it. Difference between wide drivers. A good chunk!

Quake 2
3dfx still fastest, but its getting close in 16bit! And wide1.2 takes it in 32bit!

Quake 3
All basicly the same. But what I said in that note, 3dfx would be the fastest if paired with a faster glide3x.dll. And thats also why w1.1 is faster than w1.2.

Sin
Yea here 3dfx is much faster, since w1.2 is doing 32bit on textures, but even on 32bit mode it gets wooped.
And it is 32bit in 3dfx case, cus you can see right away with the contrast of main menu.
w1.1 cant start Sin.

PART2
16bit

32bit

Soldier of fortune
Since this one was my main focus, ofc its faster here.
Its not huge. But Im very happy with it 😀

Half-life
Now this is version 1.0.
I used this one without patches, because I used that blowout.dm demo to test, I saw it mentioned a couple of times, that people used to test with it.
And it doesnt work on the latest patch.
Now here 3dfx driver murders mesa-based drivers in 16bit. Cant run 32bit though, I tried -32bpp, -bpp 32, desktop...
My explanation is this. I bet its using that palette extension 😁, and they removed it in later patches, as further on Opposing force will show. That one uses a later version of the engine. I havent tested it with the latest patch, since that would require me to record a new demo.dm an redo all 3 testruns. But Im guessing it would act as opposing force does.

Im more suprised w1.2 doesnt gain anything compared to w1.1
This one stings a bit....

HL: Opposing force (demo)
Same as I used for other benchmarks.
Small improvement over w1.1, but the main thing, faster than og driver 😜

Heretic 2
3dfx the fastest, though its close.
On w1.1 far mipmaps can sometimes show pink color.

Hexen 2
Latest patch, but og, not sourceport.
Wide drivers a bit faster than 3dfx.
So this is a modified q1 engine.

I wanted to include GLQuake as quake 1. But I cant get the damn thing to change resolution on all 3. I tried -width -heigh -bpp... but ...
So here are just the fps at default 640x480 at 16bit

GLQuake
3dfx 10401b: 276,9
Wide Driver v1.1: 294,7
Wide Driver v1.2: 294,7

Conclusion time!
I think its a nice improvement over w1.1. Basicly faster everywhere. And the main thing is. Its being put together as a driver a bit more correctly. 3dfxogl.dll only as ICD, glide pairing is better. Some other stuff that I fixed.
Performance is good, still 3dfx last driver is faste in some cases. Og driver is good. Just I cant add anything to it 😀

Im very happy how it turned out. Was really a bit of an unfinished buiseness for me, since w1.1 had problems with quake2 engine games, so the focus was there.

Im never making charts again in this life 😀

3dfx Wide driver v1.2

New version time!

Voodoo4/5 Wide Driver
Version 1.2

**************************************************************************************************************************************
Voodoo Series Driver Kit: 1.0
Voodoo Series Win9x 2D/3D Display Drivers: 4.13.01.0028
Glide 2.X Driver: 1.00.01.0106 (glide2->glide3 wrapper)
Glide 3.X Driver: 3.10.00.40406 (Glide sourceForge project)
OpenGL Driver Version: MesaFx 6.4.2.0 (OpenGL ICD)
**************************************************************************************************************************************

Release Notes
=======================================================================
Version 1.2
- Different Glide3 driver 3.10.00.40406 (based on sourceForge development version)
- But now force 32bit in glide works correctly
- Adjusted 2pxpc and analogSli, 1920x1080 and 1600x1200 can now run in 32bit without "sli pink lines".
- New OpenGl driver MesaFx-6.4.2
- Adjusted for the new framebuffer/renderbuffer and texture format changes.
- the only openGl ICD is now MesaFx in 3dfxogl.dll
- Added Refresh Rate variable to 3dfx tools, that will set the highest-avaliable refresh rate for glide, DirectX and OpenGl games
- Quake2 engine games removal of "GL_POINT_SMOOTH", increases fps by about 10%+
- Changed some default driver settings, defaulted to 60hz refresh rate(lcd-s).
- MesaFx force 16bit px and 16bit textures is now disable by default
- Z-precision now defaults to Fast
- d3d Guardband Clipping enabled by default
- added Glide Guardband Clipping toggle, enabled by default
- 3dfx splash disabled by default
- Added agp command fifo
- Games that didnt work in the previous version, but now do:
- Sin
- Oni
- Star Trek Voyager Elite Force
- Heretic II (had random lock-ups)
- Soldier of fortune

Whats known to be broken:
- Alt-tab
- App tab residue after the game is closed
- Trilinear single pass filtering is disabled on napalm, fallback to GL_LINEAR_MIPMAP_NEAREST

Refresh rate toggle

This is new. It will work on d3d, glide and opengl.
If you are changing the refresh rate of the video adapter in windows settings, this will reset and you will have to set it again in 3dfx tools.

Higher refresh rate comes with a (small) performance penalty.
- q3 went from 71fps(60hz) to 69fps(100hz)
- ut went from 44fps(60hz) to 43fps(100hz)

It will try to get the highest refresh rate. So if you have it set at 144hz and at certain resolution its max 85hz, it will use 85hz.
If another resolution has 120hz, it will use that. If you max out at 60hz, it will use that.
Default is 60hz.

Overrides
Now disabled by default. Remember MesaFx will default games to 32bit if the game doesnt specificly sets it, most Quake 2 engine games! So its usefull there if you want to play in 16bit.

Happy gaming!

You can get the driver here
3dfx Wide driver v1.2

Github Links
3dfx_Wide_driver_98
MesaFX-6.4.2
Glide sourceforge

Well done!

Dolenc wrote on 2025-10-29, 22:13:

- Trilinear single pass filtering is disabled on napalm, fallback to GL_LINEAR_MIPMAP_NEAREST

What are the chances to make this feature switchable by a user?

You can do it already if you set an environment variable "set MESA_FX_IGNORE_CMBEXT=1".

This will disable some multitexturing operations, and allow single-pass trilinear filtering.

I was thinking how to handle this in the future, since I would also like to have, if I set it to trilinear, then give mi trilinear game!...
But the thing is, since 3dfx can also do that "Level of detail bias", that will produce nicer results, it went on the future ToDo list.