One graphical feature that GLQuake omitted over its software rendered counterpart is the dynamic lighting that was used profusely throughout the game, supposedly to save a non-trivial amount of performance. Luckily, a console variable lets one restore this lost feature that makes the game really shine. Entering gl_flashblend 0 into the console replaces emulated lighting in the form of transparent spheres with the proper illumination model. Because of this alleged performance penalty on time-appropriate hardware, I propose that this should be tested to get some actual numbers.

I have attached a Quake demo that stresses the lighting routine of the game. This is to be run both with and without the dynamic lighting. For a more direct comparison, gl_flashblend should remain 0, and the related variable r_dynamic should be toggled instead.

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.

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.﻿

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.

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.﻿

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.

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide

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.

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.﻿

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.

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.﻿

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@CL2Edit: All were run at 640x480x16

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?

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.

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.﻿

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.

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide