I agree entirely. There is no need to use flags that are problematic and the code is already optimal as you said. I hope the library versions do not require much more work.

I'll search for the comment. Also, the hand written assembly optimizations have small effect (I think this has been documented, too), so the compiler optimizations are not expected to do any good, as you have measured. Like discussed earlier, if even the C path works equivalently, then that's just as well, too (portability).

Having the MMX and other friends help a very minute amount (literally 0.5-1.0 difference in it's favour). It may be worth keeping them though since they won't be optimized away. It's hard to say what's the best solution for something so tricky. I don't think the DMesa/fxMesa crew really knew the potential of it's library.

I read DBorca was hired away (was it VMWare?). If I recall this correctly, it sounds like siphoned the talent from these amazing libraries. There must have been few people who worked on it and explored its potential.

I found (what I think is the only, or one of two references, to the issue) to the -O1 and -O2 problem in glide3: http://sourceforge.net/p/glide/mailman/message/573981/.

I tried to get in touch with daniel borca, but have not heard replies though his emails still work.

His old website says around 2005-2006 (forget specifically) he was hired at bitdefender.

I wanted to send him an email so he could know about how his work ended up panning out like 10-15 years later and that it amazingly works and works properly. But, I also wanted to know some issues with Mesa 6. Never heard anything back from him, I also sent an email to Hiroshi who worked with him a lot of on glide3 project and some DMesa code. No reply either. I hope I can track both these guys down someday though. They probably spent a great deal of time (like I have) trying to get the code to work properly. More than they (or me!) probably have should have...

😀

I'm glad to hear that you have looked into that. And thank you for the details. I agree, too, it has required a lot of time and effort, but as you mentioned, there was a significant barrier to others exploring the potential of these libraries.

I have to eat some dinner and such, but I'll be back later and we can discuss it more.

Thanks for finding this issue on the mailing list... Was there subsequent replies to it?

Yes, I think a few by sezero! There is a link at the bottom to view the entire thread, I just noticed it. I'll check back later, too.

Haha the whole thing was from sezero. I didn't even realize it was him who had the same problem 10 years ago. That's rather funny.

Definitely!

Okay after all that compilation nightmares and clean up involved and crossing between 3 projects its all synced up and all the games work properly in SLI and voodoo 2. I assume the same is in dosbox glide as well.

That's wonderful! It must have been a lot of testing on 3dfx hardware to go through the library versions, the versions of compilers, along with makefile settings (at the least). I look forward to trying the maps with the added features. Thank you for this work.

I'll keep testing in dosbox with internal 3dfx emulation. I haven't actually tried nglide or openglide to see how compatible they are with the dxe configuration.

Edit: qdos/fx with the updated glide3x.dxe runs great in dosbox! The timedemo shows a large increase in frame rate (~7% ; resolution@512x384).

I don't know how good the wrappers are today but like 5-10 years ago they were basically hit or miss if they ever worked properly so I gave up on them.

I generally don't use wrappers myself. I also think their portability is limited.

I edited the above post with some numbers. Your updated glide3 dxe is a significant improvement, measured by timedemo in dosbox, but as you mentioned, also the game runs smoothly.

Maraakate wrote:

I tried to get in touch with daniel borca, but have not heard replies though his emails still work.

I last talked to him via email back in 2003... (has it been that long? Time flies...)

Maraakate wrote:

I don't know how good the wrappers are today but like 5-10 years ago they were basically hit or miss if they ever worked properly so I gave up on them.

Actually, the frequently updated ones are phenomenal.

Both current nGlide and current dgVoodoo are fairly amazing (check out nGlide's massive compatibility list), but they're also both closed source, Windows only, requiring DX9 and up (latest dgVoodoo requires DX11). This does not bode well for the open source scene, for which the newest wrapper is OpenGlide (with some hacks from gulikoza) and/or Glitch64 (the one that came with Glide64), both many years out of date.

To use these with Q2DOS, you'd need to run it in DOSBox with the Glide patch installed, and then select the wrapper choice. The Glide patch ships with using OpenGlide but you can substitute another wrapper. Alternatively, on an old enough machine you may be able to use Glidos and, again, substitute the OpenGlide wrapper it uses.

PS. It's also pretty amazing the Voodoo emulation in MAME/MESS/DOSBox/etc. operates as well as it does, still a ways to go tho. 😉

I tried using the default wrapper in those dosbox builds and saw no true speed improvement but to be fair I ran no timedemos. My PC is a bit too slow to play it properly at 640x480. My main PC is actually a laptop that is off to the side as the "tower". It has a Dual Core Pentium "T2330" 1.60ghz and 2GB RAM in XP. Intel graphics so that could very well be part of the issue.

In any case, I recompiled Mesa 6 and it despite the FitzQuake crash it does work in Qdos/Qwdos and Q2dos. There was no speed improvements though, and multitexturing still appears to be more of a software thing so there is no speed improvment there.

In any case, I'll recompile Mesa 6 DXEs and post it here. I added back in support for resolution changing. They deprecated it in Mesa 5.1 (which I also had to add back in there).

Here it is, absolutely no guarantee.

Here is 6.2.1 which is one frame (oh wow!) faster than 5.1 in timedemos.