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
3dfx driver is still faster in 16bit, since w1.2 is doing 32bit on textures, on 32bit w1.2 ofc faster.
3dfx also doesnt use shared palette extension, so in theory if I ever get 16bit path corrected in w1.2 it should be hitting 90fps+
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.

Initially 3dfx driver was much much faster here. I had a theory that its something to do with palette handling. But it turned out its using SGI_multitexturing extension.
Later engine updated to Arb_multitexuring. Since now its added to w1.2 performance is the same in hl 1.0.
Kinda moot point, since playing with updates is recommended anyway, but atleast its good to know what was happening.

3dfx driver cant run 32bit though, I tried -32bpp, -bpp 32, desktop...

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.

GLQuake
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

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.[/m]
- 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%+
- Implemented legacy extension GL_SGIS_multitexture, but just a wrapper to GL_ARB_multitexture, that superseded it.

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.

I checked it quickly, cus I was playing a game. Dont think the environment variable does what it should.

As an alternative, you can enable Mip map dithering in 3dfx tools, will give a similar effect, just blend between texture passes with dithering.

Dolenc wrote on 2025-10-31, 14:49:

I checked it quickly, cus I was playing a game. Dont think the environment variable does what it should.

As an alternative, you can enable Mip map dithering in 3dfx tools, will give a similar effect, just blend between texture passes with dithering.

This is a nice thing to know, thank you! Negative LOD doesn't look nice in some cases.

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

3dfx Wide driver v1.2 […]
Show full quote

3dfx Wide driver v1.2

New version time!

The attachment IMG_20250811_230445_tigr.jpg is no longer available

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

The attachment Drivers1.png is no longer available

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.

The attachment Drivers2.png is no longer available

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

Hey, Dolenc.
What DirectX do you recommend for your new Driver?

DirectX 7.x, DirectX 8.x or DirectX 9.x

Dont really have a recommendation, I usually use dx7, and if some software needs newer I go to dx9c and stay there, both work fine.

So I had some spare time.

First I tried enabling singlepass trilinear

I tried older MesaFx builds, where it was implemented. Used Half-life, Q2 and Q3 to test. But I cant see it. I can change modes, I just dont see the nice blend between mipmaps.

Tried implementing it, after quite a while wasnt really getting nowhere. So for another day.

Then I looked into Sin 16bit textures

Also wasnt really getting nowhere, core mesas handling of rgb565 and argb4444 would have to be adopted. Dont thing it has anything to do with shared palette or who know... not me at this point 😜

But then I noticed (testing 3dfx icd) it enables "using GL_SGIS_multitexture" to use mutitexturing. Hm...
This extension got superseded by GL_ARB_multitexture. But yea... ofc... Not every game will use the "new" one, and if you dont support the old one, you wont get multitexturing.

So Ive implemented the extension, but just so it wrapps to GL_ARB_multitexture.

And Sin fps went
16bit: 76.5 -> 81.3fps
32bit: 48.2 -> 62.4fps

Nice! Still not as fast, since Its still working with 32bit textures, but better. Should be in the 90+ range with 16bit.
And 32bit flies now.

So I tried Half-life 1.0 and yea, that was also the missing piece here.
fps went
16bit: 94.5 -> 117.4fps
32bit: 55.6 -> 79.3fps

Other games that dont use the extension ofc are not affected.

Kinda pointless for HL, since patches exist.
But it nice to know, there will be improvements if a game requires that extention to enable multitexturing.

So Im happy, another 3dfx-mistery patched, plenty more left to go 😀

Ive updated the driver files on github (you can replace just 3dfxogl.dll in system folder). Also updated the benchmarks to reflect the change.

I had some issues hitting THE blue screen, when shutting down, if switching between many games.
I hope I solved it, added some guards. Updated (yes again 🙁) the files on github.
This will be the last update for v1.2, if something shows... It is what it is...

I looked into one more thing that I was curious about.
S3 texture compression in Q3 titles.

It always said "...ignoring"

Ive checked in code, looks good to me, I have that dxtn.dll also included with the driver.
So Ive googled a bit, its disabled by default in the game (yea makes sense).
It can be enabled with the command" seta r_ext_compressed_textures "1" " (or if version pre v1.25 r_ext_compress_textures).
And it enabled it.

Fps change, tc disabled -> tc enabled
1280x960@16: 75.2 -> 81.4fps
1280x960@32: 44.6 -> 56.5fps

1280x1024@16: 71.5 -> 77.4fps
1280x1024@32: 42.1 -> 53.4fps

1920x1080@16, card oc 193mhz: 52fps (tc enabled)

This topic is a couple of years old, this is the first time I learned about this 😁
It does effect visual quality. So up to the person playing it, if its worth. Alteast its an option. And now Im sure S3tc is really working.

So... I had some future plans, what I would like to do, with a very slow paste.

Im happy how the opengl part of the driver works now.
But! The framebuffer/renderbuffer changes that were introduced in Mesa6.3 were still fairly new. Later version got quite some fixes on this topic.
Also I noticed some occasional short-frame stutters, that get resolved if I set "pending buffers = 0" in the driver settings, so could be my implementation or just core-mesa....

Also that Sin texture thingy...

So my plan was to slowly port only bugfixes from newer Mesa versions, so I would get a really solid base. But there is a lot of them. For example version 6.5.3 is a good year newer than 6.4.2.
Digging through everything and figuring out whats relevant for me and what not would take a bit too much time.

So I went ham! And decided Ill try to make 6.5.3 work.
Besides smaller changes, the main thing was missing extensions (so it looked like to me)

Looked like this, around 120 of them

1opengl32.exp:fake:(.edata+0xb8): undefined reference to `glActiveStencilFaceEXT'  
2opengl32.exp:fake:(.edata+0x110): undefined reference to `glBlendFuncSeparateINGR'
3opengl32.exp:fake:(.edata+0x1dc): undefined reference to `glColorSubTableEXT'
4opengl32.exp:fake:(.edata+0x1ec): undefined reference to `glColorTableParameterfvSGI'
5opengl32.exp:fake:(.edata+0x1f4): undefined reference to `glColorTableParameterivSGI'
6opengl32.exp:fake:(.edata+0x1f8): undefined reference to `glColorTableSGI'

So... I remember seeing this before with a bit new-er version... And fk it, if thats the problem im gonna have to figure it out.
And later version... just from release notes, they all had something fixed, that I would like to have, just so you know what I was seeing.

6.5
- fixed some minor framebuffer object bugs
- fixed a number of thread safety bugs/regressions
- paletted texturing was broken w/ floating point palettes
- lots of assorted framebuffer object bug fixes
6.5.1
- fixed convolution memory leak (bug 7077)
- fixed potential dangling pointer bug in glBindProgram()
6.5.2
- The device driver functions ResizeBuffers and GetBufferSize have been decprecated.
6.5.3
- Much faster software execution of vertex, fragment shaders.
- New vertex buffer object (vbo) infrastructure
- Fixed a number of framebuffer/renderbuffer reference counting bugs
7.x has more ...

So lets go ham and do 7.2.

Well Mesa changed how dispatch table gets generated... I did that, regenerated everything. But no, was fine as was(well didnt hurt, got everything fresh). Aliases would have to be added. I did it, with, again, the help of gpt-coworkers got C-dispatch and ASM working.

Then it compiled! But still crashed when opening a game 🙁.
My friend texstore.c was again causing problems with different texture format handling.
So I went again through their commits, also saw they added rgba4444(Sin issues) in mesa7.4... Maybe they fixed more stuff. So I took all the relevant files and replaced them in my 7.2 build. Also didnt work... But hey, now its MesaFx7.2+ 😜

Some other minor stuff had to be correctted, i flipped one argb format to bgra.. Hey that worked, gues that path is correct! Though had a lot of blue textures 😁
Anyway, some more adaptions were needed. And now it works! Works-ish... Atleast Q3 works, still other texture formats that need corrections.

Heres a video of Quake 2 runnning on MesaFx-7.2 (+)

MesaFx-7.2 First run

I will slowly chip away at it. Not gonna say its gonna go somewhere. But would be nice to have a very mature base. 6.4.2 was good, this one would be even nicer.

I managed to fix the Sin issues, some others and port all the changes from MesaFx-6.4.2.
So now MesaFx-7.2 is complete. Texstore from 7.4, Sin path additions, in general when I was adapting to 7.2 looks decent, also made some of my framebuffer and paletted textures changes cleaner.

If someone is interested, for Sin it needed mesa7.4 texstore.c version and some additions to _mesa_texstore_rgba4444 and _mesa_texstore_rgb565 paths that the game was using.
Git diff part1, part2

Sin went from
(1280x960)
16bit: 81.3->85.2fps
32bit: 62.4->63.4fps

Video of it running

SOF and heretic2 got a mini-fraction fps bump. The rest seems to be pretty much the same.

Preview version can be downloaded here (rename to 3dfxogl.dll and replace the previous one into windows/system folder.

Im gonna take some more time with it, maybe try one more thing with Q3 games, my 21:9 monitor still isnt repaired 🙁, so still waiting for that, to actually play something for longer. But general this is what I was hoping for. So when Im happy I will pack it into v1.3 release.

3dfx Wide driver v1.3

Voodoo4/5 Wide Driver
Version 1.3

**************************************************************************************************************************************
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 7.4.4.0 (OpenGL ICD)
**************************************************************************************************************************************

Release Notes
=======================================================================
Version 1.3
- New OpenGl driver MesaFx-7.4.4
- Improvements that come with core mesa additions and a bit of a code cleanup
- Sin fix when forcing 16bit textures, before the toggle was ignored for this games textures.

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

Whats new is a bumb in mesafx version, its now based of(on?) Mesa7.4.4.
So the jumps were mesa6.2 from 2004, to mesa6.4.2 from 2006, to mesa7.4.4 from 2009.
There are a bunch of internal fixes. In my humble opinion its a very mature base. I dont feel the need to bumb it any further for 3dfx.
(3d)Fx side of the driver ofc could still get some love.

In practice performance is basicly the same as the previous version, with the exception of Sin, that got a few fps.
But all the core fixes, some minor cleanup on my side, makes it a worth while.

Im not making charts again, you get a picture of my notes, ran all the games again on a fresh install
(theres an opsie in Q3 at 16bit, cus I changed the setting the result is for 1280x1024, not 1280x960)

Now its time to just play some games for a while 😀

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

Github Links
3dfx_Wide_driver_98
MesaFx-7.4.4
Glide sourceforge

And ofc theres always something.

Compressed textures needed a small fix. And one minor thing with framebuffer init.
Updated the files. If those 2 people interested 😁 got the yesterdays version, please re-download.