I also got the absolute last version with 3dfx support working... 6.2.4, requires some code modification to the source and adding a couple of things to the DXE table but it does work.

Hmmm... 86.4 fps timedemo demo1 with 6.2.4 instead of 73.0 from Mesa 5.1 😉

Also dborca just emailed me back and said when he gets back from vacation he's willing to look over some code 😀

Thank you for all the work toward finding a better mesa! That's a large and unexpected performance increase with 624, especially given your glide3 improvements today. At this point, the fxmesa renderer is close or exceeding the alternative. And the open email communication with dborca should prove invaluable! At a minimum, he may recall the advantages of the various versions, also I think he branched from mesa51 and made some game specific changes, and any possible optimizations by small code modifications (possibly mirroring the trade-offs used in the minigl driver).

I also noted your recent tests of the 8-bit texture mode which is insightful. You've opened up very good avenues to possibly enhance the renderer further.

FitzQuake works with it now in Voodoo 1, but on the Voodoo 3 computer it still crashed. I haven't tried Voodoo 5 but I assume results are the same there. Hopefully, dborca can give some insight to that issue.

I got a 3.5fps boost on the measly P1 MMX in timedemo demo1, which was nice too.

The 8-bit texture problem is funny because I explicitly remember numerous times I'd see this weird stuff going on in the distance when playing some Quake games in Windows 98.

I'll have to snap a screenshot of it at some point so you can get an idea of what I'm talking about. I do remember WickedGL making the issue go away. It's quite possible WickedGL may have removed that extension (which apparently according to MESA is a hack that only quake used).

That's good news that fitzquake is showing compatibility, along with a nice speed-up.

Also, thanks for the details on the alternate textures mode. I've been interested in your work on it.

OpenGL has this to say about it:

EXT_shared_texture_palette defines a shared texture palette which may be
used in place of the texture object palettes provided by
EXT_paletted_texture. This is useful for rapidly changing a palette
common to many textures, rather than having to reload the new palette
for each texture. The extension acts as a switch, causing all lookups
that would normally be done on the texture's palette to instead use the
shared palette.
http://people.freedesktop.org/~marcheu/extens … re_palette.html

And I guess it works in conjuction with this: http://people.freedesktop.org/~marcheu/extens … ed_texture.html

So I guess it's a way to save on some memory space too. But it's only relevant for V3 and V5 (probably V4 as well).

I appreciate the details on it. I'll bookmark the web site, too.

Maraakate wrote:

Also dborca just emailed me back and said when he gets back from vacation he's willing to look over some code 😀

That's awesome!

I appreciate latest improvements to fitzquake-dos, including the performance increase!

Yeah, can't believe I missed the changes in the gl_state being setup. I have to test, but maybe it was the 6.4.2 freeze issue also.

I have been working oin getting the gl_mode and vid_restart switching working in fitzquake. It does work but is unstable so it's been a hold atm.

EDIT: naturally it didn't work, oh well.

The client definitely stands apart with its capabilities. If the above issues are 642 specific, then perhaps a difference file (of the gl files) between qdos/fx and fitzquake-dos may help.

I can't isolate specifically what it is because the issues happens in the first version of mesa 6 and there was a big code change in that version. It also only happens on a real computer, at least on my v3 and v5 setups. I haven't tested it on the voodoo 2 yet.

Doesn't sound too bad. I also researched the mtrr stuff and found some source code, although the existing binary for it must work fine. There was a note that the fastvid tool does the same thing, but I'm not familiar with this area. I'm assuming that not all mtrr tools are open source.

It's not exactly the same, there is a complete difference between using fastvid and mtrrlfbe.exe. If you can use fastvid, you can use mtrrlfbe and its recommended over fastvid.

That note must have been incorrect that fastvid enables the mtrr registers, too.

I dont why mtrrlfbe is faster, but it always has been for me on every BX440 board I've tested it on. RayeR may be implementing it differently. You could email him ans ask

His forum posts suggest that workaround code is necessary to enable the mtrr registers on all systems. Unfortunately, I don't yet have a vintage system to test with. I also have to verify whether he has open source code or not.

The implementation looks fairly straightforward, however.