Made my own topic, so I can spam a little more. This forum (besides late falconfly forums) had the most "dev" talk, so thats why the topic is here.

How this started, my card has hdmi, plugged it in, straight to 1920x1080! And it didnt work, image smudged. Ok tried vga, works there. Hm.... Maker of my card, Anthony, suggested, its just the wrong timing probably, so I found some online. And there we go. Sharp image that can cut you.

So.... Thats how timings work on the voodoo... Wonder if I can add other resolutions? Found some online, yes they do work!
Ok but what about my lovely 21:9, can a 20y+ old tech drive that? Prob not, but worth a shot.
So I looke at some vesa specs documentation and some strange tv-spec sheets and after quite a while of tinkering got all the resolutions I wanted(for now!) and they do work.
And you can get them here:
https://www.vogons.org/viewtopic.php?p=1051669#p1051669

Desktop and d3d games worked!


But OpenGl games, and glide, but you know, atleast OpenGl games should, but didnt work. The image got letterboxed.


So I kinda suspected its a glide thing and since no one is working on adding features to the drivers anymore, guess I can give it a shot.

I will get into more details some next time, when my experiment - driver is complete, the plan is also to show how you can setup an environment and compile things and how (not saying its good) approach things when Im trying to figure out how stuff work.

Anyway Im not really a low-level developer I mostly work IN.. the in part is important, not ON, game engines, so there will be an ocassional opsie and dont think everything I write is correct, but hey enthusiasm is there and since software side of things are kinda dead right now, it will have to do.

This will be a bit random, some occasional "whats currently going on" and when I have the time Ill do a more coherent informative post.

What I already started in sfft-s topic.

The current state is:
- Having a rough idea how glide sets up the frame buffer
- Being scared of C a bit less, but still some
- Added resolutions to glide3 part of the driver as an extended list
- Using glide2->glide3 wrapper so I dont have to bother with fixing both, made by Ryan Nunn (Colourless - glideXp project)
- Adding the same list of resolutions to MesaFx 6.2, to confirm its not just glide and actually having the source

Now the current problems are
- MesaFx is kinda slow for some older games, good with new, would preffer to use 3dfx opengl icd, but dont have the source (have an interceptor though)
- Can I also override some glide resolutions? Without replacing existing ones and game not supporting it?

And what the long term battle plan is
- Find which glide source works the best for this combo
- Other parts of the driver, what can I take, what cant I take? What combination of things will work the best, specially for win98 that didnt have a update to the drivers since forever.
- Try sffts d3d part on older titles, whatever he did, it works great, just not sure for older games.
- Pack everything together, put out for testing, fix and repack!
- What comes next, depends on the time I have


So currently Im playing with how to handle glide, just glide. Im avoiding openGl since that will be harder for me
I tried just overriding the resolution in the early stage of framebuffer config and it worked. But theres still the question of intercepting the games requested resolution. And from what I can see right now, without patching the game that wont work. Or I have to check some other way...

So as an experiment, I added one more control to 3dfx tools, where I put all the extended resolutions in. Now its posible to pick one, and that will override whatever the game thinks it wants.

Its not the smartest solution, but with this, you solve the resolution request between the game and glide and the games limit to max 1600x1200 (no glide games have more). Some game ofc will lose its **** with this, but some should work. Also fov scaling would have to be correct or have a way of manually adjusting it.
Ui elements should rescale somewhat accurate, but if UI isnt really 2d, but made with meshes, that surely wont work.

I tested in unreal and this is how it looks as a concept. So atleast unreal engine games should be somewhat fine.

https://www.youtube.com/watch?v=IESjpYLQT6Y

Hi Dolenc, I see you have opened your own thread, perfect!

You keep making progress, that's a good sign, now we should start giving you some support, maybe testing your modified driver package. I, as soon as I can, will test everything with my v5 5500.

The search for source files for mesa 6.3 was unsuccessful. If I have any news I will inform you immediately.

I recommend adding a link to your second post, to link to your posts in "SFFT alpha drivers":
http://www.3dfxzone.it/enboard/topic.asp?TOPIC_ID=1129&whichpage=124

Keep up the good work!

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.

OK for testing, let's wait until the changes are finished.

I hope you learn a lot more, along the way, so that you can push for further driver improvements.

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 ....

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....

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...

Well Dolenc, I see your progress is going well, and your monologues too...

After your elaborations, I understand, that you have a clean, bug-free version of Glide3x?
If that's right, that's already a good result. Too bad I can't help you, I have no experience in these things...
Anyway, thanks for your efforts and the time you are devoting to this project.

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

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!

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...

https://ibb.co/FK8qZvK

Hi Dolenc,
sure, at a resolution of 1980 x 800, recovering almost 40fps, forcing rendering and textures to 16bit, is really a great result, congratulations!
You and v5 are doing a really good job.

Are the 128mb helping you a lot in this result, besides the 190mhz VSA/Ram overclock?

I see that override is disabled in 3dfxtool.
I also understood from what you wrote that mesa already has the override option and you enabled it.
So quake2 started at that resolution setting because it was natively set by windows, or did you edit the quake2 config file?

Maybe I asked a stupid question...

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.

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.