The oldest system I have working right now it a Athlon 1.4 with a Voodoo 4 4500.

1024x768

gl_flashblend 1: 78.4 fps

gl_flashblend 0, r_dynamic 1: 85.7 fps
gl_flashblend 0, r_dynamic 0: 95.2 fps

lost77 wrote:

The oldest system I have working right now it a Athlon 1.4 with a Voodoo 4 4500. […]
Show full quote

The oldest system I have working right now it a Athlon 1.4 with a Voodoo 4 4500.

1024x768

gl_flashblend 1: 78.4 fps

gl_flashblend 0, r_dynamic 1: 85.7 fps
gl_flashblend 0, r_dynamic 0: 95.2 fps

Interesting how flashblend is actually slower.
I guess the trend reverses once you go back to the PCI era.

I decides to do some more tests for you. First up is a Pentium 3-S 1.4 GHz.

First number is gl_flashblend, second is r_dynamic

Voodoo 2 SLI 1024x768:

(1/1) - (0/1) - (0/0)
58.1 - 71.1 - 78.7

Ati Rage 128 Pro 1024x768:

(1/1) - (0/1) - (0/0)
37.1 - 42.5 - 45.9

The default mode is still the slowest here. The halo effect from rockets seem to hurt performance quite a bit.

Second system is running a Pentium II 300 MHz (66 MHz bus speed).

Voodoo Graphics at 640x480:

(1/1) - (0/1) - (0/0)
24.1 - 23.9 - 28.2

Ati Rage Pro at 512x384:

(1/1) - (0/1) - (0/0)
19.7 - 10.8 - 20.7

Here is seems the Voodoo is a tiny bit faster in the default mode, the Rage Pro is much faster. These are the type of cards that GLQuake was originally aiming for so it makes sense.

I got some weird results:

K6-2/500 / Voodoo3 (MesaFX 6.2)

gl_flashblend=1, r_dynamic=0: 70.7 FPS
gl_flashblend=0, r_dynamic=0: 69.8
gl_flashblend=0, r_dynamic=1: 32.6

software (WinQuake 1.09): 14.9

^^ I actually did two runs on this machine, those numbers were dead consistent.

Athlon XP 1700+ / S3 ProSavage8 (aka VIA UniChrome onboard)

gl_flashblend=1, r_dynamic=0: 70.6
gl_flashblend=0, r_dynamic=0: 80.9
gl_flashblend=0, r_dynamic=1: 14.4

software (WinQuake 1.09): 81.8 FPS

I did NOT expect such an abysmal result with r_dynamic enabled here. The ProSavage8 is a Savage4 descendant. It actually defaults to flashblend=0 dynamic=1 on this thing, despite using a fresh install of GLQuake with no extra command line parameters or config done. No idea why it basically matched the K6-2's performance in flashblend mode.

All runs were done at 640x480x16 bit (software: 640x480x8 fullscreen.)

That S3 result is very telling of why flashblend was a thing, though this automatic enabling sounds mysterious to me. I never recall seeing a switch in the game code for automatically controlling the variable, so I suspect the driver is doing something fishy, ironically tanking the performance.

A whole pile of GL and display variables show on the console when you start the game on that machine, but they scroll by too fast to read. I can try to get screenshots if it helps.

I wanted to try a Radeon, and this was the only one I had installed & ready to go:

Athlon 64x2 4800+ / Radeon HD4670

gl_flashblend=1, r_dynamic=0: 387.2
gl_flashblend=0, r_dynamic=0: 403.9
gl_flashblend=0, r_dynamic=1: 218.5

Software version was locked to Vsync. This system defaults to flashblend mode, as normal(?).

You should be able to scroll in the console with Page Up.
Vid_wait 0 disables Vsync.

xjas wrote:

software (WinQuake 1.09): 14.9

Umm, wasn't the author asking for tests with GLQuake, not WinQuake?

EdmondDantes wrote:

xjas wrote:

software (WinQuake 1.09): 14.9

Umm, wasn't the author asking for tests with GLQuake, not WinQuake?

Sure I did, but it doesn't hurt to get the performance metric of different modes into the picture. It actually helps put things into perspective. When even software mode runs blazingly fast, you know how much of a bottleneck the OpenGL lightmap updates are.

It's to do with the texture formats involved for slow uploads. It's clearly not BGRA. This was early OpenGL before performance realizations were had.

PIII 1400-S, ASUS P3BF (133/33/89), 768mb PC133 C2, Compaq Voodoo3 3500 AGP (200mhz, 1.07.00 WHQL), 146GB 10k SCSI, Win98SE, Directx 7a.

GlQuake 0.97 (MiniGL 1.45)

+timedemo light -nosound

gl_flashblend 1 // 181.6 FPS

gl_flashblend 0 // 142.1 FPS
r_dynamic 1

gl_flashblend 0 // 235.3 FPS
r_dynamic 0

leileilol wrote:

It's to do with the texture formats involved for slow uploads. It's clearly not BGRA. This was early OpenGL before performance realizations were had.

GL_LUMINANCE is slow? That's counter-intuitive.

The launch parameter "-lm_4" should convert them to full RGBA. Curious to see how that runs in comparison.
On my Skylake with a GTX 760, this switch takes the frame rate from approximately 1000 FPS to 925 FPS.

While its not my place to discourage tests, I recently read this article about how some lighting features simply do not work correctly in GLQuake (somethings called Overbrights.... see the article, it explains better than a non-expert like me could). I assumed the console commands mentioned in the OP would re-enable these but apparently those are for something else entirely.

So, like, is there a way to fix the issues that article presents using GLQuake?

EdmondDantes wrote:

So, like, is there a way to fix the issues that article presents using GLQuake?

No, but it's very easy to mod in, and most source ports are based on a codebase with support for lossless overbrights.
The state of vanilla GLQuake renders the dynamic lights almost invisible, but they are nonetheless fully computed and drawn.
The more grim shortcoming that also affects Quake 2 is the restriction on texture dimensions. Foes in software mode look noticeably sharper, and the only true fix requires OpenGL 2 or newer.

I gave it a run on a few cards. If I get some more time I can run it on a few more cards. They were all tested in an intel d815eea board with a 1400MHz P3S and 256MB of PC133@CL2
Edit: All were run at 640x480x16

Matrox G450 AGP (driver 683, 120/150)

gl_flashblend 1, r_dynamic 0 - 105.3
gl_flashblend 0, r_dynamic 0 - 121.2
gl_flashblend 0, r_dynamic 1 - 8.2

Matrox G450 PCI (driver 683, 115/144)

gl_flashblend 1, r_dynamic 0 - 81.1
gl_flashblend 0, r_dynamic 0 - 90.6
gl_flashblend 0, r_dynamic 1 - 4.6

Matrox G400Max (driver 683)

gl_flashblend 1, r_dynamic 0 - 137.2
gl_flashblend 0, r_dynamic 0 - 157.1
gl_flashblend 0, r_dynamic 1 - 8.4

Matrox G400Max (driver 555) ICD

gl_flashblend 1, r_dynamic 0 - 126.7
gl_flashblend 0, r_dynamic 0 - 141.1
gl_flashblend 0, r_dynamic 1 - 77.2

Matrox G400Max (driver 555) TGL

gl_flashblend 1, r_dynamic 0 - 135.2
gl_flashblend 0, r_dynamic 0 - 151.2
gl_flashblend 0, r_dynamic 1 - 86.4

nvidia TNT (driver 2.08)

gl_flashblend 1, r_dynamic 0 - 76.2
gl_flashblend 0, r_dynamic 0 - 88.8
gl_flashblend 0, r_dynamic 1 - 73.7

intel i740

gl_flashblend 1, r_dynamic 0 - 34.6
gl_flashblend 0, r_dynamic 0 - 40.4
gl_flashblend 0, r_dynamic 1 - 40.3

S3 Savage 3D

gl_flashblend 1, r_dynamic 0 - 36.2
gl_flashblend 0, r_dynamic 0 - 41
gl_flashblend 0, r_dynamic 1 - 39.7

Rage 128pro (125/143)

gl_flashblend 1, r_dynamic 0 - 98.5
gl_flashblend 0, r_dynamic 0 - 115.8
gl_flashblend 0, r_dynamic 1 - 70.4

3dlabs Permedia 2

gl_flashblend 1, r_dynamic 0 - 15.7
gl_flashblend 0, r_dynamic 0 - 17.5
gl_flashblend 0, r_dynamic 1 - 16.6

silikone wrote:

No, but it's very easy to mod in, and most source ports are based on a codebase with support for lossless overbrights. The state […]
Show full quote

EdmondDantes wrote:

So, like, is there a way to fix the issues that article presents using GLQuake?

No, but it's very easy to mod in, and most source ports are based on a codebase with support for lossless overbrights.
The state of vanilla GLQuake renders the dynamic lights almost invisible, but they are nonetheless fully computed and drawn.
The more grim shortcoming that also affects Quake 2 is the restriction on texture dimensions. Foes in software mode look noticeably sharper, and the only true fix requires OpenGL 2 or newer.

How do you "mod it in?"

Also, are there any such sourceports which will run in Windows 98, or will my Win98 gaming PC be best off sticking to WinQuake?

EdmondDantes wrote:

How do you "mod it in?"

I probably made it sound easier than I should have. I meant that you can download the Quake source code and add a few lines here and there involving gl_arb_texture_env_combine. This is what source ports have already done.

Also, are there any such sourceports which will run in Windows 98, or will my Win98 gaming PC be best off sticking to WinQuake?

I believe FitzQuake is a port old enough to at least have builds that run on 98. It has the gl_overbright variable.

You can also try KernelEx

For Windows 2000 I've had luck running XP+ ports (SDL2) with Blackwingcat Extended Kernel 2.9b.

Latest Quakespasm can be compiled with GCC 4.7.2 and should still work with old enough SDL and GL to make 3dfx happy at least. The releases don't.