I was also able to get all the LFB mode stuff working now in win9x too.

Also, on the P2 400 the DOS binary is actually about 8-12fps faster on average (via timedemos) in a win9x dos box then the native win32 binaries, haha.

Wow, I can't believe how quickly you expanded the code of q2dos (and qdos, too) toward compatibility with the dos box. I'm glad to hear of all your results (including the code updates), especially that memstats extends to high memory systems and the performance advantage of q2dos in 9x versus win32!

Impressive work on making the LFB modes compatible. I didn't know whether that would happen. That's very good news.

It's also good not to have any items in the "not working column", except maybe for the opengl "optimized" stuff. 😀

The WOD X crash I haven't seen in a long time and I think it was partially related to something specific with the rogue (or xatrix?) code for one of the new effects. Now that it's using ASM anyways that part is skipped and the effects work anyways.

That's great. I noticed (some) mods don't document their dependencies well, although I think all your fixes to the code corrected both known and unknown issues which is fortunate.

DDay is a terrible mess. We still haven't cleaned it all up to compile properly with -Werror.

Not surprised on that, but I appreciate your work toward that mod. There is a recent thread on the dday forum about running the mod on the software renderer and the lack of bots. I believe they concluded that the code is not compatible, but the bots were actually inactivated by random placement of math symbols in the code and the other thing was already fixed by your efforts. 😀

Earlier today I was able to convert the Win32 ASM for R_PolysetDrawSpans8_Opaque which now allows the IR goggles effect to work properly in Rogue. Sezero also spent a great deal of time cleaning up a major amount of GCC warnings from DDay.

That's impressive work. I think that's the first time the win32 specific asm from the Quakes has been translated to gcc, especially important to the workings of Rogue. I look forward to trying it out and the particulars of the translation. Thanks! I like that expansion pack because it includes new gameplay and the maps seem unique in design.

Also, I appreciate the time and fixes to the dday code!

I recently came across the attached vector math header file. I believe it should allow the compiler to inline the "C" vector math functions automatically, saving the function calls. Perhaps it makes no significant impact....

I may just take Quake 1's ASM for that remaining function and just add the extra stuff by converting the win23 inline to ATT ASM. It's basically about the same as far as I can tell except the for loop for the blend particles has some slightly different math. Once that's done all the ASM will be shared among win32/dos/*nix

That's a great idea. I look forward to trying all updates. Fortunately, your project isn't on sourceforge. Their service has been down for some time.

That's if I get around to doing it. I'll have to learn how to do tight loops and all. I really need to start reading Abrash's ASM book to get an idea of what's going on. The rogue addition was fairly simple as it's almost the same code with a few extra pointers and compares.

The particle code seems fast already, and I couldn't tell the difference between asm and C versions in a win32 build. I like the idea where you inlined the major C function calls there.

Looking at the asm versus C, it seems fairly similar in structure and I wonder why it's commented on the latter's performance (is it just a few % difference). Perhaps the newer compilers do better with that code (notwithstanding SSE optimizations).

I'm guessing it was mainly for the vector stuff so it was using fast float ASM. It uses special fl** ASM stuff. I haven't checked what GCC outputs but it may be generating very similar code to take advantage of using it for the vector functions.

On a P90 maybe the ASM stuff really made or broke the framerate when a lot of particle explosions/etc were happening? You really need at least P166 to play it a mostly playable framerate at 320x240 for Quake 2 anyways. And that's like what I would say is bare minimum. Larger maps later on in the game and rooms with lots of enemies might bring it down to 15-20 fps but I never played it on anything that slow (the slowest I have is a P200 and it's for the most part pretty playable).

And yes, the SSE stuff makes quite a difference with particle effects on my P3 550 when compiled requiring SSE and optimizing for it. On demo1.dm2 near the end where there's the explosion by the bridge on regular q2.exe it has a slight slow down but with the SSE build it still chugs along fairly fluidly.

That's very interesting, thanks for the details. I was just thinking the same about any bottleneck was likely identified by bench marking on the minimum CPU required for Q2.

I did search for an x86 library of vector math functions, but mainly the examples use SSE as a target.

Attached patch for x86/87 dotproduct() function which is now active in r_part.c. No discernible performance change (~2% less fps), but it may be worth verifying any effect in timedemo/demo1. Also, it may provide hints toward future code changes.

Additional changes to save cpu cycles: this version of the patch has no performance deficit versus without it applied.

Compared the timedemo result between a case where the C function "R_DrawParticle()" is active and a case where this function is empty of code. For the map demo1.dm2, both result in 20.3fps. I have only tested in dosbox.

Even if dosbox doesn't have full advantage of the fpu function, it still should be verified because the particle function should incur some timedemo penalty. If the penalty is very small, then it is difficult to test by this method.

Also, even though this function was disabled, I noted that the "explosion by the bridge" still occurred. It must be generated by a different function than "R_DrawParticle()", so any slowdown there should be present in the original win32 Q2 client.

I haven't tested any of this code yet. Been taking a break for a few days from all of this.

Attached patch for x86/87 dotproduct() and part of R_PolysetCalcGradients() function. This code is now active in r_part.c and r_polyse.c. Tested in dosbox with comparable performance to without patch, but untested in pure DOS which has full advantage of the x87 code. Patch also provides hints toward translating the remainder of the R_PolysetCalcGradients function.

In addition, lines are removed from assembly files which are not used by the current code base.