Gold on our Voodoo

2026-10-24, the wrapper on POD Gold 2.8.

POD Gold's WPOD3DFX.EXE, unchanged, at 2'20" into a race on Beltane, drawn by our glide2x.dll at 1280 × 960 (shown 960 pixels wide).

The project now works only on POD Gold 2.8, the last version released. So the wrapper moved to Gold's builds, the 3dfx one first.

A later Glide

Gold's 3dfx build does not load glide.dll like the first edition: it loads glide2x.dll, and it speaks the later Glide 2 interface (observed, its imports and call sites):

• grSstWinOpen gives the library the game's window, where the first edition left it to be found;
• the frame buffer is locked and unlocked (grLfbLock) instead of the old begin and end calls, and a picture can be written in one call (grLfbWriteRegion);
• grTexCombine sets the texture unit's combiner in full. With one unit and no mipmaps, Gold's setting works out to "the texel", as before.

The library now exports both sets of names, 55 in all.

Two checks Wine cannot pass

Gold's EXEs stay unchanged on disk; the wrapper patches them in memory when it loads, after checking each build's timestamp and the original bytes. Two checks needed it:

• The CPU. Gold knows the processors of 1997 by name. QEMU's (an AMD family 6) is not one of them, and the game quits without a word. The same check sits beside CPUID in every Gold card build but the PowerVR one; the patch makes an unknown CPU a Pentium Pro.
• The desktop. The run then stopped here:

The dialog from Gold's 3dfx build, at its own pixels (captured by the race-loop session).

The game asks Windows for the desktop's colour depth and refuses anything but 16 bits, even though the 3dfx card draws on its own. Wine reports 32 bits for any X display, whatever depth the display really has, so a 16-bit display does not help. The test's jump is replaced with no-ops. The first edition never checked this.

The race-loop session, which now owns the emulated PC, ran each try and found the second patch.

A race, slowly

The same race at 5'11": the seven other cars are a lap ahead.

The race runs at about a frame and a half a second: Mesa's software OpenGL on an emulated CPU again, with showing each frame taking 650 to 800 ms. At that rate the script's short throttle presses fall between frames and the player's car never moves, while the seven others race on.

How it is known

• The calls Gold's 3dfx build makes and their arguments: observed, imports and call sites.
• That it reaches a race at 1280 × 960 through our library, and the speed: measured, the race-loop session's captures and the library's log.
• That the CPU check is the same in each Gold build: measured for the 3dfx build, inferred for the Direct3D, ATI and S3 builds until they run.

What is next

• Gold's Direct3D build, next in race-loop's queue.
• A faster way to show a race in the VM, or a host with a GPU.