More rambling...

My two-pass Trilinear didnt go so well, it has some random black textures appearing on surfaces. Performance doing multitexturing for base texture + lightmaps, then two passes for trilinear was also lower than single-pass trilinear and no multitexturing (suprised)... So I decided to abandon it.

The issue with having Trilinear, so blending two mips of a texture togethere in one cycle, having only 2 tmus.
Is that you have either multitexturing(combining texture + lightmap in a single pass) OR do Trilinear in single pass. To do both you would need 4 TMUs.

And you cant dinamicly say... Oh game wants Trilinear, np, we disable multitexturing so we have TMUs ready...Because thats not the first thing that a game queries, so you cant do it on the fly. You have to "report" no multitexturing, for the game to switch to multy-pass rendering, and then you can do your trilinear...

So the way I currently have it, there is a toggle!!
By default, it will be the same behavior as now, if Trilinear is requested, fallback to Bilinear filtering.
Or you can Enable Trilinear.

What that does is it reports no multitexturing support, so game switches to multy-pass texturing. And you can enable Trilinear. You still have to set Trilinear (GL_LINEAR_MIPMAP_LINEAR) in-game.
Then you have your two TMUs free to handle blending.
But you have to toggle it back to Disabled if you gonna use Bilinear, since this will keep multitexturing disabled, no matter the filtering.
Thats the best I could figure out how to implement it 😀

Quick performance numbers

Quake 3 1280x1024
Bilinear: 71.6fps
Trilinear toggled in driver(no multi), but not enabled in-game: 55.2fps
Trilinear enabled: 49.3fps

Sin 1280x960
Bilinear: 85.8fps
Trilinear toggled: 74.1fps
Trilinear enabled: 66.3fps

If anyone wants to play around with it, Ive updated the files on github and you can download clone/zip of latest files.

Heres a random picture that happened when I was playing with it

3dfx Wide driver v1.4

Voodoo4/5 Wide Driver
Version 1.4

**************************************************************************************************************************************
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.40407 (Glide sourceForge project)
OpenGL Driver Version: MesaFx 7.4.4.0 (v0.75) (OpenGL ICD)
**************************************************************************************************************************************

Release Notes
=======================================================================
Version 1.4
- Added 1960x840, 2096x900, 2304x960, 2560x1080 (21:9) resolutions.
- Replaced the display timing for 1920x1080 that now works fine with vga and dvi/hdmi.
- Fixed Alt-tab crashing in OpenGL games
- Trilinear texture filtering enabled (with a toggle). Still has to be set in-game.
- Renamed MesaFx texts in 3dfxTools to Opengl, to avoid confusion.
- MiniVdd driver minor fix that enables higher resolutions.
- One Glide fix, that fixes Ignition with 3dfx patch ver3 locking-up after language select.
- Fixed ScreenCapture not working, added DAC gama capture as was in koolsmokys version.
F12 is now set as the Screen capture key by default.
- Previous SOF corrupted textures fix redone in a more propper way. No more texture corruption.

Whats new?

- Trilinear can now be enabled!

The toggle disables multitexturing (well atleast hides its support from the game), so the game switches to multy-pass rendering. This allows us to do Trilinear texture filtering in single-pass.
Its a hardware limitation having only 2 Texture Mapping Units.

Still has to be enabled in-game either in games settings or setting texture filtering to GL_LINEAR_MIPMAP_LINEAR.
Remember to disable it back, if not using Trilinear, since multitexturing stays disabled with this feature enabled, for all filtering modes in OpenGL!

- Alt-tab switching from a game wont crash in OpenGL games anymore.
This also fixes half-life, when returning to menu (lets say, to save a game) and then crashing when trying to resume the game.

- Sdz sent me one minivdd "addition/fix", and that enabled the use of higher resolutions. Some existing (og 3dfx) are now working and Ive added some more 21:9.
2560x1080 has some issues, when combining it with 32bit. But you know... Its a Voodoo 5 running on 2560x1080! Top Image is Half-life running at this resolution!
1920x1080 should also work fine now with both vga and dvi/hdmi.

- Previous SOF texture corruption fix is now redone, to a propper way, while it was rare before that a texture got corrupted, now its completly resolved.
- I noticed screen capture wasnt working correctly, it outputed only transparency, this is now fixed and I ported reading the Gamma from DAC from Koolsmokys glide version.
- There was a bug in glide, that caused the game Ignition to hang, now resolved.

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

Github Links
3dfx_Wide_driver_98
MesaFx-7.4.4
Glide sourceforge

A desire to play older games that are in a 4:3 aspect ratio, on my 21:9 monitor, with the Voodoo 5, is how this journey started.

All glide games only have a list (if any) of 4:3 resolutions to pick from. Direct3d reads whats avaliable in the OS and OpenGl works similar to glide, but patches for games are more common, or they have an ability to override it with a game cvar or .cfg parameter.
The way the Wide driver changes this (in the Glide API) is by replacing the resolution requested by the game, with the one selected in the driver's settings.

Unreal engine games, are fine with this, they request whatever they request, its checked if its valid (in this case what we provided) and prepare the rendering perspective with this - our - resolution. Success!.
But this applies only to unreal engine games and while I havent tested those few glide3 games out there, Im guessing they would work the same.

But the majority of glide games, have there own list of supported resolutions and decision-making how to render baked in the game itself, or for statically-linked games glide api already in the game.
So using the Wide drivers override, will still create a selected-size framebuffer, but the game will only render in its own resolution.

This looks like this, 2560x1080 framebuffer and in the top-left corner a 640x480 rendering of the game.

This is something I accepted as a limitation, I dont have the knowledge to correct this, would require disassembling game files, reading hex/asm, finding where the game does this, changing it, everything can go wrong, ui scaling will be done differently that 3d, fov some games mix fake 3d with 2d, fov changes or moving the camera distance and so on...
And on the plus side, the collection of games in all 3 apis, that can now do this, is already so big, Im not sure I will have the time to play everything I want to play in my lifetime.

But there are, not many, but some games I would really like to see this working and playing them. Gta 1, gta 2, Turok, Tomb raider 1, would be on the list.

So... why go to sleep if you can converse with LLM! While I definitely share some of the llm-hate, but it really is amazing what you can do with it.
The session was really something out of a fantasy sci-fi novel, lots of guessing, reading game files, dumping memory, changing games memory right from the driver, calculating new transforms...

And, well today (who needs sleep anyway), I got Gta 2 somewhat working, replacing the resolution, extending the viewport and moving the camera. UI is still in 4:3 place, but...

Just amazing!!! On 2560x1080!!!! And the patch is done in the driver, in glide2x wrapper that Im using. This, for me, breaks the mental barrier of "ah so it can be done".

Well.. it works 😀

Gta2 is fine, not touching the main menu, but in-game, unless theres more ui text I missed, looks good.

Turok was fairly easy now that I have a bit of a template. Still need to fix the ui part a bit.

Dos-Glide games would take a bit more work (not that this was peanuts) since it reads the display timings either from glide2x.ovl or cards bios. Would need to pre-prepare the environment. Changing just the resolution is fairly simple. Additionally would need to calculate all the extra resolutions, which require lots of guesswork and testing, maybe for some other time.

I will try a few more games, so I have a bit more example code, for the future, if I ever need it 😀

Ignition

Spent most of the time fixing the 2d UI elements flickering over time, nothing to do with the aspect patching.
Didnt find a propper solution, just that it does that if x86/asm optimizations are used for the glide driver, and it works if only C path is used, so this game will have an exception and only use C path.

The game still crashes to desktop after completing a race and trying to start another, atleast on my system. Cant fixem all.

MDK

This one will be interesting 😀