« || »

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?


7 Responses to “Software vs GLQuake: Texture filtering”

  1. deus Says:
    22.06.2009 18:09

    nice observation and well presented.

  2. onetruepurple Says:
    22.06.2009 21:11

    You may also want to add cvars for how particles look – so you can alternate between nearest + pixels and linear + dots.

    In fitz, that’s r_particles 1 and 2. No idea about others..

  3. gb Says:
    22.06.2009 21:47

    I like the antialiased edges in GLquake. The better looking decals, logos, and things like skyboxes, fog and colored lighting.

    I don’t like its weird flat lighting, the fact that it makes flames, torches and candles look bad (do a comparison, I suggest playing coag3_gb in software for once to see the intended lighting), and the fact that it smears the floor textures in front of me :-(

    Also, there’s no waterwarp in GLquake…

    GLquake can in some cases even make walls have entirely different colors than in software. Mostly textures that are only dimly lit.

    I have said this elsewhere, but I’ll repeat it here: The idea to remove the software renderer from engines, “because it’s 1999, man!1!”, seems really dated today. Software rendering is not per se worse than GL.

    Oh if we only had one engine to worry about…

  4. gb Says:
    22.06.2009 21:54

    and also, transparency, which is apparently impossible in software Quake >:-( (Quake 2 and Hexen 2 do it, though)

  5. metlslime Says:
    23.06.2009 01:00

    I just wanted to point out, software quake can’t be perfectly emulated with any of these. The closest you can get is GL_NEAREST_MIPMAP_NEAREST (or perhaps GL_NEAREST) with anisotropic filtering turned up as high as possible.

    The main reason is, opengl determines which mipmap level to use based on distance and surface angle, so that sharper angles (floors in the distance) get a smaller mipmap than surfaces perpendicular to the camera (wall facing you at a distance.) The software renderer will choose only based on distance, and doesn’t look at the angle. This means that walls facing you will be similar in both renderers, but floors will be noisy in software quake and blurry in glquake. Anisotropic filtering helps sharpen those angled surfaces, such as floors, which are too blurry when using opengl mipmapping.

    The other, more minor difference is that software quake only uses 4 mipmap levels, so anything super far away will get noisy because it has no smaller images to mip down to. Opengl generates mipmaps all the way down to a 1×1 image.

  6. Spirit Says:
    25.06.2009 19:15

    Thanks again for these explanations, metl.

    Particles, waterwarp and transparent liquids are things for later chapters. I don’t think that I will go into third-party features.

  7. Bad Sector Says:
    28.06.2009 06:15

    Another minor difference is that software quake doesn’t use perspective correct texture mapping for 3D models, making model textures “wave” a bit depending on the viewing angle.

    Also i think that for small on-screen triangles another rasterizer is used that basically draws a blob of pixels approximating the triangle instead of performing a full triangle rasterization. This has the side effect that some small objects or object far away appear to stand out more in the software renderer than the OpenGL renderer.

Leave a Reply