VOGONS


First post, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

Recently, I've been on a mini-mission here to run all sorts of benchmarks and trying various combos testing against windows with the opengl icd, wickedgl and mesa dll drivers all compared to q2dos with mesa.

The computer I'm testing all of this on is a slot 1 p3 800mhz, overclocked to ~900mhz. This is very similar to the official test machine 3dfx used for the Voodoo 5 5500 AGP according to http://www.falconfly.de/downloads/3dfx-v5-PC- … ewers-Guide.zip. I am using AmigaMerlin's 2.9 driver.

Something very interesting occurred during testing. I found out by accident that multitexturing in high res modes is much faster when I ran glquake (glquake by default checks for multitexturing and has to be explicitly disabled with -nomtex otherwise) compared to QDOS with Mesa (resolutions 1280x1024 and 1600x1200). I reenabled the multitexturing code in QDOS and added to check for ARB multitexturing in GLQuake and fallback to checking for SGIS. 3dfx OpenGL ICD uses SGIS, but Mesa and WickedGL use ARB. After that was all set in place I found the same results across the board!

I took it a step further, tried it on Q2DOS and found out the same thing. Now, it only helps 1280x1024 and 1600x1200. 1024x768 and lower suffer substantially, and this effect is mirrored in all the windows drivers I tested is well.

Later on, I tested 32bpp modes with and without multitexturing enabled and found they perform much faster with multitexturing on at 1024x768 and higher. Lower resolution will suffer with multitexturing on and 32bpp.

So for those of you out there with P3 machines and a Voodoo 5 5500 it might be worth testing out multitexturing at 1280x1024 to be able to play it in high res modes at comfortable frame rates (it will still dip to 40-50 sometimes in more complex scenes, but for the most part is playable at least on my setup).

Reply 1 of 6, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

Here are my findings in Quake 2:
q2_mesados.png

q2_mesawin.png

q2_opengl.png

q2_w3d.png

16M and 32M are with multitexturing. Bilinear filtering with point parameters disabled as it causes speed issues with Mesa (DOS or Windows). No 8-bit texture mode. Default driver settings in Windows with V-Sync Off. Q2DOS uses FX_GLIDE_SWAPPENDINGCOUNT=6, MESA_FX_IGNORE_CMBEXT=1.

Computer is a Pentium 3 800mhz overclocked to ~900mhz on an Asus P3B-F. 512MB RAM. Gravis UltraSound Extreme/Synergy ViperMax. Sound was ON for these tests. Smartdrv /x and UMBPCI with Doslfn for DOS.

Oh, and timedemo 1; demomap demo1.dm2

Reply 2 of 6, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

Also forgot to mention that Q2DOS was compiled with forced SSE optimizations as a static ref_gl. CFLAGS+= -mtune=pentium3 -march=pentium3 -mfpmath=sse

This gives anywhere from a 2-10fps boost on average depending on the scene. But when I got into higher clock speeds it more hovered around 2-5 fps boost on average running timedemos.

Dynamically linked forced SSE builds are the same speeds as static linked SSE builds but they have some stability issues when changing resolutions sometimes, so I opt for a static linked build.

Reply 3 of 6, by Gamecollector

User metadata
Rank Oldbie
Rank
Oldbie

Well, I wish this project was updated with the standard glide2x.ovl support...

Asus P4P800 SE/Pentium4 3.2E/2 Gb DDR400B,
Radeon HD3850 Agp (Sapphire), Catalyst 14.4 (XpProSp3).
Voodoo2 12 MB SLI, Win2k drivers 1.02.00 (XpProSp3).

Reply 4 of 6, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie

Too bad, not converting the entire project over to Watcom so people can emulate it. This is intended for people with actual systems. Download the source and recompile for Windows in VS6 as it all cross compatible.

This has been covered before but I'll explain again that the entire input, sound, video and base system code (specifically the timer is of big interest) to Watcom. Then the entire Mesa and Glide projects also need to be converted and Mesa by itself is a huge project. Totally not worth the effort and headaches.

Tell your wrapper authors to add glide3x.dxe support if it such an issue to you. Source for Glide3 is available to learn from so to the right person it could be feasible to do so.

Reply 5 of 6, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
Gamecollector wrote:

Well, I wish this project was updated with the standard glide2x.ovl support...

I agree, but think the onus is actually on people like gulikoza and others to make glide2x.dxe / glide3x.dxe wrappers (and support in DOSBox if possible).

That said, it would still be an open challenge for the other side: no one's compiled a Watcom Glide game in years and years... 🤣

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 6 of 6, by Maraakate

User metadata
Rank Oldbie
Rank
Oldbie
Stiletto wrote:
Gamecollector wrote:

Well, I wish this project was updated with the standard glide2x.ovl support...

I agree, but think the onus is actually on people like gulikoza and others to make glide2x.dxe / glide3x.dxe wrappers (and support in DOSBox if possible).

That said, it would still be an open challenge for the other side: no one's compiled a Watcom Glide game in years and years... 🤣

100% not happening from me as DJGPP provides the needed DLL interface properly in DBorca's DXE. DJGPP also allows the code to be easily cross compatible to linux code and since we compile with GCC we can use new gcc updates to help us find more problem and produce better and faster code.

To prove a point with it, I backported heretics dos subsystem back to linuxdoom released source code to produce a watcom binary and made some small updates to it. I then was able to succesfully port it to DJGPP and gcc found a lot of warnings, some of them down right scary in the original code!