The Matrox Mystique vs. GLQuake: An Ancient Challenge

“So, uh, what’s a Matrox Mystique?”

Matrox is a company which designed video cards for IBM compatible computers, along with a selection of other multimedia-centric devices. In the 90s they were competitive in a crowded market, and the Mystique was a card they offered at the dawn of consumer-level 3D accelerators in 1996. It was the first video card I ever bought, and its marketing touted capabilities as a singular solution for fast, high quality 2D and video playback as well as video games.

The Matrox Mystique. Image found at http://www.512bit.net/matrox/matrox_mystique.html

For 2D desktop work and video playback, it delivered. Video looked great, 2D was fast and fluid, and it was a major upgrade over the integrated video on my old Compaq Pentium 90. The Mystique also offered quality VESA video mode support, which was useful for the bevy of MS-DOS games still widely available. The 3D was an unfortunately different story. Their previous, well-received card was the Millennium, which offered some very basic 3D acceleration of line drawing and geometry. Matrox built upon that technical foundation for the Mystique but prioritized speed over quality while aiming to keep the complexity of the chip economical. Consequently, they left out so many rendering features that the card didn’t actually *work* with most games that came out afterward, or a fair number that already existed when it was new.

Here’s a snapshot from the first room of Jedi Knight: Dark Forces II, as rendered on a Rendition V2200. Note the cloudy but undeniably translucent glass on the windows, showing proper alpha blending support. The texture filtering also softens the harsh edges of textures.

While the resulting graphics chip was fast, the omitted features put the Mystique at a serious disadvantage. It was reliably possible to run games in higher resolutions and color depths than early Pentium-class CPUs at the time, but the improvement in visual quality was minimal, and the unsupported features created compatibility issues that kept many games from running… like Quake.

And the same scene, captured on the Mystique. Note the stippling in place of proper transparency for the windows, which makes them look screened. Texture filtering is also nearest neighbor, causing the entire scene to look chunky. There’s also corruption of the graphic elements of the heads up display, probably related to the lack of proper alpha blending.

“So why do you want to run GLQuake on one?”

Nostalgia’s a weird thing, and I can’t help imagining that the Mystique could have managed the game better than the 90 MHz Pentium I had at the time. It’s been more than 20 years, so maybe somebody’s figured out a solution. Let’s walk through a hypothetical, here. Indulge me.

The Mystique was frequently sold in a 2 MB configuration (like mine), with an upgradeable slot allowing the connection of a 2 MB module (for a total of 4 MB, like the upgrade I bought), or an expensive 6 MB module (bumping it up to 8 MB). For best results, you’ll want at least a 4 MB Mystique to accommodate GLQuake. If you’re one of the lucky few with an 8 MB edition, that will be more than enough to avoid memory constraints. The 2 MB model wouldn’t manage well above 400×300 or so unless you get aggressive with texture downsizing… which we’ll discuss in a bit.

Getting Everything Set Up
* Download and install the latest Mystique drivers for Windows 98/Me. The 2K/XP drivers have no 3D support, so if you’re running NT 5+, you’ve effectively only got a 2D card.

* Get Quake. Install, patch, and then install the mission packs, because they’re terrific. Shoutout to the Shrak and Malice total conversions too, as well as Impel Productions’ unofficial third mission pack.

* Install GLQuake 0.98. Don’t bother with third party source ports; they’re generally intended for newer hardware, and most aren’t tested on Win9x.

* Due to hardware limitations the Mystique only officially supports the Direct3D API, but a few miniGL “wrappers,” which translate the subset of OpenGL calls GLQuake needs to Direct3D, do exist. You have a few options for coaxing GLQuake and the Mystique into talking to each other.
+ Scitech GLDirect was well known once upon a time, and may work for the Mystique. It can be downloaded free of charge with source code from SourceForge.
+ The beleaguered, widely loathed Virge line of cards by S3 eventually offered a wrapper. As it happens, it also works on *any* vintage Direct3D-capable hardware, but can be kinda buggy. It’s pretty easy to find, too.
+ The developer Techland made a similar wrapper, but it does not feature any workarounds for Matrox’s hardware limitations. I’ve had trouble tracking this one down.
+ Whichever you decide to use, take the opengl32.dll they offer and copy it into the same folder as glquake.exe.

* Crack open Quake’s autoexec.cfg file in the quake/id1 folder; if it isn’t present, open a text editor and save it to /quake/id1. Add these lines with command variables (“cvars”) to it.

gl_texturemode GL_NEAREST
Sets texturing to nearest-neighbor, sans mipmapping. This is pretty much the only supported texturing mode for the Mystique. Since GLQuake doesn’t bother with mipmaps on fluid surfaces or models, they render correctly; if you don’t pass along this parameter, the rest of the game is rendered as flat untextured polygons.

r_dynamic 0
Disables dynamic lighting, as cast by fireballs, torches, explosions, and other exciting in-game light emitters. This looks swell, but dramatically slows performance on cards that don’t support multitexturing. On most slower hardware the cvar gl_flashblend, which replaces dynamic lights with a glowing translucent sphere, is the best solution. Since the Mystique can’t render transparency, it instead draws an ugly, opaque blob that’s about as sensible and realistic as a cement cloud. The only reasonable solution is to disable dynamic light completely. Note that static lightmaps aren’t affected and still look fine.

r_picmip 1
Reduces texture resolution by a power of 2 to whatever argument is fed to it. For hardware without much video memory bandwidth, it can make a big difference. r_picmip 1 halves texture resolution; r_picmip 2 reduces texture resolution to 1/4th. If you’re running a 2 MB Mystique, start with r_picmip 3. Note that the game will be quite ugly with this level of detail reduction, as a source 128×128 texture will be reduced to 16×16 pixels.

r_playermip 1
Performs texture quality reduction on player models, using the same rules as r_picmip for textures in general. This setting shouldn’t matter unless you’re doing multiplayer, in which case I hear r_playermip 2 is the sweet spot.

Save autoexec.cfg. Open a new empty text file and save it to the root quake folder as MystQ.bat. Copy and paste the following into it, and save again.

glquake.exe -width 512 -height 384 -bpp 16 +mlook %1 %2 %3

This sets the resolution to 512×384, locks a 16-bit video mode, and permanently enables mouselook. Feel free to substitute 400 and 300 for width and height respectively, for better performance. The percentiles allow for additional command line arguments to be passed along, for playing mission packs and the like.

Additional tips:

* Assuming any of this works, remember that the Mystique is *not* fast; 512×384 may still be optimistic. This was meant to be an improvement over the days of 320×200 in 8-bit color on pokey CPUs, and assuming proper behavior from the driver the Mystique should be at least a little better. Even something like 3DLabs’ Permedia2 from a year later blows the Mystique away in terms of feature set and overall quality.

* All said and done, this will look like a software renderer running in 16-bit color. Everything I’ve seen suggests that the 8-bit lightmaps baked into Quake aren’t handled any differently in GLQuake.

* If you’re spoiled by modern performance standards, this is going to be a rude recalibration. I’d be surprised if a Mystique manages more than 512×384 at framerates acceptable when the Playstation was in vogue.

Quake isn’t terribly forgiving of old hardware limitations, but it just might be possible to get all of this working. Maybe I’ll give this a shot in early 2018.