Category: Software vs GLQuake

Software vs GLQuake: Non-square pixels

Welcome to a rather short part of the Software vs GLQuake series. It came up at func so I quickly wrote it.

Lava_Croft once taught me about another quite nasty and overlooked regression in most GL engines. Textures that are not sized in a power of two (64, 128, 256 etc) are getting rescaled. And with that the pixels are not square anymore but a huge mess of distorted uglyness. This is most easily seen on a weapon skin so I used that in the image below. The Shambler’s face also is a good place to spot it. On the left is software Quake (argh, Argh, ARGH! The high FOV is to blame for that, sorry.), in the middle a bad GL engine and on the right a good one. From what I know at least Fitzquake (of course!) and Darkplaces fixed this.

Software vs GLQuake: Fullbrights

This is another part of an (hopefully) ongoing series of posts showing some differences between the original software rendered Quake (quake.exe, winquake.exe and derivates) and hardware-accelerated GLQuake (glquake.exe and derivates).

Fullbrights are parts of textures (that includes model skins) that are always displayed in full brightness regardless of the surrounding lighting situation. There are also engines that support making whole models fullbright (for example for better visibility in competitive dueling). Those are usually called “fullbright skins”. That’s not what this is about, it is about the parts of textures that should always be brightly lit.

Notable examples in stock Quake would be the slipgate teleporter sockets and of course all the blinking red buttons. Many light textures also have fullbright parts in them but those are not as noticeable as they usually have an actual light source nearby (normally textures do not emit light in Quake but mappers have to place light “points” into the levels).

Fullbrights were part of Quake, good modern engines show them. GLQuake does not. Let’s take a look, left is what GLQuake shows, right is what an engine with fullbright support shows:

Let’s look at the technical background. Quake uses a palette file to assign colors to numeric values referenced in the texture files. The last 32 colors (two rows) in that palette are “fullbright”. The upper 16 ones are obviously used for fire effects so let’s ignore those. The lower (bottom) 16 are “the fullbrights”. By the way if you ever had really funky colors in Quake while playing some mod, chances are that there was a palette mismatch.

So far so good, but why does GLQuake not display fullbrights? The answer lies in the colormap file. “The colormap is a table used for lighting in software Quake engines. It contains a column of 64 values per each palette color. Each value is an index into the palette representing as closely as possible the original color brightened or darkened: shade 0 is double bright, shade 32 is the original color, and shade 63 is black.” The shades go top to bottom. If you remember the previous article about Overbright Lighting this might sound familiar. The shades 0-31 are where the overbrightness comes from.

Now if you look at the right side of the colormap you will notice those 32 fullbright colors again. This time as solid unshaded bars unlike the other colors in this image. The right-most ones are the fullbrights again. And since software Quake takes the color values from there it will display them always like that. Easy!

Well, as you might have guess now GLQuake does lighting completely different and does not use the colormap. Instead it treats all colors equal. Engine coders have to explicitly hard-code the fullbrights into their engines if they strive to make Quake look good.

This occasionally leads to ugly texturing disasters when mappers use bad tools to make their textures and test with stock GLQuake. Then sometimes fullbright pixels sneak in. A recent example being – Temple Of Anubis: Judgement Of The Dead and an older much worse example – Brumal Quest.

Thankfully most good 3d-accelerated engines do support fullbrights. aguirRe’s glquakes being the notable exception at the time of writing.

References used:
Quake Wiki on Quake_palette#Colormap
Metlslime’s Quake Texture FAQ
and czg’s wisdom

Software vs GLQuake: Overbright lighting

This is another part of an (hopefully) ongoing series of posts showing some differences between the original software rendered Quake (quake.exe, winquake.exe and derivates) and hardware-accelerated GLQuake (glquake.exe and derivates).

It is not widely known but overbright lighting can be crucial for a map’s looks. What is overbright lighting? Quoting metlslime:

The original quake (software) engine used overbright lighting, which means the lightmap brightness can go up to 200%. So, light.exe creates BSP files with lightmaps that go up to 200%.

In glquake [...] there is no overbright lighting, so every part of the lightmap that goes above 100% is flattened to equal 100%. This is why glquake looks just fine in darker rooms, but in bright areas the lighting looks very flat.

[Some engines] restore the overbright feature of the software renderer, so that lighting hot-spots will actually be as bright as intended.

Software    /    GLQuake    /    Overbright GLQuake

At least the following engines support overbright lighting: Fitzquake, Joequake, Qrack, QMB, Darkplaces, MHQuake, TomazQuake. In Fitzquake it is controlled by gl_overbright (default is on), I did not check what the others use (if they let you toggle it). aguirRe is a strong opponent to it, so his Enhanced GLQuake has no support for this, see below.

This was another feature I lived without for ages and did not know what I missed. It is very easy to overlook this when being blinded by GLQuake’s freshness at first. For me it makes a huge difference in atmosphere, look at this example from the start map.

While the non-overbright screenshot looks good and innocent, once you see the one with overbright lighting enabled the blandness becomes obvious.

However, there is another view on this which aguirRe presented a while back at func. The screenshots below are made by me, I guess they show the correct subject. It is an extreme example, probably the most extreme one can find. Not only are the ikwhite textures quite sensitive to colour settings, this extreme brightness is only to be found at this one spot in the map and it’s some kind of skylight.

It probably becomes even more of an issue if you play with idgamma and/or a brighter gamma setting. I don’t and I have no problem with the drawbacks (one could even say that it is the 1996 way to make HDR bloom blingbling, heh). In this particular example (kjsp1) I like the look it creates, it is so bright that you cannot see it all anymore. It really is your decision but I suggest using overbright lighting.

Software vs GLQuake: Texture filtering

This is part 1 of an (hopefully) ongoing series of posts showing some differences between the original software rendered Quake (quake.exe, winquake.exe and derivates) and hardware-accelerated GLQuake (glquake.exe and derivates).

When you launch GLQuake the first time one of the most prominent difference are the filtered textures. Where software rendered Quake showed each and every pixel, the textures in GLQuake are all soft and smooth. Some will say “hooray, no more pixels”, others might be “this looks washed out, I miss all the crisp details”. Let’s look at some screenshots (I recommend using browser tabs to switch back and forth):

I myself was amazed by it when I got a 3Dfx card, I really loved it. Then last year I tried the original look again and wished I’d done so much earlier… Well, it is a personal thing and you have decide it for yourself. Thankfully you can configure most GL engines to disable the filtering using the gl_texturemode cvar.

The options available might vary based on your graphics hardware (and maybe the engine too?). This list is taken from the ezQuake documentation (remember, ezQuake is not a singleplayer engine):

GL_NEAREST Point sampled (software-like). Lowest quality, highest performance.
GL_NEAREST_MIPMAP_NEAREST GL_NEAREST but with a bit more quality for far objects.
GL_NEAREST_MIPMAP_LINEAR GL_NEAREST but with even more quality for far objects.
GL_LINEAR No blending.
GL_LINEAR_MIPMAP_NEAREST Bilinear interpolation.
GL_LINEAR_MIPMAP_LINEAR Trilinear interpolation. Highest quality, lowest performance.

On modern hardware you can (and should) always use the *_MIPMAP_LINEAR modes for best quality. So for the original look you would use “gl_texturemode GL_NEAREST_MIPMAP_LINEAR” and for the GLQuake look “gl_texturemode GL_LINEAR_MIPMAP_LINEAR”.

I have this bind in my autoexec.cfg to play with it:

alias pixel_on “gl_texturemode GL_NEAREST_MIPMAP_LINEAR; bind o pixel_off”
alias pixel_off “gl_texturemode GL_LINEAR_MIPMAP_LINEAR; bind o pixel_on”
bind o pixel_on

Maybe you will convert to pixelquake too?