I dont see a PM option, so @SFFT if you are still here and up for a driver refresh. Its just glide and opengl.

Here are the prebuilt files, I describe additions in "Ini additions.txt". In readme you can see changes.
In short:
- glide2x to glide3x wrapper
- glide3x from laster sourceforge dev branch source and with added changes
- mesaFx 6.2(ish) for openGl icd with added changes

Think I added all the files needed. Pass is sfft, link expires in 30days.
https://easyupload.io/qyczd2

If you want sources and build it yourself, or just the changes, ofc you can get them too.

Yea she is awaiting to be exploited... If I can get 200mhz I would be happy, if I could get a bigger di... I mean score in 3dmark01, so higher than the current wr holder, that we wont mention here! that would be even better, he has it at 215mhz on a crappy green voodoo and we all know red is a faster color . For him its a win-win, either he holds the record or his card.

This pentium I have is better, its one of the last ones(wolfdale), 3.2ghz (vs 3ghz on that crappy extreme editions ) and 800fsb, that leaves room if you want higher and you dont have dividers. Win98 is single core anyway. Think that I saw around 3.7-3.8ghz with this mb I have, that isnt oc friendly, if it is goes waaaay past 4ghz, but thats around the same as what the wr record holder - that shal not be named! had.

But besides breaking the wr of the person that - shall not be named! Dont think voodoo5 scales much more past a cetrain point. I see I get same numbers as phils computer lab, with a p3 1.1ghz... So you know, plenty fast. Does scale with every mhz you get out of the card.

Did made a difference with radeon x850xt. Athlon64 240fps, cl2 ram 270fps, this pentium 400fps+, q3 fullHd all maxed, if I havent pressed demo myself wouldnt belive it that a64 bottlenecks it so much.

Thanks, I was eying that bios, just wasnt sure if it will work for 2x64mb, Ill ask Anthony, might know.
I do want more muhaherc!

Quake2 resolution list is from v3.24 patch, doesnt read what the card has avaliable, they are just avaliable to pick.

This is what the Voodoo has at its disposal, so yea 2048x1536 is a valid resolution, think its just not in windows, the timing is in .ini though.

Do you see 1080p anywhere? Yea, was never included in glide, just as a timing for desktop.


#define GR_RESOLUTION_320x200   0x0
#define GR_RESOLUTION_320x240   0x1
#define GR_RESOLUTION_400x256   0x2
#define GR_RESOLUTION_512x384   0x3
#define GR_RESOLUTION_640x200   0x4
#define GR_RESOLUTION_640x350   0x5
#define GR_RESOLUTION_640x400   0x6
#define GR_RESOLUTION_640x480   0x7
#define GR_RESOLUTION_800x600   0x8
#define GR_RESOLUTION_960x720   0x9
#define GR_RESOLUTION_856x480   0xa
#define GR_RESOLUTION_512x256   0xb <- Glide.dll
#define GR_RESOLUTION_1024x768  0xC
#define GR_RESOLUTION_1280x1024 0xD
#define GR_RESOLUTION_1600x1200 0xE
#define GR_RESOLUTION_400x300   0xF  <- Glide2x All voodoos
#define GR_RESOLUTION_1152x864  0x10
#define GR_RESOLUTION_1280x960  0x11
#define GR_RESOLUTION_1600x1024 0x12
#define GR_RESOLUTION_1792x1344 0x13
#define GR_RESOLUTION_1856x1392 0x14
#define GR_RESOLUTION_1920x1440 0x15
#define GR_RESOLUTION_2048x1536 0x16
#define GR_RESOLUTION_2048x2048 0x17 <- Glide3x Vsa based voodoos, previous max
/* Extended */
#define GR_RESOLUTION_1280x720  0x18 /* 16:9 */
#define GR_RESOLUTION_1280x800  0x19 /* 16:10 */
#define GR_RESOLUTION_1360x768  0x1A /* 16:9 */
#define GR_RESOLUTION_1440x900  0x1B /* 16:10 */
#define GR_RESOLUTION_1600x900 0x1C /* 16:9 */
#define GR_RESOLUTION_1680x720 0x1D /* 21:9 */
#define GR_RESOLUTION_1680x1050 0x1E /* 16:10 */
#define GR_RESOLUTION_1792x768 0x1F /* 21:9 */
#define GR_RESOLUTION_1920x800 0x20 /* 21:9 */
#define GR_RESOLUTION_1920x1080 0x21 /* 16:9 */
#define GR_RESOLUTION_1920x1200 0x22 /* 16:10 */
#define GR_RESOLUTION_3840x2160 0x23 /* just for a high max, still invalid */


About more information and including links, its like this, those that will want it, will find it, for others, not important, dont have to make everything easy

Someone in the yt comments suggested glide has some additional options enabled by default in UT, thats why its a bit slower than opengl and d3d, that dont. So I checked it, and yea, get about the same result now as d3d in my favorite 1920x800. Its still a tad slower, but rendering is more accurate, opengl and d3d might "leave" some things out.
https://youtu.be/Ro2RA5RH9ww

Before I bought the card, I kinda knew what to expect, bought one geforce2 to get a rough idea, downgrade in everyway from radeon x850xt I was using before, but I said to myself... Well, if atleast I could get 1080p for q2 engine games, that would be ok. Didnt know 21:9 window is just around the corner!

There are some "special tweaks" in the .ini files of other drivers. What I could find out is they were taken from Tomb raider optimizations. Didnt check if they are even present in the driver anymore. Did test them...




1280x1024  disabled  allEnabled
Unreal:    74.03     74.09
UnrealT:   52.92     52.78
Quake2:    90.4      90.4
Quake3:    69.6      69.6
Mdk2:      81.88     81.93
Drakan:    61.05     61.04


I will leave them in the file, but comment them out, so they are not installed. If someone, for whatever reason wants them, just remove the comments before installing the driver.

And now the important stuff. The hard-hitting question, is Voodoo 5 a 1080p card?
https://youtu.be/HDqk7M5vUbU

Was testing a bit, theres one major issue still present, that registry path on win98. And some smaller kinks, that I have to test a bit more, to see how they affect things. Asked Sezero if he can help me with the reg problem, cus clearly I wont figure it out. For testing its hardcoded in.

Anyway, another monologue. I was testing today a bit, yay half-life finally works again. A bit slow, enable 16bit textures, better, still too slow, enable 16bit rend, runs like a dream.

Finally everything clicked. I played around some more.

Then I test quake2. 58fps. Wtf, I know I played on 1080p before and it ran somewhat fine, what is this now again, wheres my 80fps. Noe, messed up something again, you "fix" one thing you break 3 others. Tried some more stuff... Then I look at the setting, I just forgot its still at 1920x1080, dumbass...

Anyway heres a test driver package if anyone wanna play around, for win98:
https://easyupload.io/e4cq3h (link valid for 7 days)

If its not a clean system, check the registry before installation, anything under "HKEY_LOCAL_MACHINESystemCurrentControlSetServicesClassDisplay ..." delete it. Its hardcoded to Display\0000.

Extract, read readme.txt/Extra notes, then run ->setup.exe<-



For winXp, if you wanna make one, take the driver of your choosing(I suggest sfft 1.9 since that has the most advanced d3d), install it, then put the files "3dfxOGL.dll, opengl32dll, glide2x.dll, glide3x.dll" into your win/system32 folder.

After, you will see in the driver installation folder, theres one called "Extra/Win2kXp".
Run
- XP_AddMesaFxOverride_3dfxTools.reg
- XP_AddOverrideResolution_3dfxTools.reg
- And under timings folder the one you want (can be all)
- Install 3dfxtools if not present

I was wondering why da **** the driver defaults the refreshRate to 75hz always in games, even though I have it set higher in windows.

Now Im prepping the .ini and there it is


Also added 144hz to glide and opengl. But will see how win98 behaves, 100 or 120 is more common value in games.
All those .ini "tweaks" when people were adding 200hz, dont do anything cus glide and oGl have there own checks and cap at 120hz.

Dont think 128mb helps in this game, its more for testing, same as oc, if something is wrong it will show early.

Resolution override for glide is a "hack" since games themselfs are limited. Its only for glide, even that probably wont work on most games.
For openGl, there is no override, even if enabled, its ignored.

For quake 2 it was set in autoexec.conf, thats where it is in this case and why it says custom. 1920x800 isnt a common resolution, usualy first 21:9 starts at 2560x1080, but thats a bit too much to ask out of the poor voodoo.

MesaFx can use environment variables to configure it somewhat, one of them is force 16bit textures. This one is a must, since if the game specificly doesnt have a 16/32bit toggle, like quake 3 for example, it will default to 32bit. Doesnt matter that you have your color, with resolution, set at 16bit. And there are lots of games like that, even q2 and mdk2 that I usualy test with.

The problem with environment variables is that they just arent that user friendly. They do work everywhere, I guess thats what mesa was going for.

Theres one for pixel format too, could be that it just need a bit of a fixup somewhere, it caused problem in most games. So I done it differently. And after playing around somemore might even have to change it, half-life had problems..

ciacara, good that you wanna keep the spirits up, but theres really no need. No more gj, well done, I have my grandma for that.
I wanted to do some more knowledge sharing here, atleast where to find stuff and build it, but since I can spend time looking at code or writing posts here, had to pick one , maybe when its done.

Small video update
(forgot I was testing if color controls work, so image its a bit brighter that what it should be)

https://youtu.be/zEqEUeKycqs

Mesa texture override was already present in mesaFx, I just added the control to 3dfxtools and connected everything.
For 16bit pixel mode, I did a crappy, take-this-values! solution, not proud, will revisit eventually, but should work.
Theres one environment pixel format override present in mesafx, but besides crashing in most games, also has no aa.

So what I wanted to add is done.
Now just to slowly sort out the kinks in glide...

It little things like this...



Somewhere in the process WIN32 was changed to __WIN32__, but missed this one, opsie.... Then I wonder why it doesnt work if all looks good .

One down, many more to go!

Would be great if it was bugfree, but its not...

In mid 2007 ks did a bunch of changes for xp driver release, this one:
https://www.3dfxzone.it/enboard/topic.asp?TOPIC_ID=6585&whichpage=1

Thats kinda where glide3 is in sourceforge dev branch that Im using, since he adds his changes to the project. While its written to work on all supported os. Guess no one tested win98, happens.

Current status would be:
- Reading registry path broken on win98, so 3dfx tools not working, xp works fine, fixed, but will revisit (I may have just hardcoded the correct path, or not, wont tell....)
- Now that win98 3dfx tools works, it crashes with 64MB per chip mode, could be that it just needs an update to environment variables?, In progress
- Add isOpenGl for glide override, since it was changed, in progress
- Add 2 more envir variables that control mesaFx and its rendering, so user can override 32bit, ToDo
- Mora crap can show itself on win98... ToDo
- alt+tab for mesa lock, ToDo

Well cloned the latest source from dev branch of sourceforge glide project.

Now for a bit of a rant. Thats one of the reasons no one does anything anymore. **** is always broken. Always!
You clone, read the readme file, quickly check makefiles, build....

And you are greeted with a barrage of errors



Couple of hours of fixing, removing cvs autogenerated crap, fixing makefiles (I dont think anyone tested windows), luckily Sezeros github helped a lot, so I could just replace some files, throwing the mouse at the wall a couple of times, and a build comes out.

And I have red tinting again, ****....

Ok Ill do it without Sezeros fixes, he atleast tried to make the process a bit easier, good on you man.

Error by error, code errors, makefile errors... And a build comes out. And red tint again, fuuu.....
But since I was looking at this **** for so long, I kinda had an idea whats wrong, change small portion of code for windows compiler to how linux handles it. And there we go. Try to build with all the goodies 3dnows and sse745.. Bam. Works, file size for once looks the same as other prebuilds, no tint, everything works (ok lets not get ahead of ourselfs)..

By the time I got to bed, birds were starting to make noises, if I didnt love my mouse I would throw it at them...

After some more exploring I "figured out" whats going on with mesafx and quake2, that was the reason I was looking into 3dfx icd, cus mesa did quite poorly there. And they are many q2 engine games that are of interest to me(heretic2 on the list!). For me q2 should be around the 80fps mark, else theres noticable input lag, hard for me to play the game. Its the same even for q2 rtx, just couldnt play it on 60fps, had to change settings with 80fps target, then Im happy.

As it turns out it defaults to 32bit(24bit for depth buffer) rendering and 32bit textures, so that explains the low(er) numbers.
Nicely explains the results I got from testing drivers, all that are very low in this game use mesa. The rest use 3dfx icd.



Well you have control over it, somewhat. You can force 16textures with environment variable MESA_FX_IGNORE_TEXFMT=1, theres one for 16bit rendering that didnt worked for me, so I just forced it in code and there we go.

Initial numbers in 1920x800 in q2 under xp were

Default:                53.1fps
16bit text:             58.7fps
16bit rend, 32bit text: 70.6fps
16 bit rend and text:   78fps
So mesa is back, and **** that 3dfx opengl icd doctorate.
I will have to add some way of user adjustable option, to do this in the control panel.

-------------------------------------------------------------------------------------------

Next step was testing some glide prebuilds I have with my build of mesafx. I kinda bounce between them now, need to pick "the best" to stick with it and work on it.
Sources avaliable to me:
- sourceforge 30303
- sourceforge 40404
- koolsmoky 2610

But but but why dont you test glide games if..? For glide Im sure most will be fine, its more of mesa+glide combo and if its gona be slow/fast here it will be the same just for glide.

ks10Clean is my build of koolsmoky 2610 and mysf4040 is my build of sezeros- sourceforge 40404 source.
The rest are prebuilds taken either from driver packs or websites.
My build of mesafx was used and glide3x.dll were being replaced.

Quick tests

//WinXp - am3.1r1 - MesaFx 6.2
Settings dont matter, same for all. System as dirty as it gets, still, same for all again.

[b]Quake 3 v1.32vogons - 1280x1024[/b]
2605_am29/raziel: 70.7
2610_3dhq:        70.6fps
2702_sfft59:      68.7fps
2704_sfft1_9:     70.6fps
4040_amr11:       70.4fps
ks10Clean:        70.6fps
sf3030:           68.3fps (checked)
mysf4040:         70.4fps - red tint
40405ks:          Could not load opengl

[b]Quake 3 v1.32vogons - 1600x1200[/b]
2605_am29/raziel: 48.8fps
2610_3dhq:        48.8fps
2702_sfft59:      48.8fps
2704_sfft1_9:     48.8fps
4040_amr11:       48.3fps
ks10Clean:        48.8fps
sf3030:           46.3fps (not a typo)
mysf4040:         48.3fps - red tint
40405ks:          Could not load opengl


[b]Quake 2 v3.24 - 1280x1024[/b](yes this one)
2605_am29/raziel: 90.7fps
2610_3dhq:        90.8fps
2702_sfft59:      90.8fps
2704_sfft1_9:     90.8fps
4040_amr11:       90.9fps
ks10Clean:        90.8fps
sf3030:           88.7fps
mysf4040:         90.8fps

[b]Quake 2 v3.24 - 1600x1200[/b]
2605_am29/raziel: 66.4fps
2610_3dhq:        66.5fps
2702_sfft59:      66.5fps
2704_sfft1_9:     66.5fps
4040_amr11:       66.5fps
ks10Clean:        66.5fps
sf3030:           63.8fps
mysf4040:         66.5fps


[b]Mdk2 demo v0.9 1280x1024[/b]
2605_am29/raziel: 82.79fps
2610_3dhq:        82.89fps
2702_sfft59:      79.5fps
2704_sfft1_9:     82.88fps
4040_amr11:       82.89fps
ks10Clean:        82.89fps
sf3030:           80.05fps
mysf4040:         82.9fps (red tint)

[b]Mdk2 demo v0.9 1600x1200[/b]
2605_am29/raziel: 56.09fps
2610_3dhq:        56.12fps
2702_sfft59:      55.01fps
2704_sfft1_9:     56.12fps
4040_amr11:       56.11fps
ks10Clean:        56.12fps
sf3030:           52.89fps
mysf4040:         56.13fps (red tint)


Funny how visual people are, I do the tests and write down the results, but dont really "know" what they tell, untill I look at it in a nicely assembled form, chart would be even nicer

Not much to say is it. Cant really go right or wrong.
sf3030 is out. Comes down to ks10 and 4040.
4040 is newer, sezero still does cleanup and small tweaks on it, on his github, think he made an opsie somewhere so thats why the red tint, or on my compilation side something broke.

Will try the one from dev branch from the cvs if I can clone that. If not, I wont be bothered much, use the koolsmoky one and slowly port sourceforge changes, where I feel they made things better. They are quite different in some places and the way ks did it is sometimes better, other times the way sourceforge team did it....

This will be a bit longer one, maybe someone in the future gets something out of it.

How I approach looking at the code and getting my bearings.

First small glide explanation, how it inits itself. If anyone is looking for atleast some documentation, theres a "glide 3.0 programming guide" and "Glide 3.0 Reference Manual" both useful (for the api, not a driver refference) that you can get here:
http://falconfly.3dfx.pl/reference.htm

This:
- 3Dfx Glide version 3.0 Rasterization Library    
- 3dfx Glide2 Linux SDK & Sourcecode    
- 3dfx Glide3 Linux SDK & Sourcecode

This is how it initializes

- grGlideInit() ... Sets up glide library. This has to be called first. Finds if you have a 3dfx card, allocate mem, inits variables...
- grSstSelect() ... This will make your card(s) current or active.
- grSstWinOpen() ... Thats my baby, since Im dealing with resolutions, it will prepare the framebuffer.

Whats sent to it:

GrContext_t grSstWinOpen(
 FxU32 hWin,
[b]  GrScreenResolution_t res,[/b]
 GrScreenRefresh_t ref,
 GrColorFormat_t cFormat,
 GrOriginLocation_t org_loc,
 int num_buffers,
 int num_aux_buffers
)


So here the resolution is set (sort of it goes through more checks). But broadly speaking, thats what Im looking for.
And since 3dfx gl icd calls glide then, that would be the one to catch.

THE PROBLEM
So now to the actual "problem". OpengGl and how to find out how it handles resolutions.

I cant see inside the source, since I dont have it, I can however intercept calls, override the function with my additions, and that should work, I guess, kinda, I hope, maybe...

THE IDEA
So I would have to figure out how the method that handles resolutions is called, before it sends parameters to glide.
If I know its name, I can override it( I guess, kinda, I hope, maybe) with my additions and then call glide with it, thats already modified and ready to accept additional resolutions.

THE GUESTIMATIONS - AKA GETTING MY BEARINGS
I can peak at the leaked 3dfx sources. Theres some OpenGl stuff there, dont know what they really are. I did build it, but its not working for me.

First I look at 3dfx_source_codeSWLIBSOPENGL.
I open every single file (thats relevant, you dont have to open examples, but you can if you want) in notepad++. Yes all of them. We will theck some keywords if it may narrow down the list of classes and headers that are relevant to our problem. There will be 100+,300+ files opened, but for search results usually it finds < 10 relevant files.

Search all opened documents by some keywords, lets say "resolution", "1600x1200", "1600", "max_res", "0x17", "grSstWinOpen", "grSstOpen".

At this point something relevant was found!



Allright, after a short selection, 2-3 files are relevant.




This would def be what I can correct. But looking at it. Max resolution mentioned is 1024x768.
Looking at the results I got, nah... Looking at the wrong place.
I will keep 2 files, sstcontext.c and sstglide.h, they are semi-relevant. If I dont find anything better will atleast be a start.
But it looks like this is some early alpha pre-release, from a voodoo2 time.

So lets close all OpenGlSRC and look else where, maybe OPENGLGLIDE3X

Fairly crappy results again.
Sometimes things are simple....


For example one resolution that must be valid in openGl context is "GR_RESOLUTION_1600x1024", for glide its considered "extended" and no glide games support it, but its in glide and OpenGl has it for sure. if we dont find this in any form were not looking at the correct classes.
**** ....

So I would say, unless I missed something, even if the leaked sources has the icd, its way to old to help in any way.

DIFFERENT APPROACH

Lets catch the output of game calls to opengl icd, maybe something good comes up.
Useful tool GLIntercept: https://github.com/dtrebilco/glintercept

It logs all the calls from the game, to the opengl icd, this way you atleast see whats getting called. The tools can do a lot more, but for some other time, when Im more familiar.

Log looks something like this


Browsing through it, yea all good. No mention of the part where the icd makes the glide call, but for that to happen, you would have to log one step further. So atleast the conclusion that on the game side, when the calls are made, nothing fancy with any 3dfx trickery is going on.

Oke.. its something, still doesnt really help me.
Lets open up the icd.dll


Well there are atleast method names, for further exploring.
Theres more, I also went into mesafx to check how its handled there, got some good stuff, but I ended the day there. With no resolution.

This is how it felt


Except that there was no hot babe, or waterfall, the duck was there though, and I was drowning and I swear someone peed in the water ....

So this one stays, as ment, for sfft drivers feedback, rambling continues here:
https://www.3dfxzone.it/enboard/topic.asp?TOPIC_ID=36175

No need to test right now, when its done .

My goal for now is just to add more resolutions(for the correct aspect ratio) and update the driver with the newer sources that are out there, wont make any other changes, not really in my reach right now.

If I do learn more stuff along the way, who knows... But for now its just this little thing.